New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

are there other exemptions for ATO? #95

Closed
afeld opened this Issue Jan 21, 2016 · 6 comments

Comments

Projects
None yet
4 participants
@afeld
Contributor

afeld commented Jan 21, 2016

Some interesting questions raised in Slack:

  • Does each new site published through Federalist or Pages need an ATO?
  • Are there special rules around "staging" deployments vs. production ones?
  • Are there special rules for static sites? Or is there a way to fast-track them as an Open Data ATO?
  • Is the ATO done at the "system" level, or the domain? (I'm pretty sure the former, but we should be explicit about it.)
  • #94

Our current exemptions are listed here, but wonder if there's any more we can add there to answer these questions.

/cc @mbland @dlapiduz @NoahKunin @wslack @gboone @dhcole @jeremiak

@thecapacity

This comment has been minimized.

Member

thecapacity commented Jan 22, 2016

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).

HTH

@dhcole

This comment has been minimized.

dhcole commented Jan 22, 2016

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.

@thecapacity

This comment has been minimized.

Member

thecapacity commented Jan 22, 2016

Ok - I might be splitting a different hair around accreditation vs.
authorization.

(William) Jay Huie

OCSIT/18F
U.S. General Services Administration
william.huie@gsa.gov
202.322.3023

On Jan 22, 2016, at 10:15 AM, Dave Cole notifications@github.com wrote:

According to 18F/Infrastructure#432 (comment)
18F/Infrastructure#432 (comment) and
subsequent conversations with Noah, Federalist as a platform has an ATO and
sites on the platform do not require additional review.


Reply to this email directly or view it on GitHub
#95 (comment).

@NoahKunin

This comment has been minimized.

Contributor

NoahKunin commented 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,accreditation no longer exists within the NIST RMF. Fully deprecated. There is only A&A: assessment and authorization.

@afeld - As to the the specific questions, @thecapacity more or less nails them, here's some additional context and final clarification:

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?
Combined these because it's the same answer. While aware of the context above, the short answers are No, No, and sort of. There's no fast track due to scoping - it's that Federalist itself is ATO'd, and therefore extends it speed to anything built on it or with it.

Are there special rules around "staging" deployments vs. production ones?
No. The rules apply regardless.

Is the ATO done at the "system" level, or the domain? (I'm pretty sure the former, but we should be explicit about it.)
System boundary level - which makes it subjective and complex.

@thecapacity

This comment has been minimized.

Member

thecapacity commented Jan 22, 2016

+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).

@NoahKunin

This comment has been minimized.

Contributor

NoahKunin commented Mar 10, 2016

Cool.Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment