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

Results

• Communications plan for dealing with vulnerability reports from third-parties
• Clear process for releasing security patches to software operators
• Formal process for tracking, handling, and internally communicating about incidents

Add’l Success Metrics

• >80% of project teams briefed on incident response process in past 6 months
• >80% of stakeholders briefed on security issue disclosures in past 6 months

Add’l Costs

• Ongoing organization overhead from incident response process

Add’l Personnel

• Security Auditors (3-5 days/yr)
• Managers (1-2 days/yr)
• Business Owners (1-2 days/yr)
• Support/Operators (1-2 days/yr)

Related Levels

Activities

A. Establish consistent incident response process

Extending from the informal security response team, explicitly document the organization’s incident response process as well as the procedures that team members are expected to follow. Additionally, each member of the security response team must be trained on this material at least annually.

There are several tenets to sound incident response process and they include initial triage to prevent additional damage, change management and patch application, managing project personnel and others involved in the incident, forensic evidence collection and preservation, limiting communication about the incident to stakeholders, well-defined reporting to stakeholders and/or communications trees, etc.

With development teams, the security responders should work together to conduct the technical analysis to verify facts and assumptions about each incident or vulnerability report. Likewise, when project teams detect an incident or high-risk vulnerability, they should follow an internal process that puts them in contact with a member of the security response team.

B. Adopt a security issue disclosure process

For most organizations, it is undesirable to let news of a security problem become public, but there are several important ways in which internal-to-external communications on security issues should be fulfilled.

The first and most common is through creation and deployment of security patches for the software produced by the organization. Generally, if all software projects are only used internally, then this becomes less critical, but for all contexts where the software is being operated by parties external to the organization, a patch release process must exist. It should provide for several factors including change management and regression testing prior to patch release, announcement to operators/users with assigned criticality category for the patch, sparse technical details so that an exploit cannot be directly derived, etc.

Another avenue for external communications is with third parties that report security vulnerabilities in an organization’s software. By adopting and externally posting the expected process with timeframes for response, vulnerability reporters are encouraged to follow responsible disclosure practices.

Lastly, many states and countries legally require external communications for incidents involving data theft of personally identifiable information and other sensitive data type. Should this type of incident occur, the security response team should work with managers and business stakeholders to determine appropriate next-steps.