[Suggestion] An introduction to ATO

[trevorbryant-cisa]

URL / Link to page

https://digital.gov/resources/an-introduction-to-ato/ https://github.com/GSA/digitalgov.gov/blob/main/content/resources/an-introduction-to-ato.md

Tell us how we can make this page better

Hi folks, I read the newly published article and have some things I'd like to point out and recommendations for changes. I'm happy to submit PRs for edits if that's something you'd prefer. Please have a look at the items below as these are the impacting sections to note.

• L32: The RMF is mainly a six-step process. This is Prepare; Categorize; Select; Implement; Assess; Authorize; and Monitor. Each of these steps contain their own agency-specific processes.
  • L38: POA&M creation is in the Step 4: Assesses phase.
  • L37: The process for authorization is in the Step 5: Authorize phase.
• L42: An ATO is a requirement for information and information systems to be implemented and to operate and not an acquisitions requirement. There are, however, contract line items contingent upon achieving an ATO, but not before award or procurement, that may be worth mentioning here.
• L46: There are some stakeholder roles missing here, and some of the roles and responsibilities listed don't quite align or match with the role requirements. I recommend having a look at Appendix D of the NIST SP 800-37 Rev. 2 document.
• L82:. This needs to say categorize, not classify. This is all about systems categorization, as we are not classifying anything here.
• L84: This part is a little misleading to the reader. If the system is categorized low, the accepted decision is that the system is less important than others of a higher category. Low categorization systems are a general inconvenience should they become unavailable, as there are backup procedures in place for business continuity and there is no work stoppage. A low system does not gain response preference over a moderate or higher (hopefully). If the system owner feels that their system is more important, the categorize needs to be higher and justified so.
• L111: I recommend reviewing section 3.5 ASSESS of the NIST SP 800-37 Rev. 2 document.

There are mentions of software and products, but the authorization is much broader to information systems (IT, OT, planes, trains, and automobiles). Not limited to just software or software products. Many systems are embedded or only hardware, or other mechanical systems.

As there is a good deal FedRAMP-only language here that isn't used outside FedRAMP, I recommend adjusting the article to specify this and not the overall generic process for authorization. Or, if this the 18F process for achieving systems authorization, or the General Services Administrations (GSA) process for information and information systems, this should clearly be stated, and not a representation of other agencies process for systems authorization.

Hope this feedback helps. Thanks for allowing the opportunity to contribute!

[trevorbryant-cisa]

Bump

[afeijoo]

@trevorbryant-cisa Thank you for the bump. We're working with the author to address your feedback.

[afeijoo]

Thank you for taking the time to read and respond to Digital.gov resources.

This post is meant as a practical guide for Digital.gov's audience, folks who is not familiar with compliance or security practices. We focus on giving practical advice for digital use cases. As the article says, readers should talk early and often to the person or team that will be accessing the system to understand their agency's specific policies and practices.

We are also in the process of making a companion video and that will make some of the nuances that you brought up more clear.

[trevorbryant-cisa]

@afeijoo Thanks for the clarification! I'm curious who Digital.gov's audience is? Is a limited set of viewers, or a wide set of viewers? Is this blog article written for everyone, or those that want to do business with GSA or TTS?

When can we expect to have some corrections made to at least L42 and L82? These are factual incorrect and really should be updated for correction. We want to avoid confusion and the assumption that every digital experience for systems authorization is the same of each agency.

If these articles are intended to target a wide range of viewers outside of those who are interested in doing business with GSA or TTS, I'd be interested in working with your compliance or security practice folks on contributing to these series. How would I go about contributing?