9.1 Using Components with Known Vulnerabilities

Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *

Already have an account? Sign In »

12 hours 9 minutes
Video Transcription
Hey, everyone, welcome back to the core. So in the last video, we went ahead and finished out our lab on insecurity serialization.
In this video, I want to talk about using components with known vulnerabilities.
So quick pre assessment question here. Lisa is working as a cyber security engineer, and she's also a team lead she's preventing, presenting to her team of ways to mitigate the use of components with known vulnerabilities. So which of the following is not a way to mitigate these vulnerabilities?
All right, this one is pretty easy. Sophia Guest answer D using unsupportive software. That is correct. That obviously is not a way to mitigate vulnerabilities. That's a way to include vulnerabilities.
And then things like patching inventory version ng s o maintaining that, you know, maintaining a knowledge of what versions. You actually have a software as well as monitoring components. All these are ways that we can mitigate the potential vulnerabilities.
So lonely objectives for the spitting we're gonna talk about, you know, what does using components with no vulnerabilities actually meet? We'll talk about how to check for it. Prevention methods impact, etcetera.
So we take a look at our risk rating score here we see that the prevalence is pretty widespread, right? So we see the red there indicates to us. So that's a severe ranking. They're the number three,
and so we understand that this is very widespread, and the main reason for that he is because
a lot of times reason development team, they're using so many components when they're building out, let's say your website or something like that, the building that south using different AP eyes, you know, they're using all these libraries from different sources. And so all this stuff together makes a huge attack surface, so it's
virtually impossible to not have some type of vulnerability.
And so the moment he may not even fully understand. Like everything that's connected right, they may not understand, like all the libraries and use that may have described like something over here because, you know, it was gonna fix an issue they were dealing with at the time that they didn't understand, like everything that was plugged into that particular component. So that's where we see it in a more, uh,
more widespread issue.
It's just because it's a huge attack surface
and exploit ability. It's actually relatively simple. So there are a lot of, like, pre written exploits for the most common vulnerabilities. However, there are some vulnerabilities, you know, like an attacker would have to write their own custom code for on then, you know, detect ability. Sometimes you can scan for it s So, for example, we could do something like retired Js
and scan for it. And then, of course, the impact. You know,
um, it could be minor. You know, it could be some kind of minor impact. Or it could be up to, you know, like a huge data breach or data loss or data corruption, that sort of stuff.
So we talked about using components with no vulnerability. So as I mentioned, libraries, frameworks, other software module is basically they run with same privileges as the application itself s Oh, there's any type of component there that can be exploited, you know? So
So the attack, then you know, if Tucker can get ahold of that exploited and then you know what they can do is they can you know, you make the organization occur, like, you know, a huge data loss that could take over your server. For example, So
one of one of the main things we can do to prevent against us is just constant patching. That's that's more of the key aspects here, and we'll talk about some other ways to mitigate. This is well, but just make sure your things are up to date right on. And part of that is inventorying what you have
because your development team may not know. So you need to get an inventory of what you have, so you could actually secure it.
Preferences, I mentioned is very widespread, and I've already kind of covered. Why, that is,
how do we check for it? Well, are we using old versions of software? Are we using old versions of the applications? Are Do we know that there's known issues with some of the libraries are they are very vulnerable? Are we not performing vulnerability scanning, you know. So are we not using tools like necessary open boss with her two of the most popular ones out there?
Now there's many others as well,
but are we not using these things to find thes vulnerabilities or find us many vulnerabilities as we can so we can mitigate those?
Are we not patching properly. So, yeah, we're using older versions of software. And are we also not patching anything? Are we not upgrading on a schedule? What about compatibility? Testing, right. Are we not making sure that everything that we plug in is actually compatible with what exists there? So, for example, Fineman developer and I want to plug in something else.
Am I actually doing testing to make sure that works with our production systems as it is?
Or am I just plugging it in, hoping for the best and say no, we'll deal with that later.
And then we can also use things like Showdown, which is commonly called this hacker search engine. We can use that to take a look and see if any devices on our systems are particularly vulnerable to certain aspects are too soon. Excuse me. Certain vulnerabilities.
So what kind of impact? Every mentioned data loss. Dead alteration on these can lead to things like identity theft,
effects of the intellectual property, you know, with identity theft. You know, of course, getting yourself security, your date of birth, that sort of stuff.
So prevention I mentioned patching, you know, and again, that's that's one of the easiest ways and organization can to take to try to mitigate this risk.
Also removing any unneeded items so again that goes back to inventorying everything and seeing, like do we actually need this? Do we need these things? Can we turn anything off that we're not using
inventory of your version? So what kind of versions are you using on? And then on top of that, though, because a lot of organizations face this issue with using legacy systems. So legacy, you know, an application that's that you have to maintain a earlier version of something else because that legacy application has not been updated in 20 years.
and it's gonna cost too much to move your stuff. So these are all components more for a risk management course, a ce faras determining the proper risk level for this type of thing on that particular application, for example, but for our conversation,
this is why we want to maintain or you actually have an inventory of our different versions and understand why we have to use
a certain version of the software. And from there that starts a conversation of Okay, well, what can what's equivalent out there. Now that's current that works with the latest software of X, because that way we can, you know, we can upgrade the Y system to make it, you know, more secure. And if that that particular vendor can't do it, then we need to find an equivalent
piece of software that works
so we could make all of our systems more secure.
Oh, of course you want a monitor for vulnerabilities as well. So, like, you know, looking at the different Stevie's for whatever applications were running and, you know, setting up alerts and that sort of stuff. So that way, you know, as new CVI has come out, you can determine
Is this actually applicable to my organization? And if so, how can we reduce the risk or mitigate the risk or solve the problem since you
downloading from trusted sources? So any time you're getting source code or anything like that, do it from trusted sources. Don't you know just because something is cheaper on 1/3 party Web site doesn't mean you should go there and downloaded. There's a lot of times that's gonna have now we're in it,
and then anything that we do, we always want to do the ongoing analysis, right? Any time we make a change and we're trying to correct something we need to monitor and make sure that those changes are actually effective.
So this one quick post assessment question here vulnerabilities can exist in is a frameworks be libraries C A p I, C or D. All the above.
All right. This one was very easy, right? All of the above. I mean, if you're any good, attest taking, you'll know in most cases, if you have ah, test question is asking you all the above and it's the last one. Then more than likely, that's the right answer. Don't hold me to that. More than likely, that's the right answer.
All right, In this video, we talked about using components with no vulnerabilities. Will take a look at that, hands on wise in the next lab. And then following that, we'll have our model 11 which is gonna be our insufficient logging in monitoring
Up Next