CompTIA CYSA+ CS0-002 – Mitigating Vulnerabilities Part 1

1. Mitigating Vulnerabilities (Introduction)

In this section of the course, we’re going to cover how to analyze output from vulnerability scanners. We’re going to stay in domain one in this section of the course, but we are going to cover multiple objectives this time, including objective 1213 and one four. Now, objective one two states that given a scenario you must utilize threat intelligence to support organizational security. Objective one three states that given a scenario you must perform form vulnerability management activities. And objective One four states that given a scenario, you must analyze the output from common vulnerability assessment tools. Now, as we move through this section, we’re going to start out by discussing the contents of a vulnerability scan report. As part of this, we’re going to look at the common Identifiers such as CVE’s, NVDs, CWES, Capecs, CPEs and CCE.

Then we’re going to cover the Common Vulnerability Scoring System or CVSS metrics and how they apply to our given threats and vulnerabilities. After that, we’ll describe how you can read a vulnerability report to validate the results of your scan. This is going to be important because you’re going to get questions on your exam requiring that you’re able to perform this type of action. Next we’re going to talk about some specific vulnerability scanners like Nestus, OpenVAS and Qualists. Finally, we’re going to perform a demonstration where we analyze a few vulnerabilities found from the last section’s demonstration where we were conducting a vulnerability scan together. So let’s get started analyzing output from vulnerability scanners so we can better understand all the vulnerabilities that exist within our networks.

2. Remediation and Mitigation (OBJ 1.3)

Remediation and mitigation. Now, in this lesson we are going to talk about remediation and mitigation. And this is really important because as we’ve mentioned before, you can’t get risk down to zero. Instead, we need to mitigate that risk and we do that through a process of remediation. Now, when we have a vulnerability, this vulnerability must be prioritized and then remediated because we have limited resources. The way we usually do this is by looking at the risk. If it’s a critical risk, then we’re going to try to prioritize that higher. If it’s a high risk, it’ll be a little less high than that. If we go to medium or low, it’s going to be further down the list. And eventually we’re going to have this one to end list with one being the highest most critical priority and N being the 1258th priority that we’re going to get to sometime at some point.

And that’s the idea of taking these vulnerabilities. Now, once we have prioritized them, we then start remediation. When we talk about remediation, remediation is the overall process of reducing exposure to the effects of risk factors. So remediation can be done lots of different ways. If you patch a vulnerability, that’s a form of remediation. If you put in a compensating control, that’s a form of remediation. If I isolate something from the network because it’s really, really dangerous, that’s a form of remediation too. Remediation can take lots of different forms. But the goal here is to reduce the exposure, to minimize the leftover residual risk. Now, when we do our vulnerability management scans, we’re going to come back with a vulnerability report and this report is going to offer recommendations for mitigations and fixes to the various security problems.

They might say that for this particular vulnerability there’s a patch available. For this other one, you need to use this configuration setting. Whatever those things are, they’re going to be included in those vulnerability reports when you’re using a tool like Nessus or Qualis or Openvoss. Now, when we go to do our mitigation, what is the goal when we conduct that mitigation? Well, our goal is not to erase risk entirely because that’s just not possible. There will always be some risk in our networks. Instead, our goal is remediation because remediation is going to mitigate risk exposure down to an acceptable level based on your organizational risk appetite. Now, there are lots of different questions you have to think about when you start doing your mitigations here and your remediations. First you’re going to figure out how critical is the system.

If it’s a really critical system that’s going to determine what type of mitigations or remediations you can do. If it’s a critical system to business operations, I can’t isolate it from the network and turn it off, even though that would solve the risk because that thing is critical to my operation. So I can’t do that. I also have to think about how difficult is remediation? Is it as simple as changing a configuration setting or installing a patch? Or do I need to completely overhaul the entire configuration of the system based on how difficult it is? That’s going to factor into when we remediate it and how much money and resources we’re going to put into it. And the last thing we have to think about is how risky is the issue. Now, just because a thing says it’s a critical issue, that depends on where it sits in your network.

When you get a CVSS score and it looks like 10. 0 and it’s something that’s connected to the Internet, that might be a critical issue. But if it’s on an internal land that has no external network connectivity in a trusted enclave in a secure facility, that’s not nearly as risky. Even though the CVSS would still say it has a 10. 0 because it is what is standard for that particular risk. So you have to look at each issue individually and figure out exactly how risky is it. Remember, our whole goal here is to reduce risk. We’re not going to eliminate risk. We are going to reduce risk. Now, as we try to reduce risk, one of the most important things we use is change control. This is an important part of risk mitigation. Now why is that? Because so many of the risks that we’re trying to mitigate or remediate require us to make a change to a configuration or install an update to a piece of software.

These are security patches, for instance. All of this needs to go through your change control process because if you just start installing things everywhere, you’re actually going to be adding more risk to your network, not less. So you want to make sure there is an appropriate process that you’re going to use and it is going through the proper change control process. Now, another thing we have to think about here is risk acceptance because there is going to be some amount of risk that you just have to accept in life. You cannot eliminate all risk. And so when I talk about risk acceptance, we’re talking about that there is no countermeasure that’s put in place because the level of risk is low enough or the risk doesn’t justify the cost to mitigate the associated risk. Now, I’ve mentioned this before.

If I have a piece of software that might have a vulnerability that relates to something like $10,000 per year, but it would cost me a million dollars to remediate it, that wouldn’t be worth it because I’m going to spend a million dollars to save $10,000, I wouldn’t do that. We would simply accept that risk. Similarly, if it’s a very low level risk, it may not justify spending any money or any time or any resources on fixing that. And so we have to think about these things. Now, when you accept a risk, you can’t just say I accept it and move on. There’s something you have to do when you accept the risk, you need to make sure that risk is still being monitored. Now, how do you do this? Generally, you’re going to put it on your risk register so you’re still going to know that risk exists, but you notated.

I understand there’s this amount of risk there and I’m going to accept it. That way, as we go through and do our further on risk management later on and we do more vulnerability scans and people identify this, you can go no, I understand there’s that risk there. I’ve already accepted it. It was a low risk. We’ve gone through that process and we made the intelligent decision here. Now, once you do your risk mitigations, the last thing you need to do is go back and scan again. This way your vulnerability should be rescanned and verified against the mitigation that was put in place to verify what residual risk sits there. So if I had a server and there was 100 vulnerabilities and I patched 50 of them and accepted the other 50, I should then go through and scan it.

Again and that should come back showing me that there’s only 50 vulnerabilities left. Now, based on those 50 vulnerabilities, if they’re all low or mediums, I can accept that risk. If they’re highs and criticals, I might not and I want to go back and do more patching. That’s the idea here when we start dealing with verification of risk. Because after all, just because you installed a patch doesn’t mean it actually solved the problem. Sometimes you’re going to install a patch and that’s going to fix one risk, but it introduced two or three new risks. So it’s always important whenever for you is do a patch, you go back and you verify it by doing another scan and go through your results again and verify what is the residual that’s left over, because that is what you’re accepting.

3. Configuration Baselines (OBJ 1.3) )

Configuration baselines. In this lesson, we’re going to talk about the concept of a configuration baseline. Now, a configuration baseline is all the settings for services and policy configurations that you use for a server that’s operating within a particular application role. So when you look at a particular server in an application role, like a web server, or a file server, or a print server, or a mail server, each of those is going to have its own configurations. There’s different programs you have installed, there’s different policies you’ve incorporated. All of that stuff is based on that particular baseline. Now, this baseline is important because to create it, you’re going to set up everything the way you want. And then you’re going to do a vulnerability scan as you go forward and you do this scan, you’re going to figure out exactly what vulnerabilities exist in that baseline.

You’re going to mitigate them down and remediate them down to an acceptable level, and then you’re going to scan them again and that becomes your baseline. Now, everything that goes on beyond that would be considered a deviation. Anytime you make a change from that baseline, this is a deviation. And these must be remediated or that risk, that baseline exception that you’re doing has to be accepted. And again, this goes back to your risk appetite. Now, to do this, we use things like security templates and baselines. And these exist from a lot of different sources. You might get it from a vendor such as Microsoft has one for Windows operating systems. You might get it from a third party or even your regulatory organization.

If you’re going to do something that involves credit card data, you’re actually going to have a baseline that you get from the regulatory organization for that, which is PCI DSS. And they would say, here is our security template. This is all the things you need to do for this particular operating system. This is the idea of using these baselines. And the idea behind a baseline is you have something that is known. If I’ve configured my servers to be within this baseline, then I know what security risk exists and I know what my level of appetite is for this particular system. And anything that changes from that goes beyond and becomes a deviation. Now, one of the places you can get these type of security templates and baselines is known as the center for Internet Security or CIS. Now, CIS is a nonprofit that publishes well known top 20 critical security controls.

Essentially, these are best practices. They tell you how you should configure things. For instance, if you look at the top five out of these top 20, we have the inventory of authorized and unauthorized devices. We have the inventory of authorized and unauthorized software. We have secure configurations for hardware and software on mobile devices, laptops workstations, and servers. We have continuous vulnerability assessment and remediation. And we have the controlled use of administrative privileges all of these things have benchmarks and security templates associated with them. Now, for each of these top five that I listed and the top 20 at large, the CIS is going to provide benchmarks as a series of best practices and design recommendations. And if you follow them, your systems are going to be more secure and more safe.

To find these you can go to the website for the center for Internet Security. And in here a lot of these are going to be free for you use. But there are some that require a paid membership or subscription fee. Again, this is something that you don’t have to memorize for the exam or read all of them, but in the real world these are really helpful when you’re trying to create the baselines for your particular servers and services. Now, this brings us to the last concept that we want to talk about in this lesson, which is the idea of a compensating control. Now, I have a baseline and I have risk and there’s additional risks and changes that are being done and sometimes I can’t put the right security control in place according to that baseline. So what do I do? Well, I use a compensating control.

A compensating control is a type of security control that acts as a substitute for a principal control. Essentially, when I take a compensating control and use it, I need to make sure that compensating control gives me the same levels of security assurances as the control that it’s replacing. So if I have something that is an unpatched system, for instance an ICS or SCADA system, and I can’t patch it, what can I do? Well, if I can’t patch it, I need to do something that gives me just as much protection. One of the things I could do is I could create a VLAN and I can add isolation. And that isolation could be more robust than actually patching the service. So I can use this unpatched server inside this isolate environment that has no network connectivity to the outside and that would be just as secure as patching it up fully. And so based on that, that would be considered a compensating control. By performing that isolation instead of using the directed things, which was a patch.

• Category: Uncategorized