18f / before-you-ship Goto Github PK

I'm not sure if this is a misconfiguration in this project, or an issue with the guide-style (https://github.com/18F/guides-style), but css overrides for this guide are not appearing in production.

Locally, I see that my assets/css/styles.scss are merged into the styles:

On the server, I see the raw guide styles used:

Is this a misconfiguration on our part? I see a similar situation with the agile guild's page: https://pages.18f.gov/agile/

@mbland

https://github.com/18F/before-you-ship/pull/128/files#r53687338

https://trello.com/c/bgOlpJAy/10-write-up-guidelines-on-static-analysis-tools

Project members should understand the criteria and implications of each.

• Open Data
• FISMA Low
• FISMA Medium
• FISMA High

@NoahKunin I'll need some help from you on this...anything you can point me to that has information already?

Not sure if this warrants its own repo...thoughts?

See Slack convo.

This site (and our ATO process in general) is in as much need of content help as technical help. We have documentation scattered all over the place (see #12 and links from there), without any easy steps for developers or product managers to follow (#29).

• Write up an Open Opportunity – https://openopps.digitalgov.gov/tasks/456
• Reach out to the #writing_lab – https://github.com/18F/writing-lab/issues/76
• Get someone to sign on

• Django deployment checklist
• Production Rails

It's not clear to people what changes to a project should constitute a "new" ATO being created, though maybe it's irrelevant once we move to continuous authorization? I assume in that case they have a System Security Plan that stays up-to-date throughout the development cycle, and new action only needs to be taken if they change level? @NoahKunin Does that sound right? Any other guidance here?

Raised because of https://github.com/18F/DevOps/issues/542.

/cc @gboone

The page is called before you ship, but it catalogs a lot of tasks that should begin almost as soon as a project itself begins. To emphasize that, would it be helpful if we compiled a 'Working Backwards' task timeline for this information?

The scale & tasks are obviously different, but I find the Startup Weekend Task Timeline (http://organizer.startupweekend.org/) super helpful when organizing events.

https://pages.18f.gov/before-you-ship/security/scanning/#alerts should be expanded to provide more detail about what qualifies an alert as high/medium/low.

Someone coming into this for the first time would presumably care about reading the triggers to then decide if they need to learn about the relevant law or whatever. We should lead with

Will your app be collecting personal information? If so, ...

for example.

https://pages.18f.gov/before-you-ship/security/ has a lot of information that is no longer relevant in the cloud.gov world, or that should be moved to the ATO page(s).

• https://github.com/18F/before-you-ship/blob/18f-pages/assets/18F%20DNSSEC%20Policy%202015.pdf
• https://docs.google.com/document/d/1oF-_W3k2sC74jtcBz_cFNo1w_2DOx-Y6oBdplpo77UQ/edit

Not sure why it's a PDF in the first place, but having it as Markdown means we can make changes more easily. @NoahKunin Do you have the source file that the PDF was generated from?

/cc @konklone

Would love to incorporate https://github.com/18F/glossary.

from the Introduction (home page of the site)
https://hub.18f.gov/private/standards/security/#

https://pages.18f.gov/before-you-ship/infrastructure/good-production-practices/#monitoring

has some information, but since it's a required control for ATO, we should make sure to include more detailed instructions about how to set up New Relic / Sentry / whatever.

@mogul @LindsayYoung I remember seeing some instructions around this somewhere, but can't remember. Any idea?

Per @jezhumble's Slack post, ATO requests should now move to https://github.com/18F/compliance. Maybe we convert the checklist to an issue template there?

The Client Tags section links to the 18F Enterprise Architecture spreadsheet as the source of project UIDs. That spreadsheet does not contain the ids.

Furthermore, should we be linking to an internal Google Doc on a publicly accessible page?

From @DavidEBest in Slack:

Whoever signs off and accepts the risk of operating an information system if you were to have built this system yourselves needs to sign the delegation letter. This person is normally called the Authorizing Official. They will have received this title through a series of delegations from the head of the [agency], presuming procedures were followed.

Note this document is critical and urgent - it clarifies and stipulates that the [agency] is not the system owner, 18F/GSA is, which allows us to do both what we've done to date and to complete the work we have in front of us. Without it, there is a lack of clarity, potentially legal in nature, on who is the customer and who is the provider of this system which makes it impossible to correctly move the system through the variety of compliance requirements we have in front of us.

I know that it also came up via @wslack with the FOIA project, so would be good to have an explainer about how ATO delegation works.

/cc @leahbannon

As suggested by @NoahKunin.

https://pages.18f.gov/guides/

What we currently have on the ATO page

An Authority to Operate (ATO) is a complicated security review process that is required before you can deploy anything on the public web. Before a system is made publicly accessible on the Internet, it must go through either the full ATO process or a 90-Day Authority to Test. If either are not yet complete, the system must have some level of authentication required for a user to enter.

has the following issues:

• The first sentence isn't entirely accurate
• It doesn't explain what the byproducts of an ATO are
• The last two sentences (maybe?) go into a bit too much detail

As a developer, I should know what reports are required of me for ATO, and where they should be put.

What reports are needed by @NoahKunin to verify that the application was scanned and where should the developer put them?

Is there a preferred format? HTML/JSON
Should there be an accompanying report describing false positives?

...or at least find a better place for it. As @DavidEBest pointed out in https://github.com/18F/before-you-ship/pull/38/files#r48160659, doesn't really make sense to have it in the AWS page.

Extracted from #81 (comment).

If Nessus is not going to be used going forward, should it be removed from the DevOps checklist?

If it should still be used, its usage should be documented.

From #1 (comment):

• examples of system architecture diagrams that have successfully passed through ATO
• list of things that are FedRamp or already ATO'd. If you pick components that don't have an ATO, the process is longer (like MyUSA using RDS and ElastiCache)
• expected timelines for each step of the process
• when you should start the process (hint: before you finish coding the version you want to release)
• when do you need to amend the ATO? What changes to the product trigger that need?
• what happens at the end of 1 year?

Currently, there are extra spaces in the way we're displaying unrendered markdown for copy and pasting to issues. So if you copy and paste into an issue, you're creating sub-bullets.

This is an issue for the accessibility issue text from the index.md file, but not the ATO one.

Broken out from #65.

When we "finish" a project and hand it off to the agency partner, we need to explain:

• What happens in relation to the ATO
• What accounts we need to give them access to
• etc.

Would be nice to have this in checklist form. No strong feelings about whether this information lives in this site or elsewhere.

/cc @leahbannon

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

Can't remember who proposed this idea, but I like it.

The current page is a bit disjointed:

https://pages.18f.gov/before-you-ship/ato/background/

Is this information that project teams need to know?

• If so, should we put it elsewhere?
• If not, does it belong on this site?

At the very least, I think it could

• be more narrative
• give some explanation of the video
• explain how ATOs in 18F relate to those in other agencies /cc #65

https://pages.18f.gov/before-you-ship/infrastructure/aws/

With the move to Cloud Foundry, relatively few developers are given (or need) direct access to AWS.

• Change the AWS guide to reflect this.
• Add section about when/how to grant access to new users.

As brought up by @DavidEBest in:

#117 (comment)

The reference:

https://github.com/18F/before-you-ship/blob/6c88e249c100bd07667dea2398ebd75e72a22363/_pages/ato/levels.md#categorize

The relationship between what is law vs. regulation vs. guidance in the existing ATO process is murky. How can we clear that up and represent it effectively?

I found a bug and noticed there's a PR from two days ago. We should add something to the CONTRIBUTING.md that sets some guidelines on how to help, like: https://github.com/18F/midas/blob/devel/CONTRIBUTING.md#reviewing-pull-requests

Proposed text:

Except for critical, urgent or very small fixes, leave pull requests open for most of the day or overnight if something comes in late in the day, so that multiple people have the chance to review/comment. Anyone who reviews a pull request should leave a note to let others know that someone has looked at it. For larger edits, we like to have a +1 from someone who has experience with the topic. Please note if you actually can verify the information, such as "sounds right" or "nice clarification" -- a +1 by itself will typically be interpreted as your thinking its a good idea, but not having reviewed in detail.

Anyone on the 18F ???? team who believes the change is good can (and should) merge pull requests that have been reviewed and are older than 1 day. A committer can both review and merge if they are not the author of the pull request.

Currently the ato information is split into two pages, ato & ato-and-you. ato has a top-level link in the nav, but ato-and-you is not linked from there.

https://docs.google.com/document/d/1rw01PX_NPeOK13sThLqI3EPyNwYijD0BJDUGQTdlDpA/edit

Broken out from https://trello.com/c/6zI9JUEK/13-consolidate-ato-documentation.

Say that cloud.gov should be used for all projects, unless there's a good reason not to. There should be documentation (somewhere?) about why a different infrastructure setup was used.

/cc @mogul

If the reader has a question about a particular regulation or step, this repo should tell them where/who to go to for more information. This could be some combination of:

• Whether each checklist item is a requirement or a guideline
• Where each checklist item came from (government-wide, GSA, the 18F DevOps/InfoSec team, etc.)
• A government site that goes into more detail
• The regulation text itself
• A Slack channel to ask in
  • Relatedly, the Documentation working group is going to try listing the relevant Slack channel on every Hub page.
• A repository to file an issue in
  • Maybe default to "open an issue in this repo if something is unclear"?

One thing I learned at my last job is that it's preferable to have a chat room, mailing list or repository you can go to with questions, rather than an individual, who may be sick or on vacation or no longer working there or whatever.

At the very least, link out to wherever's relevant.

• RA-5(a) - Vulnerability Scanning
• SA-11 (1) - Developer Security Testing and Evaluation | Static Code Analysis
• https://web.nvd.nist.gov/view/800-53/Rev4/impact?impactName=moderate

@NoahKunin What was the third one you mentioned?

As referenced in the SSP template.

• What programs can be used (at 18F's disposal) to create one
• What it should/shouldn't include

hi all! There are a number of pages on the Hub that concern Infrastructure guidelines or AWS:
​
https://hub.18f.gov/aws-access/index.html
https://hub.18f.gov/encrypt-pers-comp/index.html
https://hub.18f.gov/guidelines/index.html
https://hub.18f.gov/cloud-foundry/index.html
​
I would like to propose that some of this information would be better if it lived here:
​
https://pages.18f.gov/before-you-ship/infrastructure/aws/

or on the Infrastructure page on the Handbook - https://github.com/18F/handbook/blob/staging/articles/2-about-us/teams/infrastructure.md
​
Are there objections to moving this content? I want to make sure we account for it as we're completing this migration, and I want to make sure it doesn't overlap with existing content. I would much rather point to this source and the Handbook page for Devops/Infrastructure than to have small islands of content floating around the Hub.

...including what vulnerability scans to run, etc. Maybe it should be a Markdown template of what to paste into an issue on the Devops repo?

https://pages.18f.gov/risk-management-framework/

There is a lot of content here that isn't surfaced in the sidebar. https://github.com/18F/risk-management-framework/tree/18f-pages/pages

• https://github.com/18F/tls-standards
• https://docs.18f.gov/apps/custom-domains/

/cc @konklone

Say something like

Is there additional process for your agency, or other edge cases that aren't listed here? Let us know!

...or link to the relevant place.