Re-Imagining Vulnerability Management

Vulnerability Management (VM) is, in many ways, both the most straightforward and complex area of Cybersecurity. The simplicity lies in that most of the analytics and solutions work is provided by third parties – companies need to follow directions. The complexity lies in the vast ecosystem of stakeholders required to approve and execute these directions.

Vulnerability management represents one of the most opportunity-laden areas in cybersecurity to reduce risk while substantially increasing non-risk related business value. This approach focuses intently on data, process, and stakeholder management, representing a logical progression companies can leverage to keep their environments secure while improving the health and effectiveness of their infrastructure assets and services. Cybersecurity excellence and business operational excellence can be much more closely aligned than many may believe.

Defining the Scope of Vulnerability Management

Technically, any weakness compromising cybersecurity could be considered a vulnerability, from insecure data center infrastructure, disgruntled employees, etc. However, within the Next Generation Vulnerability Management framework, we will use the TranSigma definition, which outlines a slightly broader scope than traditional definitions.

Traditionally, VM addresses Infrastructure Vulnerabilities -- that is, all third-party software vulnerabilities on compute, network, and peripheral assets, with the notable exclusion of custom-built applications.

Additionally, we include the most common factors that preclude or inhibit the remediation of vulnerabilities, such as:

• Data deficiencies, such as weak or missing CMDB or ITAM data

• Missing or malfunctioning scanning and management/deployment agents 

• General IT Asset Management concerns, such as missing assets, hardware/software lifecycle management, and hardware performance

The Zero Vulnerability Framework

In traditional risk-based VM programs, most vulnerabilities are unaccounted for.  Further, those vulnerabilities which are targeted for remediation are often "assigned" to groups or individuals who are in no real position to address them.  These are the two main problems that ZVF aims to solve. Within ZVF, there is no vulnerability without an accountable risk owner and a responsible risk remediator, and the goal is to assign this ownership with precision.

1. Every known & potential vulnerability is accounted for.

In a Cybersecurity-owned VM program without close collaboration and support from other stakeholder groups, a “risk-based” approach tends to be taken. Based on the criticality of the underlying assets (data, applications, compute environments), and the criticality of the vulnerabilities, Cyber teams will often define a threshold and distribute the exposures throughout the organization for remediation. Everything else… is, by definition, involuntarily risk accepted. In the Zero Vulnerability Framework (ZVF), all risk acceptance – for current AND future vulnerabilities can ONLY be voluntary.

2. Risk Management is centered on the attack surface (IT assets – hardware, network devices, software).

Vulnerabilities grow in proportion to your attack surface and reduce in proportion to your successful management of that attack surface. Every new mobile device, PC, domain controller, application server - even a new installation of Java, MS Office, or WinZip on existing infrastructure - represents more current, or at least future, vulnerabilities in your environment. More critically, the attack surface is more at-risk if there are assets that are not currently accounted for, uncontrolled installations of non-compliant software, or instances of non-compliant software configurations.

3. ITAM and ITSM ownership groups, which tend to fall under infrastructure and the CTO, should lead vulnerability management, with Cybersecurity governing and Digital Leadership Championing.

There are several fundamental reasons why the infrastructure organization should lead VM:

• Cybersecurity’s mandate is to optimize risk in the organization, but in the case of Vulnerability Management, most of the knowledge and ability to remediate this risk sits with infrastructure teams – not Cybersecurity.

• If the onus is put upon infrastructure, it is far more likely that broader and more efficient solutions will be pursued, tackling the problem at a more foundational state.

• Further, those improvements will yield tremendous benefits in lower support costs, hardware and software costs, improved systems availability, and more.

In short – Cyber should set the standards, Infrastructure should be responsible for meeting those standards in the way Infrastructure sees fit, and the business leadership should hold digital leadership accountable.

4. Responsibility for the remediation of vulnerabilities across the attack surface should be aligned into services, explained further in Service Oriented Vulnerability Management.

Following on from the last point, cyber is NEVER going to stop asking for vulnerabilities to be remediated, and due to the nature of VM, vulnerabilities will NEVER stop being found and corrected on virtually any software package. Eventually, it becomes clear that investing in processes and services is the only way to tackle the VM problem.

Service Oriented Vulnerability Management

Service Oriented Vulnerability Management (SOVM) is the execution methodology for the ZVF. Tactically, VM remediation is really about the execution of highly repeatable and generally automatable actions, so there’s no reason to convolute what should be science into an art form. From a strategic standpoint, it simplifies the governance and management of VM into the management of a hierarchy of services, much as we would manage any area of IT. SOVM is not about getting to zero vulnerabilities, but about finding the optimal balance. This is where risk-based vulnerability management meets SOVM, in that investment decisions, rather than vulnerability decisions can be made to address enterprise-wide risk.

1. SOVM provides the execution methodology for the Zero Vulnerability Framework, in that every remediation need for every asset in the attack surface falls into the responsibility of a specific service.

In the context of SOVM, Services are collections of one or more actors responsible for one or more remedial actions across a collection of IT assets, possibly according to defined expectations, such as SLAs.

Though vulnerabilities MUST fall into a “service,” a service’s maturity can range from a defaulted application of responsibility (e.g., you own these assets, so any vulnerabilities on them are yours), to a precisely governed scope of remediation services with a professional vendor, SLAs, and the like.

2. Vulnerabilities must be viewed regarding the action required to remediate them, not the vulnerabilities themselves.

Consider commonly accepted “ownership areas,” such as OS patching or DB management. The vulnerabilities that ultimately roll into the actions owned and executed by those areas are their responsibility. Every vulnerability has an action associated with its remediation, and the correct owner of that action is responsible for those vulnerabilities.

3. Services address the reality that nearly all vulnerabilities are remediated though repetitive actions over time.

While vulnerabilities are static weaknesses that can be addressed and considered finalized, the underlying attack surface is never finalized. Software continues to have security updates published in response to new vulnerabilities that are found, and solutions are published on a continual basis. The two critical requirements for organizations:

• The ability to apply these solutions (a.k.a. actions)

• The discipline and rigor to apply these solutions again and again as they become available (a.k.a. services)