By Jim Baird
Incident Response Plans (IRP) have been expected by banking regulators for years. But with the ever-increasing threats of cybercrime, malware, breaches, ransomware and other cyber threats, the expectations have morphed into having a far more robust, comprehensive, cyber-ready and tested IRP. Further, the Federal Financial Institutions Examination Council’s Cybersecurity Assessment Tool devotes an entire domain to the topic (Domain 5: Cyber Incident Management and Resilience).
Next time you update your IRP, be sure to keep it simple. Start with a high-level summary that is only a page or two. Some people will only read the first part 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 and how to make contact (7×24). Make this section easy to find in the IRP and keep the contact info up to date.
After the summary section, capture the details. The following are areas to include:
Include a description and definition of the IRT membership and leadership. Determine and document any supporting resources that might be needed during an incident (war room, cell phones, hotel rooms, technology, etc.) and how to acquire.
Document assets, including the physical and virtual location of customer data, 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 to identify a work-around solution. Don’t include the documents in the IRP, only indicate where current copies are available.
Verify event logging and auditing is occurring on key systems (core, email, AV, web, VPN, etc.). This will be used to determine how an attacker got in, and without the log data it may be impossible to locate and secure the breach point. Also verify video surveillance and retention.
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.
Standard operating procedures throughout the company should include references to the IRP and security awareness. It is every employee’s responsibility to report any incident or suspicious activity.
Proactively engage with law enforcement, legal counsel, critical vendors, etc., and understand their roles if you declare an incident, or yours if they declare an incident (i.e., declaration of an “incident” by your core hosting vendor may 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 they are on the IRT.
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 you didn’t 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 breach of access 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: whom 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) who evaluates a situation to determine if an incident has occurred and if so, must act quickly to preserve evidence and data. If you don’t immediately have someone in mind with such skills, you should proactively get a first responder trained or identify a third party who can fill the role.
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 in the IRP 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 if called upon.
If you do not have the expertise to manage a cyber incident, plan for how to obtain the skills on short notice. If a breach of debit/credit card data occurs, per Payment Card Industry Data Security Standard 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.”1
Additionally, there may be specific card network requirements; of which many are good suggestions even if you do not have card data exposure. As an example, Visa has special requirements to preserve evidence and facilitate an investigation.2
This is the heavy lifting part of an incident response, when malware is removed, systems patched, software updated, firewall rules tightened, encryption keys replaced and compromised data restored. If there is any good news, budgets for security improvements become “flexible” after a security incident.
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, advise those affected of remediation and protective recommendations. Audiences to consider are the 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.
Cyber incidents may need to be evaluated by a forensic examiner (see PCI-DSS reference above). 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; if so, replace as needed. If non-cyber, then resolve procedural or facility problems that allowed the incident to occur.
Finally, determine “what went well and what didn’t” and work on improvements. You should review and update the Information Security Program, Incident Response Procedure, security monitoring, facilities info (floorplans, backup power, utility cut-offs, etc.) and anything else that needs improvement to prevent a similar incident from recurring. Determine the total cost of the incident, document lessons learned and provide a report to management.
If a breach occurs and card data is involved, 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 include in the IRP.
If you haven’t tested your plan, you do not have a plan. Schedule a time when your team can talk through the IRP to ensure familiarity with it, and evaluate the plan by conducting a tabletop exercise 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 Processes exercises conducted by Financial Services Information and Analysis Center. They are free, and open to most financial institutions. For more info go to: https://www.fsisac.com/CAPP-PPISC.
Jim Baird, CBCP, is an information security auditor with 10-D Security (www.10dsecurity).