This preview shows page 1. Sign up to view the full content.
Unformatted text preview: ess owners and security auditors as needed.
Ultimately, the notion of risks leading to new security requirements should become a builtin step in the planning phase whereby newly discovered risks are specifically assessed by
project teams. Security Requirements SR 3 Mandate security requirements process for all software projects and third-party dependencies 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
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. 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
✦✦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
View Full Document
- Spring '14