Configuration Management & 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 Management & Vulnerability Management Level 1

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

The SSG is prepared to respond to an incident and is regularly included in the incident response process, either by creating its own incident response capability or regularly interfacing with the organization’s existing 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 as well. In many cases, SSIs evolved from incident response teams who began to realize that software vulnerabilities were the bane of their existence.

[CMVM1.2: 102] 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 (making use of a special security flag) seems to work. The idea is to close the information loop and make sure that security problems get fixed. In the best of cases, processes in the SSDL can be improved based on operational data.  

Configuration Management & Vulnerability Management Level 2

[CMVM2.1: 82] 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, and a process that has never been used might not actually work.

[CMVM2.2: 87] 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: 57] 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. 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. Remember, open source components are components, too.

Configuration Management & Vulnerability Management Level 3

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

The organization fixes all instances of each bug found during operations, not just the small number of instances that trigger 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 via automated code review.

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

Experience from operations leads to changes in the SSDL, which 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 DevOps teams might have an easier time with this because all the players are involved. An ad hoc approach is not sufficient.

[CMVM3.3: 9] Simulate software crises.

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 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: 13] 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 service 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.