The importance of auditing the activities of privileged users on sensitive corporate systems is already well-known among CIOs and CISOs. The two main reasons for this rapidly expanding awareness are (1) the clear realization that most data breaches are perpetrated using authorized employee/vendor credentials, and (2) because numerous industry and regional regulations mandate it.
A particularly important segment of “privileged users” to watch closely are the organization’s database administrators (DBAs). DBAs hold the keys to the company’s most sensitive and critical data, such as customer lists, customers’ personally-identifiable information (PII), payment methods (such as bank account and credit card account details), financial transaction histories, sales lead pipelines, HR information and much more. Not only can DBAs view this data, but they usually have the privileges to alter or delete data that might be critical to the organization’s ongoing operations or legally-mandated reporting.
In most cases, breaches or vandalism of this data can be very costly to a company, including the direct costs of actual financial theft, defacement or destruction of data, forensics response, recovery losses, regulatory fines, legal fees and lawsuits. But financial cost is only part of the story: brand damage, erosion of customer confidence, loss of competitive advantage and declines in market value can also contribute to a company’s final damage assessment.
Therefore, it is critical that those responsible for security and regulatory compliance at their organization make it a priority to closely monitor the activities of DBAs on databases containing sensitive or regulated information.
Limitations of Built-in Auditing Solutions
Commercial database engines, such as Microsoft SQL Server and Oracle, contain internal logging mechanisms that log most database activity. However, organizations cannot permit themselves to rely exclusively on these built-in solutions because they are subject to the same exposure as the data they are ostensibly protecting: DBAs usually have full permissions on these databases and their configuration settings. In other words, DBAs can change the database logging settings at will. For example, they can disable logging just before performing unauthorized activities, or they can configure the logging to filter out their own activities. Furthermore, they can even manipulate the log records themselves after the fact, to ensure that their nefarious activities will not be discovered there.
This is exactly what happened in the case of a large consumer financial institution that was hit a few months ago by a malicious internal user. The employee, who worked in the company as a DBA, collected a wealth of sensitive information to which he had access in his role. In preparation for leaving the company, he spent months exporting valuable data, which included customer PII and credit card details. After leaving the company, he attempted to blackmail the company, asking for several million dollars under the threat that he would otherwise sell the pilfered information to the highest bidder on a darknet.
Fortunately, after the company alerted law enforcement, authorities cooperating across multiple countries were able to track down the former employee, who had relocated overseas, and have him arrested before any data was sold to a third party. However, this incident highlights the dangers involved – and the fact that the company had no idea, until receiving the blackmail request, that so much data had been stolen by an insider. Also, the company suffered a tarnished reputation and reduced customer confidence.
The Right Way to Audit your DBAs
User Activity Monitoring software specializes in recording and auditing all user activity on company computers. Because of the massive DBA risk, the best User Activity Monitoring systems include feature-sets dedicated to tracking and auditing DBA activity in sophisticated ways.
For example, Proofpoint's DBA Activity Audit feature records and analyzes every SQL query executed by DBAs against production databases. Security administrators can review all SQL queries performed on a given date, or filter results by database, DB user, server, login ID or even any text contained within the queries. SQL queries are also included in the session activity details displayed in the system’s Server Diary and User Diary. Additionally, security admins can search for, and generate reports on, specific text matches within SQL queries, such as the names of particularly sensitive data tables or fields, and SQL commands that are unusual or potentially dangerous.
Perhaps most importantly, security administrators can define rules that will generate alerts based on specific combinations of SQL command, data affected, computer accessed and user ID. By implementing a set of alert rules for the most sensitive data and SQL commands, security administrators can ensure that they are instantly made aware of any suspicious or problematic database access.
DBAs do not have access to the Proofpoint management console, so that they cannot alter recording policies to prevent their own activities from being recorded. Sophisticated data integrity checks are also included so that security teams will know if any of the recorded data has been tampered with.
Here is what a DBA Activity Audit looks like in Proofpoint ITM. In this view, all the queries executed against a particular database are shown. The user can click one button to see the complete details of a query and another button to launch video playback of the DBA’s screen while executing the query:
Try it Yourself!
There is nothing like experiencing the value of User Activity Monitoring in your own environment. Get a free 15-day trial of the full-featured Proofpoint ITM Enterprise, and see how easy it is to track everything your DBAs are doing. After your trial, purchase the solution or keep Proofpoint ITM Lite, free forever. Try it now!
Subscribe to the Proofpoint Blog