Vulnerability Remediation

Remediate or Recategorize

All this process that we've gone through to find vulnerabilities and analyze those vulnerabilities means nothing if we don't remediate those vulnerabilities. At this point in time we've discovered, assessed, prioritized and planned for remediation. Remediation is the next step that we need to take to get rid of this issue.

What I've found when it comes to vulnerabilities is that we really just have two options: we can either remediate it, or we can recategorize it. Technically speaking, we could take any action that's acceptable for any risk — we could transfer, accept, avoid or mitigate.

When it comes to risk we use this term mitigation, but when it comes to vulnerability we use this term remediation. What is the difference between the two? Mitigation is reducing the severity or seriousness of it, and so a lot of times we can't get rid of risk altogether but we can lessen it. With remediation, we restore by reversing or stopping — that's the definition of remediation. So really, with vulnerabilities, we want to fix whatever's broken with it. Generally speaking, when it comes to these vulnerabilities, we're just going to fix them.

But there is that recategorization that can happen as well. Recategorization is when we reassess what the actual impact to our organization is. For instance, let's say we have gotten a report that there is a high or critical vulnerability on our network, but after analyzing it, it really doesn't quite apply to us, and so we recategorize it as being a low concern to us.

Inhibitors to Remediation

There are some inhibitors to remediation. For one, we are a business and we're in the business of making money, so driving up costs is not something that we want to do. Sometimes remediation is very costly, and we have to consider time, money and resources. In fact, it's kind of interesting to see how many IT resources leave this one out. This is one of the most compelling reasons why we can't do something, or why we should do something, and so it needs to be top of mind for us. We need to be able to sell others, whoever the decision makers are within the company, on the reason why we do certain things, and it has to come down to this time, money and resources.

We also make a lot of agreements and promises to our users, to our clients, to vendors and partners, and we have to uphold those. So there are times when there are conflicts with these vulnerabilities and what we need to do, and we need to consider our agreements. One example might be that there are some vulnerabilities that might say, well, you need to destroy data after you're done using it; however, we may have a requirement that we keep data for a certain period of time. So there can be conflicts like that.

There are also overriding principles to our organization, or perhaps there are compliance laws and regulations that we have to fall under, and perhaps that conflicts with some sort of remediation steps we need to take for a vulnerability.

I find a lot of times that remediation can take away from other projects, can take away from functionality, can take away from other things that the business needs to use to operate. So business process interruption is one of those things that we have to consider when we're talking about remediation. Perhaps one of the biggest things that I see is that we only have so many employees, and taking employees off of a project — such as a feature, or something we've promised our users, or whatever they're working on — taking them away from that and putting them on a vulnerability might not make the most sense.

Sometimes remediating a vulnerability also means degrading functionality, and so this could be problematic if our users are used to or require certain functionality and then we have to do away with it because of a vulnerability. That's one of the considerations there.

There are times when I find that there are legacy systems on the network. The problem with legacy systems is that they're not continually being patched, and so therefore there can be a lot of vulnerabilities to it. I see this with factory floors, or where there's some sort of proprietary software that's installed that we no longer have access to updates for, and so maybe it has to be on an old operating system like Windows XP or Windows 2000. Now we can't update those legacy systems, because we rely on whatever services it's providing and don't have a lot of options to update it.

That brings us into those other proprietary systems. I've also seen where people will take some sort of canned software that's out there and do so much customization to it that now they can't really update it, and that can be problematic as well.

Compensating Controls and Strategies

This is where I find we now need some sort of compensating controls. We can't do true remediation on it, we can't recategorize it, so maybe we do other mitigation techniques to reduce the risk to it. Then our strategies become: do we avoid it altogether by getting rid of whatever it is that it's associated with? Do we reduce the impact if something were to happen to it? Can we transfer the risk to something like insurance? Or is there a way that we just accept the risk, knowing that it's part of doing business?

In these cases we might put some sort of control into place. Controls are countermeasures or actions that we take to reduce risk.

We possibly could put physical controls into place. Physical controls are things like door locks or fences. We could possibly put technical controls into place, like firewalls, or we do some sort of segmentation of that network wherever that legacy device is at. Or maybe there's some sort of operational control that we put into place; an operational control is how we go about the functions that we perform and how we go about doing things, so the procedures that we follow. Or it could be a managerial control that we put into place, and that's going to be things like our policies that we set up to be able to control some of the risks that we have.

Types of Controls

There are also several different types of controls. One of them is preventative, which stops whatever risk from happening. Or it could be a deterrent — these are things like fences that block people or deter people from being able to get access.

Then there's the detective. This is like a surveillance system, like a camera system, that not only deters people from entering in, but if they walk in or if they gain access we can see that it's happening. We either see it live that it's happening because we're monitoring that, or we can go back and review that footage and find out if somebody, if something, has been compromised.

There's the corrective action: if a risk were to take place, then we can put things into place to correct that action, usually correct it maybe even temporarily. Then we have recovery controls; recovery controls are the controls we put into place to help recover after an incident happens.

Then there's compensating controls, like insurance, where we can't completely get rid of a risk, so what we do is compensate it with something like insurance. And then there is a directive, where we're just required to put these controls into place.

A lot of times we deal with this from a risk management standpoint, but it can also apply to our vulnerabilities.