According to research done by the Ponemon Institute, third-parties are involved in over half of the data breaches in the US and a third-party breach costs, on average, twice what a normal breach costs. Considering the impact to brand reputation, loss in business, and possible decreases in share value, the overall cost of failing to effectively vet and evaluate third parties is about $13 million.
At CyberGRX we are hyper-focused on the information risks and cyber risks present in the third-party ecosystem. As a result, we have better than usual insight into how third-party breaches occur and how to prevent a data breach from happening. In this blog, I would like to share some of that insight with you so that you can better understand the attack vectors used in third-party breaches, and be able to determine how to protect yourself against a breach of information associated with a third-party.
The following example is an amalgamation of details from multiple third-party breaches. As such, this is a representation of a third-party breach but isn’t associated with any one organization. All the events, however, actually have occurred.
Before the Breach
This is a representation of the security disposition of an organization prior to a third-party breach.
As you can see, a vendor would connect to the organization’s dedicated vendor environment (normally over VPN) using credentials to traverse a firewall and other network security tools. From the dedicated vendor environment, the vendor can only access resources attached to the vendor environment, and not resources on other segments of the network. The resources attached to the vendor environment are up to date and protected by local security tools like antivirus.
As far as a high-level security architecture goes, this is actually pretty good. Presumably, an intruder cannot get past the firewall, and a malicious person with vendor credentials cannot mess up more than the systems to which they have access to their network partition. Because the local systems are running up-to-date protections, it should be hard for an attacker to subvert them. Let’s see what happens when a hacker gets involved.
A hacker may target many vendors of an organization to try to gain access to a company’s network. While the hacker strikes out with a number of vendors, she manages to steal credentials from one vendor, most likely through phishing.
Now that the hacker has vendor credentials to the organization’s network, it is much easier for the hacker to bypass the firewall and network defenses, eventually landing with legitimate seeming access on the vendor network.
Using the vendor network as a starting position, the hacker then subverts the protections of the organization’s systems attached to the vendor network using a zero-day exploit she found on the dark web. Zero-day exploits are exploits that take advantage of vulnerabilities in systems that the system designers haven’t yet found. Because a zero-day exploit was used, the systems on the vendor network have not been patched or updated against the tool the hacker used. Using the zero-day exploit, the hacker is able to infect the systems on the vendor network with a memory scraper that sends the content of the system’s memory back to her.
Unfortunately, an infected system was used to process credit cards, and the memory contents that were sent to the hacker contained personal information and payment card information from the organization’s point of sale systems. The hacker then sells this personal information and credit card data on the dark web. She will maintain this breach as long as she can, hoping to infect other systems to maximize her footprint as well as install backdoors on systems to preserve her access to the systems.
What Went Wrong?
At CyberGRX, we use attack kill chains like the one I just presented to understand what your organization can do to protect itself from third-party breaches as well as what you can ask your third-parties to do to protect themselves and you from breaches. Let’s dive into this breach and see where security personnel should have paid attention prior to the breach.
Vendor Credential Management and Employee Training
The hacker was able to retrieve vendor credentials directly from the vendor. This weakness could have been predicted and mitigated in a number of ways. First, the organization should have determined that the vendor, who had access to highly sensitive production data, should have had multiple methods of authentication established to reach its vendor network segment. This would prevent the hacker from accessing the system. Even if the Hacker was able to steal the username and password that the vendor used to access the vendor network, an additional factor for authentication is generally much harder to steal and would have made it much harder for her to gain access.
Additionally, the organization should have made sure their vendor had adequate phishing testing and training. Phishing is one of the most effective ways to steal credentials and having ongoing phishing training is among the best ways to minimize the ability of the hacker to steal credentials from the vendor.
Network Based Defense in Depth and Deep Packet Inspection
Once the hacker breached the vendor environment and compromised the systems with a zero-day, she should not have been able to remove information from the system due to in-depth network security controls. Properly configured, a firewall (or firewalls) will decrypt any encrypted packet and block it based on a number of rules.
While command and control communication into the network may look innocuous, a large amount of outgoing data should have sounded alarms and triggered the firewalls to block data from the outgoing sources. Organizations would be wise to establish multiple layers of firewalls and pay equal attention to both incoming and outgoing traffic.
You Connected What to Where?
I think the one factor that turned the breach from a nuisance to a crisis was that the organization had active payment card systems attached to systems on a vendor network. While vendors may need to access payment card systems to modify or maintain them, they should be scrubbed of sensitive data prior to a vendor accessing them. Even if you trust the vendor, having sensitive data on a vendor network opens up the possibility that someone besides the vendor will also access the sensitive data.
Consider the segments of your network zones of trust. Make sure you don’t attach sensitive systems or data to low trust zones and make sure your vendors are only able to access the network segments that give them the bare minimum exposure to data and access to systems they need to do their job.
CyberGRX Can Help
Thank you for reading this analysis of a third-party data breach. There are a lot of nuances when examining breaches for lessons learned, particularly when you extend them outside your organization to your third parties. Thankfully, CyberGRX can help. We incorporate kill chain analysis into our Exchange to provide you with a more complete understanding of what you and your third-parties can do to keep each other safe. Contact us to learn more about how to prevent data breaches with the CyberGRX Exchange.