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 Threat modeling, abuse cases, data classification, technology-specific attack patterns.
	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	1
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)	3

one

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.

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.

two

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.)

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.

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.

three

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.

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.)