Best Practices for Developing a Compliant Cyber Incident Response Program

If you think a cyber incident won’t impact your financial institution, you are seriously underestimating the lengths cybercriminals will go to steal your customers’ or members’ non-public information. According to a new report from NuData Security, a Mastercard company, financial institutions receive the highest percentage of sophisticated attacks (96%) amongst all industries.

As cybercriminals continue to exploit organizations and increase the quality of their attacks, financial institutions need to have a compliant incident response plan in place to control, contain, and recover from a potential cyber incident quickly and efficiently.

Safe Systems held a webinar discussing what a compliant cyber incident response plan should look like and shared key best practices community banks and credit unions should use to effectively document a cyber incident. In this blog, we’ll cover a few of the key points from the webinar.

Elements of a Compliant Incident Response Program

The requirements for incident response have changed significantly since 2005. The guidance was broad enough to encompass many of the events that are occurring today including cybersecurity and pandemic-related events. According to the Federal Deposit Insurance Corporation (FDIC), there are five key elements of a compliant incident response program:

• Assessing the nature and scope of an incident and identifying what customer information systems and types of customer information have been accessed or misused
• Notifying its primary federal regulator as soon as possible when the institution becomes aware of an incident involving unauthorized access to or use of sensitive customer information
• If required, filling a timely suspicious activity report (SAR), and in situations involving federal criminal violations requiring immediate attention, such as when a reportable violation is ongoing, promptly notifying appropriate law enforcement authorities
• Taking appropriate steps to contain and control the incident to prevent further unauthorized access or use of customer information
• Notifying customers when warranted in a manner designed to ensure that a customer can reasonably expect to receive it

Although these requirements have essentially stayed the same, there is one key change that has occurred in the FFIEC’s 2019 update to the Business Continuity Handbook. The guidance now requires financial institutions to reference or include the incident response plan (IRP) in the business continuity management plan (BCMP). While still acceptable to have a separate incident response plan, somewhere within your BCMP you must now reference the IRP.

How to Document and Maintain Evidence of an Incident

Documentation is a key component of incident response to provide auditors, examiners, and other stakeholders with key information about the abnormal event or incident. Initial steps include the recording of basic facts about the suspicious event before it becomes an official incident.

Key questions include:

• What specific abnormalities were noticed?
• Where were they discovered?
• When were they discovered?
• Who first noticed the abnormality or event and who did they notify/involve?
• If the event escalates to an incident, how did it happen, and what were the contributing factors that allowed it to happen?

If the event is categorized as an “incident,” you need to know how to document and maintain the evidence; what decisions were made; and the resulting actions taken. When enacting your containment strategies, part of that should involve collection and preservation of the evidence, including all the key records created by all the various technologies your institution uses. The guidance references that all financial institutions should have some type of logging intelligence. But which logs are most important for incident response?

When creating a logging strategy, there are five key challenges to consider:

• Sources – Logs are generated from various sources such as users, databases or file shares, endpoints, networks, applications, and cloud services. With so many logs coming from different sources, it’s important to be aware of all the systems and applications generating logs and know how to access them to monitor efficiently
• Log Volume – The volume can be different depending on the source. Some sources are quiet and easier to manage while other sources like network switches and firewalls are a constant torrent of volume and may be difficult to log. It’s important to determine what is realistic for your institution to store and manage
• Log Protocols – All of the various sources speak different languages or protocols. Some of them are sending emails using a language called simple mail transfer protocol (SMTP), while other sources like network switches are sending information using a constant stream of Syslog data. It is nearly impossible to create a centralized system that can speak all of these languages perfectly so you must determine how your institution will extract intelligence from the logs
• Log destinations – Once you’ve collected information, where are you going to send it? You’ll need to determine storage destinations for the different types of logs
• Log interaction – After you’ve built the logging platform, do you want it to be searchable? You’ll need to decide how you want to interact with the data and how long you will keep it. Adding data retention can become significantly more expensive depending on the time frame for storage

Different types of data likely require different lengths of time for retention. Your retention policy should outline the expected retention time frame for each data log. Institutions should carefully consider all these key challenges when building a logging strategy that fits their unique needs.

If you’d like to learn more about cyber incident response, download our recorded webinar, “Not If, But When: Best Practices for Cyber Incident Response.”