0 results 58 design review dr 1 support ad hoc reviews

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: framework, pattern, and platform usage feedback in past 6 months ✦✦>3.0 Likert on usefulness of guidance/ platforms reported by project teams Add’l Costs ✦✦Buildout or license of reference platform(s) ✦✦Ongoing maintenance and support of reference platforms ✦✦Ongoing project overhead from usage validation during audit Add’l Personnel ✦✦Managers (1 day/yr) ✦✦Business Owners (1 day/yr) ✦✦Architects (3-4 days/yr) ✦✦Developers (2-3 days/yr) ✦✦Security Auditors (2 days/yr) Related Levels ✦✦Policy & Compliance - 2 ✦✦Design Review - 3 ✦✦Code Review - 3 ✦✦Security Testing - 3 SAMM / The Security Practices - v1.0 Activities 57 Design Review DR 1 DR 2 DR 3 Objective Support ad hoc reviews of software design to ensure baseline mitigations for known risks Offer assessment services to review software design against comprehensive best practices for security Require assessments and validate artifacts to develop detailed understanding of protection mechanisms Activities A. Identify software attack surface B. Analyze design against known security requirements A. Inspect for complete provision of security mechanisms B. Deploy design review service for project teams A. Develop data-flow diagrams for sensitive resources B. Establish release gates for design review ✦✦Do project teams document the attack perimeter of software designs? ✦✦Do project teams check software designs against known security risks? ✦✦Do most project teams specifically analyze design elements for security mechanisms? ✦✦Are most project stakeholders aware of how to obtain a formal design review? ✦✦Does the design review process incorporate detailed data-level analysis? ✦✦Does routine project audit require a baseline for design review results? ✦✦High-level understanding of security implications from perimeter architecture ✦✦Enable development teams to self-check designs for security best-practices ✦✦Lightweight process for conducting projectlevel design reviews ✦✦Formally offered assessment service to consistently review architecture for security ✦✦Pinpoint security flaws in maintenance-mode and legacy systems ✦✦Deeper understanding amongst project stakeholders on how the software provides assurance protections ✦✦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 Assessment SAMM / The Security Practices - v1.0 Results 58 Design Review DR 1 Support ad hoc reviews of software design to ensure baseline mitigations for known risks A. Identify software attack surface For each software project, create a simplified view of the overall architecture. Typically, this should be created based on project artifacts such as high-level requirements and design documents, interviews with technical staff, or module-level review of the code base. It is important to capture the high-level modules in the system, but a good rule of thumb for granularity is to ensure that the diagram of the whole system under review fits onto one page. From the single page architecture view, analyze each component in terms of accessibility of the interfaces from authorized users, anonymous users, operators, application-specific roles, etc. The components providin...
View Full Document

{[ snackBarMessage ]}

Ask a homework question - tutors are online