For most organizations, the security of their database is of paramount importance. Deploying a data security solution is an important first step in protecting sensitive data from unauthorized access or exfiltration.
However, a new feature in Microsoft SQL Server 2019 presents another threat to data security. SQL Data Discovery and Classification (DDC) makes it easier for attackers to identify sensitive data for exfiltration.
What is SQL Data Discovery and Classification?
SQL Data Discovery and Classification is a feature in Microsoft SQL Server 2019. The purpose of this feature is to make it easier for users of Microsoft SQL Server 2019 to manage data classification within their databases.
The classification process starts with SQL DDC performing a scan of the database and identifying columns within the tables that could contain sensitive data (i.e. data that matches patterns like phone numbers or Social Security Numbers (SSNs)). A list of these columns is provided to the user who can then manually set the classification for each of these columns.
Classification of data within a database is useful for a variety of different purposes. Since columns marked as sensitive are included in audit logging, it is easier for database owners to track attempts to access or modify the data in these columns. This is a valuable feature for security monitoring and compliance reporting. However, the details of how SQL DDC works can also make it a valuable tool for an attacker.
Abusing SQL DDC
Applying classification information to data is valuable for compliance and reporting purposes. However, the way that SQL DDC performs this makes it easier for a compromised account to learn which data is considered sensitive.
Cybersecurity best practices include the principles of “separation of duties” and “least privilege”. Separation of duties is focused on ensuring that an organization’s security policies and controls have no single point of failure by breaking up duties over multiple parties. If multiple accounts need to be compromised for a security incident to occur, then it is harder for a cybercriminal or malicious insider to pull one off.
The problem with SQL DDC is that it does not follow the principle of separation of duties. The concept of labeling data within a database as sensitive or not is nothing new, a variety of different tools implement this functionality.
What SQL DDC does differently is that it labels data as sensitive or not within the database itself. Typically, the process of identifying and labeling columns containing sensitive data is performed by security staff and application owners outside of the database. This practice keeps database administrators (DBAs) out of the loop, implementing separation of duties.
With SQL DDC, sensitivity labeling is performed within the database, allowing DBAs access to classification information. As a result, a user with the appropriate permissions within the database can see which data is considered sensitive or even alter the sensitivity classifications of this data. These both help to make theft of sensitive data easier since it is no longer possible to scan the database for sensitive data and because altering classifications may disable built-in security protections.
Implications of SQL DDC
In most scenarios, giving the database administrator access to sensitivity information regarding information in the database doesn’t seem like that big of a deal. Since the administrator is already a member of the organization and is entrusted with power on the organization’s network, a little more power shouldn’t be an issue. Malicious insiders are a relatively uncommon cause of data breaches and other cybersecurity incidents.
That said, employee negligence is one of the biggest causes of data breaches and other incidents. While a user may not intentionally try to cause damage or exfiltrate sensitive data, they may be tricked into doing so by a cybercriminal. This is where the principle of least privilege becomes important. Least privilege states that users should have access to the permissions necessary to do their jobs and no more.
Database administrators need to have high-level permissions to perform their core duties. However, least privilege should also be applied to each set of duties that a user has. The database administrator doesn’t need high-level permissions to check their email, and phishing emails are a leading cause of account compromise. If the database administrator uses the same account to check emails and work on the database and the database is using SQL DDC, then cybercriminals have another potential vector to find and exfiltrate sensitive data from an organization’s databases.
Securing SQL Databases
The vulnerability created by SQL DDC allows an unauthorized user to gain access to the sensitivity classifications of data within a database. This vulnerability can be significant since it helps an attacker to identify the data that they should attempt to exfiltrate from an organization while remaining stealthier.
The vulnerability is created by a failure to properly follow the cybersecurity principles of separation of duties and least privilege. By giving the database administrator access to these classifications, an organization makes it possible that a single account compromise will enable an attacker to steal sensitive data.
However, this vulnerability can be easily mitigated by following these same principles. Even while using SQL DDC, an organization can mitigate this threat by ensuring that database administrators do not have the permissions necessary to view sensitivity classifications.
Beyond these simple steps, organizations should have defenses in place to ensure that data cannot be exfiltrated from their network. A data security solution detects sensitive data within the organization and monitors access to detect attempted data exfiltration.
Kidal Delonix is a contributor to Mr. Hoffman's blog. The views and opinions are entirely his/her own and may not reflect Mr Hoffman's views.
