Vulnerability and Patch Management

At its core, vulnerability management is the practice of operationalizing the risk of known vulnerabilities to aid in making decisions about remediation.

Vulnerabilities are ranked on a scale of severity. While some vulnerabilities are absolutely critical, others are far less so, meaning patching can be postponed or grouped depending on severity.

The practices of Patch Management and Configuration Management enter into the equation as well. Patch Management is the use of strategy and risk management in applying vendor updates. Configuration Management ensures that all settings, parameters, customizations, and access involved in integrating systems are preserved.

These go hand in hand with Vulnerability Management; one is the motivator and the other tries to preserve functionality. Depending on the scale of an organization, applying patches and dealing with the unexpected results of a patch breaking can be a daunting task.

In an ideal world, security updates are analyzed, evaluated, and applied in a steady cadence. This is a pain point for everyone, but the risks involved with being too far out of date can be high. There’s also considerable risk of breaking business critical systems or features with a patch. Erecting some structure and policy around the process, while avoiding panic decisions, is critical to remaining secure and operational.

There are three main pillars of success in executing an effective VM program:

• Visibility and Insight
• Policy and Controls to Aid Decision Making
• Incentive to Act

Asset Visibility and Insight are critical for effective Vulnerability Management

It doesn’t matter how good an organization is at analyzing the risks and technical details of a vulnerability if they lack the other critical pieces of the puzzle- Asset management and IT operations.

Asset management is the foundation of analysis. It provides inventory of systems, the host OS, software installed, and versions. This insight is absolutely necessary to know whether a particular vulnerability is a factor.

How are new assets added? How are lost or compromised assets dealt with? Who is the actual person applying security updates to endpoints? These actions are the purview of IT operations management.

Vulnerability Management Policy and Controls aid Decision Making

Security researchers and software vendors assign severity to vulnerabilities. This is an indicator that’s calculated as a combination of ease-of-exploit, consequences of compromise, as well as other factors. This is just one part of the decision-making process.

An organization must develop their own policies that reflect the criticality of their own assets and functions. These policies need to take into consideration that a security patch or any software update carries the same amount of risk of breaking things as it does to secure them.

It’s important to operationalize vulnerability intel and deployment of patches by coordinating the blocks of stakeholders. Depending on the size and complexity of an organization, certain stakeholders may have different objectives and/or priorities that need to be coordinated and aligned by policy.

Vulnerabilities Won’t Be Patched Without an Incentive to Act

Not everyone is focused on security. For some stakeholders, other motivating factors may result in pushback when presented with a responsive patching strategy.

There is little incentive to act without compliance requirements or a serious security incident even with good visibility into assets and systems, and the capability to patch. Internal governance to enforce policy is an ongoing battle. Some balance can be found between security and productivity with well-defined policy that uses CVE severity and other factors.

VM is a process that begins with the identification of a vulnerability, analysis and evaluation to determine applicability and risk, patching of affected systems, and reporting to reconcile coverage and performance.

Vulnerability Scanning of Assets

With intelligence feeds populated by research and software vendors, the SOC can identify if vulnerabilities exist in the organization. This is purely an exercise in scanning and discovery. In general, no remediation action is taken.

Here are some distinctions in how scanning is performed:

Agent-based scanning vs “agentless” remote scanning

Common endpoint protection solutions accomplish monitoring using an agent that runs locally on the machine to search memory, files, network activity, and software inventory for signs of threats. This same mechanism can correlate software inventory versions with known vulnerabilities. This tends to be a better method for a remote workforce where machines are not always connected to the network during remote scans.

Alternatively, a remote scan method can be used in a more rigid environment where endpoints are connected to a defined network.

Credentialed vs Uncredentialed Scans

An important distinction to make in remote scans is credentialed vs uncredentialed. Does the scanner authenticate in any way to gain access to more detailed information on the endpoint?

Credentialed scans are preferable to obtain software inventory and versions. A passive uncredentialed scan is limited in scope, but is still useful in an asset management capacity for quickly finding deltas in the network client landscape.

Analysis of Vulnerabilities

After a vulnerability is identified and correlated with assets, the team needs to determine if and how a vulnerability represents risk for the organization. No action is needed if a particular CVE only affects a range of older versions of Windows while asset management shows all installed versions are newer.

The analysis phase feeds directly into the policies required for decision making.

Reporting

Reporting is a huge element of VM that allows everyone involved to see progress, coverage, and performance of the teams at work. It involves knowing that vulnerabilities exist in the organization, that they’ve been addressed, and how to best optimize the process. Reporting closes the loop.