Standards & Requirements

The Standards and 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 and Requirements Level 1

[SR1.1: 60] 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). 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, 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: 66] 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. 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 rarely change. Organizations can supplement these materials with mailing lists and face-to-face meetings.

[SR1.3: 64] 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. Bonus points for codifying the requirements in re-usable code or containers.

Standards and Requirements Level 2

[SR2.2: 28] 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.

[SR2.3: 22] 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 two areas where specific attention to security pays off.

[SR2.4: 21] Identify open source.

The first step toward managing risk introduced by open source is to identify the open source components in use across the portfolio and really understand which dependencies they drag on stage. 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: 20] 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 to require software security efforts. This includes cloud providers. The legal department understands that the boilerplate also helps prevent compliance and 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.

[SR2.6: 17] 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 can address the use of popular frameworks and libraries. 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 beefing up security training with relevant examples. Remember, guidance does not a standard make.

Standards and Requirements Level 3

[SR3.1: 8] 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 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 are 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. Of course, this control must be applied across the software portfolio.

[SR3.2: 11] 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 can make expectations very clear.

Members

Contact Us

Email Us

bsimm@cigital.com

The BSIMM is designed to help you understand, measure, and plan a software security initiative. The BSIMM was created by observing and analyzing real-world data from leading software security initiatives.