Forensics - Commsec

Forensics

Incident Response Procedures: The Need for Checklists

One of my former bosses was also a former pilot, and so of course, we had a checklist for everything. And after going through one too many real fires (not to mention fire drills), I can safely say I’m really glad we had them. And I can also safely say that they were constantly being edited for clarity and efficiency – after training exercises, and after real incidents. There was always a better way to do something, and certainly a better way of explaining how to do it.

So… what kind of incident response checklists will I need?

Yes, that’s the right question. Because there will definitely be more than one single incident response checklist. The best checklists are those that apply to specific scenarios and break down a specific

task or activity into bite-site chunks. They may also involve a few meandering offshoots – or “if then” – branches off your main checklist, and that’s likely where the richest detail will be necessary. Keep in mind though that you may not be able to predict all incident scenarios, and these checklists won’t necessarily capture everything that could happen.

Every business operation will dictate what’s considered essential for that specific business, because the critical business systems and operations to recover first will be different. That said, there are a few general types of checklists that can be considered essential for any business. Here are a few examples, along with a few references for additional information.

Forensic analysis checklists (customized for all critical systems)

During the process of investigating an incident you’ll likely need to look deeper at individual systems. A checklist that provides useful commands and areas to look for strange behavior will be invaluable. And if your company is like most, you’ll have a mix of Windows and Unix flavors. Customize each checklist on an OS basis, as well as on a functional basis (file server vs. database vs. webserver vs. domain controller vs. DNS).

Some useful references: SANS Incident Handling Handbook and Lenny Zeltser’s Security Checklists

Emergency contact communications checklist

Don’t wait until an incident to try and figure out who you need to call, when it’s appropriate to do so, how you reach them, why you need to reach them, and what to say once you do. Instead, develop a detailed communication plan with the specifics of when to put it into place and don’t forget to get overall consensus on your approach. The entire incident response team should know whom to contact, when it is appropriate to contact them, and why. In particular, review the potential worst case scenarios (e.g. an online ordering system going down right in the middle of Cyber Monday) and identify the essential staff who can get these critical systems back online, as well as the management team who will need to remain updated throughout the crisis.

Bonus tip: You’ll also need to document when it is or is not appropriate to include law enforcement during an incident, so make sure you get the necessary input and expertise on these key questions.

System backup and recovery checklists (for all OSes in use, including databases)

Each system will have a different set of checklist tasks based on its distinct operating system and configurations. It’s also important to note the time it takes for each step required to restore operations, and also test full system backup and full system recovery while you’re documenting each checklist. There should also be specific steps listed for testing and verifying that any compromised systems are completely clean and fully functional.

“Jumpbag” checklists

SANS, one of the premier sources of information for the incident responder, recommends that each incident response team member have an organized and protected “jump bag” all ready to go that contains the important tools needed for a quick “grab-and-go” type of response. Their recommended items include:

  • An Incident Handlers Journal to be used for documenting the who, what, where, why, and how during an incident
  • Your incident response team contact list
  • USB drives
  • A bootable USB drive or Live CD with up-to-date anti-malware and other software that can read and/or write to file systems of your computing environment (and test this, please)
  • A laptop with forensic software (e.g. FTK or EnCase)
  • Anti-malware utilities
  • Computer and network tool kits to add/remove components, wire network cables, etc. and hard duplicators with write-block capabilities to create forensically sound copies of hard drive images.
Security policy review checklist (post-incident)

The most important lessons to learn after an incident are how to prevent a similar incident from happening in the future. In addition to potential updates to your security policy, expect incidents to result in updates to your security awareness program because invariably, most incidents result from a lack of user education around basic security best practices. At the very least, this checklist should capture:

  • When the problem was first detected, by whom, and by which method
  • The scope of the incident
  • How it was contained and eradicated
  • The work performed during recovery
  • Areas where the incident response teams were effective
  • Areas that need improvement:
    • Which security controls failed (including our monitoring tools)?
    • How can we improve those controls?
    • How can we improve our security awareness programs?

A Selection of AlienVault Customers

footlocker  apple bank  Dart NeuroScience  Hamilton Insurance

IRA Services  Shake Shack  Soul Cycle  Hamilton Insurance

Go to:
Threat Management
Data Leakage Prevention
Home

Talk to CommSec today, to discuss how we can help you with your needs.

captcha