Cisco Blogs

Sensitive Data Exfiltration and the Insider

- May 2, 2014 - 0 Comments

The Insider Lifecycle

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:

Native Remote Access Applications 27%
Microsoft Windows Network Shares 28%
Malware Capability: FTP 17%
Malware Capability: IRC 2%
Malware Capability: SMTP 4%
HTTP File Upload Site 1.5%
Native FTP Client 10%
SQL Injection 6%
Encrypted Backdoor <1%

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.


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.


1. Keep in mind the insider lifecycle. Tactic/Tools: YOU, the security professional.
2. Baseline data source access. Tactic/Tools: SQL baselining, Sourcefire, etc.
3. Baseline outbound traffic, with special notice to the top exfiltration traffic types. Tactic/Tools: Sourcefire, NetFlow, Lancope, etc.
4. Watch for anomalies from the baseline, with special attention to context. Tactic/Tools: Cisco ISE, Managed Threat Defense, Sourcefire, Lancope
5. Watch DNS behavior to spot exfiltration attempts. Tactic/Tools: Cisco Custom Threat intelligence Service


All comments in this blog are held for moderation. Your comment will not display until it has been approved

In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.