Grant Ongers — Gamification of threat modeling

0:00Chris RomeoGrant Ungers is co-founder of the bearded trio called Secure Delivery, with a philosophy and purpose for optimal delivery and security in one dynamic package. Grant's experience spans dev, ops, and security, with over 30 years pushing the limits of InfoSec. Grant's community involvement is global: staff at BSides London, Las Vegas, and Cape Town, Goon at DEF CON for nearly 10 years, and DC 2721 co-founder, staff at Black Hat USA and EU, and an OWASP Global Board Grant joins us to talk about gamification and threat modeling and introduces me to the OWASP Cornucopia card game. Robert already knew about it. You can use this card game to teach developers and product team members threat modeling in a fun and engaging way. We hope you enjoy this conversation with Grant Ungers. You cannot hack yourself secure. Everyone wants to focus on the offensive side of the equation. The challenge is that developers get bored with hacking broken pieces of code after a while. Sure, it's a shiny, cool new thing in the beginning, but how about one year later? At Security Journey, we focus on long-term sustainable security culture with the developers as defenders. Our approach integrates experimentation together with learning. We believe that developers need hands-on experience, but not at the expense of fundamental knowledge. Visit www.securityjourney.com to sign up for a free trial of the Security Dojo or schedule a demo.

1:40Robert HurlbutHey folks, welcome to another episode of the Application Security Podcast. This is Robert Hurlbut, and I am a threat modeling architect and trainer, and I'm joined here today by my co-host, Chris Romeo. Chris.

1:55Chris RomeoHey, Robert, this is Chris Romeo, CEO of Security Journey, and, uh, super excited to be here to talk about the thing that we talk about about 50% of the time on the AppSec Podcast. It seems not quite— statistics are a little less, but we talk about this more than anything else, and that is threat modeling.

2:16Robert HurlbutAnd, uh, with that in mind, we, we do have a special guest, Grant Ungers. Thank you for joining us, Grant. Tell us about you. Tell us your security origin story. How did you get into security?

2:31Grant OngersThanks, Robert. Yeah, so my name is Grant Ongers. I am the CTO of a company called Secure Delivery. We do a lot of application security things, so everything around the world of AppSec, primarily working with either application delivery teams to help them meet the requirements that security have laid down for them, or working with security teams to help them to understand how delivering at pace isn't going to make things less secure but rather more secure, and then helping them find the right, the right balance of things for those two sets of teams. I started off in security because I lived in South Africa, hence the strange accent, and all the best stuff was in America, and we were dialing into things. I mean, it was all BBSs at the time, and dialing into the best BBSs in the US from Cape Town, uh, was prohibitively expensive. Um, but I discovered that telephones didn't always have to bill you, uh, depending on how you used them. And that kind of got me involved in some phreaking stuff, and from there I, I got involved in, in a lot of what's— what is now the security community. So, uh— I've been at GUNA DEF CON— this year will be 10. I've been— well, I'm on the OWASP Global Board of Directors because application security is my passion. And yeah, I've been involved with BSides and all the other types of things since then. My work has primarily been either operations, nearly 20 years of my career. I've done 10 years in application development and application delivery. But security has been that golden thread all the way through for probably the 30 years I've been working. So that's where I come from.

4:14Robert HurlbutAnd your focus is, and what we're going to be talking about today, is threat modeling. Tell me a little bit about that. How did you get introduced to threat modeling, and what piqued your interest in that particular topic?

4:27Grant OngersWell, I guess it kind of comes back to a core philosophy that we at Secure Delivery have. Around how security is something that should be built into your product from the beginning. Security is, according to the ISO 25000 standard, an aspect of the quality of software. Not even necessarily the most important quality aspect, quality aspects being the non-functional requirements you have around software, but it is an important aspect, and it is definitely quality-driven. But, you can't sort of bolt security on or bolt quality onto anything at the end of building it. So, threat modeling is traditionally where you build— you'll be able to get the most amount of security eyes onto a product before you start designing and building. Threat modeling happens right at the beginning phases of projects, so that's where you should start.

5:24Robert HurlbutAnd so, with that in mind, who should be doing the threat modeling? Is it just the security people?

5:31Chris RomeoCould it be others?

5:32Robert HurlbutWhat are your thoughts on that?

5:33Grant OngersWell, Adam Shoschak and I have had a long-running conversation, and we're probably going to continue that conversation in a more public forum at some point in the future. But, threat modeling has very traditionally been a security folks' business, their job. The problem is that security people get involved in designing a product either far too early, as in before developers start developing code and the product starts to evolve, or far too late once it's already done and dusted, and going back and changing things now is bolting it on, you know, pre-release, but not really when you're designing it. So I think, I think that developers should be involved in threat modeling, Mm-hmm. which is why I'm a huge fan of projects like the OWASP Cornucopia project, where essentially you get teams doing threat modeling as part of story creation. So, product owner has some ideas. These are the things I want my product to do. He works through those with the team, and the team essentially do the scrubbing. They figure out what that story would entail, what it would take. And while they're thinking about that, they're thinking about things like, well, how do I make this performant? Is it a performance-critical component? Do I need to worry about how this will scale out? Are we expecting scale to be larger?

6:51Chris RomeoYeah.

6:51Grant OngersThese, of course, are aspects of the quality of that component you're going to be building. If you're doing a security view on things, then you've got to look at, you know, is this impacting some of the particularly sensitive areas of an application which are more likely to be, you know, to be attacked or targeted from a security perspective? And if it is, then what do we need to do? How do we cancel those things? So that's threat modeling as an aspect of story scrubbing, and Hornicopi does that really well.

7:21Chris RomeoIs there a particular methodology, Grant, that you would say is what you use when you're going in to work with a new group of developers?

7:30Grant OngersWell, so we start with— like with most things, we start with giving them some awareness around what types of issues they can expect to see from a security perspective. OWASP Top 10 is a great go-to. I mean, 2017 is the last update. We're expecting another one in 2021. It's probably the same sort of issues that we've seen year on year on year. I predict that we'll see injection as one of the top 10 in 2021 still because that's still a major concern. But we start with awareness. So these are the things that can go wrong. I then break it down, and in a lot of my training materials, I use a simplified OWASP Top 5, which, um, is essentially the, the 5, uh, suites of cards, um, other than the Cornucopia suite that you'll find in the deck of Cornucopia. And it essentially covers things like, you know, authentication, authorization, cryptography, data validation, encoding, and one that I can't think of offhand. And when it comes to me, I'll be like, oh yes, of course. But there's essentially 5 areas, 5 aspects of software that we need to focus on? Of course, it's session management. So how long between us checking the authentication authorization of a particular user? And those 5 things, whenever you're dealing with something in your software that's going to be touching on one of those 5 things, at that point, you should be thinking, how can I make this more secure? And so teaching developers that that's the way they should think about it so that when they start writing code, they're thinking about how to write code in a secure way, definitely helps. But if you want to do a formal threat modeling session— I use the word formal very loosely here— then Cornucopia, as part of that scrubbing session— okay, we're building the authentication module for our app, we should do some threat modeling, and we should grab a deck of Cornucopia, and we should run through the deck and make sure that we're covering all our bases. or we're building a data storage component, or we're building whatever it might be. And in that component, you know that there are going to be aspects of one of those 5 areas, so you want to cover those off while you're doing the work.

9:47Robert HurlbutSo you mentioned Cornucopia, and I'm familiar with that game. Tell us a little bit about that, and also that approach to gamification, and how that has helped you.

9:59Grant OngersSo I guess starting with gamification and why that's particularly useful for developers, Security is is often seen as this very black magic, dark area of the IT world. We tend to keep a lot of our our particularly focused ways of doing security things. We don't tend to share that outside of this this community, either because we think people don't care, or we think that's not interesting, or because we like. having some, I don't know, mysteriousness around our— the world that we work in. But gamification takes away a lot of that, right? It makes it very simple. You have to simplify things in order to make it a game. Otherwise, the game is very complicated and really hard to learn. Cornucopia is anything but that. I mean, it is— it's literally a kind of like a trump card game where you try and beat the previous card ahead of you by finding a card that's higher. that happens to be in the same suit that is also a potentially valid attack against the product that you're trying to target. So it's a very simple concept. The way that the game is played is very easy to understand. The complicated things are understanding what those 5 things are, and once you've played 1 or 2 cards, you begin to understand how they interact with each other, and then really the cards are just How badly can you affect data validation, or, you know, how broadly could you affect it but with very little impact? And that's kind of how the cards are spread out. Cornucopia does a really good job of that because it doesn't require a developer to take on the concepts of DREAD or STRIDE or any of the other methodologies that we've created for threat modeling. It puts things in very simple terms that they can understand. In terms that are easy to pick up on, and terms that actually tie in quite well with their development process. So I'm creating an input form. I know that I have to validate the input that comes in there, primarily because I need to make sure that when I ask them to type in a username, they actually typed in a username. When they type in a password, I know that I've got to star that out. So I understand what validation of the inputs is about. I understand what authorization is because I built an authorization module, right? You know, I'm allowing users to do certain things there because they've logged in and I know who they are. They've authenticated. Usually somebody else has dealt with that aspect of it, but now I know that, right, you've authenticated, you belong to a particular group, you're allowed to do a certain function. And because that's functional work, the concepts translate very well. So I find that the gamification methodology that Quantico uses, which is simplify everything, bring it back to the functional work that you're going to be doing within the code. Makes it really easy for them to start seeing how those functions they're building can be abused.

12:59Chris RomeoMm-hmm.

12:59Grant OngersBecause the cards go into a great deal of detail. They also tie into a whole bunch of other really good OWASP and other projects like the Secure Coding Guide or the ASVS. So there's really good connections into other OWASP projects and into SafeCode. projects outside of ROS that also really do bring you some more details. And it allows developers to go from, okay, I understand basically what I'm doing with data validation, to, hey, this is quite interesting, let me learn more, without expecting to know everything before they start building something.

13:31Chris RomeoAs I'm kind of listening to this, and I told you before we started recording, for whatever reason, I had never experienced Cornucopia. Like, I had heard of it, but I didn't— I feel like I really have a good understanding for what it is now. When I think about the methodology you kind of described and laid out in using Cornucopia, I see how that would easily work with a small development team. When I walk into a room, there's 4 or 5 developers, I'm like, hey, let's use this Cornucopia thing. How does Cornucopia work with 25,000 developers across a mega enterprise where we're trying to do threat modeling? Is there an online equivalent where I can get that same impact that I get with the card game, but yet at scale? Does Cornucopia kind of— is it really more kind of hand-to-hand combat on the ground type of influence and threat modeling?

14:24Grant OngersSo, I am actually working with a couple of guys in OWASP to try and build an online version of Cornucopia, especially now that everyone's working remotely. But, I think that Cornucopia's strengths really lie in its usage in the same way that you would do story scrubbing. So, you mentioned 25,000 devs. An organization I fairly recently worked for, or did some work for, is a large global bank based primarily out of here in the UK, but it is global. And they have 25,000 devs. It's a massive amount of developers. But all those developers are working on thousands and thousands of different products. And they're working in teams on particular aspects of those products that are much smaller. The way that most development occurs is in much smaller agile teams. And even in the larger teams where you're doing sort of a scaled agile approach to things, or even if you're doing waterfall but on larger teams, the group of individuals that looks at what stories we're going to work on in the next 2 weeks or the next, you know, whatever the next 4 cycles is going to be, that group of people is usually relatively small. The problem is, thanks to COVID-19, they're not local, which does make it problematic. So then you end up having a deck of cards each, and you have someone decide who gets which cards. It does kind of work, but a lot of teams have found that it's much easier just to literally play through the cards. The Scrum Master, or whoever's running the session, he has the cards, and he'll tell you which card you have in your hand. He'll give you that as a sort of a one-on-one direct message in Slack, or wherever you're having this conversation. These are the cards that you were dealt, and then you can try and play in that way, and it does kind of work. I've also seen some teams do it with literal decks of cards because there are plenty of online gaming platforms that provide you with just ordinary card decks. Playingcards.io, for example, they— in fact, they even do Cards Against Humanity. So if you're really bored, you want to do something on the weekend with friends and family that are not local and you can't get out to see, maybe take a look at playingcards.io to play some Cards Against Humanity with them. But they— you can play with ordinary playing cards as well. You just need to have some way of tying them up, which isn't optimal. But it definitely works. The larger the team, the more time it takes, because essentially the game time is I play a card, I read you the card, and I tell you how the attack described on the card is valid in the application we're discussing or the feature we're discussing. Everyone else goes, well, no, I don't think so because of this, or actually, no, he's right, this will also happen. And once they've determined whether it's a valid attack or not, they then talk about whether it's a— whether it's something that they can find a solution for immediately. And obviously, the larger group of people you have, the more conversations take place, the longer it'll take. So most teams try to keep it to whoever's doing the story scrubbing. which is usually 1 or 2 lead devs, 1 or 2 lead QA people, the product owner, because they're obviously bringing the stories to this mix, and usually the Scrum Master is there to act as a referee. And he's acting— or he or she is acting as a referee even without us playing the game, right? That's generally their role within that session.

17:47Chris RomeoSo it's basically taking this smaller idea, and when you have 25,000— even if you wanted to try to influence 25,000 developers with Cornucopia, you would do it in— you know, a lot bigger than 10,000 separate groups, basically, that would be lined up with their local dev. Because, yeah, like you said, 25,000 devs, they're not all in one Agile Scrum team, right? There's probably 10,000 or, you know, 5,000 separate teams that are happening there. And so by having them, if you wanted to roll it out to them, you would have to influence each of those individual teams and let them kind of experience it on their own.

18:25Grant OngersThat's exactly right. In fact, one of the organizations that I did this for that I'm happy to name because they've contributed back to the project, and they're quite proud of what they've done there, is a corporation called RBI, Reed Business Information. They're part of the Redix group of companies, so they're a FTSE 100, FTSE 6 or 7. They have probably 18,000 devs that had to go through the process. Of understanding secure development practices, and part of that was incorporating Cornucopia and threat modeling into regular Scrum sessions. They built a lot of software for the financial sector. In fact, they built the filtering methodology that most of the top banks, the top 10 banks worldwide, use to determine whether 2 entities are allowed to transact with each other. They also do a lot of KYC, know your customer, type work. So they have some pretty strict requirements. We started off with printing off the Cornucopia decks, because obviously you can get them nicely branded with your own corporate stuff on there. So we ended up printing a few thousand decks of cards. And then I was asked to go out and sort of evangelize this, which meant that I was jumping on planes. And a lot of the major offices throughout Europe. I was visiting them, talking to 2 or 3, sometimes 5 teams in a week, taking them through how the session works, and then they would go and evangelize it further, right? So you actually do have to— I mean, I can't teach 15,000 devs all how to play Cornucopia. That's a couple of years of time. But they then could spread it further, and it's a great way to it is easy to pass on, right? It's not something that's complicated because it's gamification. You understand the game, you have all the supporting materials, you can understand the threats, and it becomes really easy to transfer to other teams.

20:24Robert HurlbutYeah, I remember the first time I heard about it and even saw it in action, and it has its origin with elevation of privilege cards, right? It was sort of a used that as its inspiration and then developed this set. And EOP game is by Adam Szostak, and then the Cornucopia, if I remember correctly, came afterward. And so that similar style. But I remember being at an AppSec USA conference, I think, and they actually had a session where in the session it was using the cards, right? So we had architecture diagrams, we took a look at them, we gathered around a table, 4 or 5 people. We got a card deck, we played the cards, we learned how to play them, and it was a lot of fun. And I myself have used them quite a bit in some of my own training. And what I find is that people generally, they like that, it's fun. But I also have found, and this is where I'm heading with this, is that some say, I don't necessarily want to play a game, you know, and that— and maybe that's that seriousness part. I'm not sure, but they say— Yeah, this is okay and everything, but I don't like games, or I don't like card games, or whatever. Have you ever encountered that in terms of working with different teams, and what are your approaches on that?

21:49Grant OngersSo, I've come across people who are either engineering managers who are uncomfortable with sending devs into a room for half a day to play games, Sure. And obviously the way that you approach them is slightly different to how you would deal with somebody who doesn't want to play themselves. I've been in sessions where there were people who were dealt cards and then were very uncomfortable about participating, either because they didn't like card games, they didn't understand the game, they thought they're going to look like a fool. I think part of the reason why gamification works is because Once you get over that initial, I'm surrounded by work people that I never speak to outside of work, and once you get over that initial, I don't know how this game works, so I'm going to look like a fool.

22:38Robert HurlbutYeah.

22:39Grant OngersAnd you get to the point where you're actually arguing with each other about whether something works or doesn't. And then you find yourself siding with somebody on the other side of the table who's probably going to beat you if they get this win, but actually you think they're right, and you're competing with the architect who says it's not possible. So generally, the people in the room, once they, once they get over the, that initial awkwardness, it flows. It flows very well. You do have to make sure that it is completely safe. You do have to make sure that the engineering manager knows that he's losing this team for half a day. He's not going to see them, and what they're doing in that room is absolutely important. And often you do that by having, you know, the CISO talk to the engineering manager and explain how This, he must see as them going on a 2-day training course. Choice is 2-day training course or this half day in the room learning how to play this game, and then regularly playing this game and showing that they've done so. Generally, the engineering manager goes, well, okay, we'll spend half a day, we'll give you that. We'll do the things that we have to do on a regular basis, but you'll find that that deck of cards goes into the Scrum Master's desk drawer. And he'll be bringing them out regularly because it does kind of create a working-together feel for the team.

23:54Robert HurlbutMm-hmm.

23:54Grant OngersAnd that's especially important when it's security because it's— I mean, some aspects of the code, half the dev team never sees. They only ever get a chance to talk about it when it's discussed as an architectural component. As you pointed out, often there's— I mean, those architectural diagrams that you started off with. In fact, I think the session you're talking about, if I'm not mistaken, it was filmed on camera phones. And that is the current training material available on the OWASP website for the Cornucopia game.

24:22Robert HurlbutOh, funny.

24:23Chris RomeoWhen I think about threat modeling as— when I went teaching threat modeling as a methodology, one of my goals is always to say, how are we going to retire this methodology? Meaning developers in 1 year, 2 years are going to just understand the classes of threats and things, and they're not going to have to do the process or the steps or anything anymore because they're just going to start thinking like that. Have you seen that same impact with Cornucopia, or is Cornucopia something that the Scrum Master has to be leading that game every feature for the next 10 years?

24:59Grant OngersSo what I have noticed is that teams— and we got to see this at RBI— so teams that came on board initially, they hadn't done much threat modeling, or what they had done was all in design phases, and primarily like the architect and and the product owner would do that, and it didn't get fed into the rest of the development team. But after 6 months, or I think the longest we saw the gap between them was like 9 months later, those same teams are no longer running the Cornucopia sessions as part of every small release. They start to span them out slightly longer, and they at that point are no longer just doing it with smaller teams, they're bringing in the whole team. So they start looking at epic level rather than story level, and then they include the rest of the team to get them up to speed as well. And the reason for it is that they can go through the deck much quicker because they'll bring out a card, they'll read what's on the card, they'll talk about how this could have been an attack, but we already thought about it and this is what we've done to counter it. And they still play the game, they still mark it down, and they're doing that for less of a security and more of a compliance reason, right? They still have the score sheet that they can show that they did the threat modeling exercise, So it's part of the compliance required for FSI SAC, but it's a much quicker game, right? It's, this is not going to be valid because of this. Occasionally, they still find one, they go, you know what, we didn't think about this. This is still going to happen to us because we've just plugged this into the old component, or because there's still this other piece that we haven't fixed yet. So they still find value in it, but it does become less story level, more epic level, and less the smaller group and more the larger group. Because as you pointed out, when you start to think about how threads work, and if you've done it long enough, it becomes a way that you look at how you write your code, which is what it should be, right?

26:50Robert HurlbutRight.

26:51Grant OngersIf I have a lot of experience writing performant code, I transfer that knowledge to somebody who doesn't have the experience by, you know, reading their code, telling them, hey, listen, when you're doing this thing, think about doing it this way rather, because— and that sort of does end up passing through to the rest of Rest of the teams.

27:07Robert HurlbutSo that, that's great because that's what you want, right? You want that collaboration. First of all, you want that internalizing some of those methods. So it's not just by playing the cards or you're not needing the cards as much, but you are, you are engaged in threat modeling, whatever level it may be. And so, and then people understand what you're talking about. Which is great. One of the questions I was wondering, sort of kind of full circle here and talking about the threat modeling activity, where do you get to a point, or is there a point where you say there is enough, we've done this enough? You know, how far do you go when you're looking at something and you're thinking about the threats, thinking about threats, when you say, okay, I think we found enough, we got to do some work?

27:58Grant OngersSo that's, that's actually part of the conversation that Adam and I need to have. Um, there's a, there's a quote, great quote by Adam Troschack where he, on his, on his blog, where he talks about how, uh, you can never have too many threats when you're doing a threat modeling exercise. I believe that's fundamentally false because it's about getting software out the door. At the end of the day, nobody cares how securely you built that banking app if you release it 6 months after the bank has gone bankrupt, right? Nobody cares at that point. It's great, we have great software. Um, you're also not going to hit everything. You need to understand that from the get-go. I think threat modeling should be about highlighting particular aspects that you know are most vulnerable or are most likely to be intercepted, uh, and then even more importantly than that, it's about getting developers to think about security as part of how they plan to write the code. If I think about data validation encoding, if I think about how I'm going to talk to the database, those stories become so much easier to do with a much more secure way of doing them. So it's— I think the answer is you stop threat modeling when you're done with that session, and you do as many cards in that deck as you feel is necessary for the group session that you do. I mean, I don't think I've seen any games at Cornucopia run through an entire deck of cards after that first half day that we took them through, primarily because, okay, we're working on a feature, this feature has some data components to it, we're going to look at just 2 suites. We're going to look at data validation encoding, and we're going to look at encryption. Those are the only 2 things we're going to worry about. We're not worrying about authentication authorization, primarily because They don't have any particularly strong features inside this part of the code that we're working on. So, and then you can even take out the cards that you think, well, let's only look at the high-value cards to start with. It becomes a balancing thing. The more you think about security, the more securely you'll write your code. But you do need to get the code out the door. That's the key. It needs to actually be functional and be available to customers to use.

30:10Robert HurlbutIn terms of getting the cards, I know you just showed the deck there. Usually where I would pick them up is at an actual in-person conference, and they would sell them for about $10, if I remember correctly. So I'm assuming, and hopefully they are available somewhere on OWASP site or somewhere else, that anybody could go ahead and order.

30:30Grant OngersSo you can't go ahead and order just yet. I'm trying to find a way that we can do that as a foundation. We can't technically sell things.

30:38Robert HurlbutRight, okay.

30:40Grant Ongers803 doesn't allow us to do that. So what we're probably going to do is set up some way of, if you donate money to the foundation to a particular value, you can pick whether we send you a t-shirt or a deck of cards or whatever you're wanting to look for, right? But what you can do, because it is open source, there are all the print-ready files that you would need to actually do a print run yourself. They're all available on the OWASP website, on the Cornucopia site within OWASP. I think they were actually— those were actually contributed by Blackfoot. They actually took the original designs and they put up the full, whatever it is, the EPS design documents, which you can literally just take to a print shop and say, please print me these cards and this box, and you get the box and the little— the fanned how-to-play card or how-to-play instruction manual. And if you do it that way, you can go and— I mean, so this is, this is an OWASP deck of cards, but on the back we've got our logo. And, you know, if you actually do want a deck of cards, feel free to reach out to me. I've got a couple hundreds of them lying around. I'm happy to send you one. Um, but they are— yeah, they're easy to get yourself if you, if you chose to do that. Uh, you can also go to an OWASP chapter and speak to a chapter member, chapter leader, and say, hey, listen, I've heard about OS Cornucopia. Can you arrange for the next chapter meetup, whenever that might be, once again when we're in person, that you get a couple of these decks or a dozen of these decks to me? And I'm sure they'll be able to arrange something for you as well, because chapter leaders can actually order stuff directly from our suppliers.

32:17Robert HurlbutOkay, Grant, well, thank you for joining us. Any last, maybe something to mention to teams, developers, project managers, additional thing to think about when they're starting with threat modeling or even including gamification in some way into their process?

32:34Grant OngersSo I think gamification of particularly hard aspects of what we do is important. So it's, it's a good idea to look at ways of gamifying the problem areas that you're trying to deal with. I also think, and this is something that actually happened at RBI, I got on a plane to Amsterdam. Some miscommunications between myself and the team that I was going to be dealing with there. They were all remote, and as in not even necessarily in the country, which was rather complicated for us to have this conversation. You do need to, the first time you run through this, if you're a security team that's trying to introduce Cornucopia to to a development team, or if you're an engineering manager who thinks this is a good idea and you want to introduce it to them, or if you're a consultant coming in and you're doing the same thing, the first time you do it, you probably do want to have everyone in a room somewhere.

33:29Robert HurlbutMm-hmm.

33:30Grant OngersPhysically being able to handle cards is great. It's also— when I put together the how-to email for the Scrum Master in that particular location, she printed it out the email that I had sent her and she bound it and she gave me a copy of the printed and bound document, which as you can see is a fairly— there's a huge amount of work here.

33:53Chris RomeoWow.

33:54Grant OngersMy email is only 3 pages long. I say 3 pages, that's a hell of a long email, 3 A4 pages. But there's tons of additional material that I had included in the email saying, you know, go check out these things. And it's reach out to the ASVS or the Secure Coding Practices or any of the other projects that are mentioned in the cards. Um, it's definitely easier to talk about it like we've done now in 30 minutes. If we took an extra 15, 20 minutes, we could actually have played a couple of rounds, and then everybody in the room would understand what you're doing. That's much easier than trying to read through a manual that looks like that.

34:28Robert HurlbutRight.

34:28Grant OngersSo in person is best, um, and you actually want to play the game. There are some teams that we, uh, 6 months later discovered were not playing because they weren't finding the time to do it. And then they were literally dealing down through the deck and going, is that a valid attack? No. Is that a valid attack? No. Is that a valid— oh, that's valid. That's right. Doesn't really have the same effect, mainly because you don't get everybody involved.

34:53Chris RomeoRight.

34:53Grant OngersAnd it's one guy reviewing it, which is better than no guys reviewing it, but it's still not the way you have discussions. You'll also discover that it doesn't necessarily have to have a huge amount of people who know the product really well being involved in that first session. Because what will happen is the people who know components of the product will talk about them, and those other people who haven't picked it up yet will very rapidly learn and start contributing surprisingly fast to a game. One of the sessions we did, it was, I think, more than half the team was new that started that week.

35:28Robert HurlbutMm-hmm.

35:29Grant OngersThey hadn't even checked out the code yet. let alone understood how threats could possibly be present in it. But because they understood the threats, because we talked through those, and because the architecture was this evolving thing on the whiteboard as we talked about various components of it, they were rapidly learning how things fit together. They left the session going, well, I've learned more in the last 3 hours than I have the entire week that I've been here so far. So you find some surprising side effects of doing this.

35:58Chris RomeoYeah.

35:59Grant OngersAnother surprising side effect is that those artifacts you're referring to, the architectural diagrams and the data flow diagrams, the ones you probably have sitting in Jira or in SharePoint or wherever you're storing your documents, they're probably out of date. And the moment you print them out or you start writing them up on a board, copying from that original, as you start discussing threats, you'll realize you're moving boxes around and, oh wait, this component's been replaced now. And if you take a snapshot of that, you've got an updated architecture at the same time, which is quite cool.

36:32Robert HurlbutAll right, Grant. Well, thank you again for joining us. And yeah, I learned some new things I hadn't thought about, a couple of things there you mentioned as far as how do you try to do this remotely. So, that'll be really interesting to see some of that work, certainly in these days when we're more or less remote from everybody else, but certainly looking forward to playing a game in person with different teams as well. So, thank you again.

37:00Grant OngersMy pleasure. Thank you, Robert.

37:05Chris RomeoThanks for listening to the Application Security Podcast. You'll find the show on Twitter @AppSecPodcast or on the web at www.securityjourney.com/application-security. Security-Podcast. You can also find Chris on Twitter @edgeroute and Robert @roberthurlbut. Remember, security is a journey, not a destination.