Vulnerability Management

Getting a perspective on what the differences are between risk management and vulnerability management really helps define what it is that we're trying to accomplish.

Definitions

An asset is just something that has value to us. We're going to use the example of data. Let's say we're storing some sort of data and it has a value to us as a company. That data has threats against it: it could be stolen, it could be altered, it could be deleted. Think of the CIA triad here — confidentiality, integrity and availability.

A threat agent, or actor, would be an entity or a person that would carry out the threat. Whatever is being the perpetrator is essentially whoever is stealing, altering or deleting this data.

Risk is a calculation of the probability something could happen times the impact. If this data were to be stolen — a breach in confidentiality by this threat — first of all, what is the impact going to be to the company, and also what is the probability that this would happen? That gives us a measurement of the risk that there is to the company.

Mitigation is something that we do to reduce risk, so we either have to reduce the probability or reduce the impact. For instance, if this is our data, maybe we're putting walls up, maybe we're putting a gate up. Now we're mitigating the risk. We're reducing the probability that it's going to get stolen, not the impact, because we haven't changed the data itself in this example. We've reduced the probability that this data is going to get stolen, and so we've reduced the risk.

A vulnerability is a weakness. For instance, we've got a hole in this gate right here, a gate that's broken, and that's a vulnerability of that gate. An exploitation is when our threat agent exploits that vulnerability to get hold of this data in this example, or get hold of whatever asset it is.

Where the Risk Lies

This is a model that you might see on some cybersecurity sites, and I mostly agree with this model. It's at least good to have a discussion around this. What does it mean? We have an asset — that's the data right there. There is a threat to that data; for instance, it could be stolen. And there is a vulnerability: we have a break in the gate. Right there is where our risk lies.

I say I mostly agree with this because I do find that risk sometimes falls outside of this circle right here, and some of it has to do with how you define a vulnerability. Different people define vulnerabilities a little differently. What I mean by that is this: my area where I live is not susceptible to tornadoes. It's very rare that we would have a tornado; we just don't have the conditions right to have a tornado, and so I wouldn't say that the area is vulnerable to it. I may have a data center here. Would I say that I have a vulnerability to the tornado? I would answer no. But is there a risk there? There's still a risk that a tornado could happen here. In fact I have seen it twice before living in this area — we actually have had a tornado and it's caused a little bit of damage. Not a lot of damage, but a little bit of damage. So I suppose it could happen to a degree that could cause some damage. There is a risk there. I wouldn't really say we had a vulnerability to it, but some might argue that, well, you have had it and so you would be vulnerable to tornadoes. It just comes down to how you interpret what a vulnerability is.

Let me give you a little different aspect of these two different definitions of vulnerability. Right here we have a break in the gate, and that is a vulnerability. Everybody would define this as a vulnerability, and what somebody could do is exploit this break in the gate to gain access to whatever asset is behind the gate. What we want to do is identify that vulnerability and then fix that vulnerability. However, some would have a broader definition of vulnerability and say, well, it is also vulnerable to tank attacks. That's not really what we're identifying when it comes to vulnerability management. This is what we're identifying right here from a vulnerability standpoint. If we're concerned about tank attacks, I would label that as more of the risk side of things, that we would identify in risk management and try to combat from a risk management perspective. From a vulnerability management perspective, we're trying to identify these flaws that are within — maybe it's software, maybe it's hardware, maybe it's some sort of physical control that we have in place — and identify those flaws and fix those flaws.

Risk Management Versus Vulnerability Management

When I think of risk management, we do something like a risk assessment to identify risks to the company as a whole, the business — what are business concerns — and we're taking a look at that big picture. When we're looking at vulnerability management, we're going to do things like vulnerability scans and pen testing. We're going to look at information sources, and at maybe having some sort of discovery or disclosure program. We do things like patch management to fix these flaws that we have within our system. So this is more of the technical weaknesses that we have in there.

When it comes to risk management, they're generally larger projects to fix these risks and mitigate these risks, versus vulnerability management, where we're looking at more simple fixes — simple to maybe more complex, but more simple. I definitely have had some projects that would fall under vulnerability management.

From a risk mitigation standpoint, a risk management standpoint, we might transfer the risk, accept the risk, avoid the risk, or mitigate the risk. These all are applicable to vulnerability management as well, but generally speaking I find the two things that we really do from a vulnerability management standpoint is we either remediate it — meaning fix it, do away with it, make it so it's not a vulnerability anymore — or we recategorize it.

Examples of this: from a risk management standpoint, maybe we're concerned for the business's sake about competition stepping in and overtaking us, reducing our profits, reducing our revenue. With our vulnerability management, we're looking at more like what does a SQL injection attack look like, because in a lot of software this is a flaw, and so we're identifying those flaws and fixing those flaws.

The Vulnerability Management Process

Here's really the vulnerability management process and what it looks like. It's very similar, I'd say, to what a risk management process looks like, but we're looking at it from a little different scope, and we are using different tool sets. Although I will say that we do use vulnerability management as part of risk management: if I'm doing a risk assessment I bring in some vulnerability scans and that type of thing into the risk assessment, but it's only a small component of a risk assessment.

What we have with the vulnerability management process is that we start out with the discovery. We discover what the flaws are on our network, what the vulnerabilities are that we have on the network. Then we assess those, and based off of our assessment we're going to prioritize the importance of what we should tackle and what we should fix. Then we plan to fix those, create some sort of plan, we remediate those, and then at the end here we verify that we fixed this. This is something that we continuously do on our networks. Through the whole process here we could be pulling reports. There are certain key areas that I find that we do pull reports on, but we could really pull reports anytime during this process, so this is the reporting aspect of it all.

The Vulnerability Life Cycle

That's the management process, but we also have a vulnerability life cycle. Specifically we're talking about software vulnerabilities or protocol vulnerabilities. What this looks like is that there's a beginning, middle and end to a lot of these vulnerabilities. What we have at the beginning is what's called zero day — zero day because the developers have had zero time to fix the issue.

Let me give you an example. Let's say we're a software company and we've just rolled out an update to our software, but we didn't realize that it had this major flaw that could be devastating to us, to our customers, to the data that's being stored in the system. We rolled it out not realizing that there's a flaw, so we've had zero days to react to this.

At some point in time this flaw is going to be discovered. Maybe it's discovered by us, maybe it's discovered by somebody we've hired to discover it, maybe it's discovered by one of our customers, maybe it's discovered by a hacker, but it's going to be discovered. Now there's a concern here, because not only do we have this flaw but it's a known flaw, something that could get out and people take advantage of it. Especially if it's a hacker, they might want to take advantage of this flaw.

What happens then is that it gets put on our common vulnerabilities and exposures list. There's a list out there of all these common vulnerabilities and exposures, and so this information would be logged on there as something that is out there. This is a big concern because now it's public knowledge. Really this step isn't just CVE, it's anywhere where this is broadcast out and publicly announced. Now we have a big problem, because anybody can look at that, and a lot of people get notified that this is a new vulnerability. Now hackers are trying to take advantage of this, to exploit it for whatever purpose they are trying to do it for.

So us as a company, we're panicked now and trying to get a fix out there before this vulnerability is exploited and some hacker takes advantage of it. We create a patch to fix this vulnerability and make it go away, and then it gets deployed. Deployed might happen in a couple of ways: if we're a software as a service company we could just deploy it and fix it, but in cases like, let's say, a Windows machine or a Linux machine or something with the operating system, we are going to have to rely on all the companies out there to deploy this fix to their systems that are out there.

The real risk here comes into play between when it's discovered — and it gets heightened when it gets publicly acknowledged out there — to the point where we deploy a fix to it. This is a real danger zone for us and for our customers, and wherever the scenario is, this is the danger zone that we really need to watch out for.

Self Assessment, Scans and Pen Testing

Throughout the process — let's go back to our example where we are a software company developing the software — we're going to want to do a lot of self assessment and make sure that things are secure and that our systems are not vulnerable. But the problem is, we're the ones developing it, so we could have blinders on. Are we really looking at everything correctly? Are we experts in our field, and since we're working on the product, do we already have leanings one way or another with certain vulnerabilities and the way we construct things? So really, getting a third party, some other vendor, somebody else out there doing an assessment for us, a third-party assessment, somebody else coming in and looking at our systems and doing an evaluation, is going to be an important part of this all.

Vulnerability scans could be that we just have some sort of software that we're running on our network and it's discovering issues that we have on our network, vulnerabilities that we have on our network. This would be a fast way to understand whether we have vulnerabilities on our network. If we wanted to take it to the next step, though, we may do some sort of penetration testing. Beyond just having some sort of software that does a scan of our network, now we have somebody that's actually trying to hack our network, that's going in there and trying to figure out what these vulnerabilities on our network are. A lot of times we hire a third party to do this penetration testing, or what we call pen testing for short, to be able to really evaluate our network.