Security Features & Design
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 Level 1
[SFD1.1: 102] Integrate and deliver security features.
Rather than having each project team implement its own security features (e.g., authentication, role management, key management, logging, cryptography, protocols), the SSG provides proactive guidance by acting as or facilitating a clearinghouse of security features for engineering groups to use. These features might be discovered during SSDL activities, created by the SSG or specialized development teams, or defined in configuration templates (e.g., cloud blueprints) and delivered via mechanisms such as containers, microservices, and APIs. Generic security features often have to be tailored for specific platforms. For example, each mobile and cloud platform will likely need their own means by which users are authenticated and authorized, secrets are managed, and user actions are centrally logged and monitored. 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. It’s the implementation of these defined security features that generate real progress, not simply making the list.
[SFD1.2: 83] 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, scalability, and resiliency. One way to keep security from falling out of these discussions is to have an SSG member participate in architecture discussions. Increasingly, architecture discussions include developers and site reliability engineers governing all types of software components, such as open source, APIs, containers, and cloud services. 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: 33] Leverage secure-by-design components and services.
The SSG takes a proactive role in software design by building or providing pointers to secure-by-design software components and services. In addition to teaching by example, these resilient building blocks aid important efforts such as architecture analysis and code review by making it easier to spot errors and avoid mistakes. These components and services, whether created internally or available from service providers, often have features (e.g., application identity, RBAC) that enable uniform security orchestration across, for example, multi-environment deployments. Similarly, the SSG might further leverage this information by tailoring code review rules specifically for the components it offers (see [CR2.6 Use automated tools with tailored rules]). When integrating software components, including open source and cloud services, the SSG must carefully vet the software for security before publication.
[SFD2.2: 55] Create capability to solve difficult design problems.
The SSG contributes to building resilient architectures by solving design problems unaddressed by organizational security components or services, or by cloud service providers, thus minimizing the negative impact that security has on other constraints (e.g., feature velocity). Involving the SSG in the design of a new protocol, microservice, or architecture decision (e.g., containerization) enables timely analysis of the security implications of existing defenses and identifies elements that should be refactored, 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. The SSG could also get involved in what could have historically been purely engineering discussions, as even rudimentary (e.g., “Hello, world!”) use of cloud-native technologies requires configurations and other capabilities that have direct implications on security posture. 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: 16] 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 a typical architecture committee focused on functions, 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. A review board can help control the chaos associated with adoption of new technologies when development groups might otherwise make decisions on their own without engaging the SSG. Review board security guidance also serves to inform outsourced software providers about security expectations (see [CP3.2 Impose policy on vendors]).
[SFD3.2: 15] 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. Packaging and applying required components facilitates delivering services as software features (e.g., identity-aware proxies). Containerization makes it especially easy to package and reuse approved features and frameworks (see [SE2.5 Use application containers]).
[SFD3.3: 5] Find and publish secure design patterns from the organization.
The SSG fosters centralized design reuse by collecting secure 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 threat modeling or 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 assets (microservices, APIs, containers, infrastructure, and automation).
Members
