Intelligence: Standards and Requirements (SR)
The overall goal for the Standards and Requirements practice is to create prescriptive guidance for all stakeholders. Managers and the SSG must document software security choices and convey this material to everyone involved in the SSDL, including external parties.
|
INTELLIGENCE: STANDARDS AND REQUIREMENTS Explicit security requirements, recommended COTS, standards for major security controls, standards for technologies in use, standards review board. |
|||
|---|---|---|---|
| Objective | Activity | Level | |
| SR1.1 | meet demand for security features | create security standards (T: sec features/design) | 1 |
| SR1.2 | ensure that everybody knows where to get latest and greatest | create security portal | |
| SR1.3 | compliance strategy | translate compliance constraints to requirements | |
| SR1.4 | tell people what to look for in code review | create secure coding standards | |
| SR2.1 | educate third-party vendors | communicate standards to vendors | 2 |
| SR2.2 | formalize standards process | create a standards review board | |
| SR2.3 | reduce SSG workload | create standards for technology stacks | |
| SR2.4 | manage open source risk | identify open source in apps | |
| SR2.5 | gain buy-in from legal department and standardize approach | gain buy-in from legal department and standardize approach | |
| SR3.1 | manage open source risk | control open source risk | 3 |
SR Level 1: Provide easily accessible security standards and (compliance-driven) requirements. The SSG must provide foundational knowledge, including at the very least: security standards, secure coding standards, and compliance requirements. Managers must ensure that software security information is kept up-to-date and made available to everyone.
SR1.1
Create security standards. Software security requires much more than security features, but security features are part of the job as well. The SSG meets the organization's demand for security features by creating standards that explain the accepted way to adhere to policy and carry out specific security-centric operations. A standard might describe how to perform authentication using J2EE or how to determine the authenticity of a software update. (See [SFD1.1] Build and publish security features for one case where the SSG provides a reference implementation of a security standard.)
SR1.2
Create security portal. The organization has a central location for information about software security. Typically this is an internal Web site maintained by the SSG. People refer to the site for the latest and greatest on security standards and requirements as well as other resources provided by the SSG.
SR1.3
Translate compliance constraints to requirements. Compliance constraints are translated into software requirements for individual projects. This is a linchpin in the organization's compliance strategy—by representing compliance constraints explicitly with requirements, demonstrating compliance becomes a manageable task. For example, if the organization routinely builds software that processes credit card transactions, PCI DSS compliance could play a role in the SSDL during the requirements phase.
SR1.4
Create secure coding standards. Secure coding standards help developers avoid the most obvious bugs and provide ground rules for code review. Secure coding standards are necessarily specific to a programming language and can address the use of popular frameworks and libraries. If the organization already has coding standards for other purposes, the secure coding standards should build upon them.
SR Level 2: Communicate formally-approved standards internally and to vendors. Managers must ensure that a formal process is used to create technology stack standards. Managers, the SSG, and product owners must ensure all applicable standards are communicated to third-party vendors and that these standards and other Service Level Agreements are reinforced by contractual language approved by legal staff. The SSG must ensure that all open source software is identified in the organization's code.
SR2.1
Communicate standards to vendors. The SSG works with vendors to educate them and promote the organization's security standards. A healthy relationship with a vendor cannot be guaranteed through contract language. The SSG engages with vendors, discusses the vendor's security practices, and explains in concrete terms (rather than legalese) what the organization expects of the vendor. Any time a vendor adopts the organization's security standards, it's a clear win.
SR2.2
Create a standards review board. The organization creates a standards review board to formalize the standards process and ensure that all stakeholders have a chance to weigh in. The board could operate by appointing a champion for any proposed standard. The onus is on the champion to demonstrate that the standard meets its goals and to get approval and buy-in from the board.
SR2.3
Create standards for technology stacks. The organization uses standard technology stacks. For the SSG this means a reduced workload because the group does not have to explore new technology risks for every new project. Ideally, the organization will create a secure base configuration for each technology stack, further reducing the amount of work required to use the stack safely. A stack might include an operating system, a database, an application server, and a runtime environment for a managed language.
SR2.4
Identify open source in apps. The first step toward managing risk introduced by open source is to identify the open source components in use. It is not uncommon to discover old versions of components with known vulnerabilities or multiple versions of the same component. At the next level of maturity, this activity is subsumed by a policy constraining the use of open source.
SR2.5
Create SLA boilerplate. The SSG works with the legal department to create standard SLA boilerplate for use in contracts with vendors and outsourcing providers. The legal department understands that the boilerplate helps prevent compliance or privacy problems. Under the agreement, vendors and outsourcing providers must meet company software security standards. (See [CP2.4] Paper all vendor contracts with SLAs compatible with policy.)
SR Level 3: Require risk management decisions for open source use. Managers and the SSG must show that any open source code used in the organization is subject to the same risk management processes as code created internally.
SR3.1
Control open source risk. The organization has control over its exposure to the vulnerabilities that come along with using open source components. Use of open source could be restricted to projects and versions that have been through an SSG screening process. An internal repository of approved open source may come in handy.