Today, organizations rely heavily on data, with a big portion of that data made up of sensitive information. As organizations become the custodians of more and more sensitive information, the frequency of data breaches increases accordingly. In some cases, the origin of a data breach is outside of the organization, with hackers succeeding in evading organizations by compromising accounts; while in other cases, data breaches involve internal actors – malicious employees or contractors who intend to harm the organization and who may have legitimate credentials.
According to the 2018 Verizon Data Breach Investigations Report (DBIR), the top asset involved in data breaches is the database server (see figure 1). This is not surprising since large volumes of sensitive data are stored in databases, which is why database security is such a crucial factor.
The thing is, rather than trying to prevent a data breach, a more realistic goal would be to detect a breach at an early stage. The reason why early breach detection is more practical than breach prevention is that often times, malicious users are already inside the organization, abusing their legitimate permissions to access sensitive data. To quickly detect a potential data breach, we need to be able to identify “early signs” of a breach. The alternative is months or even years of trying to detect a data breach.
The data breach kill chain
Back in 2011, Lockheed Martin defined The Cyber Kill Chain as a model for the identification and prevention of cyber intrusion attacks. It defines the steps taken by an attacker during a typical cyber-attack (Figure 2).
The seven steps of the cyber kill chain are as follow:
- Reconnaissance – Get as much information as possible about the target, choose your target.
- Weaponization – Choose the best tool for the task.
- Delivery – Launch an attack using weaponized bundle on the target.
- Exploitation – Exploiting the vulnerability to execute code in the victim’s system.
- Installation – Install weapon access point
- Command and Control (C&C) – Enable sending remote commands for persistent access to a target network.
- Actions on Objective – Take action. For example: data destruction, exfiltration or encryption.
We’ve adjusted the cyber kill chain to suit data breaches specifically, presenting an instance where the attacker is already inside the organization/already has access (figure 3).
Having been recruited or accidentally infected — compromised by an external hacker –, the attacker continues to the reconnaissance stage; this stage is similar to the reconnaissance stage in the original cyber kill chain, and the goal is to gain as much information about the data or the assets that hold the data (think permissions, structure etc.) as possible. After choosing the target and getting enough information, the attacker will try to obtain access to the data – in the exploitation stage. This could be achieved by escalating its privileges. Once access is granted, an attacker will try to acquire sensitive data. This stage could be a large file download or specific access to sensitive data. The last step will be exfiltrating the data from the organization.
Protect data in your databases: Defense-in-depth
The principle of defense-in-depth is that layered security improves your overall security posture. If an attack causes one security mechanism to fail, other mechanisms may still provide the necessary security to protect the system.
To better protect data in your databases, you need to identify suspicious activity at every step of the potential attack chain. That way, if we fail to detect the attack at a specific step, we’ll still have the chance to catch it in the following steps. It’s always best to uncover an attack as early as possible, preferably before malicious or compromised individuals obtain access to the data.
Imperva CounterBreach looks for suspicious database activities in each step of the kill chain to detect a data breach and uncover risky security practices that are likely to be exploited by attackers. For example, we look at specific events happening at different stages of the attack chain, such as failed logins, broad access to databases, service account abuse, and accessing business-critical data.
In the latest version of Imperva CounterBreach – V2.3 – a new algorithm that detects reconnaissance attacks was added. The algorithm uncovers suspicious system table access before any data gets exfiltrated.
Reconnaissance Stage: Suspicious system table scan
System tables store the metadata of the database. Those tables contain information about all the objects, data types, constraints, configuration options, available resources, information about valid users and their permissions and more. We expect attackers to access system tables as part of the reconnaissance stage of the attack in order to explore the databases in the organization, or even change database permissions. The challenge in detecting reconnaissance attacks using system tables access, with a minimum amount of false positive alerts, rests in the fact that legitimate users access system tables on a regular basis to perform their ad hoc tasks.
To perform this task successfully, Imperva CounterBreach combines machine learning logic with domain knowledge and correlates a host of sources and hints to form a holistic picture. Imperva CounterBreach distinguishes between access to sensitive system tables and access to non-sensitive system tables. This classification is taken from our database activity monitoring solution and is based on research conducted in the Imperva Defence Center.
Imperva CounterBreach utilizes a host of profiling cycles to study everyday access patterns to the different classes of system tables (as shown in figure 4). These cycles include:
- User normal activity – Learn how users typically behave and access system tables
- Database normal activity – Learn how users inside the organization access system tables in a certain database
- Organization normal activity – Learn how sensitive system tables are accessed across the entire domain
- Community normal activity – Use data of system tables access patterns from different customers, to have a knowledge of global normal system table activity
We also make use of other hints to identify legitimate access to sensitive tables, separating a legitimate user like DBA, from an attacker. Imperva Counterbreach identifies a malicious user by analyzing the number of databases they try to access system tables from, the number of failed logins to databases in the organization in the same time frame, and more.
Figure 5 shows a real example of 11 different interactive users from one of our customers. These 11 users comprise 10 DBAs and an attacker (‘E’ in the figure) who attacked the organization on the 16th and 17th. Different colors represent different users and the x-axes represent the different days. The top graph shows the number of databases each user accessed sensitive system tables in which are not normally used by his profiling circles. The bottom graph shows the number of databases that the user failed to log into in each day.
We can see that the attacker accessed new system tables in several databases on the days of the attack. Combining that information with the fact that they also failed to log into some databases on the days of the attack indicates a suspicious activity.
Attackers will continue to attempt to steal sensitive data from organizations, this is a given. Our goal is to detect potential breaches as early as possible before any actual harm is done or any sensitive data is exposed. Uncovering suspicious system table access is a critical step to catching attackers in the reconnaissance stage where they still try to find their way in. If an attack was not detected in the reconnaissance stage, Imperva CounterBreach can still identify anomalies along the data breach attack chain, using the defense-in-depth approach. With domain knowledge expertise and machine learning algorithms, this approach allows you to detect threats at all stages of a data breach.