
All right, everybody. We'll get started with the next session. We have Stanley Harris who will be sharing how to level up your threat modeling, turning security into a team adventure. We'll be doing Q&A at the end of the session, time permitting. For that, please post your questions to Slido. If you didn't get a chance to scan the QR code already, you could also find it by going to bsidesf.org/q&a. With that, over to you, Stanley. Thank you so much, and welcome adventurers. I want to warn you ahead of time. This is going to be very Dungeons & Dragons themed. So, if you want to lean in, fantastic. If you don't, I still hope there's something you're
going to get out of this. My name is Stanley. I'm the co-founder and CEO of Catalyst. I like to call myself the champion of security champions. I am really obsessed with how people interact and collaborate with each other, and trying to find fun, innovative ways to make it easier for them to solve difficult problems. And so, to that end, I'm a appsec advocate. I'm kind of a culture warrior, if you want to call me that, but I'm definitely a D&D enthusiast. I'm a former DM. Don't necessarily have the time to do that as much as I'd like to nowadays, but I still try to get back into it when I can. But I'm a very avid gamer
generally. A lot of tabletop games, sometimes online, but again, not nearly as much time for that. And I'm a husband and cat and dog dad, for whatever that's worth. I think they like to appreciate my gaming enthusiasm as well. A little bit about today's journey. So, we're going to talk about where this idea came from. It's a little crazy. It just was a happenstance type of thing that came out of the ether. We'll talk about that, and then talk about how do we actually initiate a D&D inspired threat modeling session. What do we need to do it? How do we map the world that our our party is going to embark on? How do we reveal those monsters that exist
in our data flow diagram? How do we scout that enemy and prioritize those risks as they come up, and then play different mitigations against those threats. We'll do a little wrap-up and I have some some artifacts if you want to ever try this on your own that you can download and take home with you. So, once upon a time I was working with a client uh had a security champion program and they were trying to introduce threat modeling to their development teams. And suffice to say, it wasn't very sticky. There was a lot of lack of interest to even begin the process. It felt to that group maybe uh an infringement on the time that they
barely had to give. Maybe it was dry and something they just couldn't really get engaged into, but for whatever reason, it was difficult to get those developers to play along. And so, I happened at that point to had just finished a D&D campaign with a separate developer group that I played with every week and I thought perhaps there's enough corollary between what Dungeons and Dragons is as a game that we could fold into what threat modeling is as a practice and a process. And so, after a couple of months of thinking about how does this even work? How can you really make it gamified to do threat modeling? I was able to come up with
that first iteration and I was lucky enough to actually bring that to Threat Modeling Con in Washington D.C. this past fall. And so, this was a live 2-hour tabletop exercise that we did with some very willing participants who were willing to really kind of shed reality for that 6 or 120-minute period and dive in deep with physical cards that we had printed and played this Dungeons and Dragons aesthetic in what was really a true to form threat modeling process. And then we had an opportunity to it again just a month ago with threat modeling connects hackathon. We ran a virtual version of this D&D inspired threat modeling campaign using Lucid Spark. Nothing crazy, just an
easy-to-use collaborative tool to get people in and engaged and it was suffice to say a lot of fun and also as you can see from this board, uh there was a lot going on. We set them up at the bottom here with a really simple setup. They had these 20 different risk and mitigation cards and a very blank data flow diagram and after 2 hours they had a litany of identified threats. They had a mitigation plan for all of them and I think what was the most important thing is they had fun doing it. There was a wonderful feedback from both of these events that it was just a new different way to get immersed in this process that
didn't feel dry. And so I'm excited to share all of this with you today. So first and foremost like any adventure, we have to identify what do we need in our toolkit. I only brought a limited physical toolkit with me today. My mandolin was actually taken uh from border security coming in. So I'm left pretty pretty light, but when you go on this adventure, you're going to need a few things. Like any threat modeling practice, you're going to need a cross-functional team to engage. Folks that understand the application or system that you're working with, individuals that may test against it. Anybody that's part of the design, build, test, deploy process. Ideally, you want to bring them into this
adventure. You're going to need a data flow diagram. Maybe you don't have one and that's okay. You could start by actually building out that map and we'll talk about that in a moment, but you're going to need something to manage a system architecture or data flow diagram. That could be a whiteboard, physical piece of paper, threat modeling tool, whatever your heart desires. I like to bring in some very role-playing esque elements to this. So, there are some D&D character cards I tend to use here so that folks can take on and embody the role one of several roles within the party. I have a thing to track experience because in the cases where I have done this outside of of
being invited to these conference events, I like to translate experience earned into some type of true physical reward for the participants. Maybe we have some swag that we give out to the folks that earn the most XP. Maybe it plays directly into the security champion program they have or some other internal rewards endeavor. But, I like to track experience. I like to for folks to know how much have I given to this process and how am I being recognized and rewarded for that. We also have some monster and safeguard cards. Those are threats and various mitigations. I have a list of those different threats and mitigations. And again, if anybody wants to try this, I'll I'll provide a QR at
the end where you can take a look at those. And then you want to just bring all this with you to start the process. And so, what does that adventure look like? Well, I kind of already laid it out, but it's pretty simple. You're going to gather the party. You're going to start looking at the map that you have for your system. Again, it may exist, it may not. Maybe you're going to just review it to ensure it's up-to-date. You'll then go through a threat identification exercise or a monster search. You'll prioritize those threats and then identify the appropriate mitigations for them. And ideally, that will then translate to actionable work that can come down the line to ensure that those
threats can actually cause harm harm to your system. And of course, at the end, we want to recognize people. We want them to earn XP. We want them to realize that they've been part of an adventure as a group and that they've added value to our company. So, what is the party? Well, again, if you like D&D, you're going to probably not be too surprised here. If you're a developer, you're a warrior. Your special skill is being a a code literacy bug slayer. If you're an architect, I I love this term. I'm taking full credit for this. You're a diagram answer. I think that's just if anybody who's kind of deep deep in this, I think you'll appreciate that.
If you're a QA tester, you're a ranger. You're a threat hunter. Kind of a very natural place for a QA to play in this this type of adventure. And like me, you could be the bard. Bards typically, again, if you know D&D, might be laughed at a bit if you pick a bard class. They're typically kind of more of the fun class. They don't necessarily have a lot to do in the adventure besides kind of their own fun little things. But in this world, the bard is the facilitator. They are the security advocate. They are there to keep the group on task, maybe play a tune or two along the way. But they are there to really maintain the
lore, maintain the artifacts that you're creating throughout this adventure. And so that bard needs to be properly equipped to get started. First and foremost, again, a DFD. Could be pre-existing, could be starting with a blank whiteboard with post-its and saying, "We're going to draw this system out." But they need to be prepared to do it. For this particular adventure, you're going to want those threat mitigation cards. We'll talk with those look like what those look like in a moment. And you're going to want something to track your experience. I've I've used very simple spreadsheets for this, right? Just a list of everybody that's in the party, and then you're tracking the various motions they're taking
throughout the threat modeling process. So, preparing to build the map, again, I I think you could do this very easily on a tabletop with a big big piece of paper or on a whiteboard. But if you're using a threat modeling tool and you all can collaborate in there with a screen share, or you want to use something like a Miro, lucid spark, etc. Those all Those all work as well. You just want to ensure everybody can have their hands on this process, their hands on this adventure. And if you really want to lean into it, and in my case, I've been able to do this a few times, and I've seen a lot of great reaction out of it because people
really get immersed. You treat it like a role-playing exercise like you would building a D&D campaign. You speak to it as a story. We are entering an unknown world. Our crown jewels are in the dragon's lair. We need to understand how we protect them. Are we fortified with trust boundaries like moats and walls? Do we have external dependencies like the mountains over yore? Are there unmapped logic in the the dark forest? I may not speak to you all, but when you have folks who are willing to disengage from their day-to-day work and try something new and fun, you'd be amazed how much storytelling adds to this process, especially if you lay it on right at the beginning.
And once you do, you can get into that actual cartography part process. You can map out the system. And this is where you can start to earn experience as a member of the party. And you can do that for very simple things. I'm going to contribute this new data flow to our system diagram that wasn't pre previously identified. I have this unknown component that we actually was part of a release 3 months ago that we is not been updated in our architecture diagram. I'm going to earn 5 XP for that. The goal here is not to just, you know, randomly earn XP for for putting a bunch of lines and squares in your diagram. It's to challenge your
developers, your architects to speak up and say, "Hey, what we have here is not an accurate representation of what's in production today. Let's right-size this and ensure we are working with the true current state and by the way, earn some credit and acknowledgement for doing it along the way. So, step one, make sure our map's current, we know the world that we're working in, and earn some of that XP credit as you do. And then the fun starts at least with the cards because this is where I saw the most engagement in doing this as a part of a a couple of these events of the last year. Uh I went along this path of creating 24 different threat and
mitigation cards, all inspired by a variety of Dungeons and Dragons lore. They have stories behind them, but they do align directly to STRIDE. And so every monster I did my best to kind of utilize a a a a sort of methodology where their backstory in D&D kind of made sense somewhere in the STRIDE model. An example would be the gluttonous slime is part of denial of service, right? Because they're consuming all the resources in the system. Or you may have the mimic of trust, right? Which is spoofing. It's disguising itself to another identity. Again, I'm just looking for a storytelling device so that developers that otherwise might hear spoofing and their eyes may glaze over a little bit,
no. I have this physical idea, this thing that you can immerse yourself in that maybe makes it a little bit more tangible, a little bit more real. And so as they identify these true real threats that can exist in their application, they're playing these cards, they're now inviting a conversation with the rest of the party. Why that threat? Why that monster? Why at this particular vector of our system does that exist? Explain it to me. Have a conversation around it. Earn experience in the background eventually, sure, but the goal here again, via storytelling is they're going to identify where these threats are. The bard's going to help guide them along that journey because they're going to
kind of serve as that security expert, that gut check. And then they're going to build out this D&D threat model for their system, and it'll look a little bit like this and like that screenshot I had shared at the opener. They have a variety of different cards at different pieces of their architecture, and these are real existing threats that you would otherwise see in a normal threat modeling process. They just happen to have a little bit of a D&D overlay. And so, once those threats are identified, we want to get into this input impact likelihood analysis, and I will pause and say I've I've had conversations with a lot of folks in this community about if
impact likelihood is the best way to prioritize threats. I want to be clear, I don't necessarily have a stake in that game, per se, I have an opinion, but I'm using this format because I one, I it has a nice corollary to D&D, so it makes it easy for me to introduce it, and two, I find that input like impact and likelihood are at least an easy bar of entry to help developers, especially developers who are asking how how much of a priority is this issue, to give them a tangible output of, well, if it's a catastrophic impact, and if it's an exposed flank, meaning incredibly easy to hit, we're going to need to mitigate this immediately. And
so, it's like any standard threat modeling prioritization, but we are utilizing what I call a challenge rating matrix. Really simple. We're going to put the damage dice or the level of impact on one side of this matrix. We're going to put the saving throw or the likelihood on the other side, and then we assign the experience for every identified threat based on where it lives in the matrix. So, if my friend Shiraz who's here, I'm so sorry Shiraz, I'm going to do this to you, but if my friend Shiraz here were to play a card that had a critical hit, meaning it was a legendary level damage impact potentially to that system, right? Maybe it's a a data breach or admin takeover.
And it was very easy to do. He's going to earn eight XP for that. And over time as we go through this exercise, we're going to start to see lots and lots of cards with a very variety of different experience points added to them. And the party is going to start to see this tracker on the side. And Bill's going to have 40 experience, and then John's going to have 30. And the goal here is just to get them not necessarily to be competitive, but to recognize okay, I'm I'm being rewarded, I'm being incentivized to be really engaged in this process. There's something that I can get out of it. And I will say in one of these
instances, we were giving out for the top three XP earners, I we gave out like a D a special D20 die and some other kind of D&D inspired things. And that made them more likely to really challenge themselves to find what they otherwise may not have had have identified as threats in their system. And so, you hope for the same thing as you start having the conversation around mitigations. In this case, for my own purposes, I assigned a flat experience value to the various mitigation types. And again, these are aligned to the same stride areas. And they are as the monsters are very laced with D&D uh backstory. Uh but the goal here, similar to the
threat identification, is to challenge your party in rotation to look threat by threat and to ask themselves, what is the appropriate way to mitigate this, to protect our system? they already know that there's going to be a priority order to these things. This isn't about necessarily saying, "This is the highest priority because it has the highest XP." It's to say, "Do you understand, based on the threat we identified, why this mitigation is appropriate?" We're kind of giving them an answer a little bit, right? Because we have this alignment of the stride methodology, but that's okay. The goal here is not for them to know everything out of the box. The goal is to initiate the conversation
collaboratively. And that's what I found was the most effective piece of this. We were already kind of leading them to the answer in a lot of ways, but that was a good thing. Because we wanted them to start questioning, or at the very least validating their assumption, on why these were the appropriate tracks to take uh to to stave those threats. And similar to every other stage of this adventure, they're earning XP along the way. You're updating your leaderboard. And hopefully, as you get to the end, you're recognizing there's now an opportunity to do this iteratively. That it doesn't have to be a one-off campaign. Maybe the first one's the longest because you're assessing the entire system, the entire
application in that first go around. But maybe there's an opportunity every sprint, every month, every quarter to come back to that threat model, maintain the same storytelling device, and then revisit or reopen new systems or applications that you hadn't uh analyzed in the first go around to start a new campaign that opens up an entirely new map, an entirely new territory. And so, my my advice, if you take this on, is to avoid making it a one-off exercise or at the very least if it goes very successfully with one team, ask them to kind of spread the word so that you could start trying this with other teams. Especially if threat modeling as a program is very nascent to
your organization and you're looking for some way to make it a little bit more captivating, something they're interested in, ask them to play that role of of arbiter, right? Or playing the role of the bard truly. They're singing the praise of this adventure so that you can take it on with other teams within your org. And ensure that we're also following best practices in threat modeling as you do this iteratively. What's changed? Start by going back to your diagram and re-looking at where there are changes to the system, new data flows, new databases, whatever the case may be. And really ensure you're making progress visible. And I'm definitely biased here. I believe wholly in the idea of security
champion programs or at least the idea of really building advocates for app sec within development teams. But I also believe that recognition goes farther than anything else when it comes to behavior change. And so if your goal is to make threat modeling something that developers will do on a regular basis, I advocate that you ensure their progress is visible. Even if it is just that silly experience chart from that Dungeons and Dragons campaign you ran. Post that somewhere. Make it something that they can absorb. Make it something that their managers or their peers can see. So that they can get the kudos not just from within this small party that went on this journey, but from everybody else
in their organization. And I say that not just in the construct of D&D threat modeling. Generally, if there was any takeaway that I want this audience to have, it's that acknowledgement is the strongest way to get repeat behavior change in human beings generally. And so my goal with creating all of this was just to find a new way to acknowledge people. And how do you do that? Well, some examples again, you could have a Hall of Fame, a leaderboard. You could make neat little coins or badges. I created a custom D20 die to give people. You could do all kinds of fun things, but the key is recognize proactive behavior. These people are not only
going out of their way to do this, but in this particular case, they're letting their imaginations run free and kind of dropping the veneer in front of them and and just engaging. Give the public shout out. Make it Make it seen and heard that they are taking their time to be good security advocates. And rotate the roles once in a while. If you are doing this regularly and I'm I'm it's not easy, but if you do, rotate the roles once in a while. Find a different bard. Maybe somebody has done D&D uh threat modeling three or four times and they're a dev. And just ask them, would you like to facilitate next time? Feels like you
really like this. You'd be amazed how much they they they they're willing to lean in more and more if you kind of hand the reins over and just let them try it on their own. You can be there as a coach, but let them try it. And I want to be clear, this is one of probably myriad of ways that you could fold gamification or different storytelling into threat modeling. Try other creative formats. I chose Dungeons and Dragons because it speaks to me, because I'm I'm a nerd and I've played this game for 20 years and if there's any way I can make something an RPG, I'm going to do it. I did it when I
was 5 years old playing with Legos. I will continue doing it until I'm 85 playing with Legos. It's going to keep happening. If I'm 85 playing Legos, that's a different story. But my my takeaway for all of you is use a creative format. Letting folks use their imagination goes a long way. And I encourage you, if you're going to do this particular style, encourage them to keep leveling themselves up, not just earning XP in the threat modeling campaign. Advocate for them to level up their skills. Go to conferences, read books, get engaged. And so some some small takeaways from this entire uh we we weird project that I put together. One, threat modeling, I hope we all
understand is a shared adventure. I don't care how we do it. Don't treat it as a solo audit or as something you have to push to somebody. Invite that group in to be part of an experience, one way or the other. And everyone has a role in this process. You can let them play their class. You can let them get out of their comfort zone and do something completely different. But just let them play a role, one way or the other. I think any and all threat modeling talks say something along this line. The map is your ally. Redraw it as often as you can. Things change, we all know, on a daily basis. And things get lost when
it comes to documentation and keeping them updated. So, ensure that anytime you start this, it starts with, "Let's relook at our DFD and what's changed." And I know I've said this a couple of times already, but naming the threats kind of gives you a power to defeat them. I saw developers using the names of the monsters I had created rather than the actual terminology within stride. I don't know if that was really my end goal, to be clear. But when you hear a developer say, "I have a solution to defeat uh the the gluttonous slime." I mean, it's kind of cool. I'm a fan. Like, there's something there that just tells me they care. And I don't think that they're just
trying to play a game. I think they truly, you know, are understanding that there is a risk here that we have to address. I just have a fun way to expose that. And to frankly maybe give myself a little bit more of a a push to fix that thing because there's now a story that I'm engaged with that I'm coupled to. There's a lot of value there. And lastly, just keep it fun. Keep it flexible. Clearly keeping it fun is kind of my my life's work. Um that doesn't necessarily mean it fits everything, but I think again for things that are otherwise difficult to get folks to glom onto finding fun, creative, different ways to
do it can go a long way. And as I said a couple of times through the talk, I do have a a G Drive folder uh and in the process of moving this to get that is a list of character cards, a monster manual, all of the individual cards, a couple examples of which I brought with me if anybody wants to see those. That's all available there if you want to try. There's There's also a session script, just a quick two-page outline, how do I put this together? What are the things I need? And even a little bit of some script prompting of what to say to your party as you get things off the ground. So, I advocate if
you want to try this, give it a shot. And also look me up. I'm always happy to take feedback on this this project and I'm happy to help you bring it to life if you'd like to. Thank you. I appreciate your time.
Thank you so much Sandy for that wonderful presentation. Loved the creativity behind it. Um as a reminder again, if you have questions, you can post them to Slido by going to bsidesf.org/qna. Okay. Uh We'll give it a few minutes for questions to roll in. And meanwhile, um, couple of friendly announcements. Uh, if you want coffee, we have coffee stations on the fourth floor at CityView until 4:00 p.m. And if you want to take a break from the day's events, you could make a stop at the bar and chill out space. This is sponsored by Run Zero. You have two complimentary drink tickets that were provided to you at registration, and we already paid for them, so use them. Uh, and you can use
them for both alcoholic and non-alcoholic drinks. We also have a prayer and mothers rooms for those who need it. Our info desk staff upstairs would be happy to help you guide there. We also have headshots all day today sponsored by Nebulock right outside of the talk tracks by concessions. So, go get a new headshot for your LinkedIn. And please note, uh, they close at 5:00 p.m. today. And as always, um, thank you for attending the session. We would like to take time to thank all of our sponsors, especially our gold sponsors, Aikido, Archit Clover Datadog Socket and Sublime Security for supporting BSidesSF 2026. Thank you so much. Thanks, Stanley. Thank you.
That's fine.
Actually, we have a few questions coming in. Yay. So, have you tried other gaming platforms other than D&D? If not, what would you suggest? Yeah, is this still Okay, it's still on. Good. Yeah, so D&D was the most natural thing for me to start. I will say I have dabbled, you know, I if someone some folks here may be familiar with elevation of privilege card game Adam Shostack put together. I've used that directly separate from D&D. When D&D feels a little too inside for the audience, maybe something they're not going to glom onto. But for my own purposes, I stick traditionally with with D&D because it's near and dear to my heart. I have explored the idea of a
board game that that is kind of incorporating a lot of these elements. I'm also in the process of seeing if this can be truly productionized as more of a learning game than than a collaborative like in company exercise. But yeah, I I have to be pretty honest here. D&D's near and dear to my heart, so that's where I go. Okay, let's do one more question. Do you find that the challenge rating matrix causes team members to overvalue threats? I think it's natural with or without a matrix that they're going to overvalue threats generally. I think that's part of the goal of using something so simple is because you want to invite that conversation. It's also why I have
whether it's one bard or even another member of the security team there to serve as that that kind of source of of outside opinion. I will say also, if there's an opportunity to bring like a product representative or even a business sponsor into this, so that business impact can be truly communicated with with data and and an understanding of the impact to the end customer to the business itself, that goes a long way. But my goal is to actually invite overestimating impact so that we can have a real conversation about Well, let's let's chart this out. Let's really look at why we believe it's a catastrophic threat. Sounds good. Thank you so much, Stanley. And thanks to the audience for posting
questions even if it was last minute. But thanks thanks for the great talk, Stanley.