This preview shows page 1. Sign up to view the full content.
Unformatted text preview: ity in usage of the third-party component, etc.
This list should be created by senior developers and architects, but also include input from
managers and security auditors. After creation, this list of recommended components
matched against functional categories should be advertised to the development organization.
Ultimately, the goal is to provide well-known defaults for project teams. B. Explicitly apply security principles to design
During design, technical staff on the project team should use a short list of guiding security
principles as a checklist against detailed system designs. Typically, security principles include
defense in depth, securing the weakest link, use of secure defaults, simplicity in design of security functionality, secure failure, balance of security and usability, running with least privilege,
avoidance of security by obscurity, etc.
In particular for perimeter interfaces, the design team should consider each principle in the
context of the overall system and identify features that can be added to bolster security
at each such interface. Generally, these should be limited such that they only take a small
amount of extra effort beyond the normal implementation cost of functional requirements
and anything larger should be noted and scheduled for future releases.
While this process should be conducted by each project team after being trained with security awareness, it is helpful to incorporate more security-savvy staff to aide in making design
✦✦Ad hoc prevention of unexpected
dependencies and one-off
✦✦Stakeholders aware of increased
project risk due to libraries
and frameworks chosen
✦✦Established protocol within
development for proactively applying
security mechanisms to a design Success Metrics
✦✦>80% of development staff
briefed on software framework
recommendations in past 1 year
✦✦>50% of projects selfreporting application of security
principles to design Costs
✦✦Buildout, maintenance, and awareness of
software framework recommendations
✦✦Ongoing project overhead from analysis
and application of security principles Personnel
✦✦Architects (2-4 days/yr)
✦✦Developers (2-4 days/yr)
✦✦Security Auditors (2-4 days/yr)
✦✦Managers (2 days/yr) Related Levels
✦✦Education & Guidance - 1
SAMM / The Security Practices - v1.0 Activities 55 SA 2 Secure Architecture Direct the software design process toward known-secure services and secure-by-default designs Activities
Results A. Identify and promote security services and infrastructure ✦✦Detailed mapping of assets to
user roles to encourage better
compartmentalization in design
✦✦Reusable design building
blocks for provision of security
protections and functionality
✦✦Increased confidence for software
projects from use of established
design techniques for security Organizations should identify shared infrastructure or services with security functionality.
These will typically include single-sign-on services, corporate directory systems, access control or entitlements services, and authentication systems. By collecting an...
View Full Document
- Spring '14