In this section, we're going to talk about vulnerability management. First, we need to understand what a vulnerability is. A vulnerability is a weakness which can be exploited by a cyber attacker to gain unauthorized access to, or perform unauthorized actions on a computer system. Vulnerabilities can allow attackers to run code, access a system's memory, install malware and steal, destroy, or modify sensitive data. Basically, a vulnerability is any weakness. Generally speaking, here we're talking about technical systems, but it can be a physical weakness also. If you have doors without locks on them or you have no gates around your property or something like that, that could be considered a vulnerability that could be exploited by a threat actor. Generally speaking, when we talk about vulnerabilities in cybersecurity world there, we're talking about IT systems. Within IT systems, any application including the operating system, all these things have tons of vulnerabilities in them, it's just question of if they'd been discovered or not. A risk, however, is not the same thing as a vulnerability. A risk is a result of the impact and likelihood of a vulnerability being exploited, and that risk equals likelihood times impact is a equation that is used very often in the risk world. It's not something you'll deal so much within the SOC unless it's a high-risk scenario, then maybe you'll have a playbook for it or if it's a high likelihood, however, the case, you might have playbooks around some of those things, but when we put this risk likelihood and impact in perspective, the likelihood is how often do you think something is going to happen. If you're talking about a building fire, the likelihood might be low. Hopefully, your building doesn't catch on fire very often. However, the impact of a building fire is very very high. You would do that risk analysis and risk would come out to whatever it is. There is a five-by-five matrix, so a lot of places you use, but it's an older approach and it's very black and white if you use a five-by-five matrix and a lot of times risk is not so easily done as black and white. But you do your likelihood near impact and that creates a risk and then you have your risk rating. The more severe risk rating, generally speaking, the more assets focus and attention basically that you can put towards fixing that risk and mitigating it. With risk, there's only three things that you can do. We can never eliminate a risk completely. We can never completely eliminate the idea that a building will catch on fire. We can reduce the likelihood that it will happen, we can reduce the impact of it happening, and we can push the responsibility of it open somewhere else with something like insurance. Vulnerabilities are announced constantly. This is something that's, I think, more and more apparent as people's attention to the technological world becomes more greater, but vulnerabilities are announced constantly whether it's in your operating systems like Windows or your UNIX or your macOS, or if it's in the applications that are on them. Every day there are new vulnerabilities. Help keep track, they are often assign a common vulnerability and exposure at CVE ID and the list of CVE is maintained by MITRE. Now, you can try and follow MITRE directly for the CVE announcements, it is a little bit hard to sort what's important and what's not. There are other streams that you can go through to help you reduce some of that thing and focus on what you need to know. Now, we'll talk a little bit more in a second here, but as vulnerabilities are announced, the description of them, how they work, and how they're detected and fixed is usually announced as close to the main announcement as possible. This way, organizations can immediately hopefully, scan for the vulnerability in other networks and begin to remediate the issue. But I believe they're typically rated on severity using a system on a CVSS. The higher the rating, the more severe the vulnerability, and generally higher risk it is for an organization. There's a picture there, and we'll go to this actually in a second. This shows how we rate our vulnerabilities on severity. On the left there, you see that we have our attack vectors. This is, as an attacker, what relationship do you need to have to the target? Can you be on the network? Does that basically mean can you be Internet-connected? Can I be anywhere in the world and exploit this vulnerability? Adjacent, meaning do I need to be on the same network? Like maybe I can't do it from the outside Internet, but can I do it from the same subnet that would be adjacent. Local, it's very similar to adjacent. In physical, do you have physical access to the machine? Attack complexity. Is it a very easy attack to perform? It's a vulnerability very easily exploited? This is something that script kiddies or anybody that can find a blog about it can do. Or is it a high complexity attack? Something that requires either extremely technical knowledge and skills, or maybe it requires huge amounts of resources. There is a story awhile ago, where there was a discovery that some encryption algorithms could be cracked, but to do so, it required hundreds of thousands of dollars worth of computing assets from Amazon's AWS. To do that was pretty high complexity. The requirements to do that was something that was not explainable for everybody. Privileges required. Does it require any privileges to exploit this? This something that anybody can do against any machine. There don't have to be a user, there don't have to be an admin, they just had to be able to send network traffic add machine. They can do that on privileges or none. If they require let's say normal user access to machine, they might set the low, and if they require admin, then you might set it high. Then user interaction. If I can exploit this vulnerability without having to get a user to interact, then it's going to be none, but if it's required so maybe something like a phishing link, I would send them an email, I then require my target user to open up the email, click on the link, and maybe install something, whatever the case is. Then user interaction is required. Those are from the attacker's side of the house, what is required for you to exploit this vulnerability. On the right, we're looking at what is the impact if this vulnerability is exploited? Is the scope changed? Meaning can you move left or right or affect other systems? Then what CIA confidentiality integrity availability impacts does this vulnerability have? Exploitation vulnerability allows you to gain full access like SQL injection to all of the data in the database and that's probably a high confidentiality impact. Having the ability to write to systems or to modify the file contents, things like that could be a high integrity issue, or just causing denial-of-service issues could be a high availability issue. Then you see if we make it as easy as to attack as possible and have the highest criticality and impact possible, you can see there the score becomes a 10 of critical reading. To help vulnerabilities here, we think of vulnerability management. Vulnerability management refers to the process of discovering, confirming, classifying, prioritizing, assigning, remediating, and tracking vulnerabilities. It's important to understand typically the vulnerability management is done outside of the SOC. It's generally going to be some security engineering team that handled your vulnerability management, but they're going to have a very tight close relationship with the SOC, and we'll talk a little bit more about that in a second. You don't want to confuse vulnerability management with vulnerability scanning. Now, a lot of being part of the vulnerability managed process with an emphasis on discovery. When you have a huge network or any network, you're going to use assets, various tools like Nessus, or you can use Nmap for vulnerabilities scanning, and you can use Nessus for vulnerabilities scanning, you can use open-source tool called OpenVAS for vulnerability scanning , and there are more out there. You will scan your network with your vulnerability scanner and it will look for applications and known vulnerabilities. A lot of this is software designed to assess computer networks or applications for known vulnerabilities like I didn't find the technology arising from misconfigurations, and flawed programming within a network and form authentic and authenticated scans. This is in a discovery phase, if you look on our right, here we can see. This representation from Gartner of vulnerability management, discovery is part of assess. You see scan there identifying report. During this, you would put all of your IP space into your vulnerability scanner, you would have your own vulnerability scanner network. If there are machines in it, maybe you put some service account or you use Cloud agents or however, you want to set it on your organization tools available to do authenticated scans, the differences unauthenticated scans are basically just going to do banner grabbing on your applications web interfaces and port scanning. They're going to try to enumerate the known vulnerabilities with the burdens of protocols that are detected. Where if it's an authenticated scan, they can do a lot more. They can look at local system configurations like can look at the patch levels and all of that stuff. You'll get a more verbose report and a more accurate report from an authenticated scan. Once those scans are completed, they will generate push back report saying, on this machine, there are these many vulnerabilities, are missing patches or misconfigurations, and these are the different severity levels. Then on vulnerability management, you're going to prioritize the vulnerabilities based off of whatever metrics you come up with. Whether it's the asset value, is it a Tier 1 asset or Tier 3 asset? Or is a vulnerability easy exploited? Is there a known exploit available for the vulnerability? Whatever the case is. Is the vulnerability something that one of our main attackers that we're aware of would likely use? Etc. You'll prioritize and then you'll begin to act. You'll mitigate where you need to and then you'll accept the remaining residual risk. Maybe you have a machine, it's got 10 vulnerabilities on it, two of them are critical, two of them are high, and the rest are medium and below, you will say, well, we're going to immediately fix those critical on highs, so we patch them or we mitigate them some other way. We're going to accept the risks on the medium and below for now because we've got more assets that we need to look at. Once you've done that, you would rescan your network with your vulnerability scanner. The idea here is to verify that you've managed the patch and remediate that vulnerability and removed from your network and that you haven't created any more risk by doing that, and then you look at improving the process. What are some of the underlying issues? Maybe we're running old technology, that's why maybe our application become end of life. Maybe we're not reporting quick enough, maybe we can report faster, whatever. That's this cycle of vulnerability management. It seems fairly easy and in a lot of ways it is, but it can be very complicated depending on your structures and organization. You'll see sometimes an organization where they have known major vulnerabilities, but they're not able to remediate or mitigate them because of the critical vulnerable libraries are required for the application that they provide to their customers or something to that extent. That would then look in them and the improved portion, how do we do this? Which would require maybe an entire infrastructure stack update so we don't need that library anymore. It's no longer vulnerability management problem, it's a business problem. With all that said, what does vulnerability management have anything to do with the SOC? How did they come together? Like I said before, the SOC is typically not managing vulnerabilities, but it's important that they are aware of on abilities on the network and emerging vulnerabilities to ensure visibility and alerting. When we talk about those IOCs, sometimes it's important to say, "Hey, was there a log of somebody attempting to insert some strange studio command or hit the Escape key five times?" If so, we know that that is typed this vulnerability. We have not been able to patch it yet, we did put an alert in for it in NSM architecture that we know that someone is trying to exploit a known vulnerability. As new vulnerabilities are discovered, the IOCs can be created and shared. The SOC can provide additional attention to especially critical vulnerabilities or zero-days until remediations can be performed. Remember I said earlier, all applications, operating systems machines have vulnerabilities on them. Sometimes it's just a matter of how they've been discovered yet. A zero-day is basically a vulnerability that's been discovered, but it doesn't have a patch ready for it. You can see down here, this is a timeline of the typical lifecycle of zero-day. When a vulnerability is discovered, generally it's announced and then a CVE is assigned, from either. The exploit may or may not be available when this discovery happens, it depends on who discovers it. A lot of times, if an independent researcher discovers the vulnerability, there's usually an exploit with it. If a research company discovers it, they usually just discover it and move the patch. Or a research company might just be an arm of an IT company. Microsoft for instance, every per se second Tuesday of the month, they have what they call Patch Tuesday. They announce, generally speaking, dozens of vulnerabilities for Windows operating system. A lot of times though, those vulnerabilities don't have experts available. It's a weakness, but it's not weaponized yet. They've already moved to patch it. That's what Microsoft would do. However, if an independent researcher finds it, usually, they've developed an exploit. That way, it's usable for them. Their day is vulnerability is discovered, CVE is assigned, once it's announced in public, generally speaking, a zero-day exploit is developed or launched at the same time, then there's a patch announced and provided, and then it becomes what we call an N-Day vulnerability. Once the patch is created, it's no longer a zero-day vulnerability because there's a patch available, you'll hear it like a Day One vulnerability, a Day Six vulnerability, meaning the patch is available for it, but the path only available for that many days. There's exploitation of it. Basically, what happens is, before that patch happens, from the time that the zero-day exploit is announced up until the time you patch, you are vulnerable to it. The SOC can provide additional coverage here to cover that time from the announcement to the patch day. They can provide special indicators alerts for any IOCs related to that exploit, if possible. It may not always be possible, but if it's possible some log thing that we did the SOC identify and alert on, then that's something that they'll do. It's real quick here. We'll talk about the CVSS calculator little bit more. As you can see, from the image report, that's when we had all of these set high-impact and easily exploitable, you can see mix everything critical, but if you start to move some of these things around, or you need physical, well, that alone will drop it from critical to higher. Because no longer it's still a high impact vulnerability, but in order for you to exploit it, you need to have the laptop in your hands for instance, or it requires high complexity that still keeps at higher, but as you start to go through these things, you'll see that it will drop down quickly. Something that'll make it drop down even faster is the impact levels. If it doesn't change anything and everything is low over here, it'll drop down much faster. This is where your risk assessors and stuff like that, they will generally start looking at these when they look at the impact of a vulnerability on the network. There's some additional subcategories here, temporal scoring, exploit code maturity so that exploit is available. If it's available, how mature is it? If it's not available, then this is not fine, but if it's available but it doesn't work all the time, which could be concept then maybe it goes to one of these and those can help reduce the severity level. How hard is it to fix or is there even a fix available? If it's very easy to fix, if there's temporary fixes, if there's an official patch from the organization, you can modify all that. Then you have environmental scores here. These would do very similar things, so we talked about that above in terms of what are the environmental scores of that system within your network? Once you've probably sit together, you'll come up with a score that you can then insert into your risk calculator. Over here, we're going to mitre.org. This is the CVE database. As you can see, this is just 2021, there's already been 9,000 vulnerabilities released in 2021. Most of them are CVE identifiers that are reserved and either haven't been released yet to the public or are still being worked on. There's a lot of. It's only at the time of this recording, it's not even February 2021 yet. We've got 9,000 vulnerabilities that have been really so far this year. You can see they come out a lot of them every day. It can be very hard to see on top of, so you have to use these automated scanners. If we click on one, it'll tell you what the actual vulnerability is, it gives some references to where it's been discovered. A lot of times, these are very good to read through because these might have the exploitation code name or give you some insight into how possible it is to exploit. They might even have IOCs for exploitation, and then somebody's down here we'll just have additional information regarding the CVE. See if we can find EternalBlue, real quick. If we roll back couple years , something like EternalBlue. EternalBlue was a major exploit affecting Windows devices and became very easy. Once the exploit code came out, it was highly used for a lot of attacks across the entire globe and use by APTs as part of attack campaigns, usually combined with other attack vectors. Sometimes you'd have a thing where they would use EternalBlue to get onto a system. They would drop some piece of malware and they would hit it. Let's see here, we find and get EternalBlue. You can go ahead and spend a lot of time looking through here. It's not the most exciting thing, but it will lead you to some interesting blogs and stuff like that on vulnerabilities that are useful to read. You also know that where the source is. If you ever have, let's say your threat intelligence platform says a new CVE is announced, they'll usually link you to here, and then once you go here, you can follow these additional links, for the references, to find out more information about it. Up next, we're going to talk about incident response a little bit
