DevelopSec: Developing Security Awareness

In this episode we talk about addressing the root cause of an issue versus the symptoms. How can the process of keeping application components updated be improved?

For more info go to https://www.developsec.com or follow us on twitter (@developsec).

DevelopSec provides application security consulting and training to add value to your application security program. Contact us today to see how we can help.

Transcript:

In this episode, James talks about root cause analysis versus treating the symptoms.

Tackling the challenge to integrate security into the development process, looking for insights, answers and practical solutions to avoid getting overwhelmed. Welcome to the develop SEC podcast where our focus is your success in securing and improving development processes. And here's your host, James Jardine. Hey, everyone, welcome back to the show. Today, I want to talk about addressing the symptoms versus addressing the root problem. And I think in application security, or when we talk about secure development, this is something where a lot of times we address the symptoms, but we never really take the step back to address the actual root cause of what's causing those symptoms. And today, I want to actually talk about vulnerable third party components. This is something that has been kind of brought to the attention a lot more in the past few years, made it into the OWASP, top 10. And it's something I think everybody struggles with, we never know when we'll have a vulnerable third party component, because until somebody actually identifies a vulnerability, we just assume that we're good. And then on top of that, if there is a vulnerability identified, then we also run the chances that we're probably not even using that feature.

So vulnerable third party components are a really interesting aspect, when we think about secure development. Because there is a lot of unknowns, we may know that there's a vulnerability there. But the actual knowledge of do we use that piece and are we vulnerable, can be difficult, which, in the end, ends up adding a whole bunch of extra work and a whole lot of time for us to try to figure this out and address this stuff. And so this is where I talk about addressing the symptoms. In this case, in a lot of places, what we do is we address that symptom, we know that there's an issue of vulnerable third party components, right, that's the symptom, we have a vulnerable third party component. And so most places have some sort of process in place where we're going to identify these right, we're going to scan them all the time, whether using some of the common commercial tools, maybe you're using a free open source tool. But basically, the way it goes is I'm going to scan my repos or I'm going to scan my packages, and I'm going to look for all the dependencies, and then I'll look at their dependencies, and we'll see if there's any known vulnerable components within these right. And that requires having some sort of CVE out there that says, hey, somebody has found this, they've reported it, I remember requiring this to be a reported vulnerability. But we know that there's a vulnerability in this component.

And so now every time I scan my package, it goes and looks up to say, hey, there any known vulnerabilities for this package, and then we send it back. And then of course, the difficulty of trying to rate this and understand, you know, is it a low? Is it high? Is it critical? Love these systems, right, from a generic standpoint might say that it's critical vulnerability, but is it really of critical vulnerability? And a lot of cases, probably not, we've had a few that definitely were. But not everything is critical. Even if the CVE listed out, as you know, high or critical, it depends on your environment and how you're using that system. So there's a lot of extra work that goes around that, of course, to try to avoid that, you know, if we could just patch everything right? Wouldn't that be fantastic? But that's a little bit more difficult to get into as well. So we've got this process of we identify this thing, and then what do we do we go create tickets of some sort, send it into the backlog of the development teams. And then you know, they have to go back and address this issue. Now, as we've seen, application security changing a bit over the years, you know, some places were not as separated in that case. So you're seeing things like GitHub or other tools like that, where they actually will identify when you go do a PR, and it'll check everything right then and they'll let you know, or, you know, it just randomly is checking within your repo to be able to alert the development teams right there within GitHub, right? It'll create an advisory to let them know that hey, there's a known vulnerable component in here we got to address this. And the more we embed it, the better. But are we addressing the root cause is really what I want to try to get out here. And that root cause, ultimately, in my mind drops down to do we have proper patching built in to our development process? And we have to consider that as a developer from way, way, way back. You know, I don't think we really thought about that. And I don't think a lot of that has changed coming forward.

So how do we get to the point where we build that maintenance piece into our systems, not saying that every single release were 100% patched, you know, and that's the way it's going to be, there are some of course, downfalls to trying to apply the latest and greatest, as soon as it comes back out. We've seen this with some third party components when a malicious user takes over an account or they hack some third party component, right, and then they put their malicious stuff in there. And sometimes that takes a little bit for the system to realize that. So if you're downloading the latest thing, as soon as it's published, you have a little bit of risk there as well. Because there's time for somebody to be able to identify that. So there's risks both ways. And we want to make sure that we're trying to address this. Now, when we talk about root cause. A lot of times that is just the fact that we don't have really good patching processes in place. Within our development lifecycle. We look at being able to update certain things, right, we work on the code that we're updating, but we don't think about the dependencies that are seeing in our application. How many times have you seen a application that's still running, like the first version of jQuery out there, or application is still running really old versions of Java frameworks for their stuff, because that stuff is just the foundation it works, it's there, I don't have to think about it, you know, and then you don't do that forever.

Or maybe you stopped development on that for a while and you come back to it. Now, it's very difficult to try to get it back up to speed when you start getting, you know, three, four or five versions back from where it was. So I think it's important that as we're looking at things, and we'll talk about just the third party components right now, but understanding as a development team, what do we need to be able to do, to be able to embed a process to make sure that we're updating our components in a reasonable timeframe, right, not years, not even months, probably. But as we're going through doing our development or doing our sprints, or however, you're running your system, making sure that, hey, I'm going to make sure components are updated. When I go to push this new PR, or I'm getting ready to do a new build, let's look and make sure that we've got the up to date components within the system. And maybe it's a week behind, maybe it's two week behind. But it's not months behind, it's not years behind. It's keeping it updated. But to do that, we have to make sure that we understand that there's a cost to doing this. What happens when we pull in that latest component, and it's a breaking change? Do we just ignore it and say, Oh, I can't move to that, because it breaks my system?

Well, that then is going to cause a problem a little bit further down the road, because we just let that keep building and building and building. And then next thing you know, or three years down the road if we've never updated it, and now it's a huge update. And now we really have to figure out how to do this. So from development teams, we really have to be able to start understanding, you know, how can we handle making sure that we're paying the right a

In this episode we talk about the spell check feature of the browser and how it could present a risk to sensitive data.

Link to article referenced: https://www.darkreading.com/application-security/spellchecking-google-chrome-microsoft-edge-browsers-leaks-passwords

For more info go to https://www.developsec.com or follow us on twitter (@developsec).

DevelopSec provides application security consulting and training to add value to your application security program. Contact us today to see how we can help.

Log4J has been the talk of the town recently and everyone is focused on the technical details of the specific vulnerabilities found. In this episode, James talks about the overarching ideas around dealing with vulnerable components. Are you vulnerable? If so, what needs to be done?

For more info go to https://www.developsec.com or follow us on twitter (@developsec).

Join the conversations.. join our slack channel. Email [email protected] 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.

Chrome has announced a few changes that we need to watch out for in the near future. We previously talked about the default value for samesite that is coming up fast. I wrote about this here: https://www.jardinesoftware.net/2019/10/28/samesite-by-default-in-2020/

Also, they are getting ready to start blocking mixed content downloads:

https://blog.chromium.org/2020/02/protecting-users-from-insecure.html

For more info go to https://www.developsec.com or follow us on twitter (@developsec).

Join the conversations.. join our slack channel. Email [email protected] 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.

It was recently announced that Chrome was dropping the XSS Auditor in Chrome 78. What does that mean and how does that change things for you as a developer?  

https://www.chromium.org/developers/design-documents/xss-auditor

For more info go to https://www.developsec.com or follow us on twitter (@developsec).

Join the conversations.. join our slack channel. Email [email protected] 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 2020, Chrome will default the SameSite attribute to Lax on all cookies. SameSite helps mitigate CSRF, but does that mean CSRF is Dead?

For more info go to https://www.developsec.com or follow us on twitter (@developsec).

Join the conversations.. join our slack channel. Email [email protected] 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 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 protected] 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 some of the risks and recommendations around security questions and their implementation. 

For more info go to https://www.developsec.com or follow us on twitter (@developsec).

Join the conversations.. join our slack channel. Email [email protected] for an invitation.

 DevelopSec provides application security consulting and training to add value to your application security program. Contact us today to see how we can help.

Does your application give away details about it server, framework, or other components?  How is this information used by an attacker? Check out this episode to learn more.

For more info go to https://www.developsec.com or follow us on twitter (@developsec).

Join the conversations.. join our slack channel. Email [email protected] for an invitation.

 DevelopSec provides application security consulting and training to add value to your application security program. Contact us today to see how we can help.

Would you know if someone authenticated to your account? With the breaches we see in the news, and attacks like credential stuffing, there must be a way to be alerted to account access. James talks about authentication alerts, what they are, and why you may want to use them.

For more info go to https://www.developsec.com or follow us on twitter (@developsec).

Join the conversations.. join our slack channel. Email [email protected] for an invitation.

 DevelopSec provides application security consulting and training to add value to your application security program. Contact us today to see how we can help.