Vulnerability Management: Introduction & Prework

We are starting a new series of articles about Vulnerability Management ("VM") with the aim to provide a structured approach to VM's best practices. 

Definitions 

Vulnerability refers to a fault that is exposed to possible exploitation; a threat taking advantage of vulnerability can cause a chain of negative consequences for the whole organization.  

Vulnerability Management (VM) can be defined as a process cycle for finding, assessing, remediating, and mitigating security weaknesses on information systems. VM includes components that are distributed among people, processes, and technology. 

Scope of the series 

Our new series of articles focus only on known software-related vulnerabilities in the resource layer (e.g. configuration weaknesses, unpatched OS components, etc.). The scope is confined to looking for reported, known vulnerabilities across systems, such as those assigned a Common Vulnerabilities and Exposures (“CVE”) ID. 

Security vulnerabilities can also exist outside of hosts, applications, and network devices, as well as outside of the IT domain (e.g. Physical security, unnecessarily loose user access permissions, etc.) but these are not addressed by traditional VM processes and are not in scope for this and upcoming articles. 

Vulnerability Management  

VM can be visualized as a continuous cycle with five phases: Assess, Prioritize, Act, Re-assess and Improve. Besides, a pre-phase-defined Prework lays the foundation for ongoing processes. 

Figure 1. The VM Cycle 

Prework 

The Prework can be split into the following sub-phases. 

Determine the scope of the program 

The scope of VM’s activities must include the whole set of information systems. This also includes mainframes to embedded modern technologies (e.g. IPv6, IoT, BYOD, Cloud Computing, etc.), and even expands beyond IT into Operational Technology. Any initial scoping effort must cover all three aspects of people, process, and technology. 

However, this does not automatically imply that all of those information systems should be in scope for a single process. Organizations can choose to manage the risks related to certain types of vulnerabilities or technologies with different processes; this depends on factors such as organizational structure and risk profile. Moreover, vulnerabilities on custom-developed software, for example, are often managed as part of the SDLC and may be left out of the VM program. 

Define roles and responsibilities 

At a minimum, the organization must define who is responsible for operating the VA tool and who will act on the results of the vulnerability scans; furthermore, the handover processes between these two groups should be clearly defined and applied consistently. Organizations with more complex IT structures may have to define additional roles (e.g. Security and risk management, Security operations, etc.).  

Select vulnerability assessment methods and tools 

The organization must select the VA methods and tools according to what it includes in its VM program; most organizations will rely on traditional VA tools, such as Qualys. 

VA can be performed using several methods: Remote, network-based unauthenticated assessment, Remote, network-based authenticated assessment, Agent-based assessment, Network monitoring or “passive scanning, Indirect assessment via APIs, or integration with external tools.  

Besides, several tools with different objectives may also include VA capabilities such as IT service management and patch management tools, Penetration testing, Network traffic monitoring tools, Cloud service provider scanning tools, Breach and attack simulation tools. 

Create and refine policy and SLAs 

Risk assessment is the starting point for developing a VM program; as a shortcut, some organizations may start their VM efforts by focusing on the regulated systems (e.g. PCI DSS compliance mandates vulnerability scanning, reporting, and even specific remediation time frames — 30 days, unless the risk assessment indicates otherwise). However, this approach must also be assessed concerning the specific risks faced by the organization. A useful component to include in the VM policy is the timing of remediation; the more nuanced policies will be more successful. 

Identify asset context sources 

VM requires decisions that are made based on several factors. The severity, for example, is an intrinsic characteristic of the vulnerability and it is independent of the asset. However, information about vulnerable assets is also a crucial element in making these decisions. The most common source of asset information is the Configuration Management DataBase (“CMDB”) but very few organizations have complete and up-to-date CMDBs; in these cases, organizations may need to put together an alternative source of context data.  Basic information about assets used for VM purposes includes asset identification data, asset ownership and technical and business context, asset location, asset role, or business value. 

In the next articles of the series, we will talk about the assessment phase and the best ways to prioritize vulnerabilities. 

If your company wants to take its vulnerability management strategy to the next level, get in touch with us and our team will guide you through this process.