This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
SAMM - Vulnerability Management - 1
|
For the latest project news and information, join the mailing list and visit the OpenSAMM website. |
|
|
|
Vulnerability Management - 1
| Objective: Understand high-level plan for responding to vulnerability reports or incidents |
Results
- Lightweight process in place to handle high-priority vulnerabilities or incidents
- Framework for stakeholder notification and reporting of events with security impact
- High-level due diligence for handling security issues
Success Metrics
- >50% of the organization briefed on closest security point of contact in past 6 months
- >1 meeting of security response team and points of contact in past 12 months
Costs
- Ongoing variable project overhead from staff filling the security point of contact roles
- Identification of appropriate security response team
Personnel
- Security Auditors (1 day/yr)
- Architects (1 day/yr)
- Managers (1 day/yr)
- Business Owners (1 day/yr)
Related Levels
- Education & Guidance - 2
- Strategy & Metrics - 3
Activities
A. Identify point of contact for security issues
For each division within the organization or for each project team, establish a point of contact to serve as a communications hub for security information. While generally this responsibility will not claim much time from the individuals, the purpose of having a predetermined point of contact is to add structure and governance for vulnerability management.
Examples of incidents that might cause the utilization include receipt of a vulnerability report from an external entity, compromise or other security failure of software in the field, internal discovery of high-risk vulnerabilities, etc. In case of an event, the closest contact would step in as an extra resource and advisor to the affected project team(s) to provide technical guidance and brief other stakeholders on progress of mitigation efforts.
The point of contact should be chosen from security-savvy technical or management staff with a breadth of knowledge over the software projects in the organization. A list of these assigned security points of contact should be centrally maintained and updated at least every six months. Additionally, publishing and advertising this list allows staff within the organization to request help and work directly with one another on security problems.
B. Create informal security response team(s)
From the list of individuals assigned responsibility as a security point of contact or from dedicated security personnel, select a small group to serve as a centralized technical security response team. The responsibilities of the team will include directly taking ownership of security incidents or vulnerability reports and being responsible for triage, mitigation, and reporting to stakeholders.
Given their responsibility when tapped, members of the security response team are also responsible for executive briefings and upward communication during an incident. It is likely that most of the time, the security response team would not be operating in this capacity, though they must be flexible enough to be able to respond quickly or a smooth process must exist for deferring and incident to another team member.
The response team should hold a meeting at least annually to brief security points of contact on the response process and high-level expectations for security-related reporting from project teams.
