Developing An Incident Response Program: Moving Beyond the Basics
Many financial institutions are finding it challenging to assemble an incident response program (IRP) that not only meets minimum requirements as prescribed by financial institution regulators, but also provides for an effective methodology to manage security incidents for the benefit of the financial institution and its customers.
Financial institutions are required to include incident response as part of their information security program. The federal financial institution regulatory agencies have issued interpretive guidance prescribing standard procedures that should be included in IRPs. In addition, at least 33 states have passed laws requiring that individuals be notified of a breach in the security of computerized personal information.
The minimum required procedures addressed in the interpretive guidance can be categorized into two broad areas: reaction and notification. Reaction procedures are the initial actions taken once a compromise has been identified; notification procedures are relatively straightforward and involve communicating the details or events of the incident to interested parties; however, they may also involve some reporting requirements.
The FDIC has outlined how financial institutions can go beyond the minimum requirements and incorporate industry best practices into their IRP. For credit unions, the regulation referring to incident response program compliance is 12 CFR part 748. The FDICâ€™s best practices have been categorized into the various stages of incident response: preparation, detection, containment, recovery, and follow-up.
Preparing for a potential security compromise of customer information is a proactive risk management practice. The overall effectiveness and efficiency of an organization's response is related to how well it has organized and prepared for potential incidents.
A key practice in preparing for a potential incident is establishing a team that is specifically responsible for responding to security incidents. Organizing a team that includes individuals from various departments or functions of the financial institution (such as operations, networking, lending, human resources, accounting, marketing, and audit) may better position the financial institution to respond to a given incident.
Another step in the development of a response program is to define what constitutes an incident. Identifying potential security incidents can make the possible threats seem more tangible, and thus better enable organizations to design specific incident-handling procedures for each identified threat.
The ability to detect that an incident is occurring or has occurred is an important component of the incident response process. Most financial institutions implement some form of technical solution, such as an intrusion detection system or a firewall, to assist in the identification of unauthorized system access. Activity reports from these and other technical solutions (such as network and application security reports) serve as inputs for the monitoring process and for the IRP in general. Identifying potential indicators of unauthorized system access within these activity or security reports can assist in the detection process.
During the containment phase, the institution should generally implement its predefined procedures for responding to the specific incident (note that containment procedures are a required minimum component). Institutions that have experienced incidents have generally found that the management escalation process was not only beneficial during the containment phase, but also proved valuable during the later phases of the incident response process.
Recovering from an incident involves restoring systems to a known good state or returning processes and procedures to a functional state. The goals in the recovery process are to eliminate the cause of the incident and ensure that the possibility of a repeat event is minimized. In the case of technical compromises, such as a network intrusion, the IRP can prompt management to update or modify system configurations to help prevent further incidents. Part of this process may include implementing an effective, ongoing patch management program.
During the follow-up process, an institution has the opportunity to regroup after the incident and strengthen its control structure by learning from the incident. Organizations can determine whether affected controls or procedures need to be strengthened, whether written policies or procedures need to be updated, or whether the financial institution needs additional personnel or technical resources.
The preceding best practices focused on the more common criteria that have been noted in actual IRPs. Some financial institutions have developed other effective incident response practices. These include:
- Testing the incident response plan (via walkthrough or tabletop exercises) to assess thoroughness.
- Implementing notices on login screens for customer information systems to establish a basis for disciplinary or legal action.
- Developing an incident grading system that quantifies the severity of the incident, helps determine if the incident response plan needs to be activated, and specifies the extent of notification escalation.
- Establish a list of information security experts, in case the financial institution does not have the expertise to handle or investigate the specific incident (especially regarding technical compromises).
- Establishing evidence-gathering and handling procedures aimed at preserving evidence of the incident and aiding in prosecution activities.