Mitigating the Impact of Third-Party Data Breaches: A Guide to Incident Response and Risk Management

Ever since the SolarWinds hack in 2020, more businesses are aware of the risks third parties bring into their own enterprise environment. Whether it’s third-party libraries integrated into their applications or a third-party platform used in business productivity, a data breach from one of these vendors can be just as devastating as a direct attack on your infrastructure. To make matters worse, your business continuity and data security relies on the third party’s ability to quickly detect a data breach and responsibly provide you with notification so that the vulnerability can be mitigated.

How Does a Third-Party Data Breach Happen?

Vulnerabilities introduced from a third-party vendor integration are numerous and depend on many factors, but generally a business is affected after a vendor’s own systems are compromised or a vendor has access to a business environment and falls victim to phishing or social engineering. These two events are not the only ways a supply chain attack happens, but they are primary incidents responsible for some of the largest third-party vendor-related data breaches.

What To Do If Your Vendor Announces a Data Breach

Ideally, you find out privately from the vendor when your company is involved, but some announcements come in the media or by way of a CVE (a CVE is a reference method for publicly known information security vulnerabilities and exposures)¹. Once it is published, attackers rush to build scripts and custom payloads to exploit known vulnerabilities. In more dangerous scenarios, announcements in a CVE include a proof of concept that can be used without any coding necessary.

Time is of the essence, so businesses must initiate incident response as quickly as possible. The efficiency of your response often depends on vendor cooperation and their own investigation information, but incident response should be done swiftly to reduce the risk of damage to your own business.

Here are some basic steps for guidance after a cyber incident is identified. Note that incident response is a highly stressful event, but detailed planning that lays out what must be done can help administrators to avoid mistakes so that they can quickly assess the issue and contain the threat.

Stage 1: Discovery and Internal Investigation

For many businesses, notification unfortunately comes from media reports. You might get an email message from the vendor, but regardless, an incident response plan should be initiated immediately after you hear of the event. In some scenarios, you can not wait to hear from the vendor and must immediately put the plan into action.

Initial response should include investigation into your own audit logs and any analytics programs. Here are a few items to check:

• Review your IDS/IPS systems, any log analysis tools, and SIEM reports for anomalies.
• Review monitoring tools that indicate privilege escalation or credential exfiltration.
• Review network monitoring tools for utilization anomalies.
• Assess the environment for any unauthorized software installations.
• Validate that antivirus across workstations and servers has not been disabled.

Stage 2: Determine Third-Party Risk and Extent of Breach

Stage 1 helps you find anomalies even when you have no information from the vendor, but in many ways you are still flying blind. Without vendor information, you could be wasting time looking at the wrong issues. Ideally, the vendor has some information about the breach that they can share but you might need to initiate contact and ask them to share information. It is also possible that the vendor is unaware of the extent of the breach.

Before you begin, you need to know the vendor, the affected application and the permission level the application has on your systems. Having the version of the application and how it is used in your organization is also useful, as well as if the vendor is a data processor or a data recipient. Effective third-party risk management is useful in these situations to get this information immediately without wasting time.

Next, you need to contact the vendor to find out as much information as possible so that you can then dig into your system logs to see the extent of how badly the vendor breach affects your systems.  When you contact the vendor, you need to find out:

• A time frame of when it began and when it was discovered;
• The type of breach;
• Whether or not ransomware was involved;
• If data was stolen, modified, or destroyed;
• How attackers gained access (e.g. Was it a phishing email, software vulnerability, exposed or weak password, or stolen credentials?);
• If access was gained via software vulnerability, what is the CVE reference and was the system patching up to date;
• If data was exfiltrated;
• If the logs captured the command and control server address.

You might not get all this information, but even asking these questions internally will help to speed up your own incident response. Investigations should include your own logs and monitoring tools, but with access to vendor information you can limit your queries and search to the timeframe, exploit, payload, or malware reported as the culprit.

Here are a few ways to further investigate using the vendor-supplied information:

• Time frame information can be used to limit query results on your logs and analytics, limiting the amount of information you must review.
• Using the type of vulnerability, check your logs for information that relates to the exploit. Any specific devices affected should also be scanned and reviewed.
• Check firewalls for traffic routed to known attacker-controlled outgoing IP addresses if you know the location for exfiltrated data. This can also be used to determine which devices are communicating with the external server.
• Monitor the dark web for any information related to your users, customers, account credentials, intellectual property, or sensitive data uniquely tied to your business. Third-party threat intelligence can help with this step.

If you follow NIST standards, you should have a centralized log management and alerting system where security analysts can collect and review information. Logs and event information should be collected from all security devices (e.g., firewalls), identity and access management (IAM) systems, VPNs, servers, endpoints, antivirus, antimalware, data loss prevention (DLP) tools, applications, and databases.

With a layered security plan, you can identify and stop a breach before data loss. To set up an incident response plan and create an environment where you can investigate quickly, it is critical that you have a team that can put together a strategy specifically tailored to your business. Meet with a subject matter expert today to get started on your incident response plan and learn what you need to do to limit damage from a data breach.

Sources

¹ https://www.cve.org/