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: 95] Build and publish security features.
Some problems are best solved only once. Rather than have each project team implement all of their own security features (e.g., authentication, role management, key management, audit/log, cryptography, and protocols), the SSG provides proactive guidance by building and publishing security features for other groups to use. Generic security features often have to be tailored for specific platforms, such as mobile. For example, a mobile crypto feature will need at least two versions to cover Android and iOS if it uses low level system calls. 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. The SSG can identify an implementation that it likes and promote it as the accepted solution.
[SFD1.2: 70] Engage SSG with architecture.
Security is a regular topic in the organization’s software architecture discussion, and the architecture group takes responsibility for security the same way in which it takes responsibility for performance, availability, or scalability. One way to keep security from falling out of this discussion is to have an SSG member attend regular architecture meetings. In other cases, enterprise architecture can help the SSG create secure designs that integrate properly into corporate design standards. Proactive engagement by the SSG is key to success. Moving a well-known system to the cloud means reengaging the SSG, for example. Assume nothing.
Security Features & Design Level 2
[SFD2.1: 34] Build 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 could 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), careful vetting for security before publication is important. Encouraging adoption and use of insecure middleware does not help the software security situation. Generic open source software security architectures, including OWASP ESAPI, should not be considered secure by design. Bolting security on at the end by calling a library is not the way to approach secure design.
[SFD2.2: 46] Create SSG capability to solve difficult design problems.
When the SSG is involved early in a new project process, it 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 could 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 then refactoring when flaws are uncovered. Of course, even the best expert might not scale to cover the needs of an entire software portfolio. Some design problems will require specific expertise outside of the SSG.
Security Features & Design Level 3
[SFD3.1: 9] Form a review board or central committee to approve and maintain secure design patterns.
A review board or central committee formalizes the process for reaching consensus on design needs and security tradeoffs. Unlike the architecture committee, this group is specifically focused on providing security guidance and also periodically reviews already published design standards (especially around cryptography) to ensure that design decisions do not 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 head out into the wild on their own without ever engaging the SSG.
[SFD3.2: 9] Require use of approved security features and frameworks.
Implementers take their security features and frameworks from an approved list. There are two benefits to this activity: developers do not spend time reinventing existing capabilities, and review teams do not have to contend with finding the same old defects in brand new projects or when new platforms are adopted. In particular, the more a project uses proven components, the easier the architecture analysis and code review 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.
[SFD3.3: 2] Find and publish mature design patterns from the organization.
The SSG fosters centralized design reuse by collecting design patterns 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 should be formalized: an ad hoc, accidental noticing is not sufficient. In some cases, a central architecture or technology team can facilitate and enhance this activity. Common design patterns make building software faster, such as using secure design patterns for software, not just applications (microservices, APIs, frameworks, infrastructure, and automation).
Members
