Building AppSec In

development at NVISIUM. Is that how you say it? Okay. And wrangles the research efforts into all areas of application security. So, an advanced application security professional with years of security experience, Seth has worked in a multiple disciplines from software development to network protection as a manager, contributor, and speaker. So, Seth explores the world of app of application security via @SethLaw. Okay? And then, before we get Seth, take it away. They asked us to ask everybody to um please sign up, go talk with the vendors, sign up on their list. That the vendors need some love downstairs. I think that's where they are, right? Set up. The vendors need some love, right? Yeah. They made this all possible, right? I

mean, yeah, it cost us a little bit as far as getting in the door, but they definitely stepped up to the plate when we needed them so we could get the space, we can get the badges, everything that you see really comes from vendor contributions. So, go give them some love even if it's just, "Hey, thanks," right? Okay. Thanks, Seth. All right. Very good. And should I say how long? Oh, it's fine. I'll Okay. We got it. So, we're going to start cutting these down to about 40 minutes since Jason went so long. He's a little long-winded. I typically tend to be as well, so we're going to we're going to cover a lot of

stuff. Um Like she said, hold on, let's see if I can get back to my slides here. Uh my name is Seth Law, I'm the director of research and development at NVISIUM. Um I've been a developer, I've been in security. Um my development background was at Iomega, if you all remember that. Uh you know, years and years ago, the click of death that killed us all. I I'm I know I'm getting up there and I'm dating myself, that's okay, right? Uh if you want to talk soccer, we can talk soccer. I like RSL um or we can talk Arsenal versus Man City or Man U if you really want to get into it, right? Chelsea, hey. Woohoo. Got to dig

Chelsea. All right, what am I doing here today? We're talking building appsec and we're talking about building an application security program. Is this mic working okay for you guys back there? Kind of feels like it's going in and out to me, but that's cool. You want me to switch to hand?

All right. Is that that better? Okay. All right. First things first. What is this? Shellshocked. Yay, right? This one little string causes all sorts of bad things to happen. Um now, whose fault was Shellshocked? Who's to blame? BSD? I don't know. It it Is it Richard Stallman, right? It's bash, right? Or it's the shell at some point. Um and that that's really at the heart of what I want to get out today. Your application security program, like what you build internally, all it all boils down to who's responsible for the vulnerabilities within your code. Uh you can you can point at your developers here, but most likely they weren't the ones that implemented this inside of bash. It goes

back to some open source developer somewhere, and yet it bit us all in the butt right? So, where where does application security sit? Who's responsible for application security? Um I In this room, I mean, obviously you're up here. We got better representation here than I had at Saint Con, so you know, I'm only I'm speaking to, you know, not three people, but at least a few of you. Um Who's responsible here in this room for application security? All right. So, we've got a few people. Good. Um Are you developers? Cool. Good. I I I love to see that because when I first got in the industry and we first started talking about application security, it was all the network

security guys that just decided, "Hey, I know what SQL injection is." Or, you know, it was probably more management went, "Hey, this is security and it has security in the title, so I'm going to hand it to the network security guys that run my firewall." And then they turn around and say, "Hey, you've got SQL injection, but I don't know what that is or how to fix it, right?" So, application security goes up and down the stack, right? Um we've got all these different uh technologies and people that talk about application security, but really it should holistically be anything that your application depends upon that that may affect the overall security of your application. I mean, bash is a

portion of your application sec- security program, and you've got to have some purview into that. Uh some of the new devops technologies and things like that, whether it's Docker or something along those lines, helps us in that just because we can deploy things easily and we can push things further. But each of these different pieces, I mean, you've got sands and you've got OWASP that um tell us what application security is or where vulnerabilities exist, also got the technologies, the stack, you know, Rails, the framework you're using, you may be using Tomcat, you may be using Apache, uh you may be using BSD or Linux or whatever underneath the hood. It all affects your application security.

To kind of frame the discussion today, we're going to talk people versus technology because, you know, that's that's really where the rubber hits the road, you know, where where is that fine line that fits between those two? If you're the guy that's sitting around um you know, coding an application and you're up against Terminator, who's the one that wins, right? Who who who takes it over and who actually runs with your application security program? From an OSM OSI model model perspective, uh application security, right? We've got the different levels, but everything from physical security Um let's see if I can get all the way up there. Uh I went too fast. To application security, right? Um this

is our traditional look at the technologies that are out there and where we kind of classify the different security programs, right? Physical security, you know, it's your security guards. They cover the data and physical layers. Network security is your firewalls, your IPSs. Uh they cross over a little bit up into the application security space um and into those higher levels of the OSI model, but they still don't go as far as we traditionally can. When we're building out a program, we're really digging into the code itself. Now, the major issue um is to fit application security into the same budget that we fit everything else, right? Um if you're talking about cost-benefit analysis, you know, I'm

getting into the management section of this, but this is really important for actually funding your application security program, right? Um we are as application security professionals, we are competing for the same dollars that network security typically competes for. Um if you're in an organization where they fund it through the development or through software engineering, you are lucky compared to where it normally sits. Um I've had discussions this week already with people that are saying, "Hey, you know, application application security is great, but I'm a you know, I'm a network security admin and they came in and gave me a breach web application firewall. I implemented it. I don't know what to do with that, right? Uh I

So, you know, after 2 years we took it and we threw it away because it didn't really provide any extra security to us because it was a network security guy running it. Um so, in that case it was a it was a matter of, you know, resource problems that they have that they did not identify the correct resource to actually run the the technology that they wanted to put into place. Um So, from an SDLC perspective, these are the different the different phases of an SDLC we're going to be talking about today. Um they line up pretty closely with different application security um activities that we can perform, right? Everything from threat modeling to dynamic analysis. And that's really

what we're going to talk about during each of these phases. Um each of these does prevent I mean, we skip any one of these steps and bad things are going to happen, right? If you do a Google search nowadays for breach, over 10 million items are returned. Just a Google news search for breach. Granted, you know, this was yesterday, the top of the list here was Target, you know, talking about them actually paying people for the breach problems that they've had. Um can you know, up to $10,000 per per person if you've had problems because of the Target breach. Um but you've got all these others. I mean, this is just within the last year, right? Anthem is

the latest big one, uh TJX, JJ, Home Depot, Target, right? They've all been breached in some manner. Your data is out there and it's usually the result of, you know, some sort of application security problem. So, let's jump in. Let's start with Let's start up into our appsec SDLC. First thing we want to talk about is analysis. The analysis phase of your of your life cycle um is typically where there is very little tech involved, right? Uh it's mostly a political battle between different parties within your organization. What is it that you want to do and how do you want to accomplish it? Um and along those lines, you you traditionally fall down into different

view sets, right? Um you've got the security view, which is, "Hey, we are a bunch of geniuses and what we're trying to do is convince lazy developers to do something they don't want to do, right? How many times have you run into that? Uh either from either side. But on the flip side, we've got the development view that we are Jedi masters that can code anything and build things that, you know, make the business run, and security is just a bunch of dictators that happen to tell us no all the time, right? When was the last time you heard no from security? Every day, right? You know, I I I mean and you understand why they're saying

it, but a lot of times there's there's not this communication that goes on between the two the two parties. Um from a management perspective you're all just a bunch of geeks. And I don't really care, right? You're both experts in your field and I don't know where no way we're arguing about who's the better captain. Um because really what it boils down to is I pay both your salaries and we just need to get stuff done. So, what's really needed here? Um the important you know, I mean IT crowd obviously, but the important link that you have in your organization is right there in the middle. Right? The person that is trying to communicate application security needs up the chain.

Right? If you can't build that case for money, uh you're number one you're going to be underfunded, you're going to be over you're underfunded, understaffed, and it's going to cause all sorts of problems down the line. It's going to turn your app into a complete raid. And that's not what we want. So, what what you what can you do, right? Uh we can take this formula and present it to management, but really what does this mean right? What? More money. It does mean more money. Um but if you come to them with some mathematical looks like a mathematical model, right? But it's not really a mathematical equation. Uh this really just equates to hey, what is it that we

should really be worried about? Um you know, it's getting easier, you know, again go back to that Google that Google slide and search for breach and say, hey we we really don't want to be the next target. I I mean, not only did our stock price drop, but now we owe thousands of consumers millions of dollars, right? So, there are technologies out there. There's people that are trying to help out. There's semantic. They've got a data breach calculator where you can actually go in and kind give them some data about your organization. They'll give you a score uh and a you know, small list of things that you can work through. You know, that's not the best way to go

about it. Really you should be doing some sort of threat modeling. Um this is, you know, the analysis phase, right? Uh if you want to build a new app a new mobile application, what are all of the threats that go into that, right? Do you need to be worried about people sniffing Bluetooth off of that phone because you're transferring credit card numbers between the terminal and the mobile device over you know, Bluetooth LE LTE or something along those something along those lines. Uh you got to get people to sit down in a room and white board this stuff out. Now, how many of you have ever done a threat model? Hey, this is awesome, right? Most of the

time I ask that question um and I get like maybe one in, you know, 50 that have actually done a threat model just because organizations don't typically pay for people to sit around and think about cool ways to break into their stuff, right? It's just it's kind of counterintuitive, but that's really what needs to happen. Um if we sit down and we can figure out, you know, what sort of attack vectors exist, it's easy to extrapolate back and you know, analyze where we need to put money and we need to put dollars. Does it make sense to upgrade our firewall when, you know, our application is vulnerable to SQL injection? Yeah, probably not. Throw that money at

development versus, you know, the the network team. There are a couple uh technology instances that are out there, right? These are most frameworks that you can use for running a threat model. Microsoft is definitely uh one of the you know, premier processes or the the premier frameworks for doing this. They've got their threat mod threat modeling tool that actually just got updated within the last year. Um Trike and Octave are both open source and you can go pull those down and use them as well and they do a pretty good job. On the people side of things, um everybody's going to be involved in this phase. Uh if you're doing a threat model, you probably don't want your project

managers in there, but you do want the technical folks, right? Your architects, your your application owners that know about what they're trying to build and why they're trying to build it. Those guys have a different viewpoint than the rest of us. Um Yeah. Consultants, you know, you know, come pay us to do it. No, just kidding. You don't have to do that. But there are some issues there, right? It's a time investment. Um whether or not you want to do it on all your projects, what's your methodology, how you actually implement that across the board uh becomes a very difficult. So, you got to think about some of that. Okay, so let's jump into the next phase,

design phase. Um this is where we talk more specifically about your uh your implemented SDLC. How many of you use a waterfall method here for implementing or for coding? No one uses waterfall? Agile? Okay. I'm seeing more and more agile. What do the rest of you use? Cowboy. Wow. So, somebody's just, you know, coding in production. All right. Yeah, exactly. If you don't have production data, you can't test it. Look, it's so beautiful though, you know, this whole waterfall methodology. Um you know, this doesn't quite equate to that, but you know, it is it is along those same lines. Definitely the two most common that we run into are waterfile waterfall and agile. You know, agile I like a cheetah

there and you know, you spin around and around and around. Um but a company I worked with you know, claimed to make this switch from waterfall to agile. Like they'd been around for 20 some odd years. Uh they were what their their whole um production process was built around the waterfall methodology um and they said, "Okay, at some point somebody read a book and decided we're moving to agile." Now, how hard do you think it is to change an organization from waterfall to agile? Is it is that an easy thing to do? Right? That's just a weekend, right? To change everyone's mindset. Yeah, it wasn't until, you know, initially they said this and the development teams

they, you know, structured them into their agile teams, started doing sprints and things like that, but then they forgot, oh guess what, you know, if we don't do QA and production support and everybody else, it doesn't matter what we do on the on the development side. Yes, we may be releasing more often, but you've still got the production support people that don't trust any of the the QA people or the development people. So, you hand them a jar file and what do the production support people do because they're, you know, they're all, you know, 50 years old and they don't want anything bad to happen. They take that that jar file, they explode it out and

actually extract the classes and put them into place on the in the within the application in production. Yeah, it's a bad way to deploy an application, right? So, that's not the way the developers test it, but that's the way that the production support people did it. So, I mean, it took them about 3 years to actually make that switch where it was running and effective and even now, right? Now it's like, oh well, we've got agile in place. Let's do continuous deployment. And yeah, that's going okay. We'll see how it ends up. In this phase, you really need to talk about requirements, right? Um you're building a design for an application. You're designing all sorts

of UI requirements and functional requirements. If you're if you aren't in the discussion as an application security professional um defining the security requirements for that application game's over, right? Uh there's no reason that well, you're going to end up with simple mistakes that probably shouldn't exist in that code just because you weren't able to specify that up front. Um your requirements should be simple, testable, and transparent just like anything else, right? If you can't test that hand it out if you can't explain what you need from a security perspective to a QA person who has never heard the term XSS before then definitely the application is still going to have problems when it when it

hits hits your production instance. Um there's all sorts of people out there and organizations that will tell you how to build security requirements, right? You got PCI, McAfee Secure, right? Google Trusted Stores, and OWASP. But, right? You got to remember, wait. Compliance does not equal security. If the only thing you implement is the OWASP top 10 what are you missing? Right? Buffer overflows, right? Anybody heard of those? Yeah, they may be an issue. Just depends on your application, of course. Um let's talk a little bit about Google Trusted Stores. We did some analysis just recently on Google Trusted Stores. Do you know what Google Trusted Store means?

Bueller? Anyone? The only the only restrictions that Google places on getting a uh or being a Google Trusted Store is number one, you answer customer complaints quickly, you know, within a specified amount of time. I think it's something like 24 to 48 hours. And number two you take returns. That's it. Oh, well well, yeah, of course. There's always some money that goes along there, but um there's no checks for SSL. There's no checks for security. We found um shopping carts that were, you know, passing uh passing session IDs in plain text. It was easy to hijack someone. We actually saw credit card numbers flowing back and forth with Google Trusted Stores in plain text. Um there's there's all sorts

of issues with this. I mean, it goes back to like the whole old, you know, hacker safe days where they'd just, you know, scan your application and you could pop something up there that says, hey, they scanned me for the, you know, the you know, they used Nmap to scan my server and didn't find anything, right? It doesn't mean what we think it means. But to a consumer, this says, hey, Google trust this store and it should be totally kosher for me to actually go there and shop. So, what do we what do we need to do? We need to train people, right? Um and that that goes all up and down your organization, whether that's your, you

know, your CEO, so he doesn't, you know, just go give his password to somebody else, um all the way down to your secretaries. What do they do with information when they get it? Um and, you know, just just to put it out there, I'm going to just tell you I'm an idiot, right? When it comes to things outside of um security and what I do on a daily basis. And that's what you got to remember about most of the people that you're dealing with, even even on your development teams, is, you know, they're idiots, right? They don't mean to be idiots and it's not not a bad thing, but they are. And so are you, right?

Let's see. I wanted to show this video really quick. Let's see if I can get it to pull up. Okay, I'm just going to go like this. Oh man. Running slow here. I I don't know how many of you have seen this. I I'm not sure how well this audio's going to work here. Well, You know, we've been hearing a lot about cybersecurity lately. Can you guys hear that? Actually because of what happened to Sony, companies and individuals are more concerned about the safety and privacy of their information than ever. President Obama has unveiled a number of new proposals this week to crack down on hackers and he plans to address this in the State of the Union

speech on Tuesday. And it's great that the government is working on this, but the truth of the matter is we need to do a better job of protecting ourselves. You know, the most popular password in the United States is password123. And as long as we're as long as that's the case, we're vulnerable. So, today we sent a camera out on the Hollywood Boulevard to help people by asking them to tell us their password. And this is how that went. We're talking about cybersecurity today and how safe people's passwords are. What is one of your online passwords currently? It is my dog's name and the year I graduated from high school. What kind of dog do

you have? I have a Chihuahua and a papillon. And what's his name? Jameson. Jameson. And where did you go to school? Um I went to school back in Greensburg, Pennsylvania. What school? Uh Hempfield Area Senior High School. Oh, when did you graduate? In 2009. Oh, wow. It's like my cat's name and then just like a random number. Okay. And you say you have this cat for a while? Yeah, she's my childhood pet. Aw. And what's her name? Her name is Jolie. Jolie. So, I got password of yours would be Jolie and then a number. Yeah. Like number one? Uh like my birthday. Oh, when is your birthday? Uh June 12th. Oh, nice. What year were you born? Uh '95.

Oh, great. So, Jolie 6 12 95. Got it. So, you need to give my password right now? No, I cannot do that. But we all want to know what it is so we can tell you if it's strong or not. Oh my goodness. Um let me think. Okay. One is Tel Aviv. Yeah. 468 and then Israel. It's it's only three, but it's, you know, it's uh for me it's strong enough. Ireland 1234 Gemma. 123. Spell g e m m a. Well, most of them are Italian. Oh, beautiful. Yeah, so like Like what's a good Italian password? Uh my grandma's name. And what's your grandma's name? Uh Maria. Maria. So, Maria is your password? Oh, yeah, now you know my password.

Oh yeah. Yeah, but the important thing is he he learned I am Jimmy Kimmel. Did you know All right, so that's what we're up against right? Honestly, you know, yeah. The best is the guy that the foreign dude that's like, "No, no, I won't give it to you, but okay, you asked multiple times, so I will." So, that's what you got to remember is, you know, these people were taking that outside of their comfort zone. Um and if we're taking them outside of our comfort zone, think about how you are outside of your comfort comfort zone, right? You know, um just last night, you know, I talking to a doctor, you know, I had you know, my

daughter would had an asthma attack, so we went in, we talked to a doctor about it. He's describing all this stuff and I'm like, "Oh, yeah, you told me this like you know, this is not the first time that we've talked to you about, you know, my my daughter having this condition and yet at the same time all of a sudden I don't have the right medicine, I don't have whatever it is because it it slipped my mind and it's been been in the past. So, he's looking at me like I'm a complete idiot because I we should be able to do this. We've had this discussion before. Um so, you know, we shouldn't be slapping them up

upside the head with, you know, guess what, you shouldn't be writing your password down like that. It's just got to be these gentle reminders. Got to be this training that needs to go on. And there's all sorts of options for us to actually do this training, right? You're in person, your online, your CBT, there's requirements for doing training, uh whether that is, you know, the PCI training, the self uh the security awareness training that goes that you we all have to do every year and you know, roll our eyes when we do it, but it but it is important to remind people about the security aspects and what they are dealing with. And the same thing goes

with developers, right? Um you know, a developer training that needs to dig into the code and needs to actually show them, talk about the basics. We all need to be reminded about the basics. We do that. I mean, that's why we come to these conferences. Yeah, granted there's the new hot hotness, whatever that may be, uh but the basics are what pay our salary on a daily basis. So, in this phase, uh we got, you know, a variety of different personnel that need to be involved, right? Designing the requirements, figuring out what the requirements are, the third parties. We got to understand the risk in the tech. Um and, you know, everybody has to work

together, you know, and there has to be a specific amount of time dedicated to this, but you don't want to get stuck in the mud. Um you know, I dealt with an organization just you know, just a few short months ago that was trying to roll out a whole new Hadoop cluster, but could not for the life of them decide what version of uh Cassandra or, you know, basically no sequel database that they wanted to use on top of the data itself. They spent 6 months talking to different vendors about just this one issue, right? They they'd go they'd talk to one, they'd be like, "Oh, well, we're implementing this feature." So, they'd wait with them

while somebody else came and sold them another version and, you know, by the time it came down to it, the organization just fired the whole team and replaced them because they couldn't, you know, put rubber to the road and actually make a decision to move on and implement what needed to be done, right? At some point you just got to you got to cut it and move on to the implementation phase, right? Start building that code and start putting a solution into place. So, this is where, you know, the rubber meets the road, we got to know if the the code meets the requirements, what are those whatever those requirements are from our perspective, you know, our

security promises that we've built out during the design phase, during the threat modeling phase. Um note that the security should be a feature within your application. If it's not a feature, it's not going to be important. Hence the reason, if it's not a feature, if it's not a requirement, it's not going to be important, it's not going to be in there. Involve QA. I I always say and I tell people all the time, you know what you know what pen testers are? They're just glorified QA testers who document poorly. Really, right? You look at what comes out of a QA team and how they're trained to do QA testing and it's it's leaps and bounds above what comes

out of most pen testing teams, right? It's not some cra- crappy PDF, but it's something that's actionable for the development organization to go in and actually fix bugs, change things, and make it better. So, involve QA, you know, give them your security tests, right? There's no reason that you need to hold those close to the vest. But remember, there is no silver bullet, right? Um at this phase, you're going to start dealing with multiple different vendors. Um we've got, you know, uh you know, we we talk about static analysis tools. Come on, let's move on here. I know. Uh come on. So, we're talking about static analysis tools within the implementation phase, right? And you know, anytime that you're

writing code, you're going to be scanning it. Somebody's going to be looking at that code, whether it's a tool like an IBM, HP Fortify, you know, Coverity, Veracode. You know, all these have a static analysis tool that they will will sell you. Um who here has dealt with a static analysis tool before? Sweet. Okay, so what's the problem with it? I'm going to pick on Justin because I know his name is sitting up here. False positives, right? How much time do you spend actually like filtering down what comes out of Fortify and and yeah, basically making it useful for a developer, right? Does it take a while? Oh yeah. Yeah. Um I, you know, back when I worked

for FishNet, this is, you know, a few years ago, we worked with a very large um retail operation. And there's a couple down the road here, I'm sure you'd know who they were. Um but they decided, "Hey, we're going to go ahead and we're going to implement Fortify across the organization." Handed all the developers, but the code was so poor and it was, you know, so old, so, you know, there were so many vulnerabilities that came out of it that we had to actually go in and write a filter list of the top 10 vulnerabilities that we could identify because everything else just overwhelmed the developers too much. I mean, when you're dealing with developers across an organization, you

know, when you're talking, you know, 15,000 developers total worldwide, it's very difficult to say, "Hey, uh you know, here's 20,000 vulnerabilities, go fix all of them in the next 2 days." Right? That that just doesn't happen. So, they had to we had to actually filter it down to that list. They're like, "Okay, if we can take care of these top 10, then that means that our risk level dropped by like maybe 1 to 2%", right? And there were still so many outs that were that were out there that it was still an issue, but they they just approached it in that manner. But what does that say about these tools, right? There's so much data coming out

of it, it's not actionable. If if it's not built into their the development process, it's just like finding that needle in the haystack, right? And with the static analysis analysis tools. Um All right, if we've got that many to take care of, it's going to be an issue. Uh this is an example of one, right? This is just Fortify, but again, you know, so many There's only so much that you can do with that. So then you revert back to a manual code analysis. But again, you're searching through all the code for specific vulnerabilities. And who do you get involved, right? Is your security team mature enough to bring them in to actually talk about how SQL

injection is remediated in Rails? Um if the guys don't know that, then, you know, why are you having the discussion with them? Why are you bringing them bringing them into that discussion? So, you know, we're all, you know, we'll involve the architects, the developers, um the security team as as we see fit, but really, implementation phase needs to be owned by the development organization. These tools are not security tools, they are development tools. Um if there's any way that you can find yourself a security developer on the team itself, that's going to go uh it's going to go so far to actually fixing the problems that pop up there. So, traditionally, you know, this is the

phase that we, you know, we we will see some security involvement. We do see it rolled out in a lot of organizations, but it's not always implemented that that that well because it's security that's pushing a tool on the developers. It's not the developers going out and choosing the tool and putting it in place. So, then we get to the testing phase, right? This is this is where your traditional, you know, automated versus manual discussion comes up. Um but again, there is no silver bullet, right? The vendors will try to sell you this all day long, "Hey, just buy our next-gen firewall and you'll never have a problem with application security again." Oh, wait, wait, wait. Oh, oh,

well, well, you you found SQL injection? Well, did you run, you know, our our, you know, scanner against your code as well? So, we can sell you that. Um and that'll fix all your problems. You know, you'll never have an issue there. Um but again, you're going to run into false positives with that. Come on. I did too many x's here. There we go. There's, you know, So, not only do you have vendors, you've got free tools that are out there that'll do the same thing, right? Who do you depend on giving you the best result set? Um When you When you look at what these tools are actually doing, though, it's just a matter of pounding their way into

your application, right? I'm going to test every input that I can possibly see and I'm going to throw every I'm going to throw, you know, the kitchen sink at it with the rest of the house to see what sticks and if anything does, then I'm going to throw up a flag. Um but what are the pros and cons here, right? You know, where where do we have problems with this, right? I I I assume that some of you have run Burp Suite before before or AppScan or WebInspect, right? Okay, what is it that uh you know, AppScan is really good at finding? Just one example of a vulnerability. Any ideas? Info leaks. Info leaks? Yeah, it can it

can tell us, "Hey, guess what? I saw this in a in a in a server header", right? Uh cross-site scripting does a pretty good job of telling us where cross-site scripting exists. Um it does a very poor job of authorization issues, right? If I can jump from one account to another, if I can see someone else's account, the the the request still looks valid to the scanner, so it doesn't know if that if that information is associated with one account or another. You've got to get a manual tester involved. Um All right, so here I've got an example of cross-site scripting and a couple other things. This is AppScan, um but the manual assessment, you got to turn

those those hackers loose, right? You got to turn your security team loose at some level. Um but again, right? Why not have QA run that for you? So, this becomes, you know, somebody that's just sitting, you know, some lady that's sitting in a room, right? Whatever. But this is more real expectation if you actually want to implement this. Um the problem is, where do you find these guys, right? Um not too long ago, you know, the Army came out and they're like, "Hey, we're going to create this cyber command and we're going to hire 30,000 security professionals." How big is the security industry? I honestly, like 30,000? There You can't find You can't find 10,000 people that

know how to do this. Um so, there there is there is a huge uh gap in the number of people to the number of jobs that are out there, right? Uh so, you've got to You've got to find where they are and like I'm saying, you know, find someone on the security team, find somebody on within development that can actually, you know, spearhead this this for you. QA is a great resource, other things. Give them access to Burp, right? Uh Burp compared to or ZED Attack Proxy compared to AppScan, the price is negligible for the the value that it provides to you. Yeah, you know, give them a couple days training on it. Go send them, you know,

somewhere so that they can use the tools that are out there to actually enhance your your testing process. Doesn't have to be, you know, again, uh you know, security testing at me during the QA testing phase. All right, so you've got all these different people. One word on this, right? Dynamic testing, you know, we got all these different names that are out there for it. Really, what the hell's going on there, right? This is just an application assessment. That's That's all it is. Um if, you know, even though it all the different vendors call it something different, you got to remember that all penetration tests are not created equal. Um The guys that you get in to test your

code, uh if they if they are experts on Ruby on Rails and you're having them look at a Java, you know, Spring application, they're not going to they're not going to be able to see the same stuff. You got to know who those people are and who it is that you're bringing in to to look at it. All right, so the last phase, maintenance. I know I'm about done here. Um All right, at this point, we've done everything, we test our code and it's completely secure, right? We're done. It's good. Nah right? We've inoculated ourselves a little bit, but we shouldn't be anti-vaxers, right? We really need to to keep up with the regular checkups. And all the

organizations that are out there will push you to do this, whether that's HIPAA, FDIC, PCI, um you know, I I was working at one company uh a couple years ago that, you know, they actually hold something like 95% of the DDA account information that's out there. It's formed by a bunch of the big banks. Um yeah, they get audited, I think it was something like 16 to 20 times a year by different organizations. Everything because every one of the banks wants to come in and do an audit on them, you know, "Hey, we gave you our data." But then so does the OCC, so does the FDIC, so does PCI cuz there's credit card information in there. We can't It got to

the point they had audit festivuses every year, right? And it's like, "Hey, all the banks come down and, you know, we'll host you and you can come in and we'll show you everything and take you around." Because it the cost was so ridiculously high, they had, you know, full-time staff, like a team of like five or six people that were dedicated to audits. And, you know, we're talking an organization that's maybe 250 people. That's crazy. So, you know, in this case, proactive, um is it really better than reactive on the maintenance cycle? Uh not necessarily, right? Your reactive controls go from, you know, doors, locks, guards, firewalls, intrusion prevention systems, all the way up to web application

firewalls, um but the reactive controls as well, right? Are needed, um otherwise, we're going to be missing stuff. And the element that connects those two technical controls Let's see, like security and net monitoring right? Yeah, sorry, I'm trying to flip through these quicker than I really expected. is controlled, uh you know, the the link between those two sets of controls is your SOC. Um these are the people that are going to be sitting there and going to be watching what's going on with your code. Um They're going to be using that technology, combining it with process to make sure that you've got patching done, that you've, you know, find out find all the bugs, that they're pushing out new

and improved code, you know, new and improved applications for you. Um people are at least as good as the technology in this phase, if not better. Think about Target, right? Um Target the whole problem, the whole reason they got hacked, they knew they got hacked, but no Well, the computers knew they got hacked and the technology did. It was actually in their security event log, but no one looked at it, right? They didn't pay for the the the resources that they needed to sit down and actually take a look at the logs and do something actionable with it. So, they ended up blowing up, letting everything, you know, the castle was breached. So, maintenance is all about constant vigil vigilance.

So, you know, yeah, we've, you know, I I've talked about a lot today. Um If you want to talk about it more, come up and, you know, give me a holler. Um otherwise let's really what it boils down to is security is hard, just try harder. Um If you need help, let me know. So, I've got a cheat sheet that I'll leave up here for a minute, right? This is really everything that I've talked about for um implementing an application security program. Um Let me know if you've got any questions, though. Uh yeah, really, it's it's pretty fun stuff and it is possible. I've seen organizations implement it properly. Um But it it takes some work, both from the

development side and the security side. You just got to work together. All right, any questions? Good deal. All right, well, we we moving along fast enough. Thanks again for participating and and for coming in and Yeah. Thanks for coming to BSides. Appreciate it.

Oh my god.