What Does an Internal Attack Resulting in a Data Breach Look Like in Today’s Threat Landscape?

In my last blog, I explained why taking the approach of setting up perimeter defenses, restricting data access, patching vulnerabilities, applying sensors to data movement, and encrypting data is no longer solely effective at stopping data breaches in today’s threat landscape.

I also discussed the critical importance of early detection and the negative impact on an organization when an internally-generated security breach goes undetected. In this post, I’ll explain what a typical attack scenario looks like in today’s threat landscape (so you’ll know it when you see it) and discuss why your current best efforts may not be helping to solve the problem.

The anatomy of a typical internal attack

A common scenario is one in which an attacker gains access to an internal network via a compromised workstation that has been infected with malware, invariably via a social engineering email attack. No enterprise is immune to this type of insider attack. We all, at some point, took the bait and clicked unsolicited links masquerading as “Open Position” or “Mandatory Open Enrollment” or “Extra Floating Holiday”, etc.

Before I go on, let me say that while no organization is immune to this type of attack, there are things that a security team can do to make the organization a harder target like creating a simulated phishing attack. This exercise requires some preparation and planning, plus internal executive approval to move forward, but it’s worth it. Over time, as you roll out periodic phishing simulations, you should aim to show progress in the form of an increase in awareness about phishing and a wider knowledge of best practices across your organization.

This type of attack is so common because it’s relatively easy and proportionally problematic for the victim organization. Perimeter and endpoint security tools often do not detect this type of initial breach. Once the attacker has gained access to an internal network through the workstation of a privileged user, they begin their exhaustive hunt for a sensitive employee or customer data within company databases, that’s when the real damage can begin. The attack continues as the attacker performs scans across the internal network to identify the database host(s) attempting unwanted activity through the privileged account. Eventually, the attacker finds their targets, and they attempt to stay “slow and low” by only attempting to login to each data source once so as to not trigger any password brute force detections. This process can take an extended amount of time, but soon the attacker will have found a database that accepts the credentials. The hard part is now behind them, and from here on out it’s only a matter of time until they are able to learn the database schema to determine where the “crown jewels” are located. Finally, they determine a method of transmitting the loot to an undisclosed location to collect their prize in untraceable bitcoin.

In this scenario, the attacker would most certainly exfiltrate sensitive personal data without ever being detected. In general, there are three ways companies become aware of the breach; they are contacted by the attacker who demands a ransom, the attacker publicly discloses news of the breach, or customers report the issue because they have experienced identity theft as a result.

Two approaches to stopping internally-generated attacks (and where they go wrong)

What does a typical organization do to stop an attack that has all the markings of a legitimate user performing legitimate daily tasks?

One option is to acquire a toolset that allows you to craft detection rules at the database level. You may even have a “rockstar” incident handler who knows how to write the complicated correlations required to sniff out such an internal attack. Even then, there are two places where this type of solution breaks down:

First, most “rockstar” SOC teams don’t have a context or intimate knowledge of the data they are trying to protect. Additionally, if they contact the data owner there’s a good chance they don’t understand the data, either. Writing the complex correlations required to protect the data is impossible without this key information.

Second, while detection rules at the database level are complex, they are also static. Attackers, however, are not. It’s a constant challenge to write a static rule that doesn’t produce false positive results. As such, enterprise environments are simply too big, too dynamic, and far too transactional to continue playing this cat and mouse game.

Another option is to purchase an enterprise analytics tool to search for anomaly behaviors across all your data repositories that hold sensitive data. Then send all access logs from your data repositories to the analytics engine to detect policy-violating activity. While this approach initially sounds great, there are a couple of ways it breaks down, too.

While enterprise analytics tools function across the entire corporate estate, the saying “bigger isn’t necessarily better” comes to mind. Searching across all data repositories doesn’t provide you better visibility and detection. In fact a broader approach typically results in less detailed, less accurate detection and can be a potential sink of valuable FTE resources. These analytics tools typically search for common breach tactics across all technologies but fail to analyze at the data layer where the unique attack is happening. It misses the context and the domain expertise that a database analytics tool provides.

Now that we know what doesn’t work…

Read my next post in this series where we uncover and share the three principal functionalities your database security solution should provide in order to take on these threats effectively.