BSidesATL 2020 - Protect: Look! There’s a Threat Model in My DevOps

we'd like to thank all of these companies and and people for their contributions to to this virtual event and for being along with us for the transition and the difficulties that that has brought along we have horner media at the diamond level there are only diamond sponsors so big thanks to them Kennesaw State University Kohl's College and their department of information systems at the gold level along with Bishop Fox Coal Fired genuine parts company and NCR crystal level we've got critical paths and synopsis silver level we've got Aaron's binary defense Black Hills core light and guide point security bronze level NCC group and then our in-kind sponsors our ECE Council for their online training and

secure code warrior for the virtual CTF we'd also like to thank crosshair Information Technology Joe gray offensive security and pin tester Labs for their contributions to the raffle prizes and now I'm going to hand it off to Alyssa Miller and let her give her talk there you go Alyssa [Music]

[Music] [Applause] [Music] [Applause] [Music] [Applause] [Music] [Applause] [Music] [Applause] [Music] all right well hello b-sides Atlanta hopefully with that I've got your attention so I'm Melissa Miller and super excited to be here definitely you know with everything that's going on here kind of a weird environment to have to do these things online but hey we're gonna make it work and I'm really happy to be here so let me tell you first of all just a little about me and let me get rid of this thing I love the fact that zoom loves to put that up there every chance it gets so a little bit about me so first of all for those of you that don't

know me I'm a hacker and a researcher I've been what I would call hacking since I was very early on in childhood started with just technology toys taking things apart and figuring out how they all worked when I turned 12 I actually bought my first computer taught myself how to program in basic and did some hacking in some online services and some things finding my way into and beyond paywalls things of that nature so nowadays I've been doing a lot of research into things around machine learning and deep fake videos but beyond that I'm also a security advocate which is why I'm here talking to you today as a security advocate I do like to get out and talk

with the community I like to share my ideas hear what other people's ideas are maybe you have them challenge my ideas challenge my thoughts just discuss this whole big thing that we call security right it's security is so pervasive in every part of our lives these days and being able to go out and to share that information and to just talk about it is something that I really enjoy now recently I did also start working for an organization called sneek and so within sneaked my actual job title is application security advocate so my role now within is to get out with the community talk about what it is that we do in terms of application security how as security

practitioners we can get better being a part of this culture we call dev SEC ops and so forth and then finally I'm an author and a blogger I am working on a book currently to help those that are trying to get into security careers to start to build their careers I do blog fairly regularly both for my employer and as well for my own personal gratification I guess or just again another way to share that information so you can visit my website and and view that blog as well and then finally I am a co-host on a podcast called the uncommon journey where really our focus is just to share the stories all those unique stories that people have for how

they got into cybersecurity and if you look around our community you'll see there's so many unique different stories for how people got here and so we like to share those stories with the world speaking of stories I want to share a story with you so I'm here today to talk to you about threat modeling and this story goes back a number of years when I was working as a consultant for an application security consultancy company and we were working with an organization that had established actually a really pretty impressive threatened threat modeling program so they had made this program of theirs very efficient they had streamlined and standardized the whole process for how they did it and it

consisted of some front work where the engineering teams and the project teams had to create some diagrams and answers some questionnaires and then they got together at a meeting and in the course of about an hour or two they walked through all the information about this application that's how they built out their threat model we came out of it with action items specifications for certain security controls that would have to be implemented and so forth it was a really impressive process and all said and done it took generally between 8 to 16 hours to complete this process so 1 to 2 days for those of you that have done threat modeling before you know doing threat

modeling in one to two days is pretty impressive but I remember going into one of these sessions as a consultant to assist them with this process and after we got done with the conversation and we we came out of that meeting I was talking with one of the developers and he made the comment to me you know I I can't wait until we're done doing this and we don't have to do these anymore and I I was kind of confused what do you what do you mean why wouldn't you have to do threat modeling and the next words stuck with me and he said well we're moving to you DevOps and you you can't do threat modeling in DevOps it takes

too long it doesn't work with we're trying to implement this CI CD pipeline and we can't do that if we're doing dev up or if we're doing threat modeling in the middle of that depth that's gonna be inhibited and that got me thinking and I started thinking about threat modeling and I started thinking about how people look at threat modeling so for those of you who have done threat modeling before you may be familiar with this book or if you've had any interest in threat modeling you may be familiar with this book you may have read this book this is the book by Adam Shostak this book came out years ago and it details it is

probably the gold standard for the process of conducting threat modeling within an organization but it came out years ago and while this book is worded and written to be very non-prescriptive to be very flexible to offer frameworks without being too granular unfortunately it gets taken very verbatim and there's a lot of processes there's a lot of requirements a lot of different steps to that threat modeling discipline that are presented in this book that people try to implement as part of their threat modeling as they should but unfortunately it leads people to view threat modeling as this very heavyweight very time-consuming very difficult process if we start to break it down we can see why so within this process this

is one of the things that they tell you you're supposed to create this is a data flow diagram and the approach to threat modeling is we've got this large application this large monolithic thing that we're going to look at maybe it's even as simple as a micro-service but we still we want to look at it holistically we're going to talk about all the places that data flows in and out we're gonna talk about those different trust boundaries we're gonna talk about where data gets stored we're gonna talk about how data gets processed at each step of its journey through the application and this is where we begin for a lot of organizations just creating that is very

time consuming especially if you've never done a threat model for that application before now you have to create this entire diagram now imagine trying to do that when you're in a CI CD environment and things are constantly changing that becomes problematic then it moves on and we're supposed to create these attack tree drawings so there's a lot of drawings and things being created as part of a traditional threat model approach and they become very time-consuming so this is now I've laid it out and I kind of understand what my threats are and I'm gonna lay out how those threats travel through my system but again very time-consuming if it's a large application in particular one of

the other issues that I see with the traditional threat modeling is this idea of stride if you're involved in threat MA you've almost assuredly heard of stride before stride is nothing but a way to categorize the different threats the problem I have with stride is that it's very technically focused if you look at this you see things like spoofing and tampering and repudiation information disclosure denial of service elevation of privilege these are all things that at a functional level when we're talking to the people who will use an application the people who understand how it applies to the business they don't necessarily understand what these terms even mean so this can be really troublesome because it means that there's this high

bar of technical aptitude that people conducting threat modeling within our organizations have to achieve and then we move on then we have these things like dread and then dread wasn't enough so he came out with dread + D + + threat is ok now that we know all of these threats how are we gonna categorize them in terms of their overall severity and so forth and so there's all these frameworks there's others you may have heard of pasta and people have taken a lot of different approaches to just how do we do threat modeling and you'll see them documenting you'll see different diagrams that try to show what this process looks like but that became so

complex that we we wanted to start looking at well how do we look at common attack vectors a common threat so then we we created this thing called CAPA right and cat-back is a way to document threats that are common across multiple applications and so forth but the taxonomy looks something like this diagram here so we've added even more complexity on top of this so it's no wonder then that developers who are entering a DevOps model look at this and say there's no way that this fits so around about 2008 DevOps became a thing right Patrick Dubois another individual in Belgium got to get and they said hey why can't we develop differently well they were developers

and their focus was how do we make development faster how do we make it easier how do we make it so that we can respond quickly to the needs of our users those are great things for developers to be thinking about that's what we want out of an entire development organization we want our culture to be one where we're always trying to move quickly create quickly deploy quickly that's what DevOps is about it's about this culture and it's about bringing together dev and ops together to be this shared responsibility for quickly delivering stable software now DevOps security got left out of that conversation and security got left out of that conversation because everything that we gave to the development teams

were hurdles we put gates in the way you had to pass this quality gate for security before he could move to production you had to do the static code analysis you had to do dynamic application analysis we had to go through pen tests we had to do all of these things that stood in the way of you taking code from your development environment and getting it into production we as security made it as hard as possible and as a result we got left out of this conversation so threat modeling was a part of that threat modeling was one of those things that although it it wasn't well adopted universally it was something that we kept telling developers they needed to

do but why why what is threat modeling why do we do threat modeling what is this big old thing so as I started thinking about threat modeling and all the problems I asked myself that question how do i define threat modeling how does the industry define threat modeling now normally if we were in person this is where I would ask you to to tell me your ideas of how you would define threat modeling but we're a little less interactive here today but I'm gonna ask you to at least think about it in your head for a moment if someone came to you and said how would you define threat modeling what would you tell them so I did what we always do

we found Google and I went on I started looking for some of these possible definitions and one of the first definitions I found here that you can see was from a wasp and in that definition they you can see how complex this is this is not an easy-to-follow definition I'm not even gonna read it to you because it's so long and lengthy but you can see it centers around very technical terms like denial of service failure of a storage device we see all the the classic vulnerabilities and threats and countermeasures and mitigations and this is an unwieldy definition so in addition to a complex process now we can't even define this thing easily but wasp isn't

alone I went to Wikipedia I mean if it's on Wikipedia it's true right and it was just as complex and we're talking about things about attackers profile and attack vectors and assets most desired by the attacker answers questions like where am i most vulnerable oh my gosh this is such a lengthy definition who's going to be able to read this and actually make use of this so it's still complex well ok Microsoft wrote the book on it what does Microsoft say well Microsoft simplifies it a bit right they bring it down to it's an engineering technique you can use to help you identify threats attacks vulnerabilities and countermeasures that could affect your applications this is

still lengthy and it's still not simple enough because when we go to developers and we're in a DevOps environment we need to be able to explain it succinctly quickly help them understand why this is something that they want to do why this is something that's going to enable them to be better in their development so when I think about threat modeling and I thought long and hard on this like how am I going to really define this I decided let's just take it back to the just the bare objective of why do i do threat modeling when I think about threat modeling at its core it is simply answering the Jhin what could possibly go wrong I'm

looking at my application and I want to know from a security perspective what could possibly go wrong where are those areas where it could be targeted for attack where threats are most likely going to want to manipulate or to attack that application in some way this is what I do threat modeling for so finally a succinct definition the reason we threat model is to identify the likely threats to a system so that we can inform the design of security countermeasures that's it we're just trying to say these are the threats therefore this is how you need to design security countermeasures in the system I searched long and hard for this definition you know who authored this

definition I had to because I couldn't find anything this simple this straightforward but the reality is it is just that simple and that's straightforward so when I started to think about threat modeling in these terms now I can start to explain to my developers to my business owners to my security leaders we can do threat modeling in DevOps without breaking devops now how are we gonna do that how are we going to use threat modeling now to start to create this thing that we've thrown the term out there dev sec ops we want security to be a part of this culture and indeed when we talk about DevOps if I go back to 2008 and I look

at where DevOps came from DevOps was always meant to be a cultural change and when we think cultural change we think people we think tools processes technology governance all of these come together to form a culture now if you go out and you go to a conference that is centered around DevOps you go and you talk to people who this is their primary focus more often than not the things you're going to hear about are the tools the technology and the processes there is very little focus paid to people and indeed I went to I did some google analytics I went out and I investigated in search terms that included dev SEC ops how many of them included the word

tools versus how many included people and there salts are not totally surprising there was about a 700% difference between tools and people in those search terms so people think about tools they think about automation they think about the CI CD pipeline and and how do we how do we make that flow faster and how do we automate different pieces of that within our builds within our promotions how do we make this all happen people don't really think about the people component that human factor that is so important when we talk about creating a culture when we think DevOps we think about this we think about that CI CD pipeline how am I gonna make it faster how am I gonna

make it stronger it's in the term dev sac ops we think developers we think security we think operations and security as I've covered ad nauseam already tends to get forgotten about because we excluded ourselves from that conversation so if I'm looking to figure out how I'm going to plug security into this we've heard it preached a million times push left push left push left we've got developers pushing right pushing right pushing right we're giving them more and more control and we've created this thing DevOps that brings that developers and operations together so we're continuing to push developers farther right they've got things now there they're implementing technologies like containers and kubernetes clusters and things of this nature where they've

now got control of the entire infrastructure on which they're going to deploy their applications they pushed as far right as they can go practically so we in security are still trying to push left we're trying to create this culture of shared responsibility where everybody is responsible for developing and secure software quickly and with stability that steps like ops so for us to keep pushing left we need to continue to keep everything that we do as frictionless as possible for the developers so I started looking at threat modeling and how can we push it for the left well what's what's the farthest left we can go well the furthest left we can go it's that user story right development

in dev SCI cop starts with the user story until I take that story off the backlog and I start to develop it the developer really isn't involved they might have some role in developing certain user stories and writing these and whatnot but why can't I in this idea of continuous integration continuous development start to implement a model of continuous improvement so instead of taking this gigantic monolithic approach the threat modeling and trying to threat model my entire application what if I built threat modeling into each user story and now with each tiny component that I'm going to develop I have threat modeling information right there at the time I take it off the backlog now I sit

down with it as a developer I understand what the threats are and I can develop my code even in a very fast-paced DevOps EIC the environment I can develop my code with the necessary controls in place because I understood the threats from the beginning the minute that story came from the backlog now remember I said people I said focus on people right who's creating these user stories it's not typically developers it is not typically the security people it is not typically your operations people it's the business people it's the people who understand how the users are using that application day in and day out it's the business people that understand how that application applies to the overall

objectives of the organization they're the ones that we want writing these threat models but if we're gonna use things like stride and pasta and dread and we're gonna throw all this technical stuff at it that's not gonna work so we need to simplify this we need to look at what really matters we're back to what's the worst thing that could happen hey you want me to create this user story great tell me about that user story what does that use a story mean in terms of how we're going to be attacked what is the worst thing that could happen by us adding this new piece of functionality this new story to the user experience what is the worst thing

that could happen there tell me about that from a business perspective add that to my user story now when I as a developer I take it off the backlog I have the information not only does it inform my development in terms of creating the right security controls it actually gives me greater context to understand what it is that I'm creating how critical it is to the overall application and all of this helps me develop better quicker faster if I understand the threats and I understand the controls I need to implement any of those automated security gates we have that occur downstream in the pipeline I'm better and able to pass those more easily so now I'm starting to create a more

frictionless environment for my developers and that's what's important when we want developers to adopt our security initiatives within their dev ops pipeline so how do I simplify this for the business people well I can tell you right now we're not doing this anymore take these data flow diagrams they go away we are not looking at this as a monolithic application we're simplifying this we want to understand things from the terms of business assets what is it that makes a difference to the business what is most meaningful from a business perspective and that's going to be things like private data certainly if any of us have been watching the news we understand the level to which private

data is being exposed being compromised being sold on the market but being able to deliver critical business functions that's also a business asset just the availability of our application is meaningful in monetary terms in objective terms in tangible terms to the business so we need to be able to identify that when we talk threats we also have financial assets these are pretty obvious attackers are going to be out to steal money steal things of value from us beyond just data but what about our people aren't our people assets to the organization too so isn't it important that we understand how a change how a new users story how that that new functionality within an application

could also be leveraged to attack our people and how do we design countermeasures then that are going to help us protect those people and then finally of course we have secrets we have secrets of all kinds that's what business is all about we have trade secrets we have the secrets that exist within the application itself right we may have passwords we may have keys we may have other things we need to understand how that user story creates or modifies our use of secrets and then we can define and build the necessary controls to defend those secrets as we design our application so now that I understand those threats and business terms I can take this massive heavily

technical focused stride framework and I can throw that away too we don't need to define things in terms of these technical attack vectors let's think about it differently what are the actual threats if I understand that those are my business assets what are the threats to them the first is probably the one most of us think about quickest these days it's theft they're going to try to steal something from our organization they might also be attempting to commit fraud so if I'm creating a user story that implements new functionality and new functionality might be subject to fraudulent transactions that's something I want the business people to pull out and warn me about that this is a potential abuse

case that an attacker might use of course exposed data in today's day and age of big data massive stores of information these huge data leaks that we're using and monetizing that data we've seen the breaches out talked about every day practically in the media so we know expose data is an issue so we want the business people to point that out to us where is that data that these attackers may want to expose and then of course interrupted business there's too many attackers from nation-state perspectives especially if I'm in critical infrastructure who want to do us harm just by making our systems unavailable so if this new user story this new component introduces a way that

it an attacker might want to come after our application to interrupt that functionality because it's a way that we're delivering a critical function we want the business people to highlight these and we want them to highlight these in the users story so they're there early for the developers so now we can to our developers and say okay it's your turn you've got the information there in front of you we've now set forth for you and understanding of the threats in common everyday terms we're not talking about spoofing we're not talking about denial of service we're talking about things in everyday terms that any person can understand so the information is available to you you've been informed now it's up to you

as a software developer to implement that within your code so this idea of attack trees same thing it goes away we're not going to ask developers to sit here and Mac pout and attack tree this is time consuming and within the concept or the construct of a specific user story it's not necessary we've already illustrated what those threats look like and we've already given it to you in plain English we don't need a complex attack tree instead we need to think about security controls a little different let's let's make this simpler and I'm going to tell you as a developer I want you for each threat that I've identified to implement three types of controls that's it three types

of security controls for each threat that I identified for you the first is a detection control I want you as the developer to enable your code within that user story to detect the presence of that type of threat this could be through logging this could be through other means but we want that ability to say this thread is coming at us right now next thing we as we want those mitigation controls so I want a mitigation control now what what do I really mean we hear the term mitigation a lot when we talk about risk management and so forth but what do I mean when I say a mitigation control what is the purpose of a mitigating

control mitigation controls like I showed here using an example from Return of the Jedi because everybody loves Star Wars right that shield they put around the Deathstar what was its purpose its purpose was not to completely stop and thwart an attack it was to slow the attackers so that the defenders had time to detect and to respond to that incoming attack so when I talk mitigation defenses within my applications those controls that I'm talking about controls that just slow down and attack things that are going to make it more difficult for that attacker to attack that application things that are going to make it so that I have time to react to that incoming attack and

then finally I want them to think about a third set of controls and these are those active defenses so now I've slowed down that attack I forced them to to hold up and to have to really divides around those mitigation controls while they're doing that I have the time to react and I want those controls in place where I can actively shut down that threat whether it's disabling a user account whether it's some form of morphic technology within the application itself how do I go about shutting down that attack I need my developers to build those controls inherently into the application so as I construct these now what we start to do is a couple things

first of all as I said before we've enabled the developers now we've given them this information on the front end we've made it easier for them to design these security controls so that their code will pass those later stages that might hold up their build or might hold up their pull requests later on because of a security issue they've been able to identify it early a nice offshoot of this because we've started to design security controls now with the assets in mind is that we start to move away from this traditional approach of security design if we look at security design since 1960 when we implemented our first password-protected system we've always looked at security from the outside in

as security practitioners we talked about it right that crunchy outer exterior and then that legally middle that's soft and easy to attack once people have broken that perimeter well when I take threat modeling and I start to design my controls around those assets I now start to do this inside-out security design I now have an asset centric security design where my strongest security controls start at the assets that matter most the things I have to defend the most and then they build out from there that's how I want to design security whether I'm talking about networks whether I'm talking about applications regardless of what the scope is that's how I should be looking at my security controls so this form of

threat modeling enables that it it's a completely new culture and then finally because it's made things so much easier for developers this is how I bring security into a dev SEC ops pipeline I've now created something that's frictionless I've now created something that helps my developers I've now created something that the developers eventually as they start to see the benefits from this will actually want to implement they actually want to be a part of this because it makes their lives easier developers want to create secure code but they don't want people standing in their way and preventing them from being able to code quickly to create new cool exciting features and things that address the needs of their

users so this is how we can plug in as security practitioners so before I wrap things up I want to leave you with this quote and unfortunately I haven't been able to find attribution for it but we cannot change where we're headed by doing the same things that got us here since 1961 with that first password control password protected system we've been thinking about security as a bolt-on we've looked at security as this thing that we have to inject forcibly into development into operations deaf sack ops has taught us we have to think about it differently we have to build a culture where we as security practitioners accept that we are responsible for code getting the

production quickly we are responsible for the stability of that code throughout yes the developers the operations folks they are also they share responsibility with us in terms of making sure that software is secure making sure that infrastructure is secure we're all in this together but we have to change how we think about security how we think about what we do in terms of threat modeling and other controls and make it something that enables our developers something that creates to borrow a term from Netflix that paved road for how they get from development to production with the least amount of resistance possible this approach the threat modeling is one of the key ways we can start to do that so

as I wrap things up I want to invite you to continue the conversation here's my contact info if you want to grab a screenshot on your computer easiest way by far to get in touch with me is through Twitter I'm constantly active out there professor Andy can tell you who he sees my tweets all the time hopefully some of you are following me already if I'm not following you pointed out to me and I will follow you but Alisa M underscore InfoSec is where you can find me if you're looking more on a professional level to talk not so much day-to-day but let's talk careers things of that nature are more that that Enterprise corporate level reach out to

me on LinkedIn you can see it there Alisa M dash InfoSec is my profile on LinkedIn I'm always happy to connect to people like to see what you're doing like to see what your cool projects are you can go out there you'll see all me sharing Michael projects from time to time as well and then finally I mentioned before I have my website my blog you can go out there Alisa SEC comm not only do I post my blog out there this is also where I post my speaking engagements of course right now some of those are limited because a lot of them have gone virtual but that's okay I still as an advocate I stayed

very active I still want to interact with the community and so I'm happy to do so through any of those means and I really do invite you to get in touch with me and let me know what you think let me know what questions you have I'm very happy to have these conversations with you moving forward so with that I want to say thank you on behalf of myself on behalf behalf of besides Atlanta and also on behalf of my organization sneek always happy to have further conversation with you folks and to really talk about how do we make dev SEC ops a reality for us we've been dealing with this for better than 10

years and security still is that forgotten element so let's see what we can do to make it better and with that I think we have time and the facility for questions so I will open up the floor if there's things either from the moderator or things that you guys have in slack I'm gonna take a look here see if I can get my controls back

so there's a question here aren't those terms that I showed in the Stride slide deck part of the common body of knowledge yes when as your follow up there as we're speaking in cissp terms yeah but that's exactly the problem they're known to us in the security community outside of the security community when I talk to developers they don't necessarily know what those terms mean and that's what I'm trying to change when I talk about those businesspeople who now are the ones that are writing these user stories they definitely don't understand what all those terms mean and trying to apply those very technically focused terms to the development process is what becomes very cumbersome now it's

I have to have a trained cissp for instance be a part of that threat modeling approach in order to make sense of it because I'm trying to apply a stride in dread and so forth and so you know in in this case yeah it's common to us but we need to start to have that empathy for the wider organization and understand that they don't understand those terms and so by making it easier for them especially if I'm going to ask them to bring threat modeling to the user story I need to give them something simpler something that has business context and something that has more plain language application let's see so without the fancy tree killing

deliverables what are the effective deliverables for the one above that as trench workers can easily produce and deliver in this new model so thinking in terms of metrics right because that's ultimately what do we have the deliverables for there so what we have metrics your first deliverable is just being able to identify within the user story itself when I say identify this in the user story I'm literally talking about changing your templates if it's in JIRA go into JIRA and set up one to two to three questions that just address things like what are the critical assets that are part of this user story what are the specific threats and there is a training component to

this right if you're gonna ask businesspeople to do this you do at least want them to understand what the expectations are so that's your first deliverable is just having that information in that user story now on the flip side of that most development organizations even a dev psych ops model there is some promotion documentation that's required right so developers in some way are documenting what they've done within a user story so where I've seen that implemented is just it's a quick couple statements here are the controls that I implemented in response to these particular threats that were identified in the user story so it's kind of that that post implementation piece and so that's all you need from a

deliverable deliverables perspective because now you can demonstrate the threats that you identified you can identify the controls that you implemented and as a result you have measurable metrics that start to speak to what you're doing in terms of addressing security within that application so now when you elevate that to security leaders to business leaders they can see that and they can see the tangible results that that is having within the security of that application you you okay I don't know are there any other questions see a couple people typing so I'm going to wait for just a moment what do you think about the step of moving user stories so in code review the code

reviewers can assert that on the face that the developer did XYZ yes exactly so kind of to the the point that I was just making in terms of deliverables and so forth you want the user story to be something that continues throughout if we look at the way user stories are used today not only do they inform the development but they also inform the testing right we're gonna write use cases and indeed long term some of those use cases will become regression test use cases but things that are informing our test cycles on the back end so where I've got threat information in there those are now test cases that I can write that become a part of my test set

as well so taking that user story then and populating it throughout the pipeline becomes crucial to this and where I've seen organizations that have gotten really good at this what they're able to do is just like they've done with other test cases where they have automated user story formation into a test case within their test suite you can do the same thing with the threat information start to look at how do we define those test cases that are going to test for the exposures of that data via the the threats that we identified and so that can be very powerful as well

okay thank you Kevin that's a very awesome to hear that and yeah that's bringing it to those layman's terms is crucial it's how we enable I've in certain conversations when I've talked about extending this idea of DevOps culture to the business side I've actually I've used the term and then cringed I've said bizdev psych ops I don't want to get into that emotion of constantly adding new three-letter terms to that already lengthy term but it is it's important right to to have this culture where everybody in the organization has that sense of some shared responsibility and bringing a threat modeling into plain language that's in the user story is a great way to tie in the business side and to

really get them to experience their their capability to affect the overall security posture of the applications you all right well I think we're good I think that's all the questions we have so I will I will stop the the conversation here but I will stay in the slack for a while to interact with you folks more if you have further questions again want to thank everybody so much I definitely appreciate your attention appreciate you being here appreciate besides for the opportunity to be a part of it and yeah and mike has come up with bizdev compliance SEC legal consultant ops hipster perfect I I think we're going with that I'm gonna hold on to that one

awesome well take care everybody I hope you have a wonderful rest of the conference