How to set up the right Vulnerability Management processes


Managing your network vulnerabilities and identifying the right vulnerability management processes can be complex. Whilst finding and prioritising vulnerabilities are the responsibility of the security leader, the speed at which these vulnerabilities are remediated is dependent on other people in your organisation. System architects and administrators, IT managers and system owners all play a part in remediating the issues.

As a security professional, you are acutely aware of the security risks in leaving systems in a vulnerable state. However, addressing the issues does not always align with business priorities or present workloads. So how do you set up a process that addresses the challenges above and keeps you on speaking terms with colleagues?

Here is a 3 part process — Categorise, Prioritise, Bitesize — that can help you streamline your activities. More specifically:

  1. Helps you see patterns before they become an issue
  2. Allows you to narrow down the most important threats, and
  3. Execute resolutions as effectively as possible

1- Categorise


After running your first few scans the first step to managing vulnerabilities is to categorise. This helps to indicate potential process issues and highlights common trends and weak areas.

The main categories we come across are:

Missing patches

Many of the issues we see are caused by missing patches. The scans, apart from showing that certain patches are missing may indicate gaps in the patching process. Perhaps the organisation is patching forwards only and never applies past patches to systems that may have changed over time or changed purpose.

Configuration issues

Vulnerability scans can also show an organisation how effective their build standards are. When scans show many different vulnerabilities on similar devices it can be an indication that build standards or hardening guides are not being adhered to.

I have a colleague who works at a large multinational organisation. We were talking about patching and vulnerability management and I asked him how many servers he looked after. His answer surprised and confused me, he said “One”. In reality, he looked after close to 50,000 servers, but the build was consistent, essentially the same server replicated 50,000 times. So, when he fixes one issue on his single server, he’s actually fixing the same issue on all systems.

Scans can also highlight other configuration issues such as misconfigured devices or services, default passwords being used… etc. Many of which can be fixed by fixing the process.

Outdated software

Scans will also highlight the use of outdated software. It is also quite common to discover devices that you were not aware of. For example, in one vulnerability assessment we did, the old Windows 2003 servers were known. The multitude of Windows XP devices and a Windows NT server were more of a surprise.

False positives

Every scanner has a particular way to identify issues. For example, in the early 2000s, there was computer worm called Code Red that attacked Windows IIS servers. To combat this, the vulnerability scanners at the time were primed to spot the product code and version number for IIS. However, not long after Code Red was fixed, Microsoft no longer updated the version number. This meant that vulnerability scanners would still think, based on the version number, that the system was vulnerable to this attack. Even though it had long been fixed. So it is important to understand how the scanner you use identifies certain issues. This allows you to identify false positives.

As part of your process, you need to identify and manage false positives and carefully weed out the irrelevant information for your particular environment.

Don’t care/low risk

The final category we use is the ‘Don’t care’ or Low-risk category. Whilst scanners assign their own risk ratings, there are always findings that would have no or minimum impact on your environment.

Every environment has low-risk items. One of the most common we see is the ICMP timestamp issue. While timestamping issues should be fixed, for many organisations there are more important tasks that need addressing first.

There are also issues that could almost be considered trivial. For example, if “Last user logged on” is shown then it’s a “We’ll get around to it” fix. I’m fairly safe in saying no organisation was ever compromised through this particular issue.

2- Prioritise


When it comes to vulnerabilities, everyone tends to say that every vulnerability is important and urgent – but in reality, it isn’t. Not everything is important or urgent, you do need to prioritise and focus on the most important vulnerabilities you’ve identified.

You can create your priority list by considering:

Importance of asset

Start by looking at the criticality of each asset for your organisation. That is, if the system were to go down or be broken into, what is the realistic impact, would it spell the end for the organisation or just cause a mild inconvenience.

The risks of remediation or not remediating

What is the risk of not fixing the issue? Many organisations deprioritised MS17-010(Eternal Blue). The risk, as many companies found out, was that their environments got infected with Ransomware and suffered significant downtime.

The reverse is also true. Applying a patch for Flash on a critical server, when the server can’t be used to access the internet can probably be left alone for a little while as the risk to the server is higher than the issue it addresses.

Ease and/or difficulty of remediation

The reality is that some issues can be easy to fix, others are complex and could require extensive testing. As you evaluate the vulnerabilities identify how difficult or easy it would be to address as well as the spread of the issue. An issue that has a high impact, i.e. affects a large number of devices, may be addressed prior to a critical issue identified on a few devices.

Accuracy of vulnerability

Vulnerability scanners make suggestions, based on the tests conducted, that a certain vulnerability exists and whilst in many cases that is true, in your environment that may be how things work. The tests may also be basic version checks rather than a comprehensive test, so you need to be technically minded to decide whether the vulnerabilities identified are relevant and accurate for your environment. Scanners still require human interpretation to make the right call.

Scanners, like many software tools, provide a suggested value on the vulnerabilities detected within your environment. However, while you can tweak values to better reflect your needs, you can’t always rely on these numbers to make decisions – let me show you why.

Here we have some examples of common vulnerabilities scanners detect. Let’s explore the suggested values:

Vulnerability Management Processes

 

Password that never expires: the scanner has ranked this as ‘severe’. I tend to agree and would recommend addressing this if the password contained only a handful of characters.

TLS/SSL attacks: Again, I agree with the moderate rating, however, these types of attacks are quite tricky to do as they need very specific information. We could probably leave this one down the list of priorities.

Diffie-Hellman: While this is ranked as moderate, I would categorise this risk as severe if this was an internet facing service. Interestingly, we have found on many occasions that addressing higher-priority issues like this resolves other lower-priority issues.

Windows display last username enabled: This is ranked moderate, but I know it’s a lineball call as some organisations care more about this than others.

3- Bitesize


Vulnerability Scanning Report

 

 

 

 

 

 

 

 

 

 

As you can see from the image, this scanner has spat out a report over 11,000 pages long. Imagine if someone dropped this on your desk with a “here you go, get cracking”. What are the chances you’ll get stuck into it? What are the chances you’ll stay on speaking terms with that person?

Sadly, it’s this sort of common approach that makes it almost impossible for organisations to tackle vulnerabilities effectively.

So instead, we turn this report into bitesize chunks by:

  • Selecting what aligns with the organisation’s priorities. We want to maximise valuable resources.
  • Checking that the task is achievable. This helps to determine the sort of support you need.
  • Identify the quick wins and slow burns. Will the completion of one simple task resolve a widespread issue? Or, do you need to take out more testing or request additional help to complete something more complex

Based on the priorities and the risk to the organisation liaise with the relevant teams. Provide smaller achievable tasks and objectives rather than one large bucket of issues. By splitting the tasks into smaller achievable objectives the teams will be better able to cope.

Identify:

  • What vulnerability has to be fixed now, and
  • What can the business cope with until later

Once you have your priorities in order, create a task list and work your way from top, to bottom. Perhaps start with addressing the easily achieved remediation tasks and build up.

We can’t stress enough how successful this approach is; breaking down your tasks into manageable chunks not only makes it easier to visualise results but engages your organisation along the journey.

As you can see, setting up a process for vulnerability management is essential in streamlining what can otherwise be a difficult and lengthy process. The above approach can make huge improvements in your security posture and guide your continuous improvement when it comes to cybersecurity.