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 focuses 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. 

 Vulnerability Management Cycle

Figure 1. The VM Cycle 

Prework 

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

Determine 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 expand 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 scansfurthermore, 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 assessmentRemote, network-based authenticated assessmentAgent-based assessmentNetwork monitoring or passive scanningIndirect 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 toolsPenetration testingNetwork traffic monitoring toolsCloud service provider scanning toolsBreach 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 organisation. A useful component to include in the VM policy is the timing of remediationthe 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 assetHowever, 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 dataasset ownership and technical and business contextasset locationasset role or business value. 

In the next articles of the series we will talk about the assessment phase and 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. 

Column Header Text Column Header Text Column Header Text

Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection.

Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection.

  • Their work should have not stopped there because achieving
  • Their work should have not stopped there because achieving
  • Their work should have not stopped there because achieving
  • Their work should have not stopped there because achieving

Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection.

Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection.

Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection.

Performing a review of the media inventories at least annually

Performing a review of the media inventories at least annually

Performing a review of the media inventories at least annually

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Discover More

Advantio_Blog_DNS_Diagram_V1 Image caption goes here. This is HTML text.

Compliance consultant specialized in Data Protection Law and ISO/IEC 27001 Lead Auditor; currently working on GDPR, ISO/IEC 27001 and ISO/IEC 27701 projects.

Comments