Lifecycle of a Launch
ATOs
Timeline
ATO Sprints are staffed cross-divisionally by the GSA Office of the Chief Information Security Officer (OCISO) and TTS.
There are a few factors that will determine how long it takes a project to get an ATO. These map to , external,the checklist, so might be helpful to open that up in another window and follow along.
- Everything in , external,Phase 1 needs to be done before the project can enter the ATO Sprint. That responsibility is on the project team and the respective Infrastructure Lead. Completing Phase 1 could take 40 hours of work.
- Your Infrastructure Lead conducts the documentation review of , external,Phase 2. Projects are scheduled for , external,Phase 3 by the Infrastructure Leads as a group.
- , external,Phase 3 should take two weeks, assuming the previous Phases were done thoroughly.
The ATO Sprinting Team makes no guarantees regarding the timeline of ATOs.
Steps
Once you have , external,TTS-only, validated the path to production, see this TTS-specific information beyond the , external,general steps:
Step 0
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 is also good to ensure your system is eligible for pre-assessment authorization for user testing purposes.
Step 1
Work with your Infrastructure Lead to categorize your system's impact levels, using the , external,ATO Levels guide. GSA provides a "lightweight" ATO process designed for pilot systems running on GSA authorized infrastructure, for which fewer controls are in scope.
Step 2
Step 3
Work together with your Infrastructure Lead on this step. The documentation generated by similar TTS projects can be helpful at this stage. Consult the checklist for examples. SSP templates are available for both GSA LATOs and FedRAMP ATOs.
Step 4
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 GSA OCISO. You are encouraged to run scans yourself, so that there aren't big surprises during the ATO Sprint.
In parallel, you will collaborate with a GSA OCISO assessor to verify all the controls in the SSP. The exact tests are given by this , external,TTS-only, assessment case template.
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 and begin to follow the TTS-only, Lightweight Security Authorization Guide.
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.
Step 5
Step 6
There are several ways to ensure that your system remains compliant:
- Act on any security notifications from your static analysis.
- Perform and act on findings from dynamic scanning.
- Re-certify your Privacy Threshold Analysis (PTA).
Re-authorization
Beyond the , external,general information:
If you're planning a change that you think may require re-authorization, please , external,open an issue in the TTS Tech Operations repository to explain your planned change, so they can evaluate it.
If your systems needs re-authorization, follow the usual steps for getting an ATO, starting with the checklist. You should be able to reuse most of your existing ATO materials, assuming they have been kept up-to-date.
See also: site redesign , external,Concept form and , external,TTS-only, process.
ATO renewal
Beyond the , external,general information, follow the usual steps for getting an ATO, starting with the checklist.
ATO Checklist
, external,Create your ATO checklist
The ATO checklist helps you track progress towards a successful launch throughout your project. It is a formatted issue on GitHub, and is the canonical source of information for your path to launch.
Make sure to replace the placeholders (the things in [square brackets]). Feel
free to add a username after each task to assign it, and/or make corresponding
items in your issue tracker. Unless otherwise specified, all tasks are the
responsibility of the project team.
You are welcome to ask any questions as comments in the issue or , external,TTS-only, #infrastructure.
Types of ATO
There are several different methods in obtaining a GSA Authorization as described in the policy IT Security Procedural Guide: Managing Enterprise Risk CIO-IT Security-06-30 in TTS-only, Insite
- GSA Standard A&A Process
- Lightweight Security Authorization Process
- GSA Salesforce Platform Process
- Security Reviews for Low Impact Software as a Service Process
- FedRAMP Process
- GSA Moderate Impact Software as a Service (MiSaaS) Security Authorization Process
- GSA Subsystem Process
- GSA Information System Continuous Monitoring Program
In most cases, the types of ATO that will be pursued for TTS custom software systems are the GSA Lightweight ATO (LATO). The GSA LATO process is described in a guide on TTS-only, Insite (search for "Lightweight Security Authorization Guide" on that page). Systems that are under development must fulfill the requirements for pre-assessment for internal government use.
System categorization
The GSA LATO is designed for Low and Moderate impact , external,level systems built using agile methods that run on top of cloud infrastructure which has already received an ATO (such as AWS, Azure, and , external,cloud.gov).
Control selection
The GSA LATO is "lightweight" because it represents a tailored subset of the hundreds of controls in NIST Special Publication (SP) 800-53.
System authorization
The GSA LATO Low risk system ATOs are valid for 3 years. he GSA LATO Moderate risk system ATOs are valid for 1 year. The Authorizing Official (AO) and Chief Information Security Officer (CISO) may sometimes grant a 90-day ATO, on a case by case basis. The default expectation is to avoid 90-day ATOs whenever possible, since they make more work for everyone.
Conditions for pre-assessment
Previously known as "pre-authorization".
First, read TTS-only, GSA's guidelines for staging sites.
You may operate without further authorization, based on our approved pre-existing security authorization, if all of the following conditions are met:
- The system is deployed to , external,cloud.gov or , external,TTS-managed infrastructure-as-a-service (IaaS).
- The system does not:
- interact with or change the state of any production Federal information system, whether it is operated by TTS or our Federal partners
- collect or store any sensitive personally identifiable information (PII)
- is not the canonical source of any "production" data
- The system is only available to:
- staff of the General Services Administration
- other Federal staff / agencies, by one of:
- IP CIDR block
- some kind of auth mechanism
- HTTP Basic Auth (one set of credentials shared amonst the team is fine)
- OAuth (, external,cloud.gov authentication, or , external,GitHub authentication limited to a particular organization)
- etc.
For systems where all of the information in the system is already publicly available and is non-confidential, the last step can be skipped once you have begun your ATO assessment with GSA IT.
System Security Plan
As described in , external,the NIST guide:
The purpose of the system security plan is to provide an overview of the security requirements of the system and describe the controls in place or planned for meeting those requirements.
At TTS, the system security plan (SSP) is a long Google Doc.
Diagrams
Examples within TTS
- A simple application running on cloud.gov: , external,TTS-only, FBI Crime Data Explorer
- A more complex application running on cloud.gov: , external,TTS-only, CALC
- Another complex application running on cloud.gov: , external,data.gov (drawn with , external,PlantUML)
- , external,TTS-only, A complex application not running on cloud.gov
- , external,cloud.gov itself (drawn with , external,Mermaid)
Tools
The following have been used / are available for use in TTS:
- Google Drawings
- , external,Mermaid
- OmniGraffle
- , external,PlantUML
- Visio
FedRAMP packages
Often you'll be building on top of services that have FedRAMP authorizations. When writing your SSP, you'll need to mark certain controls as "inherited", based on the Customer Responsibility Matrices (CRMs) of the Cloud Service Providers (CSPs).
- For cloud.gov, you can download the CRM from , external,their website.
- For others, you'll need to , external,put in a package request.
RSA Archer
, external,RSA Archer is the canonical home for system compliance info at GSA. System Owners and Authorizing Officials should automatically have access, but additional read-only access can be , external,TTS-only, requested for "support staff".
Signing in
- , external,Get on the GSA network
- Visit archer.gsa.gov
- Sign in with your ENT credentials
- Check your email for the one-time password
Contact ispcompliance@gsa.gov for any issues.
Tips
- Is your project accessible and , external,Section 508 compliant? The team will need to incorporate this throughout the project, but you'll also need to set up a review at least two weeks before launch.
- How good is your code test coverage? Before shipping, you should have codecov badges on your GitHub repo READMEs and coverage should be above 90 percent (green). (This is not a perfect measure for code quality, but a helpful check.) The testing working group recommends reviewing your status early and often. Ask #wg-testing if you have questions.
- Are your APIs up to the , external,API Standards? Ask the , external,TTS-only, #api if you have questions.
- Make sure you have all the social media metadata and preview images.
