top of page
  • brencronin

Vulnerability Management - Tracking & Treating

Updated: Oct 26, 2023

In a previous article I highlighted a framework for vulnerability management program, developed by SANS instructors Jonathan Risto and David Hazar, called P.I.A.C.T. which maps key areas of vulnerability management across a Capability Maturity Model.

  • Planning

  • Identification

  • Analyze/Assess

  • Communicate

  • Treat

Following the phases of 'Identifying' and 'Assessing' vulnerabilities, the subsequent steps involve 'Communicating' (C) and 'Treating' (T) these vulnerabilities. One key reason I emphasize understanding the treatment process before communication is that many organizations have distinct Information Technology (IT) teams responsible for patching various systems. While it might be evident to these IT teams which systems fall under their jurisdiction, it's not always as clear to cybersecurity engineers who are tracking the vulnerabilities on those systems, especially those lacking the extensive experience of the IT professionals to whom they're conveying vulnerability information and patching requirements.

Furthermore, while there is an element of tracking vulnerabilities in the 'Identify' and 'Assess' domains, one of the most crucial areas to track is the 'Treatment' phase of vulnerabilities. This emphasis is warranted because fixing and patching vulnerabilities is not as straightforward as clicking a magic 'patch' button; the engineers responsible for applying patches often need to provide an estimated timeframe for completing the task because they need to do testing and other activities related to patching.

Tracking Vulnerabilities

One challenge associated with tracking vulnerabilities lies in the way vulnerability scanning systems primarily rely on key values like IP addresses (indicating the scanned system with vulnerabilities) and the specific vulnerabilities identified on each system. Managing these data points can become overwhelming, especially when dealing with a large number of systems and a multitude of vulnerabilities.

A central cybersecurity risk managerial concern revolves around the question, 'Given the array of vulnerabilities we've identified, when can we expect them to be patched?' Providing a definitive response to this query is a challenging task, even for an individual within the organization's IT team. The complexity stems from the likelihood that the IT team comprises multiple engineers assigned to different system types, each with unique testing procedures and patching schedules. Hence, this underscores the critical need to organize vulnerability tracking by system type and assign responsibility to the respective groups handling those system types.

With the correct system owners identified, you can now work with them on patching timelines and have a more accurate answer to the question, 'When can we expect the vulnerabilities to be patched?'

This is precisely where enumeration scanning, and asset management systems prove to be invaluable. Enumeration plays a crucial role in identifying the system type, while an effective asset management system should provide clarity regarding the individual or team responsible for patching each system type. Unfortunately, many organizations lack robust asset management, and the answer to the question, 'Who is responsible for patching each system type?' often exists informally within the organization. As a result, new cybersecurity engineers typically find themselves in a position of needing to inquire across teams to address this query. However, the enumeration data from the scans still remains an invaluable resource since it enables the identification of systems by operating system type, serving as a valuable starting point for locating the rightful system owner responsible for patching those systems.

IT system administrators need help too!

Even with years of experience, system administrators responsible for patching their systems may not have immediate answers (such as a 'patch' button) at their disposal. They often need to conduct their own research to comprehend various aspects of a vulnerability, including its nature, how it was detected, required remediation steps, and the potential implications of implementing patches on system functionality and availability. Providing system owners with access to the scan data is pivotal, as it significantly aids in the patching process. Additionally, this access to the vulnerability scan data can be invaluable in cases where a vulnerability is a false positive, allowing the system owner to discern such occurrences.

Key areas to a mature vulnerability management 'Treatment' capability

Key facets of a mature vulnerability management 'Treatment' capability fall under three main sub-areas:

  • Change Management

  • Patch Management

  • Configuration Management

Change Management

In the context of change management, the continuum of capabilities begins with the organization having a standardized change management process for all aspects (CMM level 1 'Initial'). As it progresses to CMM level 2 ('Managed'), a custom change process and workflow are developed specifically for handling vulnerability-related changes. At higher levels of change management capabilities, the organizations capabilities also include implementing automation for change processes and comprehensive metrics tracking, particularly in the context of vulnerability management.

Patch Management

When it comes to patch management, the continuum of capabilities initiates with the organization manually applying patches in an ad hoc manner (CMM level 1 'Initial'). As it advances to CMM level 2 ('Managed'), automated systems are introduced for patching, along with a structured patching schedule. In the more advanced stages of patch management capabilities, the organizations capabilities also include established deadlines for patching, tracking patching metrics, and integrating Cyber Threat Intelligence (CTI) data into patching activities.

Configuration Management

In the context of configuration management, the continuum of capabilities begins with the organization manually applying configuration standards in an ad hoc manner (CMM level 1 'Initial'). Advancing to CMM level 2 ('Managed'), the organization defines configuration standards, such as CIS benchmarks, and these standards are systematically enforced through automation using tools like Puppet, Ansible, GPO, and so on.

In the more advanced stages of configuration management, when the organization reaches CMM level 4 ('Quantitatively Managed'), it includes mechanisms for detecting (compliance scanning) and tracking deviations from these standards. The organization also integrates configuration management metrics into its capabilities, as well as the use of Cyber Threat Intelligence (CTI) data in its configuration management activities at CMM Level 5 ('Optimized').

7 views0 comments

Recent Posts

See All


Post: Blog2_Post
bottom of page