Difference between revisions of "SAMM - Vulnerability Management - 3"

Results

• Detailed feedback for organizational improvement after each incident
• Rough cost estimation from vulnerabilities and compromises
• Stakeholders better able to make tradeoff decisions based on historic incident trends

Add’l Success Metrics

• >80% of incidents documented with root causes and further recommendations in past 6 months
• >80% of incidents collated for metrics in the past 6 months

Add’l Costs

• Ongoing organization overhead from conducting deeper research and analysis of incidents
• Ongoing organization overhead from collection and review of incident metrics

Add’l Personnel

• Security Auditors (3 days/yr)
• Managers (2 days/yr)
• Business Owners (2 days/yr)

Related Levels

• Strategy & Metrics - 3

Activities

A. Conduct root cause analysis for incidents

Though potentially time consuming, the incident response process should be augmented to include additional analysis to identify the key, underlying security failures. These root causes can be technical problems such as code-level vulnerabilities, configuration errors, etc. or they can be people/process problems such as social engineering, failure to follow procedures, etc.

Once a root cause is identified for an incident, it should be used as a tool to find other potential weaknesses in the organization where an analogous incident could have occurred. For each identified weakness additional recommendations for proactive mitigations should be communicated as part of closing out the original incident response effort.

Any recommendations based on root cause analysis should be reviewed by management and relevant business stakeholders in order to either schedule mitigation activities or note the accepted risks.

B. Collect per-incident metrics

By having a centralized process to handle all compromise and high-priority vulnerability reports, an organization is enabled to take measurements of trends over time to determine impact and efficiency of initiatives for security assurance.

Records of past incidents should be stored and reviewed at least every 6 months. Group similar incidents and simply tally the overall count for each type of problem. Additional measurements to take from the incidents include frequency of software projects affected by incidents, system downtime and cost from loss of use, human resources taken in handling and cleanup of the incident, estimates of long-term costs such as regulatory fines or brand damage, etc. For root causes that were technical problems in nature, it is also helpful to identify what kind of proactive, review, or operational practice might have detected it earlier or lessened the damage.

This information is concrete feedback into the program planning process since it represents the real security impact that the organization has felt over time.