In this episode, James talks about investing in your people to create more secure applications in your development process. Tackling the challenge to integrate security into the development process? Looking for insights, answers and practical solutions to avoid getting overwhelmed? Hey everyone, James here and welcome to episode 114. Took a little bit of time over the summer off, but we are coming back with some new episodes. And today I want to talk about investing in people. And I put a blog post out about this, so this is kind of covering what we're talking about there. But the key thing is when we talk about application security and we talk about securing applications, secure development, secure SDLC, all these different things, we have all kinds of different ways that we can go about trying to secure our stuff and build our programs. And I want to talk a little bit about that today because I want to ask out first, what's the typical priority that you have when you're building out your AppSec program with your own organization? Where are you really looking at putting a lot of the budget? Where do you put a lot of your focus? Are you spending time really focusing on bringing in certain tools? Are you spending a lot of time trying to create out a filled out SDLC that has all kinds of security built into it to help you out there. Policies, guidelines, training. What is it that from an application security perspective, do you hit as your priorities for trying to help make sure that you are reducing your risk and bringing security into the application development process. I think application security is complex. We like to look at it sometimes as kind of simple, right? We have flaws, we have vulnerabilities, we have the OWASP top 10. We have all this information out there and we just don't want to fall victim to any of it. But it really becomes quite complex. And when you look at most organizations, you know, you have your development teams that sit within IT, you have your application security teams which sit over in the security side of the house. You've got all these tools that we're implementing. And from the outside, we have all this push, oh, everybody talking about, we got to shift left in the SDLC and shift left, shift left. The sooner we find the bugs, the better, and if we can just not implement them at all, that's the best that we can do. And now we're seeing, Oh wait, we can't just shift left. We've got to shift, right. So we're back to the whole, we've got to do the whole SDLC thing and make sure that we're thinking security throughout the entire process, which is true. But again, when we think back to that, where do you place within your organization, most of your effort in trying to make sure that you're covering everything you need to cover. And so today, because I think a lot of places do focus a lot on bringing in tools, right? We do a lot of SAST, we do a lot of DAST, now we've got IAST out there. We've got a lot of scanning technologies that we can do. We've got our DevSecOps where we are building more automation around our deployment capabilities. And you know, there's a security aspect around that, not necessarily as built into the idea of, you know, doing necessarily at the code level scans, that's more containerized. But we have all these different techniques that we can use. And look, we got to have automation. There's no doubt about it. There's got to be automation to be able to find this stuff and make sure that we are protecting ourselves from a lot of these vulnerabilities, but we also have to understand that automation isn't going to fix everything. There's no way it can. You know, automation, we're just not there yet that it can find everything and solve all the world problems. So we have to think about some other things. And, you know, when we think about SAST, we think about DAST, you know, some of these tools that we're running. And you know, we have to have some expertise around how to run these tools, we have to understand how to use the tools. I've always been a big fan that most of these tools are usually pretty simple to actually run, they don't take a lot of ramp up time. But you have to understand vulnerabilities, you know, the risks that are around there and be able to prioritize them. And that's stuff that we can teach. So we think about tools and, you know, we think about automation, but how often do we actually think about how much we're investing in the people that are building our applications from a security perspective? So we have our app sec teams, and you know, we send them to training and we train them on how to do manual pen testing and vulnerability assessments and what the different vulnerabilities are. And we put a lot of effort into that, or at least in a lot of organizations, to making sure that our AppSec experts are experts in AppSec, right? That makes sense. But At the same time, how much do you actually put on the development side of the house? Your developers, your software testers, your business analysts that are actually the ones designing, writing, and testing the application on a full-time basis. And a lot of times, these resources outnumber your AppSec side a great deal. I've been in big organizations where we've had hundreds of developers when we have you know 1 2 AppSAC people to be able to work with all of that. Now, it's important to understand that when I talk about investing in the people and talking about working with the development teams, and if your developer's listening, working with you out there as building secure software, this isn't the idea that we want to build up everybody as a security expert. My goal is not to create a bunch of security people. That's, that's not it. Your developers, your software testers, you have your identities and what you're doing. But we do have to realize that when you are building something like that, we have a responsibility that security is part of it. Just like we don't want to have, you know, typical logical bugs in our system that may be not be a security issue, but the app just doesn't work as it's supposed to. Right? I'm going from A to B, and if I don't go from A to B, that's a break in the application, that's a bug. We have to be able to fix that. Well, security falls within that as well. If I'm building an application, I have that responsibility to make sure that as I'm building it, I'm trying to design it so that user A can't access user B's account if that's not part of what we're supposed to be doing. So that's all part of what we should be doing. But how much do we actually prioritize or push to have our development teams actually being brought up to speed on this. Now again, it's not about making you a security expert. Do you have to be an expert in SQL injection to be able to do blind SQL injection or run crazy commands to be able to pull all the data out or run a remote shell on a SQL server. That's not the goal here. That's not the goal at all. But it should be the goal that if I'm developing an application, then I should understand how SQL injection works, what it means to the organization. You know, so more than just saying, oh, it's ability to write my own query, or, you know, an attacker can execute a query against my application that I didn't intend them to do. That's fine that we know that, but what does that really mean? And when we understand what that really means, that helps us better understand why it's important and why we really need to make sure that we're avoiding it versus just saying, Oh, you know, it's an error message that comes down that you have unclosed quotation marks And you'd be surprised how many people you talk to when you think about SQL injection and you're not Very well versed in it that you just think oh, well, you know causes an error in the system. I remember I was there You know 15 years ago as the developer writing this code and you get that, and you're like, oh, I got an error in my system. Let me go ahead and escape my quotes, right? And I'm all good. This was back before we really had parameterized queries, but it wasn't as much of, I didn't see that. Oh, wow, look how easy it is for me to be able to take all the data from the database and pull that down. I just thought it really is an error message. Again, I don't think we have to understand and know how to take a SQL injection and turn it into a remote code exploit on a server, but we should understand the implications of what could happen with that type of vulnerability because when we understand that, then we understand why we need to make sure we resolve that. Same thing when we talk about our software testers. You know, you don't have to be an expert penetration tester when you're doing your security testing or your application testing that you normally do. But there's simple things that we can put in there. And there's things that if we understand the concepts of what they are, like SQL injection, then you know some simple things you can do to test for that to be able to see if you've got it. Are you there to find the deep down blind SQL injection that lets you do all kinds of crazy stuff? Probably not, right? That's why we have an AppSec team. That's why we have, you know, code analysis and all these different things to really focus on those huge bugs. But we should be able to find simple things like if I put a single code in and get that unclosed quotation mark error, I should be able to as a software tester be able to test that and be able to know if, hey, we have SQL injection, let's go ahead and get that. That kind of that lower hanging fruit to get that out of the way. And then as we get better at that, then we can start going a little bit deeper and figure out how we can build that stuff into our typical test scenarios and our test cases. So that way we also have that as part of a regression testing and all the other testing that we're doing. So that when we finally get over to running our tools or having an external pen test or get it to our internal app sec team or whatever team's going to do that, right? All that low stuff, that easy stuff should be already out of the way. Now we're moving on to the harder stuff to find. And that's where we have people that are security people that focus on being able to find that really, really hard stuff, but not the simple stuff. So there's a couple different scenarios. When we think about training our people and investing in our people, a couple different scenarios or responses that I typically get, you know, if you were to go out and ask somebody, hey, how do you deal with your developers as far as training them for security? So this is out in the blog post, actually, but I'm just gonna read through just a few of these. So a couple of scenarios we have, The organization provides computer-based training modules for the development teams to watch. This is pretty common. I know a lot of places that use just CBT, right? Hey, we've got this, whether it's out on a platform that we've already got for the whole company and they've got some security modules in there or secure development modules. So we've made that available to you. Now I don't know if anything's been actually forced to watch, but it's there if you'd like to look at it. You know, or you have other places where you go out and get a specific CBT module on application security and you kind of push everybody's, hey, look, you gotta watch these modules. Okay, so we have CBTs out there that are available. You have organizations that might send a few developers to a conference or specialized training course, you know, and then with kind of that hope, so I know I've been in this situation before here, we'll send you, but we want you to come back and brief everyone on what you learned. And I don't know how well that works anyplace else, but I don't see that usually too well just because a lot of people, you know, you get a lot from these things, But sometimes it's hard to relay that back to everybody else because there is so much to be able to try to bring back. You also have the ability to, somebody could bring in an instructor to give an in-house 2 or 3 day training class that helps people understand secure development. Maybe you do that once a year, maybe you do that once every few years to be able to do that. Now depending on your requirements, you know, if you're PCI then you may be required to have security training for your developers on a yearly basis. If you're not, then you know you may have that a little bit more open. You may have some sort of SAS or DAS tools, and those results are just reviewed by the security teams. Like we don't do anything for the dev teams. We just have the security team that actually runs through this stuff and sends the stuff back over to the dev team to have them work on it. Uh, you could have updated the SDLC to include security checkpoints, but really there's not a lot of training provided to development teams is, Hey, we've got some new stuff in here and we have to deal with this. You could also on the very far end of the spectrum, just not do anything, right? You can have an organization that really doesn't provide any training or security for the developed teams. And you know, those are typically the less mature organizations when it comes to application security in general. Not necessarily less mature in development, just in the fact that not everybody's really brought in application security, because sometimes it can be difficult to show the ROI for that. So not everybody's got that in there. So those are some of the scenarios that you might have. Now, I'm not saying that one's better than the other, or 1 is worse than the other, or you should definitely do this versus that, I think all of them have, well, except for no training at all, you know, all these different aspects have the ability to provide what you may be looking for, but it is important for you to understand what it is you're looking for to do. The thing I wanna highlight as I talk through this podcast is really this idea that we can't just buy tools. You know, when we say shift left in the SDLC, well, if you keep shifting left in the SDLC, you finally hit a wall and that wall is training. And that training has to be there for your development team, your testing teams, your business analysts, right? Those that are involved in the design, because all those groups are the closest you can get to the application. Your external application security team that sits over on the other side of the building is not embedded within the development teams. And I get the reasons why we always say, oh, they have to be separated out because they have to be unbiased. They can't be part of the team to be swayed 1 way or another in their decisions or whether something should be fixed or shouldn't be fixed. They have to be completely external. That's fine. I get your reasoning for that. But that also highlights the fact that the developers, the testers, the designers, all of them, they're the closest you can get to actually writing secure code and testing your app for secure code. And so we have to make sure that we're putting a focus over on that side of the house to make sure that what we're doing is what we expect that we're doing. Right, if you're just sitting there saying, you know what, regulation requires me to have some sort of training, we'll get CBTs and I don't care if anybody actually watches them, but we have it. So we're checking the box, right? A lot of box checkers out there. That's fine. I hold no judgment on that, but then that's fine. But that's your reasoning. That's what you're looking for. And if that's what you need to get, then you can check that box and do that. If you're someplace that has higher regulations or you have a higher expectation of what you want out of your teams, then maybe you have to do something more. Could that still be CBT? Maybe. Could that be somebody coming in for a 2 to 3 day training? Maybe. It all depends. Everybody's different. CBTs might work for some people. We all learn differently. So we can't just say, oh, this has to be the way because that's going to work for everybody. It's not going to work for everybody. And that goes from a student perspective all the way up to the organization perspective. Some stuff's going to work for the organization. Some stuff's going to work for the student, the developers, the testers. You have to figure out what that's going to be. And it's important that we focus on that because if I don't have developers understanding secure code and what some of these vulnerabilities are to be able to know, like, Hey, when I'm building something and I'm connecting to a database, I need to make sure that I'm connecting safely, so I don't have X, Y, and Z issues, then that's where we're catching stuff later on. And do we really want to catch stuff later on? I mean, obviously we do, but I'd rather catch it before we even write it, and then not have to catch it later on. And we do that by training the developers. We do that by training the business analysts as they're going through, thinking about what type of things, what type of abuse cases might exist for a certain scenario. So hopefully we can think that through before we start writing the code and we can cut it off before we get there. And then we're also thinking about that we're testing it to validate, hey, we thought we needed to do this. Now we're gonna test it and we can validate that this has actually been through. So it's important that, well, we need the tools, you know, and you have to pick which tools are right for your organization. We need to make sure that we have our EPSAC teams that are up to date and know what they're doing. We have to make sure that we're investing in the people that are sitting there, developing the code, testing the code, designing the applications, because they're the ones that are right there in it. They have the ones access to the code. They're the ones that can make the changes. They're the ones that are going to be the ones that really help reduce the risk within our applications. So something to think about as you're going through with your stuff is, hey, how are we doing that? How are we going through and training the development teams on creating secure applications? Because that's an important part of our industry, that's an important part of our organization, we want to make sure they're providing what makes sense for us going forward. So that's 1 of the things when I started doing training a few years ago, I used to do the multi-day trainings, and, you know, 1 of the things I try to find is, you know, other ways to do that. I mean, we have CBTs, I have CBTs that are available, you know, and if that's what you need, then that's great. We have live training. If that's what you need, that's great. 1 of the things I found though, is sometimes it's difficult to be able to do a 2 to 3 day full days of training because it's hard to lose our teams for that long. We have tight deadlines. I can't get away. So we look for other alternatives. And 1 of the things I've kind of come up with and it seems to be actually pretty successful with the people I've done it with is actually doing kind of a hybrid. It's that hybrid of CBT and real live training, but instead of doing it once a year, the idea is that it's a full year long engagement. So we do a live session or 2 live sessions a month where we talk about a specific topic really more in depth. But then we also throughout the month have other resources where we have some like CBT modules, some videos to look at. We have guidelines or policies that we have as samples that you can take into organization to help build up your internal guidelines of how to do secure coding in certain different ways and for certain types of vulnerabilities to make sure that it's not just a brain dump of information, but it's a partnership to help make sure that as we go through, you're getting the information that you need when you need it. So it's flexible as what the topics are each month, and throughout that entire month, we're in a Slack channel together, we're in some sort of whatever your organization uses, whether you use Slack or whether you use Teams, right? I can be in the channel, you have questions, you're working on something, you can ask them, and that adds a lot of value to any type of training program because not only are we building the skills that you need, that awareness of, hey, here's the type of risks that are out there, the vulnerabilities, but we're also trying to help develop those skills and say, hey, here's how we can implement that within our organization. So it's not just a bland recording, you know, that is good. It gives good information of this is what this vulnerability is. But then you're wondering, how do I do that here? That doesn't really fully fit what I'm doing, what should I be doing? This gives that ability to ask those questions and kind of work through some of those scenarios to do that. And now you're getting training all year instead of just doing, you know, a few days or just throwing out some CBTs. I'm gonna actually do some other podcasts, like actually 116 is gonna be talking about CBTs. And if you're using CBTs, how can we get the best use and the best value out of using computer-based training. Because like I said, there's all kinds of ways that we can do this. I like what I do as far as an option where it says hybrid all year long approach, but I know that may not be right for everybody. So I wanna talk through some of the different ways that we could do this. And so those bullet points I listed out, I want to talk through some of those that say, look, if you're using this, here's some things you can do to help get better results, right? Maximize the efficiency, maximize the effectiveness that you're getting if you're using CBTs. Maximize the efficiency if you're bringing in a 2 to 3 day training for your development teams. How can you maximize that to get going? So I'm gonna break that out into a couple of different episodes. See those over the next few weeks. So those will be coming, but make sure that when you're sitting there thinking about your organization and building out security, that you are also investing in the people. I know we need the tools, but when you start investing in the people, then now you have those people that know more about being able to run the tools, they understand the results of the tools, and it's an everybody thing. It's not just a, oh, we got a 1 or 2 or 5 AppSec people that know how to do this. We've got a lot of people that understand what you're talking about when you come and talk about SQL injection or cross-site scripting or mentioned OWASP and nobody knows what it is. You start to build up that base and let's face it, our development teams, they are already loaded down with trying to learn all kinds of new development technologies, new front ends, new back ends, picking different languages, right? There's a lot of stuff going on within just the development world and that doesn't even include the security side of things. So if we can start building a little bit of that in there as we go, that'll really save everybody a whole lot of time and make our apps a whole lot more secure. So invest in your people. It's gonna help make better application security. If you have questions about how to do this, certainly feel free to reach out, james.developsec.com. I'm happy to discuss any of it, but I think it's definitely a worthwhile venture to help build up your system. So hope you enjoyed this episode. We got 115 coming up next, where I'm actually going to talk about same site flag and is CSRF really dead. So that'll be kind of interesting to talk about. And then we're gonna talk about CBTs and we're gonna talk about how to, you know, make those more effective, more efficient for your organization as you go through that. So again, thanks for listening, share your questions, share your thoughts, and we'll talk to you on the next episode. To find out more about how we can help you with application security, follow us on Twitter, at DevelopSec, or check out our website at www.developsec.com.