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.

Perimeter

11/12/2008
03:12 PM
John H. Sawyer
John H. Sawyer
Commentary
50%
50%

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
Comments
Newest First  |  Oldest First  |  Threaded View
Why Cyber-Risk Is a C-Suite Issue
Marc Wilczek, Digital Strategist & CIO Advisor,  11/12/2019
Unreasonable Security Best Practices vs. Good Risk Management
Jack Freund, Director, Risk Science at RiskLens,  11/13/2019
Breaches Are Inevitable, So Embrace the Chaos
Ariel Zeitlin, Chief Technology Officer & Co-Founder, Guardicore,  11/13/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Navigating the Deluge of Security Data
In this Tech Digest, Dark Reading shares the experiences of some top security practitioners as they navigate volumes of security data. We examine some examples of how enterprises can cull this data to find the clues they need.
Flash Poll
Rethinking Enterprise Data Defense
Rethinking Enterprise Data Defense
Frustrated with recurring intrusions and breaches, cybersecurity professionals are questioning some of the industrys conventional wisdom. Heres a look at what theyre thinking about.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-16761
PUBLISHED: 2019-11-15
A specially crafted Bitcoin script can cause a discrepancy between the specified SLP consensus rules and the validation result of the [email protected] npm package. An attacker could create a specially crafted Bitcoin script in order to cause a hard-fork from the SLP consensus. All versions >1.0...
CVE-2019-16762
PUBLISHED: 2019-11-15
A specially crafted Bitcoin script can cause a discrepancy between the specified SLP consensus rules and the validation result of the slpjs npm package. An attacker could create a specially crafted Bitcoin script in order to cause a hard-fork from the SLP consensus. Affected users can upgrade to any...
CVE-2019-13581
PUBLISHED: 2019-11-15
An issue was discovered in Marvell 88W8688 Wi-Fi firmware before version p52, as used on Tesla Model S/X vehicles manufactured before March 2018, via the Parrot Faurecia Automotive FC6050W module. A heap-based buffer overflow allows remote attackers to cause a denial of service or execute arbitrary ...
CVE-2019-13582
PUBLISHED: 2019-11-15
An issue was discovered in Marvell 88W8688 Wi-Fi firmware before version p52, as used on Tesla Model S/X vehicles manufactured before March 2018, via the Parrot Faurecia Automotive FC6050W module. A stack overflow could lead to denial of service or arbitrary code execution.
CVE-2019-6659
PUBLISHED: 2019-11-15
On version 14.0.0-14.1.0.1, BIG-IP virtual servers with TLSv1.3 enabled may experience a denial of service due to undisclosed incoming messages.