Consolidate incident Response Plans

[afeld]

User Story:

As a member of TTS, I don't want to have to figure out the differences per project team/system, especially in real-time.

As a member for the Tech Portfolio, we should see where we can reconcile, to make ATOs and incident response easier / more consistent.

Problem Statement:

Seems that we have a number of incident response plans floating around

Actions to take:

• Create a list of known incident response plans
• Propose thinning of the cloud.gov plan
• Propose thinning of the login.gov plan
• Figure out how to integrate with Continuity of Operations Plan (COOP)
• Clearly state required resolution times and where they come from

Acceptance criteria:

• Obtain cloud.gov IR plan
• Obtain login.gov IR plan
• Obtain search.gov IR plan
• Obtain data.gov IR plan
• resolution times and where they come from are clearly stated
• setup bi-weekly meetings with interested TTS programs

Supporting Documentation:

• https://handbook.18f.gov/responding-to-public-disclosure-vulnerabilities/
• https://github.com/18F/bug-bounty/blob/master/project-instructions.md#slas-your-program-must-meet
• login.gov

Related issues:

cc #49

[hillaryj]

Here's the IR guide and checklist for cloud.gov:

• https://cloud.gov/docs/ops/security-ir/
• https://cloud.gov/docs/ops/security-ir-checklist/

[adborden]

Data.gov tracks incidents in gsa/datagov-incident-response and the plan/checklist is in Drive.

[afeld]

From #49 (comment):

Re SLAs, here's a document to be updated: https://github.com/18F/bug-bounty/blob/master/project-instructions.md#slas-your-program-must-meet

Bug bounty refers to a 90-day SLA, but recommends 7-day for high, 30-day for medium.

Though the 90-day SLA above is the only required timeline, we do (strongly) suggest that your program aims for faster remediation of more severe issues.

We might want to align them better with GSA's policies.

[afeld]

Clarified this issue to be about about triaging and response, while #49 is about reporting.

[afeld]

Notes from discussion with cloud.gov

[dawnpm]

Are you talking about Contingency Plans (which would include COOP) or Incident Response Plans?

GSA uses the terms separately - Incidents are human driven (e.g., attacks, infiltrations, PII leakage), Contingencies are force majeure (e.g., the Cloud Host Has Major Problems, COOP situations). The official incident response plan is managed by the GSA IR team, so much so that there is common language for that control in the SSP templates. We are finalizing our official Contingency Plan in the GSA template, which will be posted to Google Drive. We also have an emergency procedures doc for our team's use.

[afeld]

Good point on that distinction. I think we should consider both, though maybe not at the same time.

[gbinal]

For api.data.gov, you can partially see this in how we document the process for handling abnormalities that show up in the regular monitoring. But the process then basically says that we follow the 18F incident response process.

https://github.com/18F/api.data.gov/blob/master/docs/procedures.md#weekly-monitoring-checklist

[dawnpm]

Good point on that distinction. I think we should consider both, though maybe not at the same time.

Search.gov manages our own contingency plan, and uses GSA's IR plan.

[afeld]

@dawnpm Mind providing a link?

[afeld]

• Split the Contingency / Continuity of Operations plan consolidation into its own issue

[hillaryj]

Per discussion at the wg-security meeting, @its-a-lisa will be leading the unification of IR plans from the TTS Tech Portfolio side. She'll coordinate simplifying the plans into one base plan with addendums.

Marshall Brown (representing the COOP process & docs) says that within the next two months are needed to integrate login.gov and cloud.gov into the COOP contingency process.

[dawnpm]

@dawnpm Mind providing a link?
@afeld sure -

Search.gov Contingency Plan (permissions managed by ISSO team): https://docs.google.com/document/d/1f6tAETRm8l8lvhd64YtSRw3_chg0FayDKFqDk7TNlqg/edit

GSA IR guide: https://insite.gsa.gov/cdnstatic/insite/Incident_Response_%28IR%29_%5BCIO_IT_Security_01-02_Rev_17%5D_03-20-2019_Signed_BB.docx

[mogul]

We ran an IR exercise for data.gov this week, and just did a retro; notes are here.

One of our action items was to follow up and make sure y'all know we really want this consolidation. It's confusing to have our own process, and then have to fork up/out to the broader TTS process, which results in a lot of redundant comms juggling as well as documentation overload in-the-moment.

[pburkholder]

Back to @hillaryj 's point, cloud.gov has four guides actually:

https://cloud.gov/docs/ops/security-ir/ - the documentation
https://cloud.gov/docs/ops/security-ir-checklist/ - what's supposed to be quicker in real-time process guide
https://cloud.gov/docs/ops/service-disruption-guide/ - incidents that aren't security incidents
https://cloud.gov/docs/ops/contingency-plan/ - sustained loss of services we depend on

I would like to see consolidation so we start with "Service disruption" and then follow paths depending on what the source of the disruption is.

[its-a-lisa-at-work]

Closing this issue today based on today's meeting.

Opened up new issue to continue on this effort: #229