Skip to content

Latest commit

 

History

History
207 lines (156 loc) · 9.04 KB

ato.md

File metadata and controls

207 lines (156 loc) · 9.04 KB
Raw
name about title labels assignees
ATO
Checklist for an Authority to Operate
ATO for [system] - due [date]
g: accepted, i: software assurance
  • Main repository: [url]
  • Site: [url]
  • Product manager: @[username]
  • System Owner: @[username of technical point of contact who will be the project representative for the ATO]
  • ISSO: @[username]
  • ISSM: @rpalmer-gsa
  • ATO folder: [url]

TODOs

If your system isn't live yet, "production" refers to the environment that will be production.

Phase 0: As early in the project as possible

Project team

ISSO

  • Provide SSP template
  • Lay out long-term ATO path
  • Ensure that common technical controls are part of the architecture

Phase 1: Assessment prerequisites

Everything in this section needs to be completed before the project will be scheduled for an assessment.

Tech Portfolio Lead

  • Set up an ATO intro meeting with the project team.
  • Set up the project ATO folder.

Project team

Technical

These tasks apply to every repository/application/hostname/language that is directly involved in your project.

  • Enable protected branches for the project repository.
    • Get help via #admins-github, if needed.
  • Ensure that your production environment is fully set up, and matches what's described in your ATO materials.
  • Set up monitoring
  • Log required events
  • Perform security scans, and put the results (or a link to them) in the project's ATO folder.
    • Set up dependency analysis service
      • Add service badge to your README
      • Put a point-in-time PDF of the scan results in the project's ATO folder.
    • Set up static code analysis
      • If using a service, add the badge to your README.
    • Perform dynamic vulnerability scanning
      • Resolve any visible security issues, re-running the scan as needed
      • Add the issue-free scan report or documentation about false positives to the project's ATO folder.
  • If this is a new system, add a prominent Beta label to the site.
  • Ensure the production environment has sufficient capacity to withstand the testing.
    • The testing tools create very heavy usage and traffic.
  • Architecture finalized
Documentation

...reading and writing.

ISSO

  • Tailor documentation checklist above
  • Review Section 13

Phase 2: Architecture review

ISSO

  1. Submit sections 1-12 of SSP for Architecture Review
  2. Submit section 13 to ISSM for acceptance and movement forward for assessment if no issues remain
  3. Schedule a documentation review session.
    • One or more follow-up sessions may be necessary.

Program team

  1. Fix any documentation issues identified in the session.
  2. RoE signed
    • System Owner
    • GSA IT
  3. Confirm you can access Archer

Phase 3: Environment finalization

Project team

  • Environment (live system) finalized
  • Fully instantiate environment for assessment
    • Your SaaS/IaaS/PaaS should be generally configured for launch
  • Remediate High and Critical findings from scans
  • Fill out the Rules of Engagement (RoE)

ISSO+SecOps

  • Complete operating system (OS), database (DB), and/or container scanning
  • Complete Web Scanning for GSA implementation site (Netsparker)
  • Re-scan to ensure remediation

Phase 4: Penetration testing

The following penetration tests will be performed:

  • External Interfaces
  • OWASPv4.1 & PTES-TG
  • Gray Box
  • Authenticated

Project team

  • Environment being tested is frozen (disable automated deploys to production)
  • Put all found vulnerabilities in the project's issue tracker
  • Fix any Critical or High vulnerabilities.
    • This needs to be done before the ATO can be issued, though not necessarily before the end of the assessment.

Testers

  • Deliver Penetration Test Report

ISSO

  • Request penetration test and assessment
  • Penetration test complete
  • Assessment scheduled

Phase 5: Assessment

Needs to start within 30 days of penetration test.

Assessors

  1. Assessment kickoff meeting
  2. Complete Security Assessment Plan (SAP)
  3. Complete Security Assessment Report (SAR)

Project team

  • Polish up the System Security Plan (SSP).

Phase 6: Post-assessment

  1. Controls tested - @[GSA IT representative]
  2. Create a Plan of Actions and Milestones (POAM). - @[GSA IT representative]
  3. Final review and risk acceptance signatures (issue the ATO) - @[Authorizing Official]
  4. Remove the Beta label from the site.
  5. Fix all Moderate vulnerabilities - due [30 days after ATO issued]
  6. Fix all Low vulnerabilities - due [60 days after ATO issued]
  7. Join the TTS Private Bug Bounty - due [60 days after ATO issued]
  8. Move to the TTS Public Bug Bounty - ask #bug-bounty - due [two weeks after start] or two weeks after the last critcal/high report was triaged, whichever comes last
  9. ATO letter signed
  10. Cert letter signed
  11. Launch

See the Before You Ship site for more information.

/cc @18F/tts-tech-portfolio