As discussed in a recent webinar delivered by Lancope’s Director of Security Research, Tom Cross, Carnegie-Mellon’s CERT team published a book last year called The CERT Guide to Insider Threats. With over ten years of collecting and studying insider threat cases, this guide has some very good recommendations on how to build an effective program.
One of the key pieces from the CERT Guide is that insider threats are not strictly an IT problem. Many people consider insider threats to be exclusively an IT issue, but in reality it is an issue for everyone from IT to management to HR. It has to do with the relationship that the company has with employees and especially with those employees who have become disgruntled.
Often times, the way that an incident is detected is through human intervention; it's not because some computer system identified something wrong. For example, individuals identify that an employee was making threats against the organization, and it seemed like the person was likely to do something wrong. That information is taken to IT, and IT is able to analyze monitoring systems and logs that were available – whether via NetFlow, Syslog, packet capture, etc. – to find evidence of whether or not the suspicions were true. Typically, in insider threat cases, if they are successfully identified and prosecuted, it's a consequence of good log collection.
Within Lancope’s StealthWatch System, if you are tied into your user identity information, it's very easy to put someone's username into the system and get information about what network transactions they’ve engaged in, even if they moved around to different IP addresses. Whether they were in the office or logged in over the VPN, or moving around to different wireless access points, you can get a complete picture of their behavior.
In addition to simply getting the raw network transactions they engaged in, you can also see a picture of different security events that fired against that host.
In this scenario, we have the ‘suspect data loss’ security event, which detects data being exfiltrated out of the network. We notice that an event fired while Lucy was using the IP address in question, so maybe Lucy was exfiltrating data. In this case, we can see this transaction has occurred, so we've got some evidence that Lucy might have moved a lot of data out of the network.
Let's look at a little more complicated scenario. In the course of looking at Lucy, we also noticed that Beron had a ‘suspect data loss’ event that fired on his IP address, and so we're concerned that he might have exfiltrated data as well.
We take a look at Beron's exfiltration, and we can see that it was a significantly large MySQL database dump which occurred at 9:07 a.m. and was sent out to a host in the Ukraine.
We continue to investigate, and first we are wondering: ‘where did Beron get this MySQL dump’? Beron is not a person who usually works with database systems. We look at the different network transactions associated with this IP address, and notice there was a significant download from a particular database server on our network that occurred by this host. Clearly Beron dumped some data out of one of our critical databases and then exfiltrated it to a host in Ukraine.
Right now we're very upset with Beron. As we continue to dig, we notice this database transaction timeframe occurred between 8:55 a.m. and 9:07 a.m. 9:07 a.m. is when the exfiltration to the Ukraine actually began, so we have more context that this database dump occurred right before the exfiltration.
We dig into Beron a little deeper and find out, in fact, there has been another transaction between Beron's client and this host in the Ukraine that has been going on since 4:00 a.m. This looks an awful lot like a command-and-control channel, so it may be that Beron is not actually responsible for stealing this data and that Beron's computer has been infected by an external actor. As a consequence, that external actor used Beron's system to steal some data from our database and send it to the Internet.
It's important that we found this and have begun to investigate deeper to try and understand more about this attacker and why they're compromising our network.
You always want to keep in mind the 5 W's (Who, What, Where, When and Why) as you perform these investigations on the network. You're trying to establish who did this activity, what they did, what systems were affected, how they targeted those systems, and what data they accessed. Every bit of information that you put together about their overall behavior can lead you to the root cause of the problem. You want to ensure that you have completely rooted them out of your network, and that you understand how you might be able to detect attack activity from them in the future. If you know what your adversary is after, you can take steps to protect that asset more effectively and to monitor that asset more closely.
Forensics in the context of computer security is not merely about preparing evidence for trial. We may never be able to prosecute these APT actors that are hitting our network from remote sites. It's become more about understanding the attacks that we're subject to and using that understanding to better protect our networks. It's not just about analyzing hard drives. It's about getting a complete picture of an incident that has affected us.
Watch the on-demand webinar, “Hunting Attackers with Network Audit Trails,” to learn more.