Lifecycle of a Launch

Every federal information system must go through NIST’s Risk Management Framework before it can be used to process federal information. This process culminates in a signed Authority to Operate (ATO) being issued. Because the ATO process is a complex, multi-step process which will constrain the design and implementation of your system, you should start thinking about how it applies to your system before you begin designing and implementing it.

Timeline

There are a few factors that will determine how long it takes a project to get an ATO. These map to the checklist, so might be helpful to open that up in another window and follow along.

  • Everything in Phase 1 needs to be done before the project can enter the ATO Sprint. That responsibility is mostly on the project team and the respective Infrastructure Lead. This could easily be 40 hours of work for a typical 18F project.
  • Projects get scheduled for Phase 3 based on the order they complete Phase 2, deadlines, etc.
  • Phase 3 should take no more than two weeks, assuming the previous Phases were done thoroughly.

The ATO Sprinting Team makes no guarantees regarding the timeline of ATOs.

Steps

Step 0 — Create ATO checklist

As soon as you begin developing an alpha, create your ATO checklist to set up a tracking mechanism for your ATO. You can ask questions in your checklist thread to understand the specific considerations for your system. At this time it also good to ensure your system is eligible for pre-assessment authorization for user testing purposes.

Step 1 — Determine impact level

Work with your Infrastructure Lead to categorize your system’s impact levels, using the ATO Levels guide. If your system will be providing novel or risky functions, or handling extremely sensitive data, do this as early as possible.

Step 2 — Select controls

“Controls” are individual security requirements laid out by the National Institute of Standards and Technology (NIST). Your system’s impact level baseline will determine the controls you need to implement.

Step 3 — Document the controls

This step is essentially “state how your system meets each of the regulations”. Using established web frameworks (Rails, Django, etc.) and hosting in cloud.gov takes care of a lot of the lower-level controls and security best practices for you, so you only need to be concerned with your application’s custom code and configuration. This custom code and configuration is known as the “attack surface”.

Work together with your Infrastructure Lead on this step. The documentation generated by previous similar 18F projects can be helpful at this stage. Try to create a solid draft of this document.

Compliance Masonry

The Compliance Masonry YAML file uses structured data to state how each control is one of the following:

  • Not relevant to the system
  • Relevant to the system, and is one of the following:
    • Taken care of by one of:
      • The platform (cloud.gov)
      • The framework (Django, etc)
      • The authorization layer
      • Etc.
    • Implemented by you
    • Not yet taken care of

An “inherited” control would be something like FedRAMP requiring that fire extinguishers be present near the servers, which is something that AWS needs to worry about for their compliance, and we don’t need to re-explain when launching an application hosted there. Your Masonry file essentially contains the “overrides”.

The controls that are not inherited from an underlying system must be listed in your Masonry file with a short explanation (“narrative”), and “implemented” before the system can receive an ATO. “Implementation” in the compliance sense is the same as in the code sense: ensure that the system meets that requirement, based on current industry best practices.

Step 4 — Assess the controls

In other words, “verify that your system is secure”. The first step in doing so is to run the security scans. This is a preliminary assessment, final assessment will be done in collaboration with the GSA Office of the Chief Security Officer (OCISO). You are encouraged to run scans yourself, so that there aren’t big surprises during the ATO Sprint.

Step 5 — Complete documentation package

Fill out the documentation in the checklist. We hope to auto-create the SSP from the Compliance Masonry YAML file at some point, but for now you should copy and paste.

The full list of data and functions in and of the system (in government parlance “mission based information types” and “delivery mechanisms”) must be itemized in structured data. While the data types are obviously arbitrary and custom to each system we produce, the government has a formalized data set of mission functions that should be mapped to the system via NIST 800-60. For a Rails app, for example, this can simply be a link to the db/schema.rb file on GitHub.

Step 6 — Authorize the system

Your Infrastructure Lead will work with you to schedule and prioritize your system assessment. Once assessment starts, the first step is that the AO will review all the items in your ATO checklist including all the documents you generated.

Then, for most systems, a team with members from the project team, your AO, your Infrastructure Lead, and the GSA OCISO will convene for at least a week as the ATO Sprinting Team, and begin to follow the Lightweight Security Authorization Process.

Folks from OCISO will conduct a penetration test on the system. Any penetration test findings deemed serious enough to prevent an ATO will need to be fixed right away to unblock the ATO process. They will also review the SSP document and test the control narratives. This testing and review process will take 1-2 weeks and should be the top priority for the project team at the time.

Once all of the materials are prepared and testing is done and the system is considered “ready” by the Authorizing Official, they will sign the ATO memo.

Step 7 — Continuously monitor the controls

There are several ways to ensure that your system remains compliant:

  • Act on any security notifications from your static analysis.
  • Act on any security notifications from your automated vulnerability scanning.
  • Keep your about.yml, a copy of your System Security Plan, and any other architecture/security-related documentation up-to-date.

System changes that may require a new ATO

Your system may need a new ATO if your application team is planning to make substantive changes, such as changes to:

The 18F Infrastructure team determines whether a system needs a new ATO. If you’re planning a change that you think may require a new ATO, please open a new issue in the Infrastructure repository to explain your planned change, so they can evaluate whether it needs a new ATO.

If it needs a new ATO, follow the usual steps for getting an ATO, starting with the checklist. You may be able to reuse and update your existing ATO materials.

Replacing an expiring ATO with a new one

If your current ATO is going to expire, you’ll need to replace that ATO with a new one. Follow the usual steps for getting an ATO, starting with the checklist. You may be able to reuse and update your existing ATO materials.