Part 3 Card Game Demo
Video Activity
This lesson offers a demonstration of the Elevation of Privilege (EoP) card game. This game was developed by Adam Shostack who is a Product Manager at Microsoft and the main goal is the identify bugs and security holes. Participants receive step by step instructions along with diagrams as to how to play this game.
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
or
Already have an account? Sign In »
Video Description
This lesson offers a demonstration of the Elevation of Privilege (EoP) card game. This game was developed by Adam Shostack who is a Product Manager at Microsoft and the main goal is the identify bugs and security holes. Participants receive step by step instructions along with diagrams as to how to play this game.
Video Transcription
00:04
Hello and welcome to the secure coding course. My name is Sonny Wear, and this is tthe e Threat modeling section, where we specifically look at the elevation of privilege card game. Now, first of all, some information about the game itself.
00:20
It was developed by Microsoft product manager Adam Show Stack,
00:25
and he actually has a full book on threat modeling, which is a very good read
00:31
if you are interested in getting into more details about it.
00:35
And so you confined his book on Amazon
00:38
now, in order to play the game, you really need to start with some sort of data flow diagram or architecture diagram of your system,
00:49
and it needs to have enough detail there
00:53
where implementation details are shown.
00:57
And this is mainly because you're going to be looking for flaws in the design or in the programming
01:04
Thio to basically exploit when going through the car deck in order to gain points.
01:11
Now, the card game rules are pretty simple.
01:15
Each team consists of 3 to 6 players. There's a deck of 84 cards.
01:22
There are six suits. Each suit is based on one of the letters have stride, so there's you know a suit for spoofing a suit for tampering, etcetera.
01:34
The cards are, as you would expect, there's numbers two through 10. There's an ace, a king, a queen and a Jack.
01:42
Now, as you go around in one turn,
01:46
the highest card is going to take the trick. Whoever starts the suit
01:52
and that is the case, unless someone has an elevation of privilege card.
01:59
So the elevation of privilege card can trump
02:02
any suit that is started for that round
02:07
and take the trick. Obviously, you're if you have an elevation of privilege card, you're gonna have to actually play it. You're gonna have to actually
02:15
determine where there is an elevation of privilege, vulnerability or or exploitation that can be done on the game board.
02:28
Mechanics. Here, you deal the cards clockwise. You're going to read your card
02:34
and announce your threat when it's your turn.
02:38
What you should be asking yourself internally is,
02:40
you know, is this threat applicable
02:45
if the player with that card cannot link the threat to the system designed that's being used
02:52
either because it's not applicable or because there may actually be a mitigation that is identified on the diagram
03:01
to address that threat, then
03:05
they would just The play would just proceed to the next player, and no point would be awarded.
03:12
Now, though, there are points awarded. The main goal behind this is obviously to identify bugs
03:19
identify security design flaws and security holes
03:23
within the architecture. Now, before you can actually start playing the game, you need to actually take some time to go through an architecture diagram.
03:37
Now what I'm showing on the screen is something that I have put together. I made this system up. It's it's not a real system,
03:45
however, it has a lot of features that are common for Web applications and backend systems.
03:53
And so what I've done is
03:54
I actually am describing
03:58
various aspects of the application. It's multiple tears,
04:03
as well as describing how some of the application code has been written. In other words, what techniques may have been used, for example, to authenticate user etcetera
04:16
and
04:18
in order to help facilitate the playing of the card game,
04:24
you really need to study
04:26
the picture for for a little bit of time to get an understanding of
04:32
of what all is actually implemented for this particular system. Now
04:38
I realize that I'm creating something here, fictitious. In reality, you would do something you know based on a real system,
04:47
and either you would have programmers at the table.
04:50
Designers at the table Business analysts are a conglomerate of different viewpoints that would know the particular aspects, in particular protections that maybe in place in the particular way, that something might be coated.
05:08
So let's take, for example, this password reset flaw so
05:14
you can see appear from the authentication authorization provider
05:18
that is used in the application server. That's over on the back end
05:24
that I've put in here a note that there's a password reset flaw. In other words, there's no prompt for the old password when the user goes to reset their password.
05:36
Now what that means is that
05:41
I'm pretending to be the coder or the designer,
05:45
and I know for a fact that this system has has this flaw.
05:50
What that means is, while the game is being played, this is a potential exploitation potential area that could be exploited by an attack. If you get the spoofing card,
06:03
then you could actually use this particular weakness,
06:09
spoof it and then you get a point And then, of course, the added dimension is you would add that to your dear it bug tracker or whatever your bug tracking mechanism is
06:19
in order to follow up with with that finding to see if it does indeed need to be mitigated redesigned.
06:30
So if we start looking at the cards and reading the particular attacks,
06:35
what we're going to do is, well, read a card, and then we'll see if we can find an exposure point back on our application are fictitious Acme Application. We'll just call it act me to in order to give it to a name.
06:51
So this particular card, the seven of spoofing, says an attacker can connect to a server or peer over a link that isn't encrypted okay or isn't authenticated either. One.
07:05
So back in our picture, we actually have an FTP account that's used course FTP. It's unencrypted,
07:13
and it's being used between the Web server and the database. Let's take a look at that.
07:18
If we go back to our picture,
07:21
we take a look at our Web server. We can see that there's a connection point between the Web server and this sequel data,
07:31
and
07:32
it says in the notes here that FTP runs on Port 21
07:38
the account's still uses a default password.
07:42
Everything is in clear text, and we don't have any kind of integrity check
07:46
that is being done, even when after the files were transferred.
07:50
So that's definitely an exposure point. We would give ourselves one point for finding that
07:58
and then move on to the next card.
08:01
So the next card that we see here is tampering. It says an attacker can alter information in a data store because it has weak ankles or includes a group which is equivalent to everyone
08:16
now on the picture. And I'm going to go back to the picture and show you we have our Web APP server actually connecting to cloud storage, and that connection is using a shared password. So this would definitely be an example of a weak ankle.
08:33
There's no type of authorization code being done or token or anything like that. Let's take a look at it on the picture, and it is connecting external to to the actual data center where this epic case resides. It's going outside of that
08:54
out into the Internet
08:56
to connect to this third party storage, and you can see the note here, it says uses hard coded password fixed key inside of AB code to connect to the cloud storage uses a shared key,
09:11
so we would give ourselves a point for finding that vulnerability and, of course, add add it to our bug tracking system.
09:20
And so as we returned to the deck,
09:24
we would continue to look at each particular suit and the type of vulnerability
09:31
that can be
09:33
either exploited or is being mitigated against in your system. So we've got repudiation,
09:41
information, disclosure,
09:43
denial of service
09:46
and, of course, the elevation of privilege.
09:52
So one last thing to bear in mind if you're not familiar with what the mitigation strategies and technologies maybe
10:01
please refer to either this slide. Or
10:05
you can go back to the theory lecture that we just went through before this video and review those mitigation techniques
Instructed By
Similar Content
