The Security Features & Design practice is charged with creating usable security patterns for major security controls (meeting the standards defined in the Standards and Requirements practice), building middleware frameworks for those controls, and creating and publishing other proactive security guidance.
Security Features & Design
Security Features & Design Level 1
[SFD1.1: 98] Build and publish security features.
Rather than having each project team implement its own security features (e.g., authentication, role management, key management, audit/log, cryptography, protocols), the SSG provides proactive guidance by acting as a clearinghouse of security features for development groups to use. These features might be discovered during code review, created by the SSG or a specialized development team, or be part of a library provided by a vendor, such as a cloud service provider. Generic security features often have to be tailored for specific platforms. A mobile crypto feature will likely need at least two versions to cover Android and iOS, while managing identity in the cloud might require versions specific to AWS, Google, and Azure. Project teams benefit from implementations that come preapproved by the SSG, and the SSG benefits by not having to repeatedly track down the kinds of subtle errors that often creep into security features.
[SFD1.2: 69] Engage the SSG with architecture teams.
Security is a regular topic in the organization’s software architecture discussions, with the architecture team taking responsibility for security in the same way that it takes responsibility for performance, availability, and scalability. One way to keep security from falling out of these discussions is to have an SSG member participate in architecture discussions. In other cases, enterprise architecture teams can help the SSG create secure designs that integrate properly into corporate design standards. Proactive engagement by the SSG is key to success here. Moving a well-known system to the cloud means reengaging the SSG, for example. It’s never safe for one team to assume another team has addressed security requirements.
Security Features & Design Level 2
[SFD2.1: 31] Leverage secure-by-design middleware frameworks and common libraries.
The SSG takes a proactive role in software design by building or providing pointers to secure-by-design middleware frameworks or common libraries. In addition to teaching by example, this middleware aids architecture analysis and code review because the building blocks make it easier to spot errors. For example, the SSG can modify a popular web framework, such as Spring, to make it easy to meet input validation requirements. Eventually, the SSG can tailor code review rules specifically for the components it offers (see [CR3.1 Use automated tools with tailored rules]). When adopting a middleware framework (or any other widely used software), the SSG must carefully vet the software for security before publication. Encouraging adoption and use of insecure middleware doesn’t help the overall software security goal. Generic open source software security frameworks and libraries (e.g., Spring Security, NaCl), should not be considered secure by design. Attempting to bolt security on at the end by calling a library is always an unsuccessful approach to secure design.
[SFD2.2: 40] Create an SSG capability to solve difficult design problems.
The SSG contributes to new architecture and solves difficult design problems, minimizing the negative impact that security has on other constraints (time to market, price, etc.). If a skilled security architect from the SSG is involved in the design of a new protocol, he or she can analyze the security implications of existing protocols and identify elements that should be duplicated or avoided. Likewise, having a security architect understand the security implications of moving a seemingly well-understood application to the cloud saves a lot of headaches later. Designing for security up front is more efficient than analyzing an existing design for security and refactoring when flaws are uncovered, so the SSG should be involved early in the new project process. Note that some design problems will require specific expertise outside of the SSG: even the best expert can’t scale to cover the needs of an entire software portfolio.
Security Features & Design Level 3
[SFD3.1: 11] Form a review board or central committee to approve and maintain secure design patterns.
A review board or central committee formalizes the process of reaching consensus on design needs and security tradeoffs. Unlike the architecture committee, this group focuses on providing security guidance and also periodically reviews already published design standards (especially around authentication, authorization, and cryptography) to ensure that design decisions don’t become stale or out of date. Moreover, a review board can help control the chaos often associated with the adoption of new technologies when development groups might otherwise make decisions on their own without ever engaging the SSG.
[SFD3.2: 12] Require use of approved security features and frameworks.
Implementers take their security features and frameworks from an approved list or repository. There are two benefits to this activity: developers don’t spend time reinventing existing capabilities, and review teams don’t have to contend with finding the same old defects in new projects or when new platforms are adopted. Essentially, the more a project uses proven components, the easier testing, code review, and architecture analysis become (see [AA1.1 Perform security feature review]). Reuse is a major advantage of consistent software architecture and is particularly helpful for agile development and velocity maintenance in CI/CD pipelines. Container-based approaches make it especially easy to package and reuse approved features and frameworks (see [SE3.4 Use application containers]).
[SFD3.3: 4] Find and publish mature design patterns from the organization.
The SSG fosters centralized design reuse by collecting design patterns (sometimes referred to as security blueprints) from across the organization and publishing them for everyone to use. A section of the SSG website could promote positive elements identified during architecture analysis so that good ideas are spread. This process is formalized: an ad hoc, accidental noticing isn’t sufficient. In some cases, a central architecture or technology team can facilitate and enhance this activity. Common design patterns accelerate development, so it’s important to use secure design patterns not just for applications but for all software (microservices, APIs, frameworks, infrastructure, and automation).
Members
