The recommended approach is to slowly add best

Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: ication risk and desired security requirements Security Requirements SR 1 Consider security explicitly during the software requirements process Activities A. Derive security requirements from business functionality Conduct a review of functional requirements that specify the business logic and overall behavior for each software project. After gathering requirements for a project, conduct an assessment to derive relevant security requirements. Even if software is being built by a third-party, these requirements, once identified, should be included with functional requirements delivered to vendors. For each functional requirement, a security auditor should lead stakeholders through the process of explicitly noting any expectations with regard to security. Typically, questions to clarify for each requirement include expectations for data security, access control, transaction integrity, criticality of business function, separation of duties, uptime, etc. It is important to ensure that all security requirements follow the same principles for writing good requirements in general. Specifically, they should be specific, measurable, and reasonable. Conduct this process for all new requirements on active projects. For existing features, it is recommended to conduct the same process as a gap analysis to fuel future refactoring for security. Results ✦✦High-level alignment of development effort with business risks ✦✦Ad hoc capturing of industry best-practices for security as explicit requirements ✦✦Awareness amongst stakeholders of measures being taken to mitigate risk from software Success Metrics ✦✦>50% of project teams with explicitly defined security requirements Costs ✦✦Project overhead from addition of security requirements to each development cycle B. Evaluate security and compliance guidance for requirements It is important to not attempt to bring in too many best-practice requirements into each development iteration since there is a time trade-off with design and implementation. The recommended approach is to slowly add best-practices over successive development cycles to bolster the software’s overall assurance profile over time. For existing systems, refactoring for security best practices can be a complex undertaking. Where possible, add security requirements opportunistically when adding new features. At a minimum, conducting the analysis to identify applicable best practices should be done to help fuel future planning efforts. This review should be performed by a security auditor with input from business stakeholders. Senior developers, architects, and other technical stakeholders should also be involved to bring design and implementation-specific knowledge into the decision process. Personnel ✦✦Security Auditor (2 days/yr) ✦✦Business Owner (1 days/yr) ✦✦Managers (1 day/yr) ✦✦Architects (1 day/yr) Related Levels ✦✦Education & Guidance - 1 ✦✦Policy & Compliance - 2 ✦✦Design Review - 1 ✦✦Code Review - 1 ✦✦Security Testing...
View Full Document

{[ snackBarMessage ]}

Ask a homework question - tutors are online