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: 83] Create security standards.

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, with the SSG providing a reference implementation. Often, software that isn’t an application requires its own standard (e.g., an API or a microservices architecture). Standards can be deployed in a variety of ways to keep them actionable and relevant. They can be automated into development environments (e.g., worked into an IDE or toolchain), or they can be explicitly linked to code examples or even to containers. In any case, to be considered standards, they must be adopted and enforced.

[SR1.2: 81] 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. Development teams are increasingly putting software security knowledge directly into toolchains and automation that is be outside the organization (e.g., GitHub), but that does not remove the need for SSG-led knowledge management.

[SR1.3: 85] 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 plays a role in the SSDL during the requirements phase. In other cases, technology standards built for international interoperability can include security guidance on compliance needs. Representing these standards as requirements also helps with traceability and visibility in the event of an audit. It’s particularly useful to codify the requirements into reusable code or container specifications.

Standards & Requirements Level 2

[SR2.2: 52] Create a standards review board.

The organization creates a review board to formalize the process used to develop standards and to ensure that all stakeholders have a chance to weigh in. This standards 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. When the standards are implemented directly as software, the responsible champion might be a DevOps manager, release engineer, or whomever owns the associated container or service registry.

[SR2.4: 46] Identify open source.

Open source components included in the software portfolio are identified and reviewed to really understand their 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.

[SR2.5: 35] Create SLA boilerplate.

The SSG works with the legal department to create standard SLA boilerplate for use 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 objective third-party insight into software security efforts, such as BSIMMsc measurements or BSIMM scores.

Standards & Requirements Level 3

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

The organization has control over its exposure to the vulnerabilities that come along with using open source components and all the involved dependencies. The use of open source could be restricted to predefined projects or to a short-list of open source versions that have been through an SSG security screening process, have had unacceptable vulnerabilities remediated, and are made available only through specific internal repositories and containers. In some cases, policy might preclude any use of open source. 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 risk management practices, which must be applied across the software portfolio to be effective.

[SR3.2: 11] Communicate standards to vendors.

The SSG works with vendors to educate them and promote the organization’s security standards. However, a healthy relationship with a vendor isn’t guaranteed through contract language alone, so the SSG should engage with vendors, discuss vendor security practices, and explain 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 sign of progress. When the firm’s SSDL is publicly available, communication regarding software security expectations is easier. Likewise, sharing internal practices and measures can make expectations clear.

[SR3.3: 9] Use secure coding standards.

Secure coding standards help the organization’s developers avoid the most obvious bugs and provide ground rules for code review. These standards are necessarily specific to a programming language or platform, and they can address the use of popular frameworks and libraries. Platforms might include mobile or IoT runtimes, cloud service provider APIs, and SaaS platforms (e.g., Salesforce, SAP). If the organization already has coding standards for other purposes, its 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 provide relevant examples for security training. Some groups might choose to integrate their secure coding standards directly into automation, but violation of the standards must still be considered a defect to be fixed. Remember, if the secure coding standards are not specific and enforced, they won’t be effective.

[SR3.4: 24] Create standards for technology stacks.

The organization standardizes on specific technology stacks. For the SSG, this means a reduced workload because the group doesn’t 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 (e.g., a LAMP stack). In other cases, the stack might be an application server and development framework bundle (e.g., MEAN) or even layers 1 through 6 in a cloud environment (e.g., functions-as-a-service). The security frontier is a good place to find traction; mobile technology stacks and platforms, IoT devices, and cloud-based technology stacks are areas where specific attention to security particularly pays off. Container-based approaches can make standardization more scalable (see [SE3.4 Use application containers]).