My shopping cart
Your cart is currently empty.Continue Shopping
Adam Shostack and Mark Vinkovits explain how to play the game with worked examples. This part of their talk at the AppSec Cali conference drew on their years of experience of putting games to work. They showed how games can resolve problems in scenarios where other kinds of collaboration don’t work as effectively.
If you’ve missed the first transcript of the Adam and Mark’s session, you can find it here:
[MARK] So who do you play the Elevation of Privilege Card game with? Our experience, at least the way that we apply this in LogMeIn, is that having 5–6 engineers in the room together with someone from the security team is the best way to have a good pace at which you are working. Obviously involve quality engineers. Very rarely, we get the chance to have a product manager in there, which is always a fun experience.
So you get these people into the room and you hand out the cards and you explain that this is actually just a regular card game, only that the suits are replaced with elements from the STRIDE model and the basic rule is that there is a calling card, After that everyone should stay in suit. We’re going to show that whenever you’re playing a card you should read out what’s written on the card and work with that and you play until you have time or you run out of cards.
Very importantly you also should appoint someone to take notes. Hopefully someone who is familiar enough with the system that the notes they are going to take are going to be understandable for the people in the room later on.
[ADAM] So we have here a simple little diagram, what I created for this deck ten years ago.
This was part of one of our training exercises. It’s an integrity monitoring system like Tripwire. So we’ve got some software out on hosts. We’ve got some software at a console which keeps track of what’s going, what files are being changed, what our expectations are. So we can have a model like this and use it as we play Elevation of Privilege.
For example Alice might play a card the three of tampering and the card says an attacker can take advantage of your custom key exchange or integrity control which you built instead of using standard crypto.
Now as security people we know that’s something that you don’t want to do but if Alice is a software engineer or a network engineer, she might not have that knowledge but the hint is on the card in front of her and she can say maybe that applies to this network connection right here (see red arrows).
[MARK] So next one up is Bob. He has a really strong hand and he plays the tenth of tampering.
It says that an attacker can alter information in your information store….He says well there’s a file store on the integrity checker console site, so if we have weak ACS there, then someone might alter your configurations or alter the way the software works.
[ADAM] So Charlie might play the 5 of tampering.
An attacker can replay data because your code doesn’t have timestamps or sequence numbers and looking at the diagram he might say that applies to this integrity data flow that comes back (see the red arrow).
[MARK] Finally Lisa plays the 8 of tampering saying an attacker can manipulate data because there’s no integrity protection for data on the network.
Not very often the answer to this is, we’re using TLS but just like people don’t know the difference between having encryption and doing integrity checking, what Lisa says is that there’s a connection there (see the red arrow) which might have this problem.
[ADAM] The card game derives from spades if you play a lot of card games so you have to play in suit. The high card wins the hand unless someone plays a trump card and a trump is the suit that always wins so elevation of privilege is the trump suit. There’s a mechanism for the game which is there are aces and an ace is you’ve invented a new threat that’s not in the deck and to support that there are cards in the deck that say here’s a list of all the threats that you might see on all the cards and then you give out some points. You give one point for each threat. You give one for winning the hand. Some people play this competitively and do a better job of tracking points than threats. That’s a mistake. But some people like to know who’s winning and some people play very collaboratively.
The key idea is that you’re actually engaging with the threats and the possibilities and having a conversation about the second question at the heart of threat modeling which is — what can go wrong.
[MARK] As I said, you play until you have cards or you run out of time…Very importantly after the session make sure that you triage the items, you talk to your project managers about how important the items are from his business perspective and then make sure that those which should be handled, actually get into the ticketing system.
Now after listening to us and if you have never tried the game out, I really motivate everyone to try it. And this may sound strange, like threat modelling — it’s a beautiful art that experienced security engineers are doing so why are we doing a game out of this. Surely it cannot work. Like people are going to focus on very bad aspects of the session, they are going to focus on playing the high cards and so on and you lose the whole idea.
Now those arguments might be true but the experience is that it works. So we have made regular threat modeling a practice for more than two years now and we always use the elevation of privilege card game and there’s always two three high findings in every threat modeling session which comes out by playing those cards which have not been discovered before…
Now one of my favourite findings which I would like to share with you. There was a component written a couple of years ago.
It’s job was quite simple. The idea was that an admin can upload a file or a patch he wants to distribute in the network. He uploads the file, it provides us the URL where this file can be found and then our component picks up the file and distributes it in their system.
The engineers thought there’s not really a high risk here because the admin who wants to distribute the file is already the admin of the network. He’s a local admin on all the machines so there’s not much that can go wrong here.
Also the software has been developed by some of the demigods of the company like the ones who’ve been working for 20 years… and I’m still quite fresh. How am I supposed to tell them what could go wrong. They’d certainly thought of all the things.
So we went through the session. As I said …. the admin provides us the URL of the file we should be distributing. When we were talking about the validation of that URL, we thought there’s not much we can validate because it’s a file in the customers’ network. He might be providing an IP address which is only visible to him or an s3 bucket,or uploading something to their own domain. So what do you validate against..?
Now as it turned out there was one important piece of validation which was missing which was that it shouldn’t point to our internal network. This was because the component was running an OR firewall segment so if he provided an internal IP address, we would just be picking up the file from our internal network and sending it out to his computers. So we discovered quite a nice way to use the component to extricate data.
Why I really like this one is the whole story around it. Like there were principal fellow level engineers. They were really security sensitive. Two of them were security champions for a long time and before that they’d been writing some of the very sensitive code in the company. But still there was like one quite critical part of validation that they forgot and that came out with the Elevation of Privilege card game.