Experiencing a
Security Breach?

STEP 1: Make a plan

Actions taken at the beginning of a breach can have a significant effect on the outcome.
At this point you have two priorities:

• Prevent or minimize impact to normal operations
• Ensure that sensitive data is protected

To do this effectively you must identify what systems and data are at risk and how the attacker’s actions can be blocked (containment). Unfortunately, actions taken to contain the situation are likely to destroy or compromise evidence, limiting your ability to identify other affected systems, determine how the compromise occurred in the first place or what data has been impacted.

We recommend that you start by creating several lists:

1. What systems are impacted?
2. What data is impacted?
3. What methods can you use to contain the situation?
4. What impact will these methods have on:
   1. Normal business operations
   2. Protecting exfiltration of data
   3. Preservation of evidence

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

 

 

STEP 2: Document Everything

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.

 

 

STEP 3: Make Copies

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.

Look for help from your emergency responders. The Trustwave SpiderLabs DFIR team has full-time malware reversing consultants who live to pull these things apart!

 

 

STEP 4: Identify 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.

Our experience shows that in most cases, people under-estimate the extent of systems and data at risk. A complete forensic examination is needed to determine which systems and data the attacker has had access. At this stage you are operating with incomplete information and it is safer to assume the worst rather than being optimistic.

 

 

STEP 5: Implement Containment

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. Think as broadly as possible. Common containment actions include:

1. Removing compromised systems from the network. Unless data is actively being destroyed (e.g., in the case of ransomware), keep systems powered on so that a copy of memory and other volatile data can be collected to accelerate the investigation.
2. Updating firewall rules. If a compromised system has been identified communicating with suspicious systems, it is a good idea to block those systems from the entire network. Continue to log any attempted connections to or from the suspect IPs.
3. Disabling accounts and updating passwords. If user or application accounts have been compromised or are at risk, the accounts should at a minimum have their passwords changed.
4. Update anti-virus software rules. Ensure that you have current updates pushed out to your AV agents and submit a sample of any malware to your AV vendor.
5. Block known malicious executables. If you have EDR software in place (you probably don’t need this list) update your ruleset with the malware hash and alert on the executable name, and associated IOCs.
6. Delete files, records and emails created by the attacker (after taking a backup). This action ensures other users do not fall victim to the same attack. Whether it is a phishing email, data dumped on a file share, or accounts that have been created by the attacker all this should be deleted as soon as possible. Once again though, we cannot emphasis how important it is to create copies and records of everything prior to deletion!
7. Apply security patches. While this may appear to be closing the door after the horse has bolted it will help to prevent any additional systems from being exploited.
8. Restore systems from backup. Provided you can determine when the breach started it may be practical to restore compromised systems from a known good backup. Be sure to address the vulnerabilities that enabled the attack before putting the system back online. Also, create backups of the compromised systems before you wipe them. Or better yet remove the hard drives for later analysis.

 

 

STEP 6: Review Breach Notification Requirements in Your Jurisdiction

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.

 

 

STEP 7: Consider Legal Counsel

One method of being confident that you are complying with legal obligations is to engage a legal firm that specializes in cyber breach law. Trustwave can provide referrals to firms we work with on a regular basis.

 

 

STEP 8: Notify Stakeholders

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?