Sensitive Data Exfiltration and the Insider

Traditional security is designed to keep outsiders from getting in. What happens when the enemy is an insider? A new paradigm must be explored, where the focus needs to shift inward and how data is going outbound.

Identifying anomalies in data exfiltration is critical to how to spot the insider. The insider has a typical lifecycle:

1. Identify places where sensitive data is store
2. Retrieve the data from the location
3. Move the data within the organization to prepare for exfiltration
4. Transfer the data outside the organization

Arguably, the weak points of this chain of events occur in steps 1, 2, and 4, where the insider must go through funnel points—near the data and at a public outbound connection.

Things to Look For

In almost all cases of data theft, the insider had access to the data, but in many cases, the insider’s role would have been suspect when considering the data they were accessing. Consequently, role should be examined for the end user in the context of data they are accessing.

In step 1, the insider is attempting to identify servers, and locations within servers such as databases, where sensitive information may reside. This process often involves steps that can stand out from regular traffic, even for the most careful insider.

Some of these anomalies include the insider attempting to identify which stores he has access to on a database without setting off alarms. SQL interrogations may involve actions such as SHOW TABLES and SHOW COLUMNS.

This helps the insider spot sensitive data. When compared against the user’s context this may set off alarms. Because the insider will know a trail will be left by trying to access data that is not authorized, the insider will attempt privilege examinations such as by issuing GRANT in SQL.

This type of examination for anomalies close to the sensitive data source provides a funnel point for concentrated analysis. Combining analysis with context (role, location, time, etc.), will enhance the resolution and reduce the time to discovery. A useful tool for contextual information such as role and location is Cisco ISE that can be leveraged via the PxGRID API.

A study by N. J. Percoco, Data exfiltration: How Data Gets Out, reviewed 400 data exfiltrations and identified the following as the top methods for data exfiltration:

Examining these data types for anomalous behaviors on outbound traffic could provide another powerful tool to observe data leaking. While deep packet analysis may help us observe SQL queries for data close to the source, we cannot rely on traditional deep packet inspection for outbound traffic to see packages of sensitive data because they are often in .zip, .rar, or other obscuring formats.

Mitigation

Cisco has a tool chest to help in this fight, such as Cisco Identity Services Engine (ISE) that can provide context for the traffic (role). Also, as users move to new positions access privileges should be adjusted.

The following link describes PxGrid for use with Cisco ISE to extract data:

An Achilles’ heel for many of these exfiltration attempts is that many rely on DNS. The Cisco Custom Threat Intelligence service provides analysis of DNS activity to identify suspicious DNS events. This report can identify if outbound requests are being sent to known malicious upload sites, and concealment of outbound activity by calling on services such as TOR, in addition to other interesting, and potentially dangerous outbound calls.

Sourcefire provides an essential set of tools to add to the effort. Sourcefire can baseline these and place them into whitelists, any new services trip alarms; can use exiting rules and write targeted ones to identify SQL that shouldn’t be occurring; custom rules to also enforce query parameters and block things like SHOW TABLES, SELECT *, GRANT, INTO TEMP, etc.; and can control file movement by role and type. Also, Sourcefire can create Policy and Response configuration for the assets that trip these rules to either instruct an FPC system to keep the full packet captures or to enable connection logging for the assets in question.

Some of the individuals posting to this site, including the moderators, work for Cisco Systems. Opinions expressed here and in any corresponding comments are the personal opinions of the original authors, not of Cisco. The content is provided for informational purposes only and is not meant to be an endorsement or representation by Cisco or any other party. This site is available to the public. No information you consider confidential should be posted to this site. By posting you agree to be solely responsible for the content of all information you contribute, link to, or otherwise upload to the Website and release Cisco from any liability related to your use of the Website. You also grant to Cisco a worldwide, perpetual, irrevocable, royalty-free and fully-paid, transferable (including rights to sublicense) right to exercise all copyright, publicity, and moral rights with respect to any original content you provide. The comments are moderated. Comments will appear as soon as they are approved by the moderator.