CivicActions Security Incident Response Procedure Checklist

For more details on any part of the checklist, see the Security Incident Response Plan.

Table of Contents


1. Breathe

No one's life is in danger.

2. Start documenting

Begin documenting all steps and findings. Documentation makes handoffs and responder onboarding easier. The Slack channel #general, or a Project-specific Slack channel if applicable, is recommended because it is most widely accessible, but other communication channels may be used.

3. Initiate the response

At this stage, the First Responder is usually working alone, and is also the Incident Commander (IC).

A. Allocate 5 minutes and determine whether this event is a potential incident or false alarm. Consider any potential Project impact.

B. Respond accordingly:

4. Assess the incident

IR Team responsibilities

A. Confirm the incident.

  1. Gather information, and document your findings.

    • Was the event triggered by an external dependency?
    • Is a system failure causing the disruption?
  2. Proceed to the next step for a confirmed incident. (For a false alarm, conclude the incident. Proceed to 6. Conclude the incident.)

B. Assess the severity. Use the rubric in the IR guide. (Project incidents are generally "Low severity".)

C. Assess whether to activate the contingency plan. Consider whether Disaster Recovery is required.

Reminder: Use the Explicit Handoff Ceremony when transferring/changing roles.

Incident Commander responsibilities

  • Post an initial situation report, called a sitrep (example sitrep), to the Slack channel #general. Include a descriptive name, and identify the current Incident Commander and Responders. Use @security to trigger a Slack notification for the Security team.
  • For an issue with potential Project impact, ensure that a JIRA ticket or Gitlab issue has been created. This should be done, even if the First Responder/IC manages the incident fully, for example, by simply re-starting a service.

5. Remediate

IR Team responsibilities

  • Determine the cause, implement a resolution, and return the system to normal operations. Make every attempt to identify the cause; this can prevent incident recurrence.
  • If suspicious activity is suspected or other unanswered questions exist, do the following before making any changes:

    • Make snapshots of relevant volumes and data.
    • Preserve logs.
    • Take screen captures of anomalous activity that can be used in post-remediation forensic analysis.
    • Consider implementing a containment strategy. For example, reconfigure firewall rules for the affected instance to drop all ingress and egress traffic, except from specific IPs like yours, until forensics can be performed.

Incident Commander responsibilities

  • Maintain current information in Slack, shared Google Docs files, the ticket/issue (if applicable), or other communication channels. Be sure to include:
    • Project team leads and members
    • Remediation items and their assignees
  • Establish and document work shifts for an incident longer than 3 hours.
  • Maintain communications with stakeholders, or designate a Communications Officer via explicit handoff.
  • Share sitreps on a regular basis:
    • High severity: hourly
    • Medium severity: 2x daily
    • Low severity: daily
  • Focus on coordination, not remediation.

6. Conclude the incident

A. Notify the Slack channel #general that the incident has been resolved. Use @security to trigger a Slack notification for the Security team.

B. Update the ticket/issue (if applicable) and set the status to one of the following:

  • Confirmed incident: Ready for QA
  • False alarm: Done

C. Schedule an IR Team retrospective. Optional for false alarms.

D. Share the final sitrep with stakeholders.

E. Thank everyone for their service.