WASHINGTON D.C. -- When it comes to incident response, there's one message Matthew M. Shannon wants the security channel to learn about dealing with potentially compromised machines: don't assume they must be immediately shut down.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Speaking Tuesday at the Computer Forensics Show, Shannon, principal of information security assessments and computer forensics for Tampa, Fla.-based consulting firm Agile Risk Management LLC, said many of today's incident response tools enable live forensics without pulling a suspect computer off the network.
Shannon said in the traditional incident response paradigm, it often takes several hours in a best-case scenario to identify a potential compromise, shut down a target machine, make a duplicate image of the hard drive and begin the analysis. Even with all that work, it's not always possible to determine the cause of the attack, resulting in a sunk cost for a customer.
"And during the time you're spending making that image an attacker could have hacked into five or six other machines," Shannon said.
Alternatively, live forensic analysis is not only faster, Shannon said, but also more useful. For instance, live analysis may reveal attack methods that would be undetectable after a system shutdown, such as one that uses the computer's memory without writing to the hard drive.
Plus, Shannon added, as hard drive sizes continue to increase, recreating drive images in their entirety -- especially for a multitude of compromised customer machines -- may not be efficient, especially when live analysis can quickly pinpoint the source of the attack.
While some may express concern about violating traditional incident response processes and being unable to use the data as part of a civil or criminal case, Shannon said there's no legal mandate that requires an original hard drive image; all that's necessary is documentation of how the forensic findings were acquired.
"There's an established process for incident response," Shannon said. "I'm not saying throw that out, but often there's a better way to do it."
Attendee Peter Starceski, a Michigan-based principal systems engineer for a large software firm, said that the concept of live incident response has merit, but it's unlikely that every incident could be dealt with in that way.
Starceski said it's important that integrators educate customers on the differences between the techniques, and that they understand how and why live forensics would be employed should an incident take place.
Shannon offered a number of other best practices for successful integrator incident response, including being ready to respond quickly and making sure the staff is familiar with how to use forensics tools, both on-site and remotely.
He highly recommended that solution providers teach their customers basic "first aid" skills for dealing with the immediate aftermath of a security incident. His company has found that providing customers with read-only incident response tools to collect volatile system data like physical memory data enables them to be part of the process without the risk of corrupting key data.
"We found if we taught [customers] the basic skills and tools, then it made our job easier and it made working with them easier," Shannon said. "Does that mean in certain cases we didn't get called in? Sure, of course. But in the large, important cases, we got the phone call."
He also emphasized making sure customers have detailed incident response plans that identify the roles of key stakeholders and mesh with the organization's business strategy.
"The most important piece of any incident response plan is buy-in on the executive level," Shannon said. "Without that, it's just words on paper."