BRACKETOLOGY | FEDRAMP

SA-15: DEVELOPMENT PROCESS, STANDARDS, AND TOOLS

  • FedRAMP Baseline Membership SA-15:
  • HIGH
FedRAMP Bracketology

Use the FedRAMP Control Membership information above to determine if a control or control enhancement is required for each Impact Baseline — LOW, MODERATE, or HIGH

Click on the panel below each control or control enhancement to review the FedRAMP Impact Baseline-specific control configuration requirements for each of the [BRACKETS] in each control and/or control enhancement.

Review and use Additional Requirements and Guidance to build FedRAMP-compliant controls for your risk-based cybersecurity program.

To change the baseline view in the panel, click on LOW, MODERATE, or HIGH when the panel is open

Panels only appear where there are [BRACKETS] in the control or enhancement or where there is FedRAMP-specific requirements or guidance available.

The organization:

    • a. Requires the developer of the information system, system component, or information system service to follow a documented development process that:
      1. Explicitly addresses security requirements;
      2. Identifies the standards and tools used in the development process;
      3. Documents the specific tool options and tool configurations used in the development process; and
      4. Documents, manages, and ensures the integrity of changes to the process and/or tools used in development; and
    • b. Reviews the development process, standards, tools, and tool options/configurations [Assignment: organization-defined frequency] to determine if the process, standards, tools, and tool options/configurations selected and employed can satisfy [Assignment: organization-defined security requirements].
Click Low | Moderate | High below to see FedRAMP control configuration information. It's in BOLD.

There are no FedRAMP-specific requirements if this control is used for a LOW Impact system.

There are no FedRAMP-specific requirements if this control is used for a MODERATE Impact system.

The organization requires the developer of the information system, system component, or information system service to:

  • (a) Define quality metrics at the beginning of the development process; and
  • (b) Provide evidence of meeting the quality metrics as needed and as dictated by the current threat posture; organization and service provider-defined security requirements ; upon delivery.

SUPPLEMENTAL GUIDANCE

Development tools include, for example, programming languages and computer-aided design (CAD) systems. Reviews of development processes can include, for example, the use of maturity models to determine the potential effectiveness of such processes. Maintaining the integrity of changes to tools and processes enables accurate supply chain risk assessment and mitigation, and requires robust configuration control throughout the life cycle (including design, development, transport, delivery, integration, and maintenance) to track authorized changes and prevent unauthorized changes.

CONTROL ENHANCEMENTS

SA-15 (1) DEVELOPMENT PROCESS, STANDARDS, AND TOOLS | QUALITY METRICS

The organization requires the developer of the information system, system component, or information system service to:

    • (a) Define quality metrics at the beginning of the development process; and
    • (b) Provide evidence of meeting the quality metrics [Selection (one or more): [Assignment: organization-defined frequency]; [Assignment: organization-defined program review milestones]; upon delivery].

Supplemental Guidance:

Organizations use quality metrics to establish minimum acceptable levels of information system quality. Metrics may include quality gates which are collections of completion criteria or sufficiency standards representing the satisfactory execution of particular phases of the system development project. A quality gate, for example, may require the elimination of all compiler warnings or an explicit determination that the warnings have no impact on the effectiveness of required security capabilities. During the execution phases of development projects, quality gates provide clear, unambiguous indications of progress. Other metrics apply to the entire development project. These metrics can include defining the severity thresholds of vulnerabilities, for example, requiring no known vulnerabilities in the delivered information system with a Common Vulnerability Scoring System (CVSS) severity of Medium or High.

SA-15 (2) DEVELOPMENT PROCESS, STANDARDS, AND TOOLS | SECURITY TRACKING TOOLS

The organization requires the developer of the information system, system component, or information system service to select and employ a security tracking tool for use during the development process.

Supplemental Guidance:

Information system development teams select and deploy security tracking tools, including, for example, vulnerability/work item tracking systems that facilitate assignment, sorting, filtering, and tracking of completed work items or tasks associated with system development processes.

SA-15 (3) DEVELOPMENT PROCESS, STANDARDS, AND TOOLS | CRITICALITY ANALYSIS

The organization requires the developer of the information system, system component, or information system service to perform a criticality analysis at [Assignment: organization-defined breadth/depth] and at [Assignment: organization-defined decision points in the system development life cycle].

Supplemental Guidance:

This control enhancement provides developer input to the criticality analysis performed by organizations in SA-14. Developer input is essential to such analysis because organizations may not have access to detailed design documentation for information system components that are developed as commercial off-the-shelf (COTS) information technology products (e.g., functional specifications, high-level designs, low-level designs, and source code/hardware schematics).

RELATED CONTROLS: SA-15 (3)

SA-15 (4) DEVELOPMENT PROCESS, STANDARDS, AND TOOLS | THREAT MODELING/VULNERABILITY ANALYSIS

The organization requires that developers perform threat modeling and a vulnerability analysis for the information system at [Assignment: organization-defined breadth/depth] that:

    • (a) Uses [Assignment: organization-defined information concerning impact, environment of operations, known or assumed threats, and acceptable risk levels];
    • (b) Employs [Assignment: organization-defined tools and methods]; and
    • (c) Produces evidence that meets [Assignment: organization-defined acceptance criteria].

Supplemental Guidance: NONE

SA-15 (5) DEVELOPMENT PROCESS, STANDARDS, AND TOOLS | ATTACK SURFACE REDUCTION

The organization requires the developer of the information system, system component, or information system service to reduce attack surfaces to [Assignment: organization-defined thresholds].

Supplemental Guidance:

Attack surface reduction is closely aligned with developer threat and vulnerability analyses and information system architecture and design. Attack surface reduction is a means of reducing risk to organizations by giving attackers less opportunity to exploit weaknesses or deficiencies (i.e., potential vulnerabilities) within information systems, information system components, and information system services. Attack surface reduction includes, for example, applying the principle of least privilege, employing layered defenses, applying the principle of least functionality (i.e., restricting ports, protocols, functions, and services), deprecating unsafe functions, and eliminating application programming interfaces (APIs) that are vulnerable to cyber attacks.

RELATED CONTROLS: SA-15 (5)

SA-15 (6) DEVELOPMENT PROCESS, STANDARDS, AND TOOLS | CONTINUOUS IMPROVEMENT

The organization requires the developer of the information system, system component, or information system service to implement an explicit process to continuously improve the development process.

Supplemental Guidance:

Developers of information systems, information system components, and information system services consider the effectiveness/efficiency of current development processes for meeting quality objectives and addressing security capabilities in current threat environments.

SA-15 (7) DEVELOPMENT PROCESS, STANDARDS, AND TOOLS | AUTOMATED VULNERABILITY ANALYSIS

The organization requires the developer of the information system, system component, or information system service to:

    • (a) Perform an automated vulnerability analysis using [Assignment: organization-defined tools];
    • (b) Determine the exploitation potential for discovered vulnerabilities;
    • (c) Determine potential risk mitigations for delivered vulnerabilities; and
    • (d) Deliver the outputs of the tools and results of the analysis to [Assignment: organization-defined personnel or roles].

Supplemental Guidance: NONE

RELATED CONTROLS: SA-15 (7)

SA-15 (8) DEVELOPMENT PROCESS, STANDARDS, AND TOOLS | REUSE OF THREAT/VULNERABILITY INFORMATION

The organization requires the developer of the information system, system component, or information system service to use threat modeling and vulnerability analyses from similar systems, components, or services to inform the current development process.

Supplemental Guidance:

Analysis of vulnerabilities found in similar software applications can inform potential design or implementation issues for information systems under development. Similar information systems or system components may exist within developer organizations. Authoritative vulnerability information is available from a variety of public and private sector sources including, for example, the National Vulnerability Database.

SA-15 (9) DEVELOPMENT PROCESS, STANDARDS, AND TOOLS | USE OF LIVE DATA

The organization approves, documents, and controls the use of live data in development and test environments for the information system, system component, or information system service.

Supplemental Guidance:

The use of live data in preproduction environments can result in significant risk to organizations. Organizations can minimize such risk by using test or dummy data during the development and testing of information systems, information system components, and information system services.

SA-15 (10) DEVELOPMENT PROCESS, STANDARDS, AND TOOLS | INCIDENT RESPONSE PLAN

The organization requires the developer of the information system, system component, or information system service to provide an incident response plan.

Supplemental Guidance:

The incident response plan for developers of information systems, system components, and information system services is incorporated into organizational incident response plans to provide the type of incident response information not readily available to organizations. Such information may be extremely helpful, for example, when organizations respond to vulnerabilities in commercial off-the-shelf (COTS) information technology products.

RELATED CONTROLS: SA-15 (10)

SA-15 (11) DEVELOPMENT PROCESS, STANDARDS, AND TOOLS | ARCHIVE INFORMATION SYSTEM/COMPONENT

The organization requires the developer of the information system or system component to archive the system or component to be released or delivered together with the corresponding evidence supporting the final security review.

Supplemental Guidance:

Archiving relevant documentation from the development process can provide a readily available baseline of information that can be helpful during information system/component upgrades or modifications.

REFERENCES:

  • NO REFERENCES

© 2017-2019 Wayfinder Digital, LLC. All Rights Reserved | Sitemap | The Fine Print — Terms of Use & Privacy