In this episode, James talks about investing in the development teams to increase application security priorities.
For more info go to https://www.developsec.com or follow us on twitter (@developsec).
Join the conversations.. join our slack channel. Email email@example.com for an invitation.
DevelopSec provides application security training to add value to your application security program. Contact us today to see how we can help.
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? Welcome to the DevelopSec podcast where our focus is your success in securing and improving development processes.
And here is your host, James Jardine.
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 there’s 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 within 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’re reducing your risk and bringing security into the application development process?
I think application security is complex, we like to look at it sometimes it’s 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 them. But it really becomes quite complex. And when you look at most organizations 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 all everybody talked about, we got a 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 got to shift, right. So we’re back to the whole, we 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. And we’ve got IAST out there, we 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 there’s a security aspect around that not necessarily, as built into the idea of doing necessarily at the code level scans, it’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 build 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 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 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, the risks that are around there and be able to prioritize them. And that 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 appsec teams and 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 one appsec person 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 developers listening, right 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 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 were building something like that, we have a responsibility, that security is part of it. Just like we don’t want to have typical logical bugs in our system, that may 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 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 shouldn’t be the goal that if I’m developing an application, then I should understand how SQL injection works, what it means to the organization so more than just saying, Oh, it’s ability to write my own query or 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 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 causes an error in the system. I remember, I was there 15 years ago, as the developer writing this code, and you get that, like, Oh, I got an error on my system. Let me go ahead and escape my quotes, right. And I’m all good. This was back before we really had parameterised 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 turned 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 don’t have to be a 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 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 say, we have SQL injection. Let’s go ahead and get that right, that kind of that lower hanging fruit to get that out of the way And 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 appsec team, or whatever team is 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 that 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 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, 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 you know, they’ve got some security modules in here or top secured development modules. So we’ve made that available to you. Now, I don’t know if anything has been actually forced to watch, but it’s there, if you’d like to look at it or you have other places where you can get a specific CBT module on applications security, and you kind of push everybody’s a 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 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 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 that somebody could bring in an instructor to give an in house two or three 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 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 may have that a little bit more open, you may have some sort of SAST or dast tools. And those results are just reviewed by the security teams like we really 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, you could have updated the SDLC to include security checkpoints. But really, there’s not a lot of training provided to the development teams, just hey, we got some new stuff in here. And we have to deal with this.
You could also on the very far end of the spectrum do not do anything, right, you can have an organization that really doesn’t provide any training or security for their 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 broad 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, when I’m saying that one’s better than the other, or one 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, 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 to do. The thing I want to highlight, as I talk through this podcast, is really this idea that we can’t just buy tools 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 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 one way or another in their decisions, 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 a 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. Alright, 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 two to three 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 is going to work for the organization, some stuffs 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 what 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 more testing to validate, hey, we thought we need to do this. Now we’re going to test it. And we can validate that this is actually been through. So it’s important that, well, we need the tools and you have to pick which tools are right for your organization, we need to make sure that we have our exec 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 they’re 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 one of the things when I started doing training a few years ago, I used to do the multi day trainings. And you know, one of the things I tried to find is other ways to do that, I mean, we have CBTs, I have CBTs that are available and if that’s what you need, then that’s great if we have live training, if that’s what you need, that’s great. One of the things I found, though, is sometimes it’s difficult to be able to do a two to three 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 one 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, but the idea is, is that it’s a full year long engagement. So we do a live session or two 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 and 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, and 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 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, if 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 a few days, or just throwing out some CBTs, I’m going to actually do some other podcasts like actually 116 is going to be talking about CBTs. And if you’re using CBT, is how can we get the best use in 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 want to 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 two to three day training for your, for your development teams, how can you maximize that to get going, so I’m gonna break that out into a couple different episodes. See those that 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 that 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 one or two or five 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 backends big in 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 going to help make better application security. If you have questions about how to do this. certainly feel free to reach out James at 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, we’re actually gonna talk about same site, flag and is CSRF really dead. So that’ll be kind of interesting to talk about. And then we’re going to talk about CBTs. And we’re gonna talk about how to make those more effective, more efficient for your organization as you go through that. So, again, thanks for listening. Share your questions or your thoughts, and we’ll talk to you on the next episode.
You have been listening to the DevelopSec podcast with James Jardine. To find out more about how we can help you with application security. Follow us on Twitter @developsec, or check out our website at www.DevelopSec.com