Top Considerations for
Incident Response
INTRODUCTION
Incident response is a key part of any comprehensive security plan. However, many firms are not even sure where to begin to create an incident response process. While LegalSec will be producing templates for an incident response plan document in the near future, this document provides a high level overview to get you started on preparing for incident response at your firm.
TAKE STOCK OF YOUR DOCUMENTS
Proper documentation and access to that documentation during an incident response is crucial to proper and effective handling of an incident. Ultimately, the documentation gathered is going to act as the run book or action plan for how the firm responds during an emergency. When possible, add any and all documentation available and identify areas with deficient records. It is better to have the documentation and never need it, than to need it and never have it. An incident response plan may span the length of several careers and it is important that the knowledge necessary to handle an incident is retained within the firm.
What do you want documented? A good starting place is Information Security Management System documentation (Policies/Standard/Procedures), Incident Response Plan, Contact Lists (internal/external for key vendors), logins and passwords for key systems, business continuity plans, network diagrams and any data maps that identify where the most sensitive information is located.
HAVE A PROCESS FOR DETECTING AN INCIDENT
As part of a comprehensive incident response process, it is important to identify the indicators for detecting an incident. Retain important log files for a sufficient amount of time to facilitate any investigation and make sure your firm retention schedules accurately reflect the appropriate retention time. Some top potential indicators of an incident are as follows:
1) User reports of suspicious activity such as clicking on a phishing link, lost/stolen media or device.
2) Web server log entries that indicate the use of a vulnerability scanner. Examples of this and other windows log entries can be found at the NSA site.
3) Antivirus software alerts detecting that a host is infected with malware. 4) A network administrator noticing unusual network traffic flow.
5) An email administrator noticing a large number of bounced email messages with suspicious content.
6) An application logging multiple failed login attempts from an unfamiliar remote system. 7) A host’s audit log recording a change in its configuration.
8) A threatened attack upon the firm from a hactivist or similar group.
9) An announcement of an exploit targeting known vulnerabilities of the firm’s mail server. 10) A network intrusion detecting sensor alerting of a buffer overflow attempt on a database
11) A system administrator observing a filename with unusual characters. 12) Abnormal activity within the Document Management System.
Employees should be trained as part of security awareness to report all suspicious activities. (See “Information Sharing and Education” below.)
FORM AN INCIDENT RESPONSE TEAM
Good incident response requires the identification and training of first responders who can form an incident response team. Members of this team will be responsible for classifying an incident, investigating and mitigating an incident, and reporting status as appropriate. When considering members of this team, consider:
1. Internal technical resources such as subject matter experts, top technical people from areas such as networking, desktop, server setup or other areas.
2. Vendors and other external resources that add skills your firm may not have on staff, such as forensic analysis.
3. Public Relations personnel, for both internal and external communications. 4. An official records keeper.
5. Risk Management / General Council / Privacy Attorney. 6. A team leader.
Each team member should know his/her role, even though the roles of the team may vary based on classification of the incident
Part of forming a team includes identifying a clear chain of command. That chain of command should answer questions such as:
1. Who is authorized to mobilize the incident response team?
2. Who is operationally in charge of the team during an incident? Avoid too many chiefs. 3. Who in firm leadership should be notified (CIO, Information Security Office Managing
Partner, firm’s General Counsel, Compliance Officers) and who are their backups in case those people are unavailable?
As you form a team, consider that some incidents can be resolved very quickly, but some responses may take days or weeks. As a part of the communication role, it should be noted who will be briefing which groups (Executive Committees/Chair/General Counsel/etc.) and what is the maximum time between briefings.
Once the team is formed, the firm will want to train them on the firm’s incident response plan. HAVE A DOCUMENTED INCIDENT RESPONSE PLAN
Firms require a documented incident response plan for when (not if) the firm must respond to an incident. There are many example documents available (see reference section at the end of this paper), and LegalSec will be providing templates designed for law firms in the near future. However you start, you should tailor the plan so that it is actionable by your firm. Starting with standards such as the ISO 27000 series is a good start. However, firms make a mistake if the incident response plan is an
third party, a client or an ISO 27001certification body, will check to ensure that your incident response plan matches your standard practices. Another tip: a well written incident response plan should be written with sufficient detail and clarity that a junior member of the incident response team could execute the plan as written.
All firms have different levels of skill and there are many detailed and nuanced approaches available for creating an incident response plan. However, at minimum, the incident response plan should cover Roles and Responsibilities, Investigation, Triage and Mitigation, Recovery, and Documentation.
ROLES AND RESPONSIBILITIES:
The incident response plan should identify the members of the response team and what their roles will be for a given incident. (See “Form an Incident Response Team” section above for details.)
INVESTIGATION
Initially, the firm’s incident response team will classify an event. Not all events rise to the level of potential incident. The incident response plan should accommodate responses to multiple types and classifications of incidents (e.g. physical theft, hacking, lost device). The investigation step may require the firm to engage external resources, so these relationships should be set up in advance of any incident and documented in the plan. This section should then cover the investigation approach for each incident type, including what to look for, who to involve, and how to document what is found.
TRIAGE AND MITIGATION
The triage and mitigation steps are the natural extension of the investigation step. As the team identifies potential exposure, they should plan and execute effective mitigation. For many incidents, the plan should include the incident type and steps for mitigation. For some incidents, the response may require more complicated and coordinated actions to remove attackers from your environment, and some firms may not have the expertise or experience to document all steps. Each type of incident should include details for vendors who may need to respond, such as an ISP during a Denial of Service attack, or a forensics firm to mitigate a complex Advance Persistent threat.
RECOVERY
The recovery step is the transition from active incident to standard monitoring. The plan should document the steps for transition given the particulars of the firm’s environment and approach. For example, when returning a compromised machine to production, is it acceptable to clean infection residue or should the machine be wiped cleaned, formatted and rebuilt from known good media? DOCUMENTATION
The incident response plan should provide instructions on the final form of the incident documentation, how long it should be retained, and who should be involved. Considerations include regulatory
OTHER AREAS TO CONSIDER
A comprehensive incident response plan will also address post-incident reviews for lessons learned, guidance on information sharing, the plan for communicating with internal users, clients and members of the media as necessary, and the process for gathering and reporting on incident metrics to measure incident cost and continuous improvement. Last but not least, the incident response plan should address the education requirements for both the team, and for the firm’s users who might play a key role in detecting an incident.
INFORMATION SHARING AND EDUCATION
All computer users should receive training on what a security incident is, and how to report any suspected security incidents so that members of the incident response team can properly investigate, classify and, if necessary, mitigate and escalate. Training on what constitutes an incident should include a range of scenarios, from a suspected malware infection, to a lost mobile device, to concern about an insider threat. These items can be reported to the Service Desk, a Security Team Hotline, or in an automated fashion, but the reporting mechanism should be available at all times.
The firm should have already defined an incident response team and incident response plan (see sections above). Members of that team will classify reported potential incidents, and the firm should have a defined reporting and escalation procedure based on the classification. The following are considerations to follow in classifying an incident:
1. The operational impact and value of data at risk.
2. The type of incident, based on specifics of reported incident.
3. The type (or suspected type) of perpetrator(s) either known or unknown. 4. The geographic scope of the impact .
a. Is the impact confined to a single or a few users? b. Is the impact/confined to an entire office?
c. Is the impact/confined to the Data Center(s)? d. Is the impact to the entire firm?
Based on how a potential incident is classified, different people in the firm, or outside of the firm, may need to be notified, or play a role in response. The escalation procedures should include plans for communicating with internal users, engaging law enforcement, involving strategic vendors such as forensic personnel, and a plan for communicating with clients and the media. Firms should involve the General Counsel’s office (or equivalent) when building reporting and escalation procedures to ensure factors such as regulatory obligations, contractual obligations, and insurance obligations are properly considered as the incident investigation proceeds. All team members should be trained in a common lexicon of language to ensure prompt and clear communication during an incident response.
Each incident response team member should be trained on the various roles within the team, and should understand what role or roles they should perform for a given incident. Finally, the team should
regularly practice incident handling, which includes practicing classification of the potential incident, utilizing the documentation collected, reporting the status to various members of the team during the investigation, updating leadership, keeping records and, of course, practicing mitigation techniques. These exercises and actual experience will provide insight into potential process improvements.
CONTINUALLY IMPROVE YOUR PROCESSES
While the completion of an incident response plan is a major accomplishment, it is likely that, upon completion, it is already out of date. Unfortunately, the threat landscape changes so rapidly that the plan will be a continually evolving document. Below are three ways to improve the firm’s incident response processes and keep the plan nimble and ready to meet the challenges of an evolving future.
DEFINE AND PRACTICE DRILLS
Once the firm’s plan is in place, run through part or all of it as a table top exercise. Gather the various stakeholders and talk through different scenarios and how the group would react. Document the results of these exercises and incorporate the findings into your plan.
As new people join the firm’s incident response team, make sure they understand how important these mock drills.
Another way to practice the firm’s plan is to do a live test. This test can be as simple as dropping a thumb drive on the floor of the office and seeing what happens, to simulating a data breach or phishing attack. The goal here is not to scare peers into submission or shame them about what they may have done wrong, but rather to illustrate how your plan works or does not work when put to real world tests. CONDUCT A POST MORTEM
After any drill, the most important piece is the post mortem. Adding lessons learned both positive and negative to your firm’s plan is essential to keeping it current and relevant to your firm’s office
environment. Keeping versions of the plan after every drill will help track the evolution of the plan and which previous lessons learned were either integrated successfully and which need to be revisited. Acting on lessons learned, as well as integrating the things you uncover in your drills or real incident responses, will make the plan more flexible and applicable to real-life incidents.
SHARE INFORMATION ABOUT THREATS WITH OUTSIDE PARTIES
No one knows everything and the larger one can make one’s tent with regards to incident response, the better the outcome will be. To this end, bring peers in on your discussions and share parts of your plan with key vendors and other trusted advisors. If you have not already, subscribe to the ILTA LegalSec peer group. Consider joining InfraGuard or other information sharing organizations. Finally, if your client’s are members of an industry specific ISAC (Information Sharing and Analysis Center), ask them if you can get in the loop to receive and share information as appropriate.
Bring firm management into the fold by briefing them on drills and giving them after-action reports on actual incidents. These reports should include the General Counsel, but also reach to the highest level of management.
CONCLUSION
This document should provide a starting point for firms looking for a place to start. Look for further resources from ILTA LegalSec in the near future.
REFERENCES
NIST SP 800-61 R2 – Computer Security Incident Handling Guide
http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf
ISO 27035 (Note: you must pay for this document)
http://www.iso.org/iso/home/store/catalogue_ics/catalogue_detail_ics.htm?csnumber=44379
Simple IR plan from Proactive Risk
http://www.proactiverisk.com/home/services/mssp/ir
ILTA LegalSec
http://connect.iltanet.org/resources/legalsec
UC – Computer emergency response team page
https://www.us-cert.gov/ncas/current-activity
Financial Services Industry Information Sharing and Analysis Center
ACKNOWLEDGEMENTS
This document was assembled for ILTA LegalSec with contributions from the following:
Team Members Organization
Tom Brennan Proactive Risk
Mark Brophy Keno Kozie
Brian Donato Vorys, Sater, Seymour and Pease LLP
Gerard F. Haubrich Drinker Biddle
Patrick Kohnle Lockpath
Joel Lytle Jackson Walker
Will Pulsifer Smith Debnam
John Verry Pivot Point Security
Phil Townsend Wyche
Wei Tschang Fried, Frank, Harris, Shriver & Jacobson LLP
Phil Waterbury McDermott Will & Emery
Document History
Date Name Changes
