Confusion in these terms leads to unprotected businesses and unmanaged risks
The Australian Signals Directorate’s (ASD) Strategies to Mitigate Cyber Security Incidents was published back in February 2017 as a list of activities organisations can undertake to make their ICT systems more resilient to cyber attackers. Two of those eight strategies relate to patching, focusing on application patching to prevent malware running and operating system patching to reduce the damage an incident can cause and help recover data. Both patching strategies fall into the larger field of vulnerability management, however there is some misunderstanding of what vulnerability management is, compared with vulnerability assessment, so let’s look at both activities and see how to ensure you manage the patch deficit as effectively as possible.
What is Vulnerability Management?
In its most basic form, vulnerability management is the process shown in Figure 1, where vulnerabilities are discovered, then go through an assessment phase, get remediated then the process verifies the fixes before proceeding on to the discovery phase again. This is a continual process that requires scanning for and assessing vulnerabilities on an ongoing basis to ensure you understand exactly where your weaknesses are and what you are doing about them.
There are a variety of tools on the market that can perform the vulnerability scans that are required by the discovery stage. They are often used by consultants who are called to assess the current state of an enterprise’s security posture. But this is where the issue lies – the scanning and reporting activities that this kind of point-in-time assessment provides are, but half of the overall vulnerability management process shown in Figure 1. As soon as the consultant provides the report the content is out of date as new vulnerabilities are being discovered all the time. A critical vulnerability that has just been discovered in Microsoft Office, for example, won’t be in your report – so which takes precedence?
Linking this back to the beginning of this post, patching applications and operating systems is the remediation step in your Vulnerability Management programme: i.e. your patch debt equates to a subset of the vulnerabilities that need fixing, alongside any configuration issues, open ports, networking concerns and physical weaknesses.
To be successful in managing these vulnerabilities, and thus assuring Essential Eight compliance, you need to introduce vulnerability management as a process rather than a one-off assessment activity. This means it’s ongoing rather than a point in time assessment, and also includes the remediation as well as a risk assessment.
There are several enterprise ready tools on the market that fit the vulnerability management category, all of which can help institute this process model in your organisation. A real-time scanning tool, where the technology ingests threat intelligence from the parent company in real time and assesses your systems to see which are at risk of exploitation, will allow you to report your findings to management in a format that they understand – i.e. with the risk context. This allows the security team to prioritise remediation activities, where, for example, a Microsoft Office vulnerability would be assessed alongside the other issues to see whether it’s more or less important to your business. The other consideration is to how compensating controls and your infrastructure play a part in this risk context. If a vulnerability is behind firewalls, intrusion protection systems and you have a MSSP watching the network for attacks, even if a vulnerability is publicly listed as high-risk, you might downgrade it for your business.
Interestingly, the ASD fails to include protective monitoring in the Essential Eight, but a well-implemented monitoring capability can de-risk every other security control (or lack thereof). By feeding vulnerability notifications into the SOC, the monitoring team sees where weaknesses exist and vigilance over what’s been patched is exponentially boosted. For example, if a vulnerability is discovered in an older SAP application, with the security team knowing about that weakness, they can build additional monitoring rules and triggers around the application that alerts them to potentially risky behaviour. If someone then tries to exploit that SAP vulnerability, the SOC picks it up and launches into the incident response process.
Security cannot be and should not be something you set and forget; it requires continual cycles of risk assessment, prioritising, remediating and verification, while monitoring who is doing what and to whom – only then will you have the visibility you need to keep the bad guys out and your most sensitive data safe.
