Data Breach Laws Drive IR, Preparation Is Key
Fellow Dark Reading blogger Gadi Evron had an interesting take on the relationship between incident response and forensics in his post "Incident Response Is Not Forensics." I agree with him for the most part, but I don't think forensics is the most common course of action depending on who is responding to the incident.
Fellow Dark Reading blogger Gadi Evron had an interesting take on the relationship between incident response and forensics in his post "Incident Response Is Not Forensics." I agree with him for the most part, but I don't think forensics is the most common course of action depending on who is responding to the incident.With a sysadmin at the helm, evidence collection is often at the minimum because he or she wants the system back online ASAP. Not so with security professionals.
We as security professionals want to know the who, what, why, and when so we can prevent the problem from repeating itself. Much of the impetus to find out what happened is simply personal and professional curiosity, but that has been changing. In the U.S., nearly every state has a law requiring us to disclose information surrounding a data breach involving personal information; the affected individuals must be notified. So while Gadi's statements about getting the system back online immediately may be desirable from a business perspective, legal reasons could also impact our decisions. Similarly, the decision to bring a system back online should rest solely in the hands of business decision-makers, who must weigh the costs of lost business versus the legal requirement to perform a thorough investigation to see if personal information was accessed. I think the No. 1 problem facing security professionals and businesses is a lack of preparation. The pros dealing with an incident are not fully prepared to respond at the drop of a hat, and their environments aren't designed well enough to provide information quickly. What can they do to be better prepared? To start off, they need to have the tools, training, and know-how. The majority of good, solid incident response tools are free or relatively inexpensive (CAIN, Helix, etc.) -- you just need to have them ready to go and know how to use them efficiently and effectively when the time comes. The other step is preparing your environment. I discussed that last week, along with some links to Richard Bejtlich's Defensible Network Architecture 2.0. Being prepared with standard configurations that allow compromised hosts to be rebuilt goes a long way toward speeding incident response, as does having comprehensive centralized logging and full network monitoring. There are a lot of reasons that forensics seems to complicate the incident response process, but that doesn't have to be the case if you're prepared for the inevitable compromise.
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.
About the Author
You May Also Like
DevSecOps/AWS
Oct 17, 2024Social Engineering: New Tricks, New Threats, New Defenses
Oct 23, 202410 Emerging Vulnerabilities Every Enterprise Should Know
Oct 30, 2024Simplify Data Security with Automation
Oct 31, 2024Unleashing AI to Assess Cyber Security Risk
Nov 12, 2024