Understanding Vulnerability Management

There are some common themes that you pick up on after a few years of doing consulting with organizations, one of them is just how all over the map vulnerability management is. The portion of it that is concerning is the varying understanding of what it is, not the maturity (or lack thereof) of the programs.

“You keep using that word, I do not think it means what you think it means” – Inigo Montoya

What is Vulnerability Management?

Let’s start with a statement and then we can unpack it and go from there: Running vulnerability scans is not vulnerability management. Vulnerability scans are a tool that can be used to support, or be an input to a vulnerability management program, but in of themselves, are not one.

There are a number of authoritative definitions of Vulnerability Management, including from US-CERT, CIS,  ISO and other standards bodies, but if we just look at it for what it is – a vulnerability is a potential vector of weakness that can be acted on by a threat. You are managing them.

Vulnerability Management is risk management, or at least an integral part of it, and as such there is a method to doing this effectively. We can break the thought process behind getting started with Vulnerability Management down into a few steps or stages. However, your mileage may vary.

A Good Vulnerability Management Program

The most important part of vulnerability management is the scope. When it comes to actually making a program out of these things and doing something with all these tools, the single piece of it that everybody skips over is understanding what you have and where it is.

Understand what you have

Fundamentally, you cannot understand risk without following a well known formula. Document assets, document threats, map vulnerabilities to the assets and threats. Vulnerability management is no different. In order to properly understand what vulnerabilities exist, you must first understand what you are protecting. These may be tangible or intangible assets – data, systems, processes, people, facilities, SLAs, hardware, are just a few examples.

Understand what can act against what you have

This could be a who, a when, a why, a where, a what – understand what threats can act against you. A person? Could be an employee, a vendor, a contractor, an external person, anyone. A thing? This could be a government or legislative body (regulation), or maybe environmental (a storm).

Understand what attack surfaces present themselves to your threats

This is a vulnerability. It can be operational, procedural, physical, logical, technical, or many other things. In Information Security, its common to focus on technical vulnerabilities, and reference things like found exploits as a vulnerability, but that is a small portion of the overall picture.

For example, in asset inventory, not knowing what’s authorized in your environment is a vulnerability in of itself. You can’t be proactive about vulnerabilities across the whole enterprise technology stack because you don’t know what’s there all the time. Understanding all that information in a central place, being able to review it all, report on it when a new vulnerability comes up is the one huge piece.

Developing a Methodology

Once you have defined the scope of your vulnerability management program, for example – technical risk associated to known bugs, architecture, and system/device hardening. Then you can begin to develop a methodology to review those defined assets from the specific threats. Its important to define the scope of your activities explicitly, or the organization may lose track of what’s not being done in terms of vulnerability management.

For example, if your scope is narrowly defined to a particular compliance based subset of servers and technologies, and only things that are external facing that are related to items found in a single input, such as a vulnerability scan – there is still unrepresented risk. In turn, the organization may not be able to quantify or properly respond to this risk. The more gaps in your organization’s knowledge, the more unmitigated risk exists. What we notice is that when companies are hyper focused on risk they know about, and firmly believe they have accounted for everything, they often have a false sense of what their actual risk universe is. Even if you have a firm grasp on the elements of risk, changes occur – organizationally, geographically, politically, legally, within your industry, culturally within the company, etc. – it’s important to keep an open mind and remain agile.

Vulnerability Management Tools

Now, where do your tools fit in? Well, there are tools, products, techniques to assist you all over the place within your Vulnerability Management program. GRC solutions can be fed information from other tools and techniques, be it interviews, observations, or automated solutions for example. Vulnerability scanning can help report on some technical vulnerabilities on systems and devices. Penetration testing can take a more target approach and also help validate the level of risk associated to some vulnerability scan findings as well. Social engineering may test the people and processes, some technical capabilities, so on and so forth.

Data and trending of the data from these tools and techniques, can actually develop key risk indicators (KRIs) and key performance indicators (KPIs) which may be used to help alert you when a risk is changing, or that your management method is working as intended. These KPIs and KRIs, as well as what the organization does with them, is vulnerability management.

What does it mean for the cloud?

If you’re using service-based architecture, you will have configurations that need to be made in order to properly secure that environment. Not configuring these services correctly is a vulnerability in of itself.

Depending on where your responsibility starts for management on those machines, there’s things like patching that may or may not be getting done. Maybe it’s a shared responsibility. The question is, in what direction is it going to grow? Is that Cloud provider doing anything to enable you to do a better job to control that scope creep?

Are people the biggest vulnerability?

It’s disingenuous to say that people are the biggest vulnerability. If we’re supply technology to our employees to do things, and it’s simple for them to click on a link that ransomwares and encrypts the entire network, that’s a business problem. It’s not a person problem. It’s a single click for somebody to potentially bring down your entire environment. That’s not fear, that’s not doubt or uncertainty. That’s the reality of the world we live in. Your job as a business is to try to protect yourself from that.

The most common issues often found when incidents occur are

• basic security misconfiguration,
• not requiring strong passwords or allowing previously breached passwords,
• lack of multifactor authentication,
• not doing any patching, and
• not isolating systems on the network.

These are the things that happen over and over again. It’s about the business leaving the front door open sometimes. Vulnerability management is about the tech that allowed you to leave the front door open.

Security and technology have to support the business. They’re going to be agile, and there are going to be exceptions, but you still have to manage those exceptions.

If you need assistance with your vulnerability management technology, please contact us at any time!