Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
are there other exemptions for ATO? #95
Some interesting questions raised in Slack:
Our current exemptions are listed here, but wonder if there's any more we can add there to answer these questions.
Usually "systems" need the ATO - so a new page/site shouldn't need a new ATO - unless someone made a "risk based decision" that the "new site" had substantial functionality. For example, since Federalist is largely static pages - a new static site that was informational e.g. "About Us" wouldn't represent a substantial change to the system "boundary" - but if the "new site" represented a "substantive change" (maybe because the data was PII, or it had functionality like payment processing) then it would need an assessment about the potential (either to expand the ATO or create a new one).
Usually the staging vs. production "rule" is agency specific - most development environments don't tend to get an ATO nor to transient environments like "staging" (rather they have one that's a blanket authorization).
No special rules for static sites - but the process should be "repeatable" quickly - i.e. documented for one static page/site and then "re-used" (but again a static page might link to something sensitive so it's a case-by-case basis).
ATO is by "system" which could equate to a technical "domain" but doesn't normally (i.e. a website domain hosted on a single server might still include other systems in the ATO - such as tape backups, networking, DoS preventions, out of bad access, etc).
According to https://github.com/18F/DevOps/issues/432#issuecomment-159406665 and subsequent conversations with Noah, Federalist as a platform has an ATO and sites on the platform do not require additional review.
Ok - I might be splitting a different hair around accreditation vs.
(William) Jay Huie
On Jan 22, 2016, at 10:15 AM, Dave Cole email@example.com wrote:
According to 18F/Infrastructure#432 (comment)
referenced this issue
Jan 22, 2016
There are no exceptions - you must receive an authorization before operating. The issue is in defining "operation". NIST does not define it for you. @thecapacity is correct on that, as well as whether or not a new site being deployed on Federalist triggers an ATO or not, for the reasons he lists. The nuance here though, which is relatively new to the Federal government space, is the shared tenancy of platforms like Federalist and cloud.gov.
In either case, each agency using a platform must either accept the current controls and boundary to be sufficient for their usage or not, and whether controls at their layer (the software or application layer) are sufficient to compensate for risk elsewhere. It's not our job to police whether or not someone uses Federalist or cloud.gov to post the nuclear codes - that's the responsibility of the agency user of the platform. This is one reason why we're investing in Compliance Toolkit and Masonry, to make sure that risk acceptance is transparent and fast.
Operation at GSA means any one of the elements linked above are not true (I'm realizing that creates a double negative for the third condition, should fix that).
On the flip side @thecapacity,
Does each new site published through Federalist or Pages need an ATO? Are there special rules for static sites? Or is there a way to fast-track them as an Open Data ATO?
Are there special rules around "staging" deployments vs. production ones?
Is the ATO done at the "system" level, or the domain? (I'm pretty sure the former, but we should be explicit about it.)
+100 to @NoahKunin 's answers
System Boundary is also at the discretion - e.g. "whether or not someone uses to post nuclear codes" that might be one system or it might be that the Federalist page for codes is part of some larger "system" (in a non-technical sense but in a "big bucket of parts" sense).