Intelligence: Security Features and Design (SFD)
The overall goal for the Security Features and Design practice is the creation of customized knowledge on security features, frameworks, and patterns. The customized knowledge must drive architecture and component decisions.
INTELLIGENCE: SECURITY FEATURES AND DESIGN
Security patterns for major security controls, middleware frameworks for controls, proactive security guidance.
|SFD1.1||create proactive security guidance around security features||build and publish security features)||1|
|SFD1.2||inject security thinking into architecture group||engage SSG with architecture|
|SFD2.1||create proactive security design based on technology stacks||build secure-by-design middleware frameworks and common libraries (T: code review)||2|
|SFD2.2||address the need for new architecture||create SSG capability to solve difficult design problems|
|SFD3.1||formalize consensus on design||form review board or central committee to approve and maintain secure design patterns||3|
|SFD3.2||promote design efficiency||require use of approved security features and frameworks (T: AA)|
|SFD3.3||practice reuse||find and publish mature design patterns from the organization|
SFD Level 1: Publish security features and architecture. The SSG must provide architects and developers with guidance on security features and participate directly with architecture groups.
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 (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. 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.
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.
SFD Level 2: Build and identify security solutions. The SSG must provide secure-by-design frameworks and must be available for and capable of solving design problems for others.
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 out of the box.
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 an 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. 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.
SFD Level 3: Actively reuse approved security features and secure-by-design frameworks. The SSG must provide additional mature design patterns taken from existing software and technology stacks. Managers must ensure there is formal consensus across the organization on secure design choices. Managers must also require that defined security features and frameworks be used whenever possible.
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 can also periodically review already-published design standards (especially around cryptography) to ensure that design decisions do not become stale or out of date.
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. 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.
Find and publish mature design patterns from the organization. The SSG fosters centralized design reuse by finding and publishing mature design patterns from and throughout the organization. A section of the SSG web site 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.