hi and welcome to Module One
and this module. We're gonna talk about the threat landscape, and essentially, what the threat landscape is is. It's a combination of all of those vulnerabilities in those risks out there to our infrastructure. All of the things that could go wrong in the infrastructure as faras, the security is concerned
whenever we talk about the threat landscape, it's important that we start off by talking about the attack surface, and the attack surface is its conceptual. You can visualize the attack surface as a plane, and on that plane is everything in our infrastructure that's vulnerable to attack.
We're talking about all of the systems in the environment. So all of the PCs and the laptops and databases and servers and even badge readers and videoconferencing systems Basically, any technology system that's attached to our environment is on this attack surface.
We're also talking about all of the networks that link all of those systems together, the routers and switches on all of the other network components behind the scenes.
Also on that surface is the people, and a lot of times we forget about the people as being a part of the attack surface, but it's a very big part of it.
People are human beings, human beings make mistakes, and a lot of times they're taken advantage of to gain access to an environment.
And finally, on that serve attack surface is all of the processes. All of those things that we do that regulate our people and technology. We could have the best tech in the world and the best people in the world. But if we have a broken process, someone confined a gap in that process and can exploit it to gain information they shouldn't have.
The word vulnerability simply means open to attack or damage.
And when we talk about vulnerabilities, weaken really break it down into three different groups. There's software vulnerabilities, configuration vulnerabilities and hardware vulnerabilities
to start out by talking about software vulnerabilities and buy software vulnerability. We're talking about the flaws in the way the application code is actually written. We're talking about the the code level itself. The way the code is written were just bugs in the way it's written that allow Attackers to do things that they shouldn't be able to dio.
Now, when it comes to software vulnerabilities, there is a non profit organization called AWAS, but stands for open Web application Security Project. And they made it maintain a top 10 list of the top 10 most common software vulnerabilities.
A few examples air here. This isn't the whole top 10 list. This is just a few examples. You know there's injection where
code allows a user to inject something that they shouldn't be able to. There's broken authentication management. Maybe the system doesn't request credentials. Or maybe it requests credentials in A in a way that's not very safer away. It shouldn't
or there's even sensitive data exposure. Maybe there's a flaw in the way the code written that allows somebody to gain access to some data that they shouldn't have.
We'll take a look at an example of one of the injections. Now, this is just one example. So weaken sort of get an idea of how software vulnerabilities work, the one we're gonna talk about a sequel injection. But before we can talk about sequel injection, we need to talk about how a normal sequel query works.
So we've got this situation where we've got our in user Bob over here on the left and Bob wants to,
uh, interact with a form out there on the Web. You know, maybe he's logged into, you know, some application, and he wants to pull his own profile information from that application. So Bob
sends a request. He types his name in the form in the field in the form and says, You know, give me my data. The form is like says what data do you want in? Bob puts his name in there and says, Give me my data.
The application passes that back to the database, and the database says Okay, well, that's a valid request. So I'm gonna hand back Bob's data, and the application passes Bob's data to him.
Pretty straightforward. Bob put his name on the form. Bob's data came back
in the case of a sequel injection.
Instead of Bob requesting his name in the form, Bob's gonna inject some code in the form,
and now this is not actual code. This is just a visual representation, but Bob can inject some code in the form, and maybe this code is in the form of a sequel query.
And if the applications not ridden properly, if it's a vulnerability in the application. It may not realize that what Bob entered into the fields not actually his name but a but a sequel query, and it simply passes it back to the sequel database and says, Hey,
in this case, Bob's sequel, Query says, Hey, give me everyone's data.
The sequel database says, OK, well, I've got a valid request from a trusted entity, which is the application itself, not from Bob. So I'm gonna go ahead and pass that back and in the application simply passes that back to Bob's. And now Bob's got everybody's data because he injected a query into the form and the application allowed him to do that.
Another example of sequel injection could be the same situation, you know, instead of this time the code that Bob injects into the form instead of it being a sequel query. Maybe it's a command that deletes the entire sequel database, and now the database is gone.
That's an example of sequel injection. As I said, that's just one example of one type of software vulnerability. We could spend months and months talking about the different types of vulnerabilities, but I wanted to give one example so that you can have some context as we go through this course.
So how do we mitigate vulnerabilities in software? Well, the best way to do it is by regular patching.
There are the software vendors out there are constantly reviewing their software internally. There's also a lot of companies that have bug bounty programs where they actually will pay people just random people out there on the Internet. If they find a bug in a piece of software,
vendors will pay them for that because they use that information that didn't create a patch that they can
pass on to the general public and and mitigate that vulnerability. So regular patching this critical
also regular scanning.
You know, not only should we just patch when the when the vendor tells us to patch, but we should be scanning the environment. There's a number of scanners out there, both commercial and open source that allow you to scan an environment, and it gives you a nice report on You know what the environment looks like. We're the vulnerabilities exists, and you can use that to help prioritize how you patch.
And this is a big one, too. You know you need to sunset your end of life applications and what I mean by that is get rid of them. Ah, lot of organizations have these applications that maybe there a revenue generating applications, so they're really important. But the vendor stopped supporting it. You haven't updated the application, and forever
the vendor stops supporting that version of the application so that as vulnerabilities, Air found
that software vendor is not going to continue to put out regular patches. So, yes, this
application may be making money for your organization. But the longer you go with that end of life application, the more vulnerabilities that pile up and the more exploits that are developed against that vulnerability and your risk starts toe exponentially increase.
So when you have an application out there and it's it's end of life, you should either upgraded to the latest version but create a plan to upgrade to the latest version or creative. If in cases where the vendor went out of business and it doesn't exist anymore, you need to create a plan to get rid of it altogether and replace it with a new application.
Keeping up to date is critical when you're talking about mitigating software vulnerabilities.
The software vulnerabilities air scored, according to AH, system, known a CBS s, which stands for the common vulnerabilities scoring system.
And essentially, it's a system that it's, ah, industrywide system that gives a scored. It attempts to score the criticality of the vulnerability so we can prioritize it. And it uses a lot of different methods to do that. There's a lot of artifacts that it looks at for vulnerability. For example, what's the attack vector? Is this something that could be attacked
via the network? Or do you have to have physical access to the device?
Doesn't require user interaction or not. Right? All of those types of things go into the CVS s score, and that scores a mechanism that can be used to prioritise vulnerabilities in environment.
Si ve is another common term, and that stands for common vulnerabilities and exposure. A lot of times, you hear the two together
Si ve is just a way to identify the vulnerability itself. It's a unique identify or so in this case we've got C V E 2019 16 701 right and looks like some kind of vulnerability, and PF sense there's hundreds of thousands of these si ves out there. But
a si ve is just a way to identify the vulnerability so that you can link
mitigation actions and it could be referenced by lots of different products. Whenever they identify a vulnerability, they'll they'll put the vulnerability i d. So you know what you're talking about. There's usually links you can you can click to understand what you need to do to mitigate those vulnerabilities.
So see, ve is the identification and CVS s is the scoring system.