Incident Response Plan

Responding to Robberies

Comparing Physical and Cyber Robberies in Banking

Ask anyone outside of the banking industry"What do banks have in place for responding to robberies?" and you will likely get a response referring to silent alarms, surveillance video, guards, tracking systems and/or exploding dye packets.  It's assumed, and obvious, that banks have robbery prevention and response plans.  Now consider this: in 2010 the average bank robbery netted around $7,500.

The Importance of Incident Response Plans (IRP) in Cybersecurity<

But what about cyber theft? Determining average bank losses for cyber theft is harder to do, since many (if not most) institutions' cyber losses don't get reported to law enforcement or make the news.  Now ask"What do banks have in place to respond to cyber robberies?" and you are likely to get a less certain or silent response.  A good answer would be "They have an Incident Response Plan."

Incident Response Plans (IRP) have been expected by banking regulators for years.  But with the ever-increasing threats of cybercrime, malware, breaches, Ransomware, etc.  the expectations have morphed into having a far more robust, comprehensive, cyber-ready, and tested IRP.  Further, the FFIEC Cybersecurity Assessment Tool devotes an entire Domain to the topic (Domain 5: Cyber Incident Management and Resilience).  Consider the following key elements the next time you update your IRP.

Getting Started: Key Elements for Your IRP

Start with a high-level summary that is only a page or two.  Some people will only read the first of a lengthy plan document, so cover all the highlights in this summary section.  Include a short description of what type of events the IRP covers, how to declare an incident, roles and responsibilities, and communication reminders.  A simple flow diagram with initial contact info works well too.

Include who is on the Incident Response Team (IRT) and how to make contact (7X24).  Make this section easy to find in the IRP and keep the contact info up to date.

After the summary section you'll then need to put the effort into capturing the details.  There are many examples or templates out there for what to include in an IRP if you are starting from scratch.  The following are thoughts to consider when you are creating or reviewing your IRP.

Preparing for Incidents: The Role of Forethought

Make sure the IRP includes a description and definition of the Incident Response Team membership and leadership.  Determine and document any supporting resources that might be needed during an incident response (war room, cell phones, hotel rooms, technology, etc.) and how to acquire.

Document assets, including: The physical and virtual location of customer data, network diagrams (network devices and systems), and copies of device configurations (firewalls, routers, etc.).  During a high-stress situation is NOT the time to find out the network diagram hasn't been updated since the Y2K project.  You may need it to find where the problem started, or in identifying a work-around solution.  Don't include these items in the IRP, only indicate where current copies are available.

Ensure event logging and auditing is occurring on all relevant systems (core, email, AV, web, VPN, etc.).  This may be the only way you have to determine how an attacker got into your systems, and without the log data it may be next to impossible to locate and secure the breach point.  If you are unable to definitively determine HOW you were breached, there won't be a lot of restful nights in your foreseeable future.

Verify video surveillance and retention.  You have video of the teller lines and ATMs (right?), but do you have it for the data center, building access points, and other key areas within the bank?

Document and verify location and status of data backups, and be sure to note where your backup system's encryption keys are stored.

Include a form for memorializing response actions as they occur.  Don't rely on individuals' memories or ad hoc note taking.  Retain timeline notes for the after-action and lessons learned report, and maybe for insurance or legal purposes.

Ensure standard operating procedures throughout the bank include references to the IRP and security awareness.  It is EVERY employee's responsibility to be aware of AND report any Incident or suspicious activity.

Proactively engage with law enforcement, legal counsel, critical vendors, etc.  and understand their involvement or abilities if you declare an incident, or what they might expect if they are the one to declare an incident (i.e., declaration of an"incident" by your core hosting vendor probably will result in your bank declaring an incident too).

Your IRT will also need periodic training on the IRP.  Go over the plan and their roles during an incident.  An actual incident is not the time to set expectations or to break the news to them they are on the IRT.

Identifying an "Incident": The Power of Definitions

Define"Incident" carefully - Clearly indicate what is in scope and explicitly state it includes Cyber incidents.  Don't include minor events, otherwise you may have auditors asking"Why didn't you document a lessons learned report?" for some minor infraction inadvertently included in the scope.  Where possible, set thresholds for events that could trigger an Incident Response, such as an access breach of the core system, disclosure of nonpublic personal information, dollar loss over $(pick your limit), etc.

Also define incident triggers, or what events necessitate notification of the IRT.  Detail the initial actions: who to contact, who will be in charge during an incident (i.e., incident commander), and incident analysis/assessment.

Initial detection of an incident can be obvious ("My laptop full of customer data is missing!") or obscure, such as a log file that doesn't look right.  It can be the technical equivalent of"thinking" you smell smoke versus SEEING flames.  Regardless, you must take action quickly.  The first responder is the person(s) that can evaluate a situation to determine if an incident has occurred, and if it HAS then they must act quickly to preserve evidence and data.  If you don't immediately have a person in mind with such skills you should proactively get a first responder trained or identify a third-party that can fill the role.

Taking Control: The Importance of Containment

Incidents can spiral out of control quickly.  First responders must understand it is imperative to immediately inform management and engage others to assist.  Include a section to notate how to escalate the response to ensure appropriate resources are available.  If that means having third-party involvement, get that in writing and clearly understand what they can provide and how quickly they will be able engage resources when called upon.

Do you have the expertise to manage a cyber incident? If not, plan for how to obtain the skills on short notice.  If there is a breach of debit/credit card data, per PCI-DSS rules your bank"may be required to engage forensic investigators approved as part of the PFI Program to investigate the Security Issue, determine root cause, and report back to affected Participating Payment Brands and others." (see https://listings.pcisecuritystandards.org/documents/PFI_Program_Guide_v3.0.pdf)

Additionally, there may be specific card network requirements; many are good suggestions even if you do not have card data exposure.  As an example, Visa has special requirements to be followed in order to preserve evidence and facilitate the investigation.  The following requirements have been excerpted from Visa's Fraud Investigation Procedures (https://usa.visa.com/dam/VCOM/download/merchants/cisp-what-to-do-if-compromised.pdf):

• Do not access or alter compromised system(s) (i.e., don't log on at all to the compromised system(s) and change passwords; do not log in as ROOT).  Visa highly recommends the compromised system not be used to avoid losing critical volatile data.
• Do not turn the compromised system(s) off.  Instead, isolate compromised systems(s) from the network (i.e., unplug network cable).
• Preserve all evidence and logs (i.e., original evidence, security events, web, database, firewall, etc.)
• Document all actions taken, including dates and individuals involved.
• If using a wireless network, change the Service Set Identifier (SSID) on the wireless access point (WAP) and other systems that may be using this connection (with the exception of any systems believed to be compromised).
• Block suspicious IPs from inbound and outbound traffic.
• Be on high alert and monitor traffic on all systems with cardholder data.

Request a Quote

Cleaning Up: The Eradication Phase

This is the heavy lifting part of an incident response, where you roll up the sleeves and remove any malware, patch systems, update software, tighten up firewall rules, replace encryption keys, restore compromised files and close-up the attack entry points.  Clean and disinfect.  The good news, if there is any, is that budgets for security improvements seem to become"flexible" after a security incident.  You probably shouldn't try to acquire a Tesla, but if you know your IDS is outdated it might be the time to get that replaced.  Better yet, push for it BEFORE an incident, then remind management some quiet day their wise investment has paid off.

Communicating Effectively: Keeping All Parties Informed

Communications should occur throughout an incident event, but it's worth repeating to include references to all entities you might have to contact.  If customer data has been compromised then advise those affected of remediation and protective recommendations.  Audiences to consider in the communications plan: IR Team, management, staff, law enforcement, regulators, customers (directly affected only and/or all customers), and media.  Employees should know how to respond to media queries, and customer-facing staff will need a consistent and unified message they can provide.

Recovering from Incidents: Regaining Normalcy

Cyber incidents may need to be evaluated by a forensic examiner (see PCI-DSS reference above).  Ensure problems have been resolved and proactive steps have occurred to prevent follow-on events.  If the incident was a cyber-attack, you will need to determine if naming conventions, email addresses, contact info, security certificates, etc.  have been compromised and if so replace as needed.  If it was a non-cyber event then resolve SOP issues or other facility problems that allowed the incident to occur.

Reflecting on the Incident: Learning Lessons

Finally, determine"what went well" and"what didn't go well" and work on improvements.  You should review and update your Information Security Program, Incident Response Procedure, security monitoring, facilities info (floorplans, backup power, utility cut-offs, etc.) and anything else that might be an area for improvement to prevent a similar incident from recurring.  Ensure sufficient preventative and detective controls, as well as personnel skills and awareness, are in place.  It might be a good idea to determine the total cost of the incident, and if cards/accounts were breached figure the cost-per-card/account.  Document lessons learned, and provide a report to management and/or your board of directors.

PCI requirements - If card data is involved in a breach then specific rules come into play for what is expected at every step of the incident response.  Reference the respective card issuer's requirements and make sure your plan includes those steps.

Testing Your Plan: The Final Step in Preparation

To wrap this up, as the saying goes"If you haven't tested your plan, you do not have a plan." Schedule a time when you can get your IRT members together, talk through the plan to ensure everyone is familiar with it, and then evaluate the plan by conducting a tabletop exercise with a scenario simulating an incident.  Document the results and update the IRP as needed.

If you aren't comfortable developing your own tabletop exercise then consider participating in the annual"Cyber-Attack Against Payment Systems" (CAPS) exercises conducted by FS-ISAC.  It is free, and open to most financial institutions.  For more info go to: https://www.fsisac.com/events

Authored By: Jim Baird, CBCP

  Download Blog