Bixal Solutions Incident Response Plan (IRP)#

Table of Contents#


Note: This Incident Response Plan applies to systems for which Bixal Solutions has negotiated and defined Incident Response/Contingency Plan (IRCP) operations. Each IRCP-managed system will have a specific, tailored version of this Incident Response Plan or in some cases a completely unique Incident Response Plan will be developed. All Bixal Solutions employees are aware of the procedures outlined herein.


This Incident Response Plan provides baseline guidance for the Bixal Solutions Team's process for responding to security incidents and other disruptions of a Bixal Solutions IRCP managed system, product or service ("system"). It outlines roles and responsibilities during and after incidents, and it lays out the steps we'll take to resolve them.

If you're responding to an incident, here's an IRP checklist as a short, actionable companion to this guide.

At a high level, incident response follows this process:





During this process, the team communicates in the following places:

For full details, read on.

Response process#


An incident begins when someone becomes aware of a potential incident. We define "incident" broadly, following NIST SP 800-61, as "a violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices". This is a deliberately broad definition, designed to encompass any scenario that might threaten the security of a system. (For more, see: What is an incident?)

When a person (the reporter) notices what appears to be a security-related incident, they should check #Official - Incident Response and project specific channels on Teams to see if this may be expected behavior (e.g., expected system downtime during a maintenance window) and if necessary alert the on-call system administrators by messaging on #Official - Incident Response. If they don't get acknowledgment from the Incident Response team within 10 minutes, they should escalate by contacting the Bixal Solutions Incident Response Team directly until they receive acknowledgment of their report.

The first participant on the Bixal Solutions Incident Response Team becomes the initial Incident Commander (IC) and carries out the next steps in the response. The IC's responsibility is coordination, not necessarily investigation. The IC's primary role is to guide the process. The first responder may remain IC throughout the process, or they may hand off IC duties later in the process.

The IC makes sure that the incident response process is followed, including supporting the reporter if the reporter already started it, or starting it if nobody has started it yet.

Comms at the Initiate phase#

Note that at this point the event's status is "investigating" — we haven't confirmed that it's really an issue yet. So, we should actually refer to this as just an "event" at this point; it doesn't become an "incident" until we've confirmed it.

To help with reporting, you may copy the following template into Teams to create the issue (replace ALL CAPS with pertinent details):

Short description of what's going on with SYSTEM

* *Status*: investigating
* *Severity*: unknown


The IC is responsible for keeping this issue up-to-date as investigation and remediation progresses. Everyone involved in the issue (responders) should leave notes as comments on the issue.


The next step is to assess the event. We need to answer two questions:

To answer these questions, the IC should form a response team by DM'ing people in Teams. The response team should work to confirm the event and assess its impact.

If the event turns out to be a false alarm, the IC should update the issue, setting the status to "false alarm", and closing the issue.

If the event is a valid incident, the team should assess its impact and determine an initial severity following the incident severity guide below. (Note that the severity can change over the lifespan of the incident, so it's OK to determine the initial severity fairly quickly.)

If a security incident is suspected, the IC ensures that system state is captured with disk snapshots, screen captures and any other mechanisms relevant to the system such that post-remedation forensic analysis is supported.

Once this is done, the IC should update the issue, noting:

The IC should assess whether to also activate the contingency plan.

At this point, the IC should write an initial situation report to Slack or other permament medium (GitHub, Bitbucket, JIRA, etc.) summarizing what's going on, identifying the IC, and linking to the issue. Here's an example sitrep:

Subject: [sitrep] The chickens are escaping

Severity: low
IC: Farmer Jane
Responders: Spot the Dog, Farmer Dave

We've confirmed reports of escaped chickens. Looks like a fox may have tunneled into the run. Dave is working to fix the fence, Spot is tracking the fox.

This sitrep should be posted in Ops Alerts (include link to incident issue/ticket if possible).

Comms at the Assess phase#

Updates and real-time chat should continue as above (chat/video in Teams).


At this point, we're trying to fix the issue! Remediation will be very situation-specific, so specific steps are hard to suggest. However, a few guidelines to follow during this process:

Once the incident is no longer active — i.e. the breach has been contained, the issue has been fixed, etc. — the IC should spin down the incident. There may still be longer-term remediation needed, and possibly more investigation, but as long as the incident is no longer active these activities can proceed at the regular pace of business. To close out an incident, the IC should:

Comms at the Remediate phase#


The final step in handling a security incident is figuring out what we learned. The IC (or one of the ICs if there were multiple, or a designated other party) should lead a retrospective and develop an incident report.

The report should contain:

The cause analysis is an important part of this report; the team should use tools such as Infinite Hows or Five Whys to try to dig into causes, how future incidents could be prevented, how responses could be better in the future, etc.

The report should also contain some basic response metrics:

This report should be posted as a final comment on the issue, emailed which can then be closed.

Incident Severities#

Note that most Bixal Solutions' systems no High Value Assets (HVAs) or Sensitive Personally Identifiable Information (SPII). As such, system incidents are generally expected to fall into the Low Severity bucket.

Severity ratings drive the actions of the response team. Below are the severities ratings we use, some examples of incidents that might fall into that bucket, and some guidelines for ICs and response teams about how to treat each class of incident.

Note the severities may (and often will) change during the lifecycle of the incident. That's normal.

1 - High Severity#

High-severity incidents successfully compromise the confidentiality/integrity of Sensitive Personally Identifiable Information (SPII), impact the availability of services for a large number of customers, or have significant financial impact. Examples include:

Guidelines for addressing High-sev issues:

2 - Medium Severity#

Medium-severity incidents represent attempts (possibly un- or not-yet-successful) at breaching PII, or those with limited availability/financial impact. Examples include:

Guidelines for addressing Medium-sev issues:

3 - Low Severity#

Low-sev incidents don't affect SPII, have little availability and no financial impact. Examples include:

Guidelines for addressing Low-sev issues:

How this document works#

This plan is most effective if all Bixal Solutions team members know about it, remember that it exists, have the ongoing opportunity to give input based on their expertise, and keep it up to date.

Edit on GitHub

Documentation built with MkDocs using a modified Windmill Dark theme