Deployment: Configuration Management and Vulnerability Management (CMVM)
The overall goal of the Configuration Management and Vulnerability Management practice is change management. The SSG and application owners must ensure their ability to track authorized changes to applications and to detect unauthorized changes and activity. Application owners must enforce adherence to corporate policy.
|
DEPLOYMENT: CONFIGURATION MANAGEMENT AND VULNERABILITY MANAGEMENT Patching and updating applications, version control, defect tracking and remediation, incident handling. |
|||
|---|---|---|---|
| Objective | Activity | Level | |
| CMVM1.1 | know what to do when something bad happens | create/interface with incident response | 1 |
| CMVM1.2 | use ops data to change dev behavior | identify software bugs found in ops monitoring and feed back to dev | |
| CMVM2.1 | be able to fix apps when they are under direct attack | have emergency codebase response | 2 |
| CMVM2.2 | use ops data to change dev behavior | track software bugs found during ops through the fix process | |
| CMVM2.3 | know where the code is | develop operations inventory of apps | |
| CMVM3.1 | learn from operational experience | fix all occurrences of software bugs from ops in the codebase (T: code review) | 3 |
| CMVM3.2 | use ops data to change dev behavior | enhance dev processes (SSDL) to prevent cause of software bugs found in ops | |
CMVM Level 1: Use operations monitoring data to drive developer behavior. The SSG supports incident response. The SSG uses operations data to suggest changes in the SSDL and developer behavior.
CMVM1.1
Create or interface with incident response. The SSG is prepared to respond to an incident. The group either creates its own incident response capability or 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.
CMVM1.2
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).
CMVM Level 2: Ensure that emergency response is available during application attack. Managers and the SSG support emergency response to ongoing application attacks. Managers and the SSG maintain a code inventory. The SSG uses operations data to direct evolution in the SSDL and in developer behavior.
CMVM2.1
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.
CMVM2.2
Track software bugs found during ops through the fix process. Defects found during operations are fed back to development and tracked through the fix process. This capability could come in the form of a two-way bridge between the operations trouble ticket system and the development defect tracking system. Make sure the loop is closed completely.
CMVM2.3
Develop operations inventory of applications. The organization has a map of its software deployments. If a piece of code needs to be changed, operations can reliably identify all of the places where the change needs to be installed.
CMVM Level 3: Create a tight loop between operations and development. The SSG must ensure the SSDL both addresses code deficiencies found in operations and includes enhancements that eliminate associated root causes.
CMVM3.1
Fix all occurrences of software bugs from ops in the codebase. The organization fixes all instances of software bugs 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.)
CMVM3.2
Enhance dev processes (SSDL) to prevent cause of software bugs found in ops. Experience from operations leads to changes in the development process (SSDL). The SSDL is strengthened to prevent a repeat of bugs found during operations. To make this process systematic, the incident response post mortem could include a "feedback to SSDL" step.)