Significant Change rubric

We follow this rubric for changes before they are deployed to production. This is part of the Security Impact Analysis routinely performed when considering any new functionality. This rubric supports controls including CA-6 (c), CM-2 (1), and RA-3.

When no discussion or SCR (Significant Change Request) is needed for a change

No timeline required.

The change:

• Fits our existing SSP control descriptions, diagrams, and attachments, as well as our policies and procedures (including our configuration management plan. No updates to the SSP would be necessary to reflect the change.

This includes:

• Integrating routine updates to existing upstream open source system components, including updates that resolve CVEs, fix bugs, add new features, and/or update the operating system.
• Routine updates to existing open source components that we maintain, such as fixing bugs and improving security and reliability.
• Improvements to the configuration of services and system components.
• Improving our implementations in excess of the minimum requirements described in our SSP control descriptions.
• Using a new feature of an approved external service that we already use (where the feature doesn’t change our SSP or risk posture).

Examples:

• Base OS update that fixes CVEs
• cloud.gov buildpack updates that don’t change security model
• User documentation updates
• Configuring alerts to be more specific or precise
• Adding alerts
• Adding automated tests to any component
• Adjusting configuration or number of "virtual machine" components, such as disk size (not major changes to configuration that may have security impact, such as a whole different operating system)
• An upstream open source component integrates a new dependency

When a change should be discussed with our ISSO and/or ISSM

Start the discussion when we identify that we want to make this kind of change. Must be discussed at least one week ahead of planned change.

The change fits one or more of the following criteria:

• Requires minor clarifications to SSP control descriptions, diagrams, or attachments - not changing the substance of implementation of a requirement.
• Relaxes requirements in our policies and procedures.
• Adds or removes a point of contact for our system (a named person in our SSP, such as a new System Owner).

This includes:

• Changes to some aspect of our external system boundary, such as ports, that don’t change the risk posture.
• Removing use of an external service.
• Minor updates (that don’t have security impact) to roles and authorized privileges listed in the Types of Users table.
• Removing internal dependencies. (In other words, simplifying a diagram.)

Examples:

• Changing a substantial aspect of our logging that isn’t required by our SSP.
• Using an additional aspect of an existing protocol that we already use.
• Making use of a high-availability plan for a service that cloud.gov operates.

When a change requires an approved SCR but not pen-testing

SCR should be submitted at least 30 days ahead of planned change.

The change:

• Would require changing the SSP in a non-trivial way (such as updating the control descriptions, diagrams, tables, or attachments to reflect the new or changed functionality), but it primarily uses existing pen-tested features in AWS or cloud.gov to implement the change.

This includes:

• Integrating a new external service that has a FedRAMP Moderate or higher authorization, using an existing integration system.
• Adding a new component to the system inside the authorization boundary that doesn’t substantially change the risk posture.
• Integrating a new open source codebase that we’ve reviewed according to our procedures.

Example:

• Integrating a new service that is FedRAMP-Authorized in AWS GovCloud.

When a change requires both an approved SCR and pen-testing

SCR should be submitted at least 30 days ahead of planned change.

The change fits one or more of the following criteria:

• Changes the system boundary by adding a new component that substantially changes the risk posture.
• Changes our risk posture in a major way not reflected in our SSP.

This includes:

• Integrating a new external service that does not have a FedRAMP Moderate or higher authorization.
• Integrating a new external service using a new integration system.
• Exposing new services on new domains or IP ranges.
• Modifications to cryptographic modules or services.

Examples:

• Adding an integration with a service that is not already pre-approved by GSA.
• Deploying and using a custom broker for a back-end service that is not provided through cloud.gov