Пълният препис на Ep. 122: Integrating Security Responsibilities into Development

00:06:01.384 --> 00:08:33.019 So making sure that we keep that. But that's a cost that we have to consider. And then once you're kind of done with the main development of an application and it maybe goes into maintenance mode, you still have to have that time to go in and still update Secure those components are still gonna get actively developed and updated as they go forward. And some of those updates are security updates, so they have to be included. Speaking on that same line of third party components, also the ongoing maintenance of just the software in general due to the changing technologies, platform updates, new vulnerability categories coming out. If anybody has been watching, recently, they had double click jacking pop up that had never really been talked about before, something that we'll talk about on another show. But it's a new kind of I don't wanna say class of vulnerability, but it's a new vulnerability out there that nobody or most nobody has any actual mitigations for at this point. The stuff for click jacking doesn't work for it. So it's something completely new that even if your app has been up and running and fine, now it may be vulnerable to this. So we have to be able to stay on top of those things, and there's a cost, of course, to going back and ensuring that we're staying up to date on those. But if you're building your applications on dot net or some other framework, those frameworks or updating their end of lifing, All that stuff has to be considered when you're looking at the applications and its security to make sure that we are getting that all handled that, you know, we're not still sitting out there on dot net two point o twenty years after it's already been end of life, and, you know, trying to get to the next version is gonna be much more difficult. The final thing I wanted to cover on costs, and these it's just a small list, so it's not everything, but training. So there's always new types of risks that may pop up. The double click jacking is a good example. And, also, there's a lot of stuff just in the security realm to understand. So it's important that developers and product teams understand these different vectors to mitigate them. And there's a cost to being able to, one, obtain that new knowledge, and then, two, to share it with the team and make sure that it's understood across the members that need to know it. So I think there's a few different things that we need to consider when we talk about the cost of applications, that as we look at this, how does that fit? 00:08:33.480 --> 00:08:47.764 So as we think about these different items, we can start to consider how each team can be beneficial. Our goal should be to reduce friction where possible. In many cases, the security team acts as the guide in the verification center. 00:08:47.904 --> 00:10:32.250 Security can help to find out what types of testing is required and help identify the vendors or tools that are supported within the Application, we may

find that development teams are actually more efficient at identifying how to properly implement those tools within their teams. We've seen this before where if you can supply the tooling and say, hey. You need to use this SaaS for whatever reason. Maybe it's some sort of compliance reason. Here's what needs to be done, but you identify how it fits best in your workflow, in your pipelines. Oftentimes, the development teams will come up with a much more efficient way for that to be implemented to fit how they work versus when the security team is doing that outside of the development team and saying, oh, well, we'll just put it together like this because this is how everybody does it. And then it doesn't actually fit the workflow of the development team. So if you can get the development team to help set that up and, usually, that's kind of a one time setup. Hey. How do we get this working in our SDLC? It's gonna help reduce that friction. Security teams can help stay on top of the latest trends and risks out there to help identify appropriate training opportunities for the development teams, but it should be the responsibility of the development teams to enforce the completion of that training. And finally, as the development teams are given the capabilities to execute the needed security requirements, the security team is there to help verify that the required tasks are being properly completed and provide guidance when needed. So it's a little bit of a shift of what we typically think of application security or product security where the devs sit on one side. 00:10:32.250 --> 00:10:35.549 They just work on the coding, throw something over the fence. 00:10:36.014 --> 00:12:24.549 Security looks at it from a security only perspective, gives that information back because security can't go in and fix those or and my opinion usually shouldn't be going in and fixing that Secure if I keep fixing it for you, you're just gonna keep doing it incorrectly. But we get that back and forth, and that doesn't really work that well. But if you can let the teams do what they're best at, the development James doing the Development, and the security team's going out there and finding what are the biggest risks and identifying that information. That's gonna be a much better use, and then they provide that back to Development James. And then Development teams understand, hey. This is how we can now implement this information that's being provided for us. And that gets us away from that need for the development team to spend a whole bunch of time trying to research new risks, new vulnerabilities, even sometimes mitigations because the security team can dig into that and be able to provide back. Here's the risk. Here's some ways that the way we develop our applications, we could look at resolving this risk. Now let's work through of how we can go ahead and do that. But we can't stop there. Just identifying the responsible party would do no more good than what we have now as we are starting to see the shift slowly starting to happen. So what's the second thing we need to do? I think the second thing, and this is important, is we need the development community to realize that Security development concepts are required for jobs just like the experience with Agile, object oriented programming, test driven development, and understanding their current frameworks. I quickly browsed a few software engineering jobs on LinkedIn the other day. 00:12:24.610 --> 00:12:42.634 Not one of them had a mention of security in them. Even when they mentioned building quality software, none mentioned building secure software. And we can argue that, you know, secure software is quality software or vice versa. Right? Security is part of quality when we look at that. 00:12:43.414 --> 00:13:57.164 But we have to get to the point where we are requiring our new developers that we're onboarding to have some secure development experience and understanding. We've fallen into this trap where it is the security team's job to provide training to our developers on secure development. This at a is at a company level, wherein not all companies do it, so it's not across the board. This training is seen as a burden, both from the security side of creating it and the dev side of taking it. It is seen as something that security wants you to do because of some compliance requirement rather than something that should already be done as part of the general development role. This isn't a ploy to get rid of the security team. Instead, it is a direction that is needed to be taken to scale our capabilities. The security team can't secure your applications. It's just not possible. The security team can help reduce some of the risk by adding in some controls, but it will never be as effective as the development organization building with security in mind. If we actually want to see the security no move within application development, we need the people building applications to step up and take on the challenge. Otherwise, we'll just keep doing what we're doing, which clearly is missing the mark. 00:13:57.865 --> 00:14:34.784 I remember back in 02/2011 when I would interview new candidates for a software engineer position. I would ask them about how to protect against cross site scripting or SQL injection. Honestly, I didn't come across any candidate that even knew what those were. To be fair, I was asking the questions, but I was not basing my decision off of the responses because I didn't expect many to have the answers. This was well before AppSec really took off with mainstream outside of being more of, like, a testing side of the house, maybe building the policies. It's definitely really grown a lot since then. 00:14:35.245 --> 00:16:29.554 But I would expect that ten years later that a developer would know the answers to simple security questions. However, I would not ask them in the same way this time around, which I will cover my thoughts on that in a different episode. The point being that at this point, there should be an expectation that DevelopSec understands some security concepts as part of their role. Your job description should start to reflect the desire for security related knowledge. For example, some understanding of how to handle keeping third party components up to date. The expectations would change based on the level of the DevelopSec, requiring more understanding the higher you go. I plan to talk more about this in an entire other episode. I've met quite a few developers that have a pretty sound Security understanding. I think we're seeing more every day. I believe that if we start to formalize the requirements and vocalize it more, it will become normalized much quicker. It is hard to hold someone accountable for something that you haven't clearly defined your expectations for. Unfortunately, I think we do this too much with application development and security. There are plenty of fingers pointing the other way and too much hesitation to look for simple solutions. Hopefully, this has provide a little bit of idea provocation to start thinking about ways that we can update and make simple changes, honestly, to our systems and our organizations by modifying our job descriptions a little bit to get people a little bit in line with what our expectations are for the different roles. I think simple changes to your job descriptions make a big difference. And a lot of James, there's this concern that, oh, well, if I put this in my job description now, all my current employees won't match this. But most places already have some sort of corporate security training happening. 00:16:30.529 --> 00:16:41.190 Pick stuff, one, that is relevant to your organization and to your application development. Don't overdo it. Ease it into those job descriptions. 00:16:41.889 --> 00:17:08.019 And then if you're picking something that's super relevant but you're not actually confident your developers have, then you've now just picked your next team training topic and go forth and work with that to make sure that you're getting them to that level that you want them to be at. This shouldn't be a situation where, oh, I'm a senior developer, but now that you've updated my job description, I'm gonna drop down. I'm I'm I don't need that anymore. 00:17:08.720 --> 00:17:16.355 We've just added security into this. If there's something we need to do to get somebody to that point, then let's provide that training. 00:17:16.355 --> 00:17:29.160 But don't try to boil the ocean. Put in one or two things to start the idea of updating these job descriptions. So I wanna thank everybody for listening, and stay tuned for the next episode. 00:17:36.180 --> 00:17:51.630 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 at DevelopSec, or check out our website at www.developsec.com.