Diagram outside firm role early in security incident response process

Preventing incidents is one of the most important functions of an enterprise information security team, but having a strong security incident response process is also important. Even the

Requires Free Membership to View

most secure organizations eventually will face a security incident and may need outside support to augment their in-house incident response capabilities. To determine what happened, when it happened, who did it and how to prevent it in the future, it often takes special digital forensics skills most infosec teams don't have in-house.

It's often difficult and time-consuming to determine the types of incidents an incident response firm has dealt with, so this is where performing your due diligence well in advance is especially helpful.

However, the midst of an incident is one of the worst times to identify a trusted partner to support any incident response needs, which is why enterprises should try to select an incident response firm before an incident ever occurs. As part of an extended computer security incident response team or CSIRT, this partner, or partners, may need to be called upon to investigate specific types of incidents.

In this tip, we’ll provide brief criteria for choosing the right incident response firm to support the enterprise incident response process, including the different types of incident response organizations, guidance on choosing a big firm vs. a boutique, and when to contact an alternative or government organization like US-CERT.

Incident response organizations
The types of incidents to investigate and the assistance needed for an incident response will vary by industry and organizational capabilities, but there are key considerations for choosing an incident response firm that holds true in most scenarios. Potentially the easiest criterion for some organizations is if they feel the security incident response will have legal implications. Often, internal investigations do not follow the same rigor as investigations that may be scrutinized in a court of law. Although internal investigations may or may not be investigated with the equivalent rigor from one organization to the next, enterprises should not follow sloppy security incident response procedures. Along a similar line, if the data involved is payment card data, an enterprise might be required to use a PCI Forensic Investigator (PFI) to investigate the incident. The Payment Card Industry Security Standards Council (PCI SSC) requires the use of a PFI to ensure investigators or responders “completely understand the PCI DSS and its intended application within the cardholder data environment.” The takeaway here is to immediately distinguish whether an incident may have legal or compliance implications, and if so, be sure to select an incident response team that has experience collecting evidence and responding to the type of incident in support of the legal proceedings that may accompany that particular type of incident. Naturally, it's also a good idea to involve corporate counsel as well.

Listen to this tip 
as an MP3!

Listen to Diagram outside firm role early in security incident response process as an MP3 here.

Once the legal implications are squared away, another consideration is choosing an incident response organization based on the type of attack. By using a third party that is experienced in responding to certain attackers, methods or tools, it’s possible it has encountered the attack signatures previously, which makes it more likely it will know exactly what to look for and how to clean up affected systems. It's often difficult and time-consuming to determine the types of incidents an incident response firm has dealt with, so this is where performing your due diligence well in advance is especially helpful. Take the time to research and even speak with a handful of incident response firms personally and ask about their areas of expertise, and make notes that you can go back to should you need a rapid response in the future. You may even want to place a retainer so their services could be available in a specified timeframe when responding to an incident. While this may often result in smaller firms with specialized skills being favored over more well-known organizations, it's often these boutique firms that are best equipped to respond to specific types of attacks. 

Another important consideration is internal resources. Some organizations may choose to outsource incident response altogether so they don’t need to maintain the high level of expertise in house. Others simply don't have ample security staff resources and aren't prepared to respond to a security incident. They may also outsource investigations or incident response when internal staff members are unavailable. If this is the case, it may make sense to consider a large firm that can handle a broader range of incidents.

For reference, there are multiple categories of incident response organizations, including large, boutique and even government agencies. Some of the large incident response organizations (Verizon, McAfee Inc., Symantec Corp., Trustwave Inc., etc.) have practices that could encompass most of many organizations’ incident response needs as noted above. There are many boutique organizations (Mandiant, Dell SecureWorks, Langner, etc.) that specialize in certain areas, which means they may be the most appropriate choice to handle advanced or specialized incidents. These companies can be evaluated by reviewing any publically available tools, reports or presentations they support or produce along with speaking with the firms.

More security incident response planning

Establish a better business continuity plan in the face of DoS attacks.

Take a more proactive approach with a security incident response program.

Reporting security incidents
Regardless of an incident being investigated internally or externally, reporting the security incident may be required by law. Though incident response and reporting are ultimately separate, enterprises should contact law enforcement if the incident is serious. If the data involved was payment data, protected health information (PHI), or personally identifying information (PII), the incident most likely needs to be reported to one or all of following: state or federal government agencies, the payment card brands, and the individuals affected. Even if an investigation shows an incident does not need to be reported, reporting the incident to different agencies or organizations could improve the overall state of information security and help identify trends. So to help more organizations learn from an incident, an enterprise should consider contacting US-CERT, a regional CERT, an industry ISAC or another organization to share incident response data. Assistance with investigating the incident or notifying other affected organizations may also be needed. If a zero-day exploit was used in the attack, a report should be filed with the software vendor to fill them in on incident and attack details.

Planning for an incident response well before an incident takes place is critical to not only responding effectively, but also minimizing the impact of the incident on the organization. Part of this planning includes identifying when to bring in a trusted outside partner to investigate an incident and determining what type of incidents to have them investigate. Establishing these relationships and procedures prior to an incident will greatly improve the incident response process.

About the author:
Nick Lewis (CISSP) is an information security architect at Saint Louis University. Nick received his Master of Science in Information Assurance from Norwich University in 2005 and Telecommunications from Michigan State University in 2002. Prior to joining Saint Louis University in 2011, Nick worked at the University of Michigan and previous at Children's Hospital Boston, the primary pediatric teaching hospital of Harvard Medical School, as well as for Internet2 and Michigan State University.

This was first published in June 2012

There are Comments. Add yours.

TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.