Exceptions for should be limited to no more than 20

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: cally, high-risk functionality will correlate to features implementing creation, access, update, and deletion of sensitive data. Beyond data, high-risk functionality also includes project-specific business logic that is critical in nature, either from a denial-of-service or compromise perspective. For each identified data source or business function, select and use a standardized notation to capture relevant software modules, data sources, actors, and messages that flow amongst them. It is often helpful to start with a high-level design diagram and iteratively flesh out relevant detail while removing elements that do not correspond to the sensitive resource. With data-flow diagrams created for a project, conduct analysis over them to determine internal choke-points in the design. Generally, these will be individual software modules that handle data with differing sensitivity levels or those that gate access to several business functions of various levels of business criticality. B. Establish release gates for design review Results ✦✦Granular view of weak points in a system design to encourage better compartmentalization ✦✦Organization-level awareness of project standing against baseline security expectations for architecture ✦✦Comparisons between projects for efficiency and progress toward mitigating known flaws Add’l Success Metrics ✦✦>80% of projects with updated dataflow diagrams in past 6 months ✦✦>75% of projects passing design review audit in past 6 months Add’l Costs Having established a consistent design review program, the next step of enforcement is to set a particular point in the software development life-cycle where a project cannot pass until an design review is conducted and findings are reviewed and accepted. In order to accomplish this, a baseline level of expectations should be set, e.g. no projects with any high-severity findings will be allowed to pass and all other findings must be accepted by the business owner. ✦✦Ongoing project overhead from maintenance of data-flow diagrams ✦✦Organization overhead from project delays caused by failed design review audits Generally, design reviews should occur toward the end of the design phase to aide early detection of security issues, but it must occur before releases can be made from the project team. Add’l Personnel ✦✦Developers (2 days/yr) ✦✦Architects (1 day/yr) ✦✦Managers (1-2 days/yr) ✦✦Business Owners (1-2 days/yr) ✦✦Security Auditors (2-3 days/yr) Related Levels ✦✦Secure Architecture - 3 ✦✦Code Review - 3 SAMM / The Security Practices - v1.0 For legacy systems or inactive projects, an exception process should be created to allow those projects to continue operations, but with an explicitly assigned timeframe for each to be reviewed to illuminate any hidden vulnerabilities in the existing systems. Exceptions for should be limited to no more than 20% of all projects. 61 Code Review CR 1 CR 2 CR 3 Objective Opportunistically find basic code-level vulnerabilities and other high-risk security issues Make code review during development more accurate and efficient through automation Mandate comprehensive code review process to discov...
View Full Document

{[ snackBarMessage ]}

Ask a homework question - tutors are online