Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


03:12 PM
John H. Sawyer
John H. Sawyer

Correlating Many Data Sources Is Often The Key

Being able to successfully perform incident response and digital forensics requires having the right tools and, more importantly, the right sources of information. I was assisting a client with a case recently that made this simple fact more apparent the more I dug into the monstrous amount of information they provided me.

Being able to successfully perform incident response and digital forensics requires having the right tools and, more importantly, the right sources of information. I was assisting a client with a case recently that made this simple fact more apparent the more I dug into the monstrous amount of information they provided me.This particular case required the review of logs from numerous systems, as well as the standard "dead" forensics in which the hard drive from the suspect's computer or compromised system is forensically copied while the system is off and which serves as the primary source of information.

During analysis of a dead hard drive, other information sources are typically used to lend credence to what is seen on the hard drive. Unfortunately, the copy of the hard drive is sometimes incomplete due to damage caused by the suspect or intruder, or by physical damage caused by hardware failure or mishandling by the first responders. This is where the additional sources of data can prove to be invaluable to help fill in the picture so investigators can truly understand what took place.

So what sources of data can be important to cracking a case? The obvious answer is that it depends on the case, but several sources can apply to just about any case. Interviewing key personnel, both users and sysadmins, is very important. Users can tell you what weird things they saw when their systems were acting up, and sysadmins can tell you whether they patched diligently and what security protections were in place. They can also point you to important system and network documentation (if they exists).

Logs, logs, and logs. I can't beat this drum enough. Logs are critical to investigations, but the sad truth is that many organizations simply don't pay any attention to them. Logs from network devices (firewall, IDS, switches, routers, etc.), operating systems, applications, and even printers can be very important to providing clues to what happened. Can you imagine the credibility your findings will have if you can correlate traffic from the firewall showing that a particular service was accessed at the same time logging for that service failed and antivirus began detecting malware on the local file system?

I could go on and on about different data sources (like the cell phone in this case), but what I try to get across to people when we discuss this is that being overwhelmed with too much information during an investigation is most often a good thing. It can seem daunting at first when trying to get to some initial answers to appease management because they always want to know immediately what happened, but in the long run your investigation will be much more solid and defensible when you can take those different sources and correlate them to get the full picture of who, what, when, and why.

John H. Sawyer is a Senior Security Engineer on the IT Security Team at the University of Florida. The views and opinions expressed in this blog are his own and do not represent the views and opinions of the UF IT Security Team or the University of Florida. When John's not fighting flaming, malware-infested machines or performing autopsies on blitzed boxes, he can usually be found hanging with his family, bouncing a baby on one knee and balancing a laptop on the other. Special to Dark Reading.

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
Inside the Ransomware Campaigns Targeting Exchange Servers
Kelly Sheridan, Staff Editor, Dark Reading,  4/2/2021
Beyond MITRE ATT&CK: The Case for a New Cyber Kill Chain
Rik Turner, Principal Analyst, Infrastructure Solutions, Omdia,  3/30/2021
Register for Dark Reading Newsletters
White Papers
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-04-13
The ReplicationHandler (normally registered at "/replication" under a Solr core) in Apache Solr has a "masterUrl" (also "leaderUrl" alias) parameter that is used to designate another ReplicationHandler on another Solr core to replicate index data into the local core. To...
PUBLISHED: 2021-04-13
When starting Apache Solr versions prior to 8.8.2, configured with the SaslZkACLProvider or VMParamsAllAndReadonlyDigestZkACLProvider and no existing security.json znode, if the optional read-only user is configured then Solr would not treat that node as a sensitive path and would allow it to be rea...
PUBLISHED: 2021-04-13
In Apache Commons IO before 2.7, When invoking the method FileNameUtils.normalize with an improper input string, like "//../foo", or "\\..\foo", the result would be the same value, thus possibly providing access to files in the parent directory, but not further above (thus "...
PUBLISHED: 2021-04-13
When using ConfigurableInternodeAuthHadoopPlugin for authentication, Apache Solr versions prior to 8.8.2 would forward/proxy distributed requests using server credentials instead of original client credentials. This would result in incorrect authorization resolution on the receiving hosts.
PUBLISHED: 2021-04-13
Siren Federate before 6.8.14-10.3.9, 6.9.x through 7.6.x before 7.6.2-20.2, 7.7.x through 7.9.x before 7.9.3-21.6, 7.10.x before 7.10.2-22.2, and 7.11.x before 7.11.2-23.0 can leak user information across thread contexts. This occurs in opportunistic circumstances when there is concurrent query exec...