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: 85] 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, 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 pre-approved 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 they like and promote it as the accepted solution.
[SFD1.2: 70] Engage SSG with architecture.
Security is a regular part of the organization’s software architecture discussion. The architecture group takes responsibility for security the same way they take responsibility for performance, availability, or scalability. One way to keep security from falling out of the 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 re-engaging the SSG. Assume nothing.
Security Features & Design Level 2
[SFD2.1: 29] 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.
[SFD 2.2: 41] Create SSG capability to solve difficult design problems.
When the SSG is involved early in the new project process, it contributes to new architecture and solves difficult design problems. The negative impact security has on other constraints (time to market, price, etc.) is minimized. 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 lots 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. Some design problems will require specific expertise outside of the SSG.
Security Features & Design Level 3
[SFD3.1: 5] 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. The group also periodically reviews already-published design standards (especially around cryptography) to ensure that design decisions do not become stale or out of date. A review board can also reign in the chaos often associated with the adoption of new technologies where development groups might otherwise head out into the jungle on their own without ever engaging the SSG.
[SFD3.2: 11] Require use of approved security features and frameworks.
Implementers must take their security features and frameworks from an approved list. There are two benefits: developers do not spend time re-inventing 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 architecture analysis and code review become (see [AA1.1 Perform security feature review]). Re-use is a major advantage of consistent software architecture and is particularly helpful for agile development.
[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 facilitates and enhances this activity. Common design patterns make building software faster. Use secure design patterns for all of your software, not just applications; this includes microservices, APIs, frameworks, infrastructure, and automation.
Members
