Action Item 1

Create a Checklist

What systems are impacted? What data is impacted? What methods can you use to contain the situation? What impact will these methods have on:

• Normal business operations
• Protecting exfiltration of data
• Preservation of evidence

These lists then become part of the incident documentation and should be updated as the incident progresses.

---

Action Item 2

Document all activities

Maintain a record of all actions taken and the time they occurred. This is especially important when taking actions that may impact evidence. It’s also useful when it comes to restoring systems and determining which systems may still be at risk. Records should be maintained on systems that are not accessible.

---

Action Item 3

Back Up!

Production systems and data should be backed up before changes are made. This policy especially applies to malware. Even if anti-virus software is reporting a file as being a particular variant, it is likely that there is additional information to be collected from malicious files, including IP addresses of command and control servers, links to other malicious payloads and timeline data. It is also possible that any malware identified as one type by anti-virus software may be a variant of a family with different or additional behavior and capabilities.

---

Action Item 4

Triangulate Platform & Systems at Risk

Once an incident has been identified, systems immediately affected are easily identified. You should also consider how those systems interact with the rest of the network, what information may be on them, and how that information could enable an attacker to pivot to other systems. This information ranges from system and application settings (e.g., trust relationships, account credentials, APIs) to intelligence (e.g., standard email templates, network diagrams, organization charts). Attackers use many methods to exploit compromised systems and gain access to other systems and data in the environment.

---

Action Item 5

Contain & Sustain

Once you know systems at risk and have some understanding of the breach you can determine the most effective method of protecting your systems and data. You should keep in mind that containment is a short-term approach designed to “stop the bleeding”. Some containment actions may only be in place for long enough to allow you to implement more comprehensive solutions. For example, taking the entire network offline while reviewing and updating firewall rules. When implementing containment actions consider the impact to production systems and potential evidence.

---

Action Item 6

Data Breach Notification Law obligations

Breach notification requirements vary significantly from one legal jurisdiction to another. You should consider both the location in which the breach has occurred and the location of anyone whose data is at risk. In some cases (e.g., the EU) even if your systems are not located in that jurisdiction if personal information of people within that region is affected you are still required to notify them. You need to consider both state and federal laws and business relationships in conjunction with the type of data at risk. For example, different rules apply to credit card data versus medical information.

---

Action Item 7

Lawyer Up!

One method of being confident that you are complying with legal obligations is to engage a legal firm that specializes in cyber breach law.  GM Sectec has a preferred list of leading law firms we work with regularly.

---

Action Item 8

Notify!

In addition to any legal requirements to notify your impacted parties, consider how the incident and containment actions will influence your users and partners. Are there any immediate effects that they should be aware of? Is there a risk of partner systems being impacted? Are there actions that your users should be taking that will help contain the breach?