BSidesSLC 2017 -- John Overbaugh -- Influcencing the SLC...When I'm Not A Developer

[Music] All right. Can you all hear me? Okay. All right. So, just a a a point of order before we get going. Number one, I'm a pacer, so I'll walk around. If that annoys you, I'm sorry in advance. Um, number two, this is uh if you've come to sit and watch 15 20 slides and lecture you and give you a cut list of things that you can do, you're not going to get that. Um, I have three actual slides and then I've got five uh photos that I've shot just to have something pretty to look at while I talk. So, and really I would rather that this was kind of an interactive session. So, please

ask your questions. I'm super passionate about secure code. I've been working in secure code since 1999 when I led the first uh product group at Microsoft through what was then the Microsoft secure development life cycle. So ever since then I've been working to try to help uh teams and clients to build secure code from the start. Um I have a little mantra that says it's just as easy to write secure code as it is to write insecure code. You just need a little bit of tools, skills, and some process. What I uh um I came up with this topic because I've had a lot of people talk to me about it. They're very passionate about secure code, but they

may be a product owner. They may be a test engineer that doesn't have a lot of background in coding or they're play some other role in a company and they don't know how to code and they're worried about well how can I influence it if I can't if I can't code and can't talk to a developer. And the the key thing to keep in mind is that secure development is not a oneanddone thing. It is a process and so you know unfortunately for as many of us here who like to code we are going to talk about process um quite a bit today because it's an ongoing thing that's why it's called a secure development life cycle

instead of a secure development activity. So um who am I? I'm John Overby. I run a company called Infoscure. Uh I do a lot of work in secure coding with my clients. We also do web app and mobile app pen testing and risk assessment. you know, pretty much everything else that you might want to do uh security oriented. Um, so the goal today, I want to make sure that everyone leaves understanding how they can help with application security even if they're not a developer. But let's start off first. How many people here would consider themselves to be a developer? Do do you write code on a regular basis? Okay, we got a few. The rest of you just kind of tell me what

your job roles are so I can understand where we're coming from. application security. Okay. QA. Lots of QA. All right. Ops. All right. Go ops. Anyone else? No one else plays a role they're proud of. Apparently, security management, right? So, governance side. All right. Excellent. So, like I said, I want you to leave understanding some ways that you can influence uh uh security without being a developer. So, as I told you already, I've worked with the Microsoft SDL for a long time. I find it to be a great SDL. It's flexible. Um, they actually have what they call the SDLA, which is an abbreviated SDL oriented toward agile teams. And, uh, SDLA is a great way to get started. Um, both from

a personal perspective of starting to understand the concept in invol concepts involved in secure development, but also to start as a team. the the Microsoft SDL uh process starts with training and and in my opinion that's where all of our secure development work should begin. Training is critical. Like I said, it is just as easy to write secure code as it is to write secure code. Any developer here knows that, you know, if I want to write a SQL injection line, it's a line of code. If I want to write a line of of SQL that uses parameterized queries and prevents SQL injection, it's the same line of code. is just a little bit different. So training really helps

cut a lot of things off uh before they even happen. So that's uh a big part of the SDL. The next step is requirements. Um and you know if you don't specify your security requirements before you start your project, they're probably not going to happen. So gathering security requirements going into the application is a key component of uh the overall design process uh or overall building process. So we talk about things like a security and privacy risk assessment or we talk about um creating quality gates and bug bars. This is all common stuff that a lot of teams do anyhow. It's just the idea of adding a little bit of uh additional security thought into it. By the way,

these slides are really blurry. I don't know if you guys can focus the projectors, but they were clear on my monitor at home. So, um, and then we get to the design phase where we're starting to figure out what the application's going to look like. This is where we would do some threat modeling and things like that. I am going to do a class on threat modeling later today. We're going to do just a hands-on threat model using the Microsoft threat threat modeling tool. So then implementation phase, that's where people are actually coding. And if you're not a developer, that may be the phase where you don't have as much impact as other phases, but you can

still help impact in that phase. Um, after all, so you know, there's the idea of using approved tools, making sure that the team's not using unsafe uh functions, uh, making sure static analysis happens and so forth. We're going to dig deeper into each one of these in a bit. I just want to give you a high level overview of the phases. Next is the verification phase. We got a lot of people here in QA. So uh this is really where you can jump in and help uh in in in terms of verifying that things have been written correctly. Release phase is also probably one of the most overlooked phases in an application where we build our incident response

plan that's oriented toward that application. We make sure that uh we have a final security review. We said we were going to do these five things for security. Did we actually do them and do we approve of the outcome? That kind of thing. And then finally there's that response plan. that's just sort of ongoing. So ensuring that your organization has an ongoing uh focus and is is ready to respond uh as needed. So this uh this diagram is available uh if you just go to microsoft.com if you just Google Microsoft SDL it'll take you there. Um and you can see that diagram and it breaks down and that's what we're going to do for the next while I 40 minutes or

so is really break these down and start talking about uh individual things. And please, if you want to know more about a given concept, raise your hand. If you have a question about it, it's likely that half of the other people in the room have a question about it as well. So, be very interactive. So, um I I promised I had three slides. Those are my three slides. So, I use these slides now to trigger my memory. Um and they're just a bunch of pictures that I've taken over the last couple years in my travels around Utah. So, if you're bored by the talk, you can at least look at something hopefully that's a little bit pretty. We'll see.

So, first of all, do you have a defined secure development life cycle? And just I don't know if you're willing to admit it or not, but how many people here do have a defined SDL in their organization? One guy. Two guys. Three people. That's cuz you defined it. We'll talk about that in just a minute. How's that working for you? Okay. So, you defined it, but the team took it. Excellent. Fantastic. That's good. Yes.

Yeah. So, a lot of times we we sit down and we build these awesome SDLs. They're they're massive. Like you can take I have a whiteboard. I have an 8x4 whiteboard on my wall in my office and you can fill a whiteboard with an SDL and marketing will throw it all out the window the next day. So, how do we build an SDL that the organization um will accept and can accept, right? So, one of my uh good friends and mentors is Chris Nelson, who is the director of security for Distill Networks. Hopefully, you know, that's not a pitch for them, but I like Distill and I like Chris. Um and Chris taught me the the best mantra I've

heard, and that is simply to ask ourselves, are we more secure today than we were yesterday? So instead of throwing a you know a 50 element security development life cycle at your team what you could do is you could say look what are the four biggest most important things that we could do that will move the bar and I'll argue that threat modeling or not threat modeling sorry we'll get there later training should be one of those four it may not be the top of the list there may be others but training should be the one so building a rightsized SDL is the challenge the first thing that we can do if we're not developers we don't

understand this is we We're going to educate ourselves on SDL. So we can go read the Microsoft SDLA. Then you can read the full Microsoft secure development life cycle. Uh there's an organization called BIM building security in maturity model. BSIM.com now it used to be.org but they were sigil has uh ingested. I don't know how you say it. Sigil is now running the BSIM. So it's a.com. The BSIM is not necessarily an SDL. The BSIM is a snapshot of the best practices that the top information security organizations uh in the industry perform. Um they were the original BSIM was uh peer nominated and there were about I think 32 organizations that they looked at and

they came up with 120 odd common practices amongst them and they've listed it out. So it's a great place to go and look and see what practices you you could start to do and how they might help you. So, BIM is a great place to go and read up on SDL and SDL practices. Um, some other sources, the OASP application security verification standard. Does anyone here use that in their day-to-day work? Got a couple. Good. I'm glad to see that. I I asked this question a couple years ago when I presented at ISC squared and no one even knew what it was. So, we're making progress with the ASVS. Hopefully in a couple of years

it'll be as well known as the OASP top 10 is. So I like to think of it as the OASP top 10 is the target that you don't want to hit, right? Because I mean if you have a SQL injection vulnerability, that's a bad thing. The ASVS is the target you do want to hit. Um it's a security standard uh for web applications and it just kind of lists the things that you should be doing the the things that your application should be doing and it gives you a framework to test or verify and validate your application against. So if you are in QA you should become intimately familiar with the ASVS. Now the ASVS is not the

process. Remember SDL is a process. The ASVS are the things that you can do inside of that process but it's not necessarily the process. Okay. Um, so if you don't have an STDL, go to those resources, start reading up on them. There's another one called Open Safe. Um, and Open Safe, one of the things I really like about Open Safe is that they actually have abuse cases. So, they've published a series of agile abuse cases that you can literally pull into your uh uh your agile, you know, management tool, which sort of seems contradictory, but anyways, we'll skip that. Um, and you can use these abuse cases in your testing or as in your development and so

forth. They're really they're they're already predefined for you and they're very nicely done. So, Open Safe is a great place to go as well. So, what we do is we we read up on all of these things and we pull them all together and from them we start to build a secure development life cycle that works. If you are a small fivep person organization, you're probably not going to build a secure development life cycle that includes 32 practices. It includes static code analysis with Fortify or some other six-figure application. You can't afford that. You don't have time for that. You need to figure out an SDL that fits you. Now, when we talk process and we talk SDL and we talk all these

activities, uh how many people here are agile in their shops? Wow, that's fewer than I had expected. So, a lot of shops, a lot of agile teams say, "Oh, process, we can't do that." Right? And I actually have uh very few clients who think this, but I've had a lot of conversations with sort of stodgy people who've been in waterfall for a very long time who say agile, you can't do secure agile. And my take on that is you can't build a more secure application with any other workflow methodology than agile, right? because it's the whole iterative idea of we we wrote it, it's broken, let's fix it and we can get that fix out quickly. Uh I've

I've had places where I've uh worked and clients that I've worked with who have taken 30, 60, even 90 days to get a a critical fix into production. I have an agile team that uh I worked with that had um they were vulnerable to um heart bleed, I guess. I can't remember which one it was now. It was a couple years ago. But because they were all agile and everything was implemented, they just were able to push that change through Puppet in across their entire organization in a matter of about two hours. So once we had the conversation about the vulnerability and we agreed on the right fix and they tested it, they deployed it almost immediately. So all

of the things that we'll talk about today can be done in in in an agile environment. In fact, if you go back and look at this, this looks very waterfall, right? It's actually not because at any given phase in your agile life cycle, you have stories that are in the requirements phase or I'm sorry, let me try that again. At any point in time in an agile organization, you have stories that are in each one of these phases. So instead of sitting down and doing a 3-day long security uh and privacy risk assessment for your application, bing, a new feature drops on the backlog. You look at that feature, you gather two people, you have a 20 minute chat, and

10 of it is talking about the game last night. Um, and and you do the security and privacy risk assessment for that new feature. So you and and and then 20 minutes later, you may be uh fuzz testing a new feature that a dev is ready to drop. Okay? So this is very applicable to the agile world. And so when we build our SDLs, don't be afraid when you read the SDLs, especially like the Microsoft one and the BIM one. They sound like their waterfall. Pick and choose the practices that work for you if you're agile and it'll be fine. Okay, so summarize this first point. If you don't have an SS SDL, get cracking, make

one, read up, educate yourself. If it's something that you don't feel qualified to do, reach out and find help and and and build that agile based on, you know, all the resources that are available. Any questions? You we can go back later and ask questions about this phase two, but does anyone have any questions about this concept? Like how would you get started? Go

ahead. Mhm.

Right. That is correct. So the comment is I sort of said two things about agile. Number one, I love agile because if there is a problem, it can be fixed quickly. It doesn't take 30 days or 60 days to get it to production. The other reason I uh the other the other comment that we've made about agile is bake security in through all of your agile activities. You won't have this waterfally, you know, this month we're doing requirements, this month we're doing design, blah blah blah. But every single day you have activities in each one of those categories.

Mhm. That's a great question and that's the challenge for everyone, right? He he mentioned it over here. The question is, well, okay, if we're already strapped, if we're already short on time, how do we add these security activities in? So, the first concept I'll bring up is, do you have a concept of technical debt in your agile program? What's your what's your technical debt? How do you measure it? 20%, 5%, 10%, or do you have some other way you do it? Yeah. Yeah. Anyone actually, anyone in the audience, but okay. Okay. So, uh the one of the best ways to introduce security is to introduce it into as technical debt. Just keep in mind right agile is about building the

the the right software and and you know so the other thing you do is you modify your estimates a little bit and you say look you know yeah normally we could build you a new UI in in in a day because we're you know agile gods that way but um we're actually going to have to take two days because we've got to do some security work around it. The other thing you do like I said earlier is you rightsize it and you show a return on investment. So uh you may say look we want one sprint out of this release to focus on security. We want to show you what we can do if you give us a sprint

how we can improve the security of this application because that's what agile is all about is returning um return on investment and as getting that return on investment as quickly as you can and having demonstrabably better software. Uh it is a mindset change. Other thing that you can do, this is really the deeper question, which is no matter whether I'm agile or waterfall, how do I socialize the concept of investing time in security? There are a number of studies, in fact, I was just working on slides this morning for someone on this very topic um that show, you know, it uh it costs you one unit to fix a poor design. When that gets to the

development phase, it costs you 6.5 units to fix the same flaw. When you get finally out to production, it's a 30x cost in production. So if you can do your security work in design and if you can teach your developers not to write defects, then uh you've you've won, right? And you've saved yourselves all of that extra time. So that's that's one way to work on it. You really have to build a business case and that's sort of frustrating to us in agile, right? Because we just want to write code. We want to write good code. We want the time to write good code. The other thing is that really when we're when we're writing code, I

can write a SQL query two ways. I can write a parameterized query that's uh um robust and and resilient to SQL injection attacks or I can handcraft my query based on user input. So if I just have a little education, it costs me no additional time to write a parameterized query versus writing a user, you know, a query that's based on user input. Does that help answer the question? Okay, other questions about this. If I don't have an SDL, go go go get started. So, to summarize, read up on some of the STLs that are out there. Um, am I ask yourself, am I more secure today than I was yesterday? If there's just one

activity I could do, um, and then, uh, you know, if if you feel like it's more than you can tackle, uh, go get help. find find you know either talk with friends uh people that you know in the industry bring in consultants you know whatever it takes to get that kickstart and get that going make sure that it's right size all right let's move let's move ahead um next do you have training um I so infoscure we're we're uh poised here event soon to release a product that is all around secure development and the uh the trademark for that product is knowledge is security because That's what it is. So, um, training comes in all sorts of different forms. You can

pick up a developer and you can send them to San Diego to go to the Sands West conference and they can take any number of security courses and it's a pretty big investment. You're losing them for 6 days. It's going to cost you 6K at least, more like 7500 with travel and all that stuff. Um, hey Sean. And uh, but when they come back, they come back with a wealth of information. So, that's one way to train. That would be what I consider the waterfall training method, right? Stop everything, go get trained, come back. Other ways to train though are, you know, there's plenty of knowledge and information available on the internet. So, OASP is a fantastic place to go.

There's the OASP developers guide. Um, and you know, we can have developers reading from the OASP developers guide studying. You can do brown bags, bring in people, you know, I I am more than happy to come do brown bags about security um in your organizations. I I I'm really passionate about the topic and don't have a problem doing something like that. So, feel free to ask me. Uh whatever it takes to get someone in there and, you know, little snippets, little incremental snippets of what I what can I do to be more secure. But training is really really critical. Like I said, if there were four things that you were going to do, I would put

training in there. Sometimes, depending on my clients, I might recommend that you do something like, you know, oh my heavens, your code is so horrible. Let's put a WAT in place before we do anything else, right? And a WFT doesn't protect you from everything, but if I can protect you from, you know, the the 90% of attacks that are coming your way, let's start there and then I might move to training. But training is really really critical. Ensuring that your developers have a training model. Um, I've had a lot of conversations with some of my my friends uh in industry about uh training formal training processes in organizations. So, if you're familiar, uh Cisco had a a black

belt program. So, you know, you started out as a white belt by attending a 4-hour fundamentals of security course and then uh as you went through uh different projects and different training and stuff like that, you moved up all the way up to in order to earn a black belt, you had to do like a week-long external training program. You had to come back and you had to do like a um what do they call it when you're when you're just about to finish college, you have a hands-on project that you do thesis. Well, not so much a thesis, but a practicum. Yeah, a capstone. That's the word I'm looking for. Thank you. It's not that early, but it's

early. Um, so you actually come into the company, you do a capstone that has a significant impact on the security of your organization. So, you know, for instance, for some companies, a capstone might be I'm going to define our secure I'm going to work to define and propose our secure development life cycle and socialize it across the company. Now, not a lot of us engineers want to do that because we don't like to work with people. So, you know, but there are some people who would be good at that. How can you tell, by the way, an outgoing engineer versus the normal engineer? Any guesses? An extroverted engineer. He's the one looking at the other guy's feet.

All right. So, I had to get a laugh in there from someone. Okay. Questions on training. We can be really, really creative with training. There is no lack of information on the internet about secure development. In fact, it's amazing that we are we suck so bad today given all the information that is out there except for the fact like this guy said, you know, our our our organizations don't give us enough time to do that. And um you know, I I liken an untrained software developer to an untrained puppy. They're both as irresponsible, right? I mean, if I have a little puppy dog and I never train the thing, is it going to grow up to be a docile, you

know, contributing member of the community? Not at all. It's going to be a little a little terror. And same thing with developers. I mean, it just I like shudder sometimes when I see developers sit down and start writing code. And when I see the code that I get that goes through for, you know, code review or that I look at for static analysis and things like that, I just it just amazes me. Um, I'll give you an example. I had a I was doing a code review for a login mechanism and it started out with a bool is authenticated equal to true and then it went through a series of checks to make sure that it still was

true. So if you broke at any point during those checks you were authenticated. Congratulations. So that's the kind of thing where you're just like ah really so so training's great. It's it's uh it's a quick hit. You can do it small. You can send people away to go to SANS courses. SANS are fantastic courses. I love them. Um, you can send people away, make that big commitment, or you can do little snippets along the way. All right, good. Any other questions, comments? We're good. All right. Okay. So, next, um, learn how to conduct security and privacy risk assessments. So, what is a security risk assessment? That's where we sit down and it it's not a threat model of the

application. A security risk assessment is more of a high level conversation around what's the appropriate security bar, right? I have uh I' I've worked for a guy at one point who was like, "Yes, let's secure everything. We're in medical software. We're going to secure all the things." Um and then I came with a bill and suddenly the conversation changed to oh well, we can't secure all the things. What things can we secure for this amount of money? So a security risk assessment is simply a conversation around what's the content of the application. What basically you know the three-legged arm of security confidentiality, integrity and availability. We talk about what the acceptable bars are for that and and we

also talk about what are the risks uh in that application. Is it publicly facing? Does it contain PHI or PII? Um, is it uh is it something that we rely on that it brings us a lot of money? I mean, how much money do you think Amazon loses if their shopping cart goes down for 30 seconds? That was AWS, I think. I don't think it was Amazon, but anyways, you know, you're talking millions of dollars. Just 30 seconds and they've lost millions of dollars of revenue. So, in the security risk assessment, we start to figure out what's the highest priority. you know what's our prime directive for this application? Is it confidentiality? Is it availability? Is

it in the integrity of information? So if you are a uh healthcare application, confidentiality is probably your top thing unless you are a primary care application. If I'm a medical professional and I I look at an application and I make a lifethreatening or life-saving decision based on what I see in that that data, then integrity might be the higher priority, right? Okay. And if it's a shopping cart, availability is probably a highest priority. So that security risk assessment allows us to define what's most important. The other thing, like I said, we start talking about risks to the application. Are we going to build it on a lot of open-source software? I don't have a problem with open source

software. I love it. Uh it it is an accelerator like none other. However, sometimes two things happen. Number one, that open source software may not necessarily have been built with security in mind. So, we got to be careful about what we bring into our organization. We are as strong as the weakest link. Uh, the other problem with open- source software is it's kind of a a integrate and forget, right? So, um, what's the name of the new one? Strutshock. I love that the press has become part of the infosc community, right? I just feel so marketed to now. So, Strut Shock, what's the what's the concept there? Well, we're using Struts. We're depending on Struts. and oh, we

didn't have time to upgrade to the most recent version of Struts, right? Um, OpenSSL is a great example of that. Uh, there's all sorts of frameworks, you know, I I have clients who use Ruby and they're like, "Ah, we don't have SQL injection vulnerabilities. We use Ruby, right? We don't have memory management problems. We use Ruby." And then you go back to like, you know, all the different databases that track all the different vulnerabilities, you know, like, well, what version of Ruby on your are you on? and then you can list all of the vulnerabilities in that version of Ruby that they're running. So the thing about open source is when you bring it in, it's an accelerator, but it al also

introduces risks that you don't control and at times risks you're not aware of. So security risk assessment is where you talk about all these things. You catalog all this information. You figure out, okay, well, what open source projects are we going to use and how are we going to track those open source projects so when updates come available, we're ready to take them. All right. So, a privacy risk assessment is very similar to that. In a privacy risk assessment, we talk about what information is going to be stored in the application. How long are we going to store that information and how much of that is really needed? I had a privacy uh risk assessment uh with a

client uh five six years ago medical organization that was collecting all sorts of data about their about their customers, their patients. And and I said, 'Well, what do you have? What do you keep this information for? It's not clinical. And they said, 'Well, you know, we might want to market to them someday, and we should have that information someday. I'm like, well, you've got like 5,000 pieces of information for each one of these people. You don't need it. So, uh, when you have that privacy risk assessment, you you force the business to justify retaining data. And you can also force them to to come up with a retention plan for that data. How long is is marketing

data valid for? You know, if uh I here's a great example. I go on Amazon and I buy something like um I'm working on scuba certification. So the other day I bought a book on scuba certification, right? So then what happens when I go back to Amazon the next day, I get another ad for a scuba book. I go on Google, I get ads for scuba books and I'm like, I already bought it. So your marketing information has a lifetime. And and during that privacy assessment, if you can't convince the team to not store the data, you can at least convince the team to come up with a a data retention policy and eliminate it. How many people here

have a data retention policy in their organization? Other wait, sorry, don't answer yet. Other than forever, you do. You do. Okay. A couple people do, right? So, a lot of companies, they never even think about it and they're just like, "Yeah, how big is your database now?" Oh, that's why we have terabytes and pabytes. So, these risk assessments are are a strategy for knowing your risk while you're building your application. The only other way to to um know your risk profile is to back into it. Right? So, we build this app. We've got all this stuff in our application. Oh, what's our risk with that now? What do we have? Oh, look, we have social

security numbers. Oh, but it's okay because we push the social security number down in its entirety in HTML and then we mask the first seven characters. That's all right. Okay. So, so having these assessments, you can force your team to have conversations about the application and really decide whether or not it's acceptable. Um I've gone to a number of of uh product and program managers and I've said to them this application is insecure and it's a huge risk to the organization and they they're you know their eyes roll back in their head fear uncertainty and doubt is never a good strategy. On the other hand, when I started doing security and privacy risk assessments, when I was done and I

turned to that product owner and said, "You are the owner of this. You and this VP are ultimately held accountable if it breaches." Then they're like, "Yeah, you know, I think that there are 15 risks in here that we should get rid of. There's some features we shouldn't have in the product. There's some data we shouldn't be storing." There's a reasonable conversation. This SDL really is all about what my career has been about. When I first started in information security, well, after Microsoft, when I was first full-time as director of security at an organization, I I tried the fear and certainty and doubt approach a lot and it didn't get me very far. It was very very frustrating. Uh

and then when I started going this route and I started working with management and working with the the teams that I worked with and influenced as a security manager, um we got a long ways because we had conscious conscientious conversations about um our security risk and the security decisions that we were making. Okay, questions. I've been talking for forever. Someone ask a question. All right, I have an incentive. So, I I I do uh like fishing assessments. I'm not trying to pitch those, but I I built these little uh marketing things that have fly ties in them. So, if someone will ask a question, you will get free fly fishing ties right here. Anyone? Come on. It can even be a

dumb question. No fly fisherman. What kind of camera do I use? Thank you. You She asked a question. She gets a She gets a fly tie. Here you go. I use uh Nikon cameras. I have a Nikon D200 and I have a little J1. It's like this big and it takes better pictures than the D200. I love the new Nikon 1 series. Great. Okay. So, let's move on. All right. Uh next, learn how to threat model. Okay. Of those four things that you see the the the theme here. We've talked about training, we've talked about risk assessments, now we're talking about threat modeling. Of those four things, a good threat model is an amazing help. Um, with a threat model,

what are we doing? We're looking at the application from some sort of structural perspective. Usually, especially because we're all engineers, it's very analytical. We sit down, we draw a diagram of the app, right? And then we start to think about what attacks could happen against this application. Uh, and we build a threat model. As a QA, I used to be a test manager at Microsoft. That was my role, even though I led the teams through security because we had no specific security leaders for each team. I loved threat modeling. Anyone here QA, can you guess why? When you sit down and you start to threat model, you say, "Okay, so we have an end tiered application, right? Oh,

yeah. We have a three- tiered application. Okay, so we've got an IS server here. We've got a uh another is we have a a Windows server running the business layer and we have a Microsoft SQL database, right? Yeah. Yeah. Yeah. Is there anything else? Well, you know, and then we we we actually the business layer calls back to this system. Okay. So, we put that on this thing. Is that it? Oh, no. Actually, the business server also logs to this system. And as you build these threat models, you come up with all sorts of functionality that no one ever told you was going to be built into the product. So you actually do your QA job better in addition to

doing your security job better. It is awesome to see developers go through a threat model and realize the footprint that they've created, you know, because like, wow, we've got this awesome service that's running here and we call out to, you know, XYZ service to get data and we do mashups with this service and, you know, we're we're pushing data to these guys and and all of a sudden they step back and they're like, "Holy Hannah, we've got a ton of stuff going on here." So the threat model process is great from an overall engineering perspective period. It forces people to definitively uh set down what they do, what their application does, what the components of the applications are and

what the dependencies are. You would be amazed if you take your threat model and then you start asking people, okay, well what open source components are used here and what are used here and what are used here. Pretty soon you find out that you've got like four different versions of Tomcat running. Well gosh, we could get a lot better if we just synced everything up to the same version, right? So, there's a lot of efficiencies that come out of threat modeling besides just the security perspective. The nice thing about threat modeling, though, is you begin to uh develop another uh security strategy for the application. You're looking at the different components and how they communicate with

one another and you're finding ways to make it more secure. For instance, you know, um nothing in our data center communicates over encrypted channels. Well, it'd be really easy to put IPSec in here or to use uh SSL certificates so all of our servers are talking to each other and we uh eliminate the risk of uh confidentiality breach within our data center. Layered security, right? And a lot of times that's what happens with a threat model. You'll have uh I used to work for a VP of development who really should have been called the VP of sales and and his thing was we're secure. We use we use Windows forms and SSL. And I'm like, okay, great. It's a

good start. I know your code underneath. Uh, so threat modeling, learn how to conduct them. It uh it does not take a developer to conduct a threat model because as a developer or as a threat model conductor, you are asking questions, probing questions. You start with a network. We start with a blank diagram and you say, "Okay, what are we going to put on here? Put the user's browser on. Let's put the server on. Let's put the database on. Where are the boundaries? Where are the trust boundaries?" You keep asking questions and the best question you you can ask is, "Is there anything else? Is there anything else?" I can do a a threat model. I I I had a a client um based in

New York who go out once a year. It was awesome. I love the food in New York. Um and we would sit down and we would threat model that application. And you'd think if after you've done a threat model two years in a row that the third year would be quick, but every year it seems like they completely rearchitected it. And I would ask, is there anything else? Oh, yeah, that's right. We added this service. Is there anything else? Ah, we added that service. Anything else? Ah, we put that service in. So, uh, it got infinitely more complex each year as well. So, it doesn't take a real technical person to do this. It takes

someone who's passionate about it and and has a little bit of information. So, if you want to learn how to threat model, I'm doing a a session at 1:30. We're actually just going to bring up the Microsoft threat model tool and we're going to threat model um the elk stack. All right, questions. Come on, you guys are not You totally let me down here, Dan. All right, Dan's going

fishing. Uhhuh. What are the most common qu uh objections to threat modeling? So, the the the most common objective to implementing threat modeling is it's going to take more time. And uh the the the best answer to that is what I just kind of shared which is um yeah but it's super vulnerable or let me try that again super valuable not vulnerable valuable um in in that we are going to gain from a security perspective but we're also going to gain an overall better understanding. If you invite your QA team and your ops team to a threat model they'll both be stunned. They'll be like you didn't tell us we were doing that. or if you have a large

organization with multiple operations teams, pretty soon they start trying to talk to each other. They're like, "Really? You're doing that? How you do? How'd you do that? What are we doing this?" So, there's a lot of value in general. Um, I think the number one most the biggest objective that I get to anything security related is I don't want to do this because if I do it and I know there's a problem and I can't afford to fix the problem right now, I'm going to be responsible. The best way to overcome that objective, there's a couple of ways. Number one, HIPPA is very, very clear. If you could reasonably have known that that vulnerability existed in your

application, but you didn't know, doesn't really matter. If you could have reasonably known, then you should have fixed it. So, um, you know, number one, you have the compliance hammer that you can use. I try not to use that. I pull it out as a last measure. Um but you can you can also uh point out that you know by knowing all of the vulnerabilities in our application we can stack rank them and we can say we think this is the biggest risk and we think this is the next risk and we think this is the next risk and if you document that and you go at it appropriately and start attacking those risks top to bottom. If this one happens

to pop and you get breached because of that risk that was number five, the only thing someone can hold you accountable for is you picked the wrong risk to prioritize. And you can say, well, yeah, but you know, here's the email memo between us and our security manager, and here's the rationalization we put behind prioritizing that as number five instead of number one. So um and more importantly you also you know I one of the best managers I ever worked for her uh her mantra was you can't boil the ocean. So by going through the threat modeling process you you identify additional risks and you can put them on the list of risks and you can prioritize

that list of risks and you can say that's where we draw the line. You don't have to worry well we worry as security professionals. We worry about all those risks we didn't address but you don't have to worry about it. you can focus on the top risks that you've identified and attack those risks. So, good question, Dan. Uh, other questions, threat modeling. All right. Okay. I think this is this is it. This is our Oh, penultimate slide. Sorry. Do you have an incident response plan? How many people here have not a generic corporatewide incident response plan, but a an incident response plan for a given web application? or do you have a generic one that that applies to your web

applications in general? Or do you just have an incident response plan that says light our hair on fire, we're screwed. You're better off than anyone else if you have that. Right? So, there are levels of incident response, right? The first level of that incident response plan just identifies a few key players and what you're going to do if an incident pops, okay, a major incident. And the the the number one rule in that first line should be developers don't talk to anyone outside of the company, right? Because what happens, right? You know, let's say you you you're a major healthcare organization here in the area and you get breached and you got a developer who's hacking away at it and the phone

rings. Hi, this is KSL. Oh man, yeah, well, we almost got it fixed because we love forensics, right? Forensics is fun and it's exciting. And as much as we hurt when someone breaks our app, an elegant hack is really kind of cool. So, we're on the phone with KSL. This is the most awesome hack I've ever seen. This guy came in here and he pivoted there and he used this blah blah blah. Right? Worst thing could ever happen from a PR perspective. Okay? So, make sure instant response plan, you have one person. It's an executive and that person talks to the press. No one else. Okay? So you can have an incident response plan that just

says in our organization if there is an IT incident not an event but an incident then these five people get together and they plan the response. The next level down is to say okay for web applications these are the people that get together. The best incident response is the one that says for this application when there's an incident, you know, this executive is notified. They bring in the senior direct leader of development and that person taps this individual on the development team or these three individuals on a rotating schedule. Here are their phone numbers. So, you know, you can get the right people in the room at the right time and get your fix put

in place. Okay? Um, and they'll have other steps in the incident response. If you don't have an incident response plan, the worst time possible to write one is during an incident. It's awful. Uh I helped a client through an incident last year in January. Um they it wasn't a huge deal. Their WordPress server uh got owned. Um but they had no clue what to do. And so I'm like, "Okay, let's do this. Go out and grab me an image of your WordPress server. How do I do that?" Well, I I'm not sure. I I don't know your WordPress server. Do you not know how to get an image? No, I don't know how to do I don't I work in Windows

and we just bought this other company and they're all Linux and I don't know how to do imaging on Linux. It's real. These things happen, right? Okay. So then they call the ISP and they find out, oh, we can't image that. And then all of a sudden their Windows servers start popping. So I'm like, okay, grab an image of your Windows server. Let's look at what's going on. I don't know how to image a Windows server. Okay, so you write your plan before it happens and then you execute it before it happens. You don't have to do that. Go online, find an incident response plan template. The SANS templates are fantastic. Get the go-ahad from your

senior management and from engineering to build an incident response plan. Bring the right people in the room and say, "Okay, how are we going to define an incident? How are we going to respond to an incident? What are we going to have to do? You know, who's going to do it? Who are the contact people? What things do we need to know that we don't know today?" And then let's go practice that. put it on the backlog as technical debt and exercise it as technical debt. Okay, so that's that's incident response planning. Questions on that? I thought we would not have be pushed for time, but we kind of are. So, let's go to the last

one. Do you conduct a final security review? The final security review is easy. Uh, how many people here saw the movie Apollo 13? Pretty much everyone. Great movie, right? What happens before they launch? The guy in the nice vest, what does he do? He goes around the room and he says, "Temetry, are you ready? Telemetry is green." Um, you know, I I can't remember all the different groups, but each and every individual group, are you green or are you red before you hit the launch button? I don't know if there's a button. I don't know how. Anyways, let's keep going. So, um, that's what we do in a final security review. We have an SDL

defined. We have activities we're supposed to perform in the final security review. We make sure those activities were performed. We make sure that any action items that came out of that activity really happened and we make sure we're happy with the results. It's not just enough to say, "Okay, we do static code analysis. So, we're good. We here's here's the report. We did our static code analysis. Let's release." Well, what if there's like 75 criticals in that one? Let's make sure those got fixed. That's part of your final security review, right? So, this is your last check. This is your opportunity for everyone to say, "We did what we're supposed to do, and it's okay." If there

are problems, exceptions, and senior management wants to go out the door with those exceptions, senior management says, "We recognize that there are exceptions. We recognize the risk, and we accept the risk, and then you go out the door. That's your final security review." It's pretty simple to do, and it can be very, very straightforward. I mean, it can be a 20-minute meeting if you want to. Some some organizations actually like in their final security review to sit down and look at every artifact. That would be very anti-agile. So do do the final security review that fits you. Okay. Questions on final security review? Questions on how do I Yes.

Yeah, I have. Unfortunately, there are some developers who don't care. They will write whatever hacky code they can to get out the door. And uh there's two strategies to that. One is to be persistent, right? And try to work through that. try to work with senior leadership to establish bars and then if that developer doesn't hit that bar it's up it's between them and their manager. The other thing to do is to say at the certain point is this going to be career limiting for me to stay here. It's a good question. This whole conversation all comes down to whether or not your organization cares. And if your organization doesn't care, you you you have a real uphill battle to fight.

The good news is more and more and more organizations do care. Uh, you know, five years ago when I would talk about application security, people were like, well, whatever. We don't have time for that crap. Now more and more people are are at least saying we want to do it. We don't know how and we don't know how we're going to fit it in, but we want to do it. It's important. Help help us do it. That's a good question. For a minute, I thought he was going to say your whole presentation. I didn't understand it. Next question. Come see me. I'll give you a fly fly. Any other questions? So, either it was that

overwhelming that everyone's like, "Oh crap." It was that boring and everyone's like, "Oh crap." Or I really did an amazingly fantastic job of explaining how to do a secure development. I don't think it's the latter, although Philip says it is. All right. If you have any questions, come see me afterwards or look for me. I'll be here. I'm going to be here all day. I didn't I couldn't come yesterday, but I'm here all day today. Uh, and I'm always happy to talk. And if you want a brown bag, I'm glad to come and do a brown bag at your place. I'm passionate about it. I'm a terrible con consultant. I give away all sorts of

time for free because I care more about it getting done than well, I want to put food on my table, but that's about it. So, okay. Thank you very much for your time. I appreciate it.