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. |
|||
|---|---|---|---|
| Objective | Activity | Level | |
| SFD1.1 | create proactive security guidance around security features | build/publish security features (authentication, role management, key management, audit/log, crypto, protocols) | 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/common libraries (T: code review) | 2 |
| SFD2.2 | address the need for new architecture | create SSG capability to solve difficult design problems | |
| SFD2.3 | practice reuse | find/publish mature design patterns from the organization | |
| SFD3.1 | formalize consensus on design | form review board or central committee to approve and maintain secure design | 3 |
| SFD3.2 | promote design efficiency | require use of approved security features and frameworks (T: AA) | |
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.
SFD1.1
Build/publish security features (authentication, role management, key management, audit/log, crypto, protocols). Some problems are best solved only once. Rather than have each project team implement all of their own security features, 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 creep into features such as authentication, role management, audit/logging, key management, and cryptography. The SSG can identify an implementation they like and promote it as the accepted solution.
SFD1.2
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 along with additional mature design patterns taken from existing software and technology stacks. The SSG must be available for and capable of solving design problems for others.
SFD2.1
Build secure-by-design middleware frameworks/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 Struts 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.) Carefully vetting middleware frameworks 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.
SFD2.2
Create SSG capability to solve difficult design problems. When the SSG is involved early in the new product 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 re-factoring when flaws are uncovered. Some design problems will require specific expertise outside of the SSG.
SFD2.3
Find/publish mature design patterns from the organization. The SSG fosters design reuse by finding and publishing mature design patterns from the organization. A section of the SSG Web site could promote positive elements identified during architecture analysis. This process should be formalized. An ad hoc, accidental noticing is not sufficient.
SFD Level 3: Actively reuse approved security features and secure-by-design frameworks. 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.
SFD3.1
Form review board or central committee to approve and maintain secure design. A review board or central committee approves and maintains secure design. The group 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 review already-published design standards (especially around cryptography) to ensure that design decisions do not become stale or out of date.
SFD3.2
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 becomes. (See [AA1.1] Perform security feature review.) Re-use is a major advantage of consistent software architecture.