Configuration And Vulnerability Management

The Configuration Management & Vulnerability Management practice concerns itself with patching and updating applications, version control, defect tracking and remediation, and incident handling.

Configuration and Vulnerability Management Level 1

[CMVM1.1: 92] Create or interface with incident response.

The SSG is prepared to respond to an incident and is regularly included in the incident response process. The group either creates its own incident response capability or regularly interfaces with the organization’s existing incident response team. A regular meeting between the SSG and the incident response team can keep information flowing in both directions. Sometimes cloud service providers need to be looped in. In many cases, software security initiatives have evolved from incident response teams who began to realize that software vulnerabilities were the bane of their existence.


[CMVM1.2: 96] Identify software defects found in operations monitoring and feed them back to development.

Defects identified through operations monitoring are fed back to development and used to change developer behavior. The contents of production logs can be revealing (or can reveal the need for improved logging). In some cases, providing a way to enter incident triage data into an existing bug-tracking system (many times making use of a special security flag) seems to work. The idea is to close the information loop and make sure security problems get fixed. In the best of cases, processes in the SSDL can be improved based on operational data.

Configuration and Vulnerability Management Level 2

[CMVM2.1: 78] Have emergency codebase response.

The organization can make quick code changes when an application is under attack. A rapid-response team works in conjunction with the application owners and the SSG to study the code and the attack, find a resolution, and push a patch into production. Often, the emergency response team is the development team itself, especially when agile methodologies are in use. Fire drills don’t count; a well-defined process is required. A process that has never been used might not actually work.


[CMVM2.2: 83] Track software bugs found in operations through the fix process.

Defects found in operations are fed back to development, entered into established defect management systems, and tracked through the fix process. This capability could come in the form of a two-way bridge between the bug finders and the bug fixers. Make sure the loop is closed completely. Setting a security flag in the bug-tracking system can help facilitate tracking.

[CMVM2.3: 44] Develop an operations inventory of applications.

The organization has a map of its software deployments. If a piece of code needs to be changed, Operations or DevOps can reliably identify all the places where the change needs to be installed. Sometimes common components shared between multiple projects are noted so that when an error occurs in one application, other applications that share the same components can be fixed as well.

Configuration and Vulnerability Management Level 3

[CMVM3.1: 4] Fix all occurrences of software bugs found in operations.

The organization fixes all instances of each software bug found during operations and not just the small number of instances that have triggered bug reports. This requires the ability to reexamine the entire codebase when new kinds of bugs come to light (see [CR3.3 Build capability for eradicating specific bugs from entire codebase]). One way to approach this is to create a rule set that generalizes a deployed bug into something that can be scanned for using automated code review.

[CMVM3.2: 6] Enhance the SSDL to prevent software bugs found in operations.

Experience from operations leads to changes in the SSDL. The SSDL is strengthened to prevent the reintroduction of bugs found during operations. To make this process systematic, each incident response postmortem could include a “feedback to SSDL” step. This works best when root-cause analysis pinpoints where in the SDLC an error could have been introduced or slipped by uncaught. Cross-functional agile teams might have an easier time with this because all the players are involved. An ad hoc approach is not sufficient.

[CMVM3.3: 7] Simulate software crisis.

The SSG simulates high-impact software security crises to ensure software incident response capabilities minimize damage. Simulations could test for the ability to identify and mitigate specific threats or, in other cases, could begin with the assumption that a critical system or service is already compromised and evaluate the organization’s ability to respond. When simulations model successful attacks, an important question to consider is the time period required to clean up. Regardless, simulations must focus on security-relevant software failure and not on natural disasters or other types of emergency response drills. If the data center is burning to the ground, the SSG won’t be among the first responders.

[CMVM3.4: 12] Operate a bug bounty program.

The organization solicits vulnerability reports from external researchers and pays a bounty for each verified and accepted vulnerability received. Payouts typically follow a sliding scale linked to multiple factors, such as vulnerability type (e.g., remote code execution is worth $10,000 versus CSRF is worth $750), exploitability (demonstrable exploits command much higher payouts), or specific services and software versions (widely deployed or critical services warrant higher payouts). Ad hoc or short-duration activities, such as capture-the- flag contests, do not count.