💡 Vulnerability Management (explained to non-security people)
What are vulnerabilities?
Vulnerabilities are default or flaws in computer systems that weakens the overall security of the device/system. They can be due to a weak design, a bug, or even a configuration mistake. In most of the cases, they are the result of a human error.Vulnerabilities can be exploited by a threat actor, such as an attacker, to cross privilege boundaries within a computer system and gain control of information or functionalities they are not supposed to be able to access.
It is important to understand that no system or design is immune to vulnerabilities. And while some vulnerabilities can be easy to fix, some are very complex to remediate.
Vulnerabilities can come in multiple forms, but there are usually 4 types that are dealt with in Information Security:
- Hardware vulnerabilities are issues in the physical device, being a computer, a router, a web camera or other. These are usually the costliest to fix. Occasionally they can be fixed by a firmware update, but often they would require to replace part or all of the device. Fortunately, they are also often the hardest to exploit, as they might require physical access to the device to be exploited.
- Operating System (OS) vulnerabilities are issues in the OS, such as Microsoft Windows, MacOS or Linux. OS are very complex and contains millions of lines of code written over decades. So it is not unusual for attackers and researchers to find vulnerabilities in them, even years after they have been introduced. This is why OS vendors, like Microsoft and Apple, provides security patches to their systems on a very regular basis (in Microsoft’s case, every second Tuesday of each month). OS vulnerabilities could have grave consequences, as if exploited, they could result in attackers having access to all data and capabilities of the system. But because of the commitment of their vendors and a relatively good culture of patching OS on a regular basis, they are usually fixed quickly, before they become widespread issues.
- Applications vulnerabilities are similar to OS vulnerabilities, but affect a specific application or framework that run on top of the OS. They can be introduced by the developer of the application, or by external libraries used by the applications. Similar to OS’s, they could result in attackers having access to data and capabilities they are not supposed to. Patching of applications is usually not as mature as patching of OS, due to the dependance of the application vendors, the difficulty to track all applications in an organisation, and also the fact that each application might have a different patching approach, resulting in a lot of additional work for the maintenance team.
A recent example of wild-spread application vulnerability is the Log4J zero-day (Log4Shell) that went unnoticed for almost 10 years before being made public in late 2021.
- Configuration vulnerabilities are issues created by the user / administrator of a system or application by setting options and configuration in a way that make them susceptible to an attack. Example of configurations issues are not changing the default password for a system (so anybody knowing the default password can use it to get in) or configuring a system to be open to all on the Internet (as S3 buckets used to be by default). The issue and correction in these cases are not with the vendor but with the user, not following (and often not knowing) adequate practices for their systems and putting themselves at risk.
Tracking and Rating Vulnerabilities
As security became more and more of a concern, and with the very large number of systems and environments available in the world, it became very quickly clear that a common approach to reference, track and rate vulnerabilities was required. As such, the Common Vulnerabilities and Exposure (CVE), a database referencing all published vulnerabilities on OS and software, was established in 1999. It provides a unique ID (i.e. “CVS-2021-3333” ) to all vulnerabilities, a description and references for security professional to consult.The CVE database is extended by the US National Vulnerability Database (NVD), which provides for each vulnerability additional information, such as a risk assessment, affected software and versions, vulnerability type etc.
Vulnerabilities are also being rated using the Common Vulnerability Scoring System (CVSS). The CVSS used a formula to rate risk, helping the security community in a common language and facilitating prioritisation.
CVSS provides a rating from 0 to 10 (10 being the maximum):
The formula considers multiple factors, such as the vector (can it be exploited remotely, is it complex to exploit, does it requires a user interaction… ), temporable (is there a patch, is it exploited… ) and environmental (how it would impact the organisation confidentiality, integrity and availability… )
One thing the formula does not consider is the exposure the systems might have within the organisation exposed. This is left to the organisation’s information security team to assess. As such, it is not unusual to see an organisation decide to prioritise a medium risk issue that might affect their systems exposed to the Internet over a High risk vulnerability that only affect an isolated system, on its own internal network, accessible only by a very limited number of privilege staff.
Zero-Day
Some vulnerabilities are called “Zero-Day” vulnerabilities. This term refers to issues that are already being exploited by malevolent actors at the time the security community is being made aware of them. For vulnerabilities with higher rating, these are usually of great concern as they mean attacks are already happening, and resolving them usually take upmost priority.Detecting vulnerabilities
Due to the usually large number of devices, applications and systems in place in an organisation, it could be extremely complex to detect and track vulnerabilities at an organisation-wide level.Fortunately, a number of commercial solutions exists and can help in scanning and checking for vulnerabilities in an environment. Solutions such as Qualis, Rapid7 and Tenable are the biggest name on that segment.
These solutions can automatically perform scans of computers, servers, network, routers, switches, IoT and more and assess if they present any exposed vulnerabilities that could present a risk for the organisation. Most solutions can also scan cloud capabilities and implementations.
These solutions usually offer 2 scanning approaches:
- Scan without credential performs a surface scanning, trying to identify any vulnerability that would be identifiable by any malevolent actor looking at your network and environments. These scans are usually easy to implement and provide a good perimeter check, but do not provide a full view of the risks the organisation is exposed to.
- Scan with credential usually requires an agent to be installed on the devices to be scanned, and privilege accesses (“credentials” ) to be shared with the scanning tool. These scans will be able to check in details each components of the systems in scope and will be much more efficient at detecting vulnerabilities. However, the effort to configure and deploy this approach requires more effort.
Vulnerabilities scanning solutions also provide capabilities to centralise all the findings, assist in prioritising and managing them, and provide overall reports or specific compliance (such as PCI DSS).
One of the challenges of vulnerability scanning is that not all findings are valid. Occasionally, and especially with configuration management issues, some of the findings might be what is called a “false positive” - an adequate configuration that is considered by the scan as a vulnerability. These cases usually require additional investigation to ensure they are, actually, not a risk, before being safely discarded.
Remediating Vulnerabilities
As mentioned before, detecting vulnerabilities can be quite a big task, but it is usually nothing compared to the coordination, tracking and efforts required to remediate them. It is not rare to see hundreds, if not thousands of vulnerabilities being identified following a scan. The next step consists in classifying them, prioritising them and fixing them. It is an endless battle as new vulnerabilities are identified every day. Large organisations have teams of dozens of engineers just dedicated to these tasks, and they never really get a break.The first task the IT or security team will have to go through will be to prioritise which of the numerous vulnerabilities identified should be resolved first. Using the CVSS rating to identify which items represent a greater risk is a good start, but organisations should also consider their own strategy and preferred approaches. Some will prefer to address first the outlier (the systems with most vulnerabilities, which will help to reduce the number of items quickly), some might focus on a specific vulnerability, some might prefer remediate their most critical systems first. There is no good or bad approach there, but it is essential to have a good tracking of the actions planned, ensuring due dates are met and status is known.
It is usually helpful to define Service Level Agreements (SLA) to help prioritisation and facilitate monitoring the effectiveness of the remediation process. While indicative, and not necessarily achievable by all organisations, it is usually recommended to try to close critical vulnerabilities within a very short amount of time (~5 days), high within a couple of weeks, medium within a month and low within 3 months. But these numbers are relative to each organisation, their appetite for security breaches and their technical capabilities to deliver.
Remediation can take different forms. For configuration management issues, it will usually be a configuration change that will require testing to ensure the new settings do not impact the system.
For application and OS, patches, when available, are the best solutions. Having a patching cycle for all OS and application facilitates vulnerability removal, as the new fixes are deployed systematically on a schedule, closing the vulnerabilities more regularly. Some systems even provide automatic updates, however not all IT departments are necessarily comfortable with these as they can result in untested updates being deployed and (occasionally) breaking the system.
Unfortunately, patches are not always available, or might take time to be published and tested. In such cases, alternative sometime exist (removing or turning off a specific part of the software, changing people accesses… ) and should be considered as a temporary measure.
For hardware, firmware updates work similarly to patches, however usually requires a much more manual distribution approach. And as mentioned earlier, some vulnerabilities are part of the hardware design and cannot be remediated. For these, a replacement plan of the devices must be considered.
Finally, fixing the issue does not mean that the remediation is finished. A vulnerability can only be considered as closed once the remediation has been tested and confirmed functional. This is usually done by running a new scan and confirming the vulnerability is not in the list of findings anymore.