In most previous newsletters, we have discussed the use of logging for various regulatory mandates (such as PCI DSS, HIPAA and FISMA) as well as the use of logs for incident response and malicious software tracking. This log data can also be incredibly useful for detecting and investigating insider abuse and internal attacks.
While comprehensive coverage of insider abuse tracking goes much beyond this article, it was important to note that we will focus mostly on enabling investigations to determine the scope and breadth of insider abuse. Although detecting broad categories of insider attacks in real-time will likely remain elusive for years to come, logs will still play a critical role in detecting and stopping this problem. In fact, according to the 2010 Verizon Data Breach Investigations Report, 86% of those affected by an attack of some sort had evidence of the breach in their log files. However, many other technical and policy safeguards will be required to have a chance of actually thwarting an insider attack “in the act”.
There is no need to provide motivation for insider attack investigation and tracking. While malicious hackers from remote countries may damage your business and incur losses, trusted employee “going rogue” have a better chance of actually destroying your business and causing irreparable losses. Moreover, this trend will continue as more critical business information is created and utilized in digital form. Costs of insider investigations, especially when abuse has been ongoing for months or years, are known to cost much more than malware or other external attacks.
On top of this, there is no single piece of technology or policy that can reliably detect insider attacks as they are happening. Technical controls, access controls based on a well-written security policy, employee monitoring—these all have met with varying degrees of success yet none of them on their own create airtight insider security within an organization, or even guarantee detection of all insider attacks in time. Thus, insider defenses will fail, and accountability in the form of logging will be the only effective weapon, remaining in your arsenal.
There is a way to track insider activity— authorized or not—to provide a continuous fingerprint of everything that happens within the security perimeter. All users, whether trusted and non-malicious or malicious, leave traces of their activity in logs. If an employee opens a file that they need to use to finish a report during the workday, there is a log of this activity. Likewise, if someone accesses a database and downloads data after business hours, there is a log of that activity as well.
So, let’s review how various types of logs can be used for detecting and investigating insider attacks, as defined above.
We will go through a few common types of logs and illustrate how they can help in the discovery and investigation of insider-related incidents.
Firewall logs are often considered to external threats and not “insider-focused.”
Still, these logs are often extremely helpful as a proof of network connectivity by systems under control of malicious insiders. They directly help answer the questions such as “Where did the data go?”, “Who connected to the target system and who didn’t?”, “How many bytes were transferred out?” etc. These are critical during any insider investigation. Of course, the usual assumption is that logging of accepted connections through the firewall needs to be enabled. Overall, firewall logs, while extremely voluminous, provide a useful way to track insider activities on the network in the absence of more robust network monitoring tools.
Next is the favorite of security personnel: network IDS and IPS logs. IDS’s are supposed to be detecting intrusions, but they certainly won’t accomplish that for most cases of insider attacks. However, IDS’s will likely record various suspicious things that might be occurring during the incident. For example, IDS/IPS logs may contain the records of access to administrator accounts of systems and applications, outbound malware connectivity (for cases where insiders use malware to do their bidding) and other events of note. Overall, IDS logs are much less useful for insider attacks compared to regular hacker or external attacks. Still, IDS logging should not be discounted and can be used as a set of mildly suspicious indicators to be correlated with other data sources, such as system and application logs that record activities, not attacks.
Server logs, such as those from Unix, Linux, or Windows truly shine in cases of insider incident investigations. Given that an attack or abuse might not involve ANY network access and happen purely on the same system (with attackers using the console to use the system), server and application logs shed the most light on the situation. However, just as with firewall logs, these don’t talk of “attacks” and “exploits” but of activities, which are not inherently good or bad. As we mentioned before in our compliance newsletters, relevant logged activities on a server include login success/failure, account creation, account deletion, account settings and password changes, various group policy and registry changes as well as file access (read/change/delete). While these logs maybe also be created in bulk, having this data allows one to recreate the “insider path” within your environment.
Overall, server logs provide a key piece of the puzzle for investigating insider attacks. File access logs are probably more insightful than the rest of the log types above since they give granular information on information accessed by the computer users (in many cases, inside attackers will be after valuable data), but such logs are usually created in much larger volume than other server or desktop logs.
Another enlightening source of log data for insider abuse is VPN logs. In a few known cases, an employee or an ex-employee was engaging in nefarious activities from home after work hours, thereby creating a detailed and incriminating trail of their activity — if only the target organization would care to look at remote access logs! VPN logs might also contain references to resources accessed within the company as well as evidence of application use over the VPN. As with system logs, network logins and logouts are also useful during insider-related investigations. Some of the useful VPN log messages are remote login success/failure, session logout, as well as connection session length and the number of bytes moved from the corporate environment to the outside. Overall, VPN logs are indispensable for cases where a trusted insider committed his misdeed while “working” from home.
Somewhat unusual for insider investigation, web proxy logs are also useful for cases where the information was stolen or leaked over the web. Proxy logs can reveal the activities such as connection to a specific website (including file uploads), webmail access (including attachments), several types of HTTP tunneling for data theft and various malware activities. Overall, web proxy logs are extremely useful when the suspected insider was using the company connection for data theft or other network abuse, including e-mailing the confidential information out, or using tunneling over HTTP protocol. However, as with network IDS’s, the use of encryption decreases the utility of such network logs.
As we move higher up the stack, database logs and audit trails begin to come into play. These logs are less frequently collected and analyzed, but usually prove very enlightening in cases related to data theft and unauthorized access. Databases can log a dizzying array of different messages such as database data access (SELECT and other SQL queries), data changes, database structure and configuration change, and database starts, stops, and other administration tasks.
Overall, database logs are useful for investigating attacks where database data theft, access, change, or destruction were involved. Such logs are very detailed and can help piece together what information was gathered. They can also be used for various types of anomaly detection to find “out of character” behavior (sometimes associated with insider abuse). In addition, database logs are the sole source of information on Database Administrator (DBA) activities– and DBA’s can never “go rogue,” now, can they…?
Insider threat will remain a primary information security risk for the foreseeable future. A number of diverse factors (technical, administrative, psychological) contributing to the problem makes it one of toughest challenges in information security. In addition, combined with a high potential financial and reputation loss, it deserves more attention than it is currently given. Analysis of log data from a variety of sources (firewalls, routers, servers, applications, operating systems, network devices, etc.) is essential to tracking insider activity as well as investigating, detecting, or even predicting and preventing insider attacks. Centralized log collection and subsequent analysis (via pattern matching, correlation, or anomaly detection) of all logs and audit trails is of crucial importance.
-Dr. Anton Chuvakin
Security Warrior Consulting
Dr. Anton Chuvakin (http://www.chuvakin.org) is a recognized security expert in the field of log management and PCI DSS compliance. He is an author of books “Security Warrior” and “PCI Compliance” and a contributor to “Know Your Enemy II”, “Information Security Management Handbook”; he is now working on a book about computer logs. Anton has published dozens of papers on log management, correlation, data analysis, PCI DSS, security management (see list www.info-secure.org) . His blog http://www.securitywarrior.org is one of the most popular in the industry.
In addition, Anton teaches classes (including his own SANS class on log management) and presents at many security conferences across the world; he recently addressed audiences in United States, UK, Singapore, Spain, Russia and other countries. He works on emerging security standards and serves on the advisory boards of several security start-ups.
Currently, Anton is building his security consulting practice www.securitywarriorconsulting.com, focusing on logging and PCI DSS compliance for security vendors and Fortune 500 organizations. Dr. Anton Chuvakin was formerly a Director of PCI Compliance Solutions at Qualys. Previously, Anton worked at LogLogic as a Chief Logging Evangelist, tasked with educating the world about the importance of logging for security, compliance and operations. Before LogLogic, Anton was employed by a security vendor in a strategic product management role. Anton earned his Ph.D. degree from Stony Brook University.