Standards & Requirements

The Standards & Requirements practice involves eliciting explicit security requirements from the organization, determining which COTS to recommend, building standards for major security controls (such as authentication, input validation, and so on), creating security standards for technologies in use, and creating a standards review board.

Standards & Requirements Level 1

[SR1.1: 75] 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 on an Android device 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). Often, software that is not an application requires its own 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), but in others, guidance can be explicitly linked to code examples or even containers to make them more actionable and relevant. Standards that are not widely adopted and enforced are not really standards.

[SR1.2: 78] Create a security portal.

The organization has a well-known central location for information about software security. Typically, this is an internal website maintained by the SSG that people refer to for the latest and greatest on security standards and requirements, as well as for other resources provided by the SSG (e.g., training). An interactive wiki is better than a static portal with guideline documents that rarely change. Organizations can supplement these materials with mailing lists and face-to-face meetings.

[SR1.3: 76] 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, the organization demonstrates that compliance is 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 can include security guidance. Representing these standards as requirements helps with traceability and visibility in the event of an audit. It’s particularly useful to codify the requirements in  reusable code or containers.  

Standards & Requirements Level 2

[SR2.2: 38] 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, putting the onus 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.

[SR2.3: 23] Create standards for technology stacks.

The organization standardizes on specific 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 areas where specific attention to security particularly pays off.  

[SR2.4: 39] Identify open source.

The first step toward managing the risk introduced by open source is to identify the open source components in use across the portfolio and really understand the dependencies. It’s not uncommon to discover old versions of components with known vulnerabilities or multiple versions of the same component. Automated tools for finding open source, whether whole components or large chunks of borrowed code, are one way to approach this activity. An informal annual review or 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.

[SR2.5: 29] Create SLA boilerplate.

The SSG works with the legal department to create a standard SLA boilerplate that is used in contracts with vendors and outsource providers (including cloud providers) to require software security efforts. The legal department understands that the boilerplate also helps prevent compliance and privacy problems. Under the agreement, vendors and outsource providers must meet company-mandated software security standards (see [CP2.4 Include software security SLAs in all vendor contracts]). Boilerplate language might call for software security vendor management solutions, such as vBSIMM measurements or BSIMM scores.

Standards & Requirements Level 3

[SR3.1: 17] Control open source risk.

The organization has control over its exposure to the vulnerabilities that come along with using open source components and their army of dependencies. Use of open source could be restricted to predefined projects or to open source versions that have been through an SSG security screening process, had unacceptable vulnerabilities remediated, and are made available only through internal repositories. The legal department often spearheads additional open source controls due to the “viral” license problem associated with GPL code. In general, getting the legal department to understand security risks can help move an organization to improve its open source practices. Of course, this control must be applied across the software portfolio.

[SR3.2: 10] 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 vendor security practices, and explains in concrete terms (rather than legalese) what the organization expects of its vendors. Any time a vendor adopts the organization’s security standards, it’s a clear win. When a firm’s SSDL is available publicly, communication regarding software security expectations is easier. Likewise, sharing internal practices and measures can make expectations clear. Don’t work with a vendor that has worse security policies than you do.

[SR3.3: 10] Use 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 or platform, and they can address the use of popular frameworks and libraries, but mobile platforms need their own specific coding standards. 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 to beef up security training with relevant examples. Remember, guidance does not a standard make.