Global
| SecureWorks - On the Radar Newsletter - 0909 | |
|---|---|
 |
|
Incident Response Pitfalls: It's the Little Things that Count
By Alan J. White, CISSP, GCIA, CEM, CISA, QSA, CCE, GCIH
As the security partner for more than 2,700 organizations worldwide, we are frequently called in to help organizations respond to security incidents. Over the years, we have found that often it is the little things that can cause big problems when responding to an incident. Here are a few of the pitfalls we've seen that can derail incident response efforts and leave organizations no better off than where they started.
Pitfall #1: Imaginary Log Collection
Do you have access to the log data you need to support your incident response plan?
Logs are a valuable source of information during the incident response process. Log data gives you insight into the activity on systems and applications which can help you determine the appropriate course of action with a high degree of certainty.
If your access to logs is limited or if logs are missing, it is difficult to get a solid picture of the incident. Without log data, you have to rely on other forensic methods to determine the what, when, why, who, where and how of an incident. As someone who has done a lot of incident response and forensic work in the past, I can tell you these methods are typically more expensive and time-consuming.
Don't wait until you're in the middle of your incident response plan to learn you weren't logging sufficiently. Ensure full and complete log collections are always available for critical business systems. Know how long the logs are stored before they are overwritten. Understand the verbosity of logging levels to make sure the appropriate information is being logged to support incident response and forensic investigation. Do these things beforehand and save time, money and headaches.
Pitfall #2: The Undead Incident
After an incident, are you sure it is completely remediated?
A common problem we have seen organizations experience is to have a second malware outbreak after they thought they had purged all infected systems. Today's malware is stealthier than ever before, making it a challenge to be sure that all systems are truly clean after an incident. Organizations can often find themselves experiencing déjà vu when an incident thought to have been remediated comes back to life days or weeks later.
The classic example of the Undead Incident is when an infected server gets wiped, re-imaged and redeployed, only to be infected again by the same malware a few days later. After further investigation, it turns out there is another infected machine on the network that was never detected during the initial incident response process. Had a thorough investigation been done the first time around to determine the source of the infection, the organization would have found the other compromised system and been able to avoid a repeat incident.
It is essential to determine the full scope of an incident during the response process. Once you believe the incident is contained, you must do a thorough investigation to understand its full extent – including how the incident happened in the first place. Only then can you know what steps need to be taken to completely mitigate the incident and return systems to their proper state.
Pitfall #3: Superhero Syndrome
Do you have appropriate resources you need to adequately respond to an incident? How much does the incident response process rely on the presence of only a few individuals?
Incident response can be a very high-stress process, even if you have a well-defined plan from which to work. The process can take several days, with key individuals working around the clock. Fueled by coffee, energy drinks and determination, incident response staff can work beyond their usual limits. Eventually, stress, combined with lack of rest, will take its toll.
Burnout, fatigue and ego lead to lack of clarity, stale thinking, poor decision-making and sometimes a stalled sense of urgency. In a situation where you must think clearly and make the right decisions to save the day, avoid trying to be a superhero and putting it all on your shoulders. Keep a healthy bench of qualified resources that you can bring in to pick up the process when you've reached your limit. Have a plan to hand off responsibilities before responders reach their limits, to minimize the risk of making unnecessary mistakes and overlooking critical details.
Pitfall #4: The Missing Scribe
How do you accurately capture and document the incident response process?
The Scribe is a vital, yet often overlooked role. Incident response is a dynamic process. It is imperative to collect and document as much as possible during the process so that you have a clear record of facts. This is particularly necessary for incidents that take several days to resolve because it allows fresh responders to easily step in and pick up where the previous shift left off, without missing a beat.
It is also important to document events so that afterwards you can accurately report the incident as needed to comply with policies and regulations. After the incident, you do not want to have to rely on memory to recall the details as you go through postmortem procedures. At the onset of an incident, designate a Scribe who is responsible for taking detailed notes to ensure an accurate assessment of the situation at all times.
Preparedness improves response time. Continuously review, test and update your incident response process to ensure little pitfalls like Imaginary Logs, The Undead Incident, Superhero Syndrome and the Missing Scribe aren't lurking behind the scenes to derail your effectiveness.
Mr. White is the Director for SecureWorks' InfoSecurity & Incident Management, Security and Risk Consulting practice, and is responsible for the company's incident response and forensic practice. He has won hacking challenges at SANS and DoD security conferences, and assisted NSA with overseas military networks.
Additional resources on Incident Response:
- Security 101: Building a Computer Security Incident Response Plan
- Webcast Archive: Emergency Procedures – Best Practices for Incident Response
- SecureWorks Incident Response Services
New White Paper: Managing Application Security in Business Processes
This white paper will provide the reader with an understanding of application vulnerability management and strategies to mitigate the risks those vulnerabilities pose to business processes.
SecureWorks Extends Defense of Web Application Vulnerabilities
SecureWorks recently launched a new Web Application Scanning Service that enables organizations to quickly and accurately identify top-line vulnerabilities in Web applications. Using the service, businesses can proactively eliminate Web application security flaws and protect against attacks such as SQL injection, cross-site scripting, session hijacking, etc.
Read the Press Release
Read More about Web Application Scanning Service
SecurePoll
Question: When is the last time your organization had a penetration test?
To vote, simply fill out the right-column sidebar on this page.
We thank you for your participation!
