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.
|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|
|SR2.5||gain buy-in from legal department and standardize approach||create SLA boilerplate (T: compliance and policy)|
|SR3.1||manage open source risk||control open source risk||3|
SR Level 1: Provide easily accessible security standards and 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.
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 guidance 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.) Standards can be deployed in a variety of ways. In some cases, standards and guidelines can be automated in development environments (e.g., worked into an IDE). In other cases, guidelines can be explicitly linked to code examples to make them more actionable and relevant.
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. An interactive wiki is better than a static portal with guideline documents that only rarely change. Organizations can enhance these materials with mailing lists and face-to-face meetings.
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. In other cases, technology standards built for international interoperability reasons can include security guidance. Representing these standards as requirements helps with traceability and visibility in the case of audit.
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. A clear set of secure coding standards is a good way to guide both manual and automated code review, as well as beefing up security training with relevant examples.
SR Level 2: Communicate formally-approved standards internally and to vendors. Managers must ensure that a formal process is used to create standards specific to technology stacks. Managers, the SSG, and product owners must ensure all applicable standards are communicated to third-party vendors and that these standards and other SLAs 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.
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 alone. 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. When a firm’s SSDL is available publically, communication regarding software security expectations is easier. Likewise, sharing internal practices and measures (including a BSIMM measurement) can make expectations very clear.
Create a standards review board. The organization creates a standards review board to formalize the process used to develop standards and ensure that all stakeholders have a chance to weigh in. The review 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 review board. Enterprise architecture or enterprise risk groups sometimes take on the responsibility of creating and managing standards review boards.
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. The security frontier is a good place to find traction. Currently, mobile technology stacks and platforms as well as cloud-based technology stacks are two areas where specific attention to security pays off.
Identify open source. 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. Automated tools for finding open source are one way to approach this activity. A process that relies solely on developers asking for permission does not generate satisfactory results. At the next level of maturity, this activity is subsumed by a policy constraining the use of open source.
Create SLA boilerplate. The SSG works with the legal department to create standard SLA boilerplate for use in contracts with vendors and outsource providers. The legal department understands that the boilerplate helps prevent compliance or privacy problems. Under the agreement, vendors and outsource providers must meet company software security standards. (See [CP2.4] Paper all vendor contracts with software security SLAs.) Boilerplate language may call out software security vendor control solutions such as vBSIMM measurements or BSIMM scores.
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.
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 pre-defined projects. It could also be restricted to open source versions that have been through an SSG security screening process, had unacceptable vulnerabilities remediated, and made available only through internal repositories. Legal often spearheads additional open source controls due to the “viral” license problem associated with GPL code. Getting legal to understand security risks can help move an organization to practice decent open source hygiene.