How to avoid headlines and thwart breaches with exposure management

In this article:

Several years ago, one of the largest banks in North America found itself under attack. Its cloud storage was breached in a chained exploit and the personal and financial information of more than 100 million customers was compromised. In the end, the breach cost the bank $250 million in cleanup costs, lawsuit settlements and regulatory penalties.

Ironically, the bank had done nearly everything right. Its cybersecurity posture was very good. It was seen as a pioneer in the financial industry for its embrace of new technologies, especially cloud computing. Once it learned of the data breach, it quickly and responsibly disclosed the details to its customers, shareholders and regulators.

The one thing the bank didn't do was anticipate the complex attack path that the attacker took. It failed to see that small weaknesses in its cloud security could be linked to small weaknesses in its identity security in a way that would provide access to sensitive customer information.

For more information:

Because its teams were siloed and their information was compartmentalized, the bank could not see its own complete attack surface from the attacker's point of view.

"Most breaches don't happen because of one glaring issue," wrote Hadar Landau, Product Marketing Manager at Tenable, in a recent blog post analyzing the data breach. "They happen when multiple, seemingly low-risk factors silently combine."

Today, enterprises with similar hybrid systems have the benefit of being able to deploy comprehensive exposure management platforms that can anticipate potential exploitation paths across the entire attack surface, breaking down silos and distributing information among all defenders.

These platforms can map out, analyze, assess and prioritize vulnerabilities, weaknesses and misconfigurations, giving security teams action plans for effective and timely remediation before an attacker strikes. Such all-encompassing proactive knowledge and efforts will greatly lessen your organization's chances of being in the headlines.

How the breach happened

The attack on the bank began with a misconfigured web application firewall (WAF). The attacker, who had detailed knowledge of the architecture of Amazon Web Services (AWS), had created their own tool to scan for misconfigured WAFs protecting AWS instances. (The bank described here was not the only organization attacked.)

The attacker then exploited that misconfiguration to send a malicious request to the bank's AWS metadata service, which granted an access token — temporary credentials — to information on the bank's Amazon Elastic Compute Cloud (EC2) assets.

It's not clear exactly what happened at this stage. Many analysts believe that a server-side request forgery (SSRF) — a malicious request that seems to come from an authorized user or service — was sent directly from the WAF. Others think that the request came from an application behind the WAF.

Amazon said it wasn't an SSRF at all, but instead a reverse proxy attack that the WAF misconfiguration made possible.

In any case, the misconfiguration let the attacker bypass the protections the WAF was meant to provide and send an access request to the identity provider.

Because the request came from the WAF or a closely associated application on the "safe" side of the WAF, the identity provider trusted the sender and granted the request. The attacker — which the metadata service assumed was the WAF or an authorized application — was given an access token for the bank's Amazon Simple Storage Service (S3) cloud repository of customer data.

That data was encrypted. But unfortunately, the same credentials that gave the attacker access to the S3 "bucket" also came with decryption keys for the data. The attacker was able to view all the files in directories in the repository.

They then copied the customer details, which included names, dates of birth, street addresses, U.S. Social Security and Canadian Social Insurance numbers, bank account information, and credit reports, to their own systems.

Four months passed. The bank had no idea anything had happened. Whatever alerts may have come up as the attacker moved through the bank's cloud assets seem to have been dismissed.

"The issue wasn't a lack of alerts," wrote Landau. "It was a lack of context. Without the technical insight to understand how the assets were connected — or the business perspective to recognize that the path led directly to sensitive data — no one could see how the pieces fit together."

The breach might have gone entirely unnoticed were it not for the attacker's loose lips. They boasted of the breach and its data yield in an online forum, and another forum participant then sent the information to the bank's vulnerability-reporting email address. The attacker was quickly caught, tried and found guilty.

What went wrong here

So where did the bank make mistakes? In an academic paper following the attack, researchers from the Massachusetts Institute of Technology listed six different errors:

To this, we can add:

"This attack was successful, not because of its novelty, but because of a number of control failures at various levels of the organization, any one of which, if adequately enforced, would have been able to prevent the attack or at the very least would have been able to limit the scale of the breach," wrote the paper's authors. "Had it not been for this event, something else would have likely resulted in a similar outcome."

An exposure-management platform could have provided greater visibility by proactively connecting the dots between the individual weaknesses — the firewall misconfiguration, the SSRF/reverse-proxy vulnerability, and the over-permissioned access tokens/roles, none of which may have seemed like high priorities on their own.

More succinctly, exposure management would have provided the attacker's point of view, which would have made the attack path more apparent to defenders.

"When you assess risk in isolation, without understanding how different asset types or seemingly unrelated weaknesses can connect, it's almost impossible to see how attackers can actually move through your environment," wrote Tenable's Landau. "This siloed approach creates major blind spots when it comes to understanding real risk exposure."

Or, as the MIT study authors put it, "our most important recommendation is that organizations must think of security as a system problem, focusing not only on security of individual components, but also those vulnerabilities that emerge from interactions between components such as latent flaws resulting from poor organizational structures and missing informational feedbacks."