How to Build a Security Incident Response Program
“Boss, I think we might have a security problem.”
There are few words more likely to strike fear in the heart of an IT manager. How did you feel the last time these words were spoken in your office?
If you and your team remained calm, cool and collected, it’s likely that you have a strong incident response program that specifies everyone’s roles and responsibilities in the wake of a breach. If your reaction was chaotic, however, you might benefit from enhancing the strength of your response.
Strong security incident response programs have well-defined processes and procedures for identifying security incidents, activating a well-qualified incident response team, bringing in outside help when needed and complying with legal and regulatory requirements.
One of the most critical foundational steps to take as you build your incident response program is to agree on your organization’s definition of the term “incident.” While there are several widely accepted definitions, most security professionals agree that the term should be reserved for cases in which an organization’s security has actually been undermined. The National Institute of Standards and Technology suggests the following definition:
“A computer security incident is a violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices.”
The first signs of a security incident can be detected almost anywhere in an organization. You might receive calls to your help desk reporting unusual system behavior, a security monitoring tool might report anomalous activity, or you might even receive external reports of malicious activity originating from your networks.
Your incident response process should be designed to accept input from a wide array of sources and initiate consistent, appropriate responses.
Building Your Incident Response Team
Every organization should have a well-defined and adequately trained security incident response team. The size of the organization and volume of incidents will dictate whether these are full-time positions or part-time responsibilities fulfilled by staff with other regular positions within the organization. Common positions found on an incident response team include:
The Team Leader is responsible for managing the incident response efforts, obtaining necessary resources, interpreting organization policy and directing actions needed to resolve the incident.
Security analysts provide specific expertise needed to assess the extent of an incident, implement additional controls required to contain the incident, and perform forensic analysis of affected systems. Larger incident response teams may subdivide this category into multiple roles.
Technical subject matter experts may serve as ad hoc members of the team, contributing desktop, network, server, application, database and other skills as needed.
An attorney is normally included on an incident response team to assess the organization’s legal and regulatory liabilities and provide legal advice to both team members and management as the incident unfolds.
Public relations staff may be brought into response efforts to communicate with the media, government agencies and the general public.
Each member of the incident response team should receive role-specific training prior to their involvement in an actual incident. Additionally, the entire team should participate in regular incident response drills to ensure familiarity with the incident response plan. This is especially important in organizations with a low volume of incidents.
Bringing in Outside Help
As you create your incident response team, you may find specific areas of expertise that cannot be filled with internal staff. In this case, you have two alternatives: You could add a staff position, if you feel it is warranted; or you could hire security contractors to fill these specialized needs.
If you choose to augment your staff with contractors, you should keep two issues in mind. First, you should negotiate contract terms in advance and possibly even put a security firm on retainer. This saves you the headache of attempting to negotiate a contract in the middle of a crisis. Second, you should integrate these outside partners into your routine testing and training processes.
The old sports adage “you play like you practice” certainly applies to security incident response. If the first time your staff encounters consultants is during an actual incident, you can count on botched handoffs and awkward working relationships.
Incident Response and Compliance
Whatever your industry, there are likely to be one or more laws or regulations that dictate how you should respond to security incidents. Your response plan should clearly outline the specific requirements governing your organization and the situations where these rules apply.
Almost every business is covered by state-level breach notification laws. These laws vary from state to state, but generally require that you notify individuals affected by a breach of personally identifying information in a reasonable amount of time. Be sure to consult your attorney to determine the applicable requirements in your state.
In addition, many organizations are subject to industry-specific requirements calling for additional notifications to individuals, government agencies and other regulators. For example, organizations involved in the provision of healthcare are subject to the breach notification requirements of the Health Insurance Portability and Accountability Act (HIPAA).
Similarly, businesses that process credit card transactions are subject to the stringent requirements of the Payment Card Industry Data Security Standard (PCI DSS) that require immediate notification to both your merchant bank and the U.S. Secret Service.
Creating a solid incident response program built upon the principles outlined here can set your organization on the path toward successful incident handling. Most important, the planning conducted as you develop your program will facilitate a calm, rational response as the chaos of a security incident unfolds. Regular training, testing and revision of your plan will ensure that it remains a “living” document that meets the changing business needs of your organization.