Difference between revisions of "SAMM - Security Requirements - 3"

Results

• Formally set baseline for security expectations from external code
• Centralized information on security effort undertaken by each project team
• Ability to align resources to projects based on application risk and desired security requirements

Add’l Success Metrics

• >80% of projects passing security requirements audit in past 6 months
• >80% of vendor agreements analyzed for contractual security requirements in past 12 months

Add’l Costs

• Increased cost from outsourced development from additional security requirements
• Ongoing project overhead from release gates for security requirements

Add’l Personnel

• Security Auditor (2 days/yr)
• Managers (2 days/yr)
• Business Owners (1 day/yr)

Related Levels

• Threat Assessment - 3
• Policy & Compliance - 2

Activities

A. Build security requirements into supplier agreements

Beyond the kinds of security requirements already identified by previous analysis, additional security benefits can be derived from third-party agreements. Typically, requirements and perhaps high-level design will be developed internally while detailed design and implementation is often left up to suppliers.

Based on the specific division of labor for each externally developed component, identify specific security activities and technical assessment criteria to add to the vendor contracts. Commonly, this is a set of activities from the Design Review, Code Review, and Security Testing Practices.

Modifications of agreement language should be handled on a case-by-case basis with each supplier since adding additional requirements will generally mean an increase in cost. The cost of each potential security activity should be balanced against the benefit of the activity as per the usage of the component or system being considered.

B. Expand audit program for security requirements

Incorporate checks for completeness of security requirements into routine project audits. Since this can be difficult to gauge without project-specific knowledge, the audit should focus on checking project artifacts such as requirements or design documentation for evidence that the proper types of analysis were conducted.

Particularly, each functional requirement should be annotated with security requirements based on business drivers as well as expected abuse scenarios. The overall project requirements should contain a list of requirements generated from best-practices in guidelines and standards. Additionally, there should be a clear list of unfulfilled security requirements and an estimated timeline for their provision in future releases.

This audit should be performed during every development iteration, ideally toward the end of the requirements process, but it must be performed before a release can be made.