incident response plan Archives

09 Nov 2022

Banks, Credit Unions, Security Kai Xu 0 comment

Best Practices for Ransomware Prevention and Recovery

In the world of cybersecurity, an ounce of prevention is worth a pound of cure—especially when it comes to ransomware. Ransomware attacks hit a new target every 14 seconds, disrupting operations, stealing information, and exploiting businesses, according to the Cybersecurity and Infrastructure Security Agency (CISA). As a result of ransomware attacks, US Banks paid out nearly $1.2 billion in 2021, which is up by 188% from 2020 according to the Financial Trend Analysis report [PDF] on ransomware from the US Treasury’s Financial Crimes Enforcement Network (FinCEN). But banks and credit unions that consistently implement best practices can effectively prevent and recover from ransomware attacks.

Prevention Strategies

The ideal strategy is to keep ransomware assaults from happening in the first place, but prevention can be tedious and challenging. As a general practice, institutions should identify and address known security gaps that can enable a ransomware infection. (If there is a loophole, hackers will eventually find it.) Since human mistakes are the root cause of most security breaches, providing ransomware training for employees is a crucial step that institutions can take to reduce their cybersecurity risk. Ransomware awareness training can help staff identify, respond to, and circumvent attacks as well as test their knowledge in a safe environment. Institutions can also limit their security risk by adhering to the principle of “least access” to grant employees the minimum levels of access or permission needed for their job.

As another best practice, institutions can also take a stricter stance on the technical aspects of cybersecurity. They can employ intelligent network design and network segmentation to limit risk by restricting ransomware intrusions to a portion of the network instead of the whole system. Institutions should also have overlapping security solutions to provide layered protection for their systems and networks. Then if a single security element fails, another layer will be in place to compensate.

Response and Recovery Tactics

Even with multiple protective measures in place, there is only so much financial institutions can do to avert a ransomware attack. When a breach happens, the institution must respond immediately to mitigate the impact. This includes implementing pre-established processes for incident response, vendor management, business continuity, and other key areas. Bank management, for example, should have an incident response program to minimize damage to the institution and its customers, according to the Federal Financial Institutions Examination Council (FFIEC) IT Handbook’s Information Security booklet.

Having pre-defined procedures to declare and respond to an incident can be essential to effectively containing and recovering from a ransomware infection. While incident containment strategies can vary between different entities, they typically include the isolation of compromised systems or enhanced monitoring of intruder activities; search for additional compromised systems; collection and preservation of evidence; and communication with affected parties and often the primary regulator, information-sharing organizations, or law enforcement, according to the FFIEC.

In addition, restoration and follow-up strategies for incidents should address the:

elimination of the intruder’s means of access
restoration of systems, programs, and data to a “known good state” (using available offline or offsite backups)
the initiation of customer notification and assistance activities consistent with laws, regulations, and interagency guidance
monitoring to detect similar or further incidents

Another step in the recovery process might involve notifying an insurance carrier—if the institution has ransomware coverage. However, cyber insurance might not prove to be the ultimate remedy: A policy exclusion could keep the carrier from paying the claim. Or the settlement amount may not fully compensate for the institution’s intellectual property losses, revenue reduction, tarnished reputation, and other damages.

Augmenting Internal Resources

With the growing complexity of ransomware, it can be challenging for institutions to react to and recover from a cyberattack. However, those with limited internal resources can get help from a third-party cybersecurity expert to manage the process. Safe Systems, for instance, offers multi-layered security services that make it easier for community banks and credit unions to enhance their cybersecurity posture, so they can be better equipped to prevent, respond to, and recover from a ransomware attack. For more information about this critical topic, read our white paper on “The Changing Traits, Tactics, and Trends of Ransomware.”

30 Mar 2022

Banks, Compliance, Credit Unions The Safe Systems Compliance Team 0 comment

Get Prepared for the New Computer-Security Incident Notification Rule

As of April 1^st, financial institutions are expected to comply with new cyber incident notification requirements for banking organizations and their third-party service providers. The Computer-Incident Notification Rule, as it’s officially called, is designed to give regulators early awareness of emerging threats to banking organizations and the broader financial system, including potentially systemic cyber events. The final rule—approved last November by the Federal Deposit Insurance Corporation (FDIC), Federal Reserve, and Office of the Comptroller of the Currency (OCC)—takes effect on April 1, 2022, with full compliance extended to May 1, 2022. (To date, the NCUA has not adopted the new rule, although it’s possible they may at some point. Credit Unions should check with their regulator for notification expectation specifics.)

Understanding the Regulations

To meet the upcoming deadline, financial institutions need to be well versed in the intricacies of the new rule. The rule has two components:

The first part requires a banking organization to promptly notify its primary federal regulator of any “computer-security incident” that rises to the level of a “notification incident.”
The second part requires a bank service provider to notify each affected banking organization customer as soon as possible when the bank service provider determines that it has experienced a “computer-security incident” that has caused, or is reasonably likely to cause, a material service disruption or degradation for four or more hours.

Focusing on the financial institution expectations under the final rule, a couple of definitions must be understood.

A “computer-security incident” could include almost anything: a hardware or software failure, an innocent mistake by an employee, or a malicious act by a cybercriminal. However, the incident must result in actual or potential harm to the confidentiality, integrity, or availability of an information system or the information the system processes, stores, or transmits.
A “notification incident” is defined as a significant computer-security incident that has materially disrupted or degraded a banking organization in at least one of these areas:
its ability to carry out banking operations, activities, or processes, or deliver banking products and services to a material portion of its customer base in the ordinary course of business
its business line(s), including associated operations, services, functions, and support that, upon failure would result in a material loss of revenue, profit, or franchise value
its operations, including associated services, functions, and support, as applicable, the failure or discontinuance of which would pose a threat to the financial stability of the United States.

In the event an incident rises to the level of a “notification incident,” the banking organization’s primary federal regulator must receive this notification as soon as possible, and no later than 36 hours after the banking organization determines that a notification incident has happened.

Recognizing the Gray Areas

The words “material” and “materially” are key terms; so much so that they are used 97 times in the 79-page guidance about the ruling. But beyond an “enterprise-wide” impact, the regulation does not precisely define these concepts, so financial institutions will need to specify what this term means to their organization as a whole. And since a determination of materiality is a prerequisite to starting the 36-hour “clock” for notification, they should do so ahead of time. The undefined nature of “material” to each organization creates a gray area open for interpretation that not only allows institutions some flexibility in this area but also opens the door for differences in opinion between an institution and its regulator.

In another gray area, the rule does not impose any specific recordkeeping requirements, which is a reduced burden. However, we strongly recommend keeping at least basic documentation in case the examiners ever question why your institution did or did not decide to escalate an event from a computer-security incident to a notification incident, and why it started the “clock” when it did.

Preparing for the Unknowns

At this stage, there are some unknowns about the implications of the new cyber incident notification requirements. One of the unknowns discussed in our recent webinar was related to an official contact person and method for each primary federal regulator. This has since been addressed and we recommend incorporating the following verbiage into the regulator notification section of your Incident Response Plan:

FDIC institutions:

Notification can be made to the case manager (primary contact for all supervisory-related matters), to any member of an FDIC examination team if the event occurs during an examination, or if the primary contact is unavailable, the FDIC may be notified by email at: incident@fdic.gov.

OCC Institutions:

Notification may be done by emailing or calling the OCC supervisory office. Communication may also be made via the BankNet website, or by contacting the BankNet Help Desk via email (BankNet@occ.treas.gov) or phone (800) 641-5925.

Federal Reserve Institutions:

Notification may be made by communicating with any of the Federal Reserve supervisory contacts or the central point of contact at the Board either by email to incident@frb.gov or by telephone to (866) 364-0096.

Another unknown as of the date of this post: Will the State banking regulators also require notification if a federal regulator is notified? The unofficial initial indication we have received is ‘Yes,’ but it would be good practice for institutions to check with their state regulator. Chances are regulators will request this, but whether or not it will be a requirement is still unknown.

Steps to Take Now

There are additional steps financial institutions can take now to be better prepared to address the requirements of the computer-Security Incident Notification Rule.

Our primary recommendation is for institutions to expand the notification section of their incident response plan to include the criteria for determination of a notification incident, and to add the regulator contact information above.
Institutions should also define “materially” for their organization and predetermine the meaning of “materially disrupted or degraded,” or what constitutes a “material portion” of their customer base.
Third-party contracts should contain verbiage obligating them to notify your institution under certain circumstances as required by the new rule. We also strongly advise designating an official contact person within your institution — whether it’s the CEO, CIO, or ISO — who should receive incident notifications from your third parties. It’s also prudent to specify a backup contact person—and make sure vendors know who the primary and alternate contacts are to ensure a smooth notification process.

For more information about this important topic, access our webinar on “New Cyber Incident Notification rules: How to Get Prepared”, or this recent blog post from Compliance Guru.

01 Dec 2020

Banks, Compliance, Credit Unions The Safe Systems Compliance Team 0 comment

Why Documentation is an Essential Priority During the COVID-19 Pandemic

While financial institutions have spent the last nine months focused on pandemic response and ensuring critical services remain available to their customers and members, there are other key areas of consideration to ensure their institutions remain compliant and can thrive in the future, including documentation. Unfortunately, few financial institutions are adequately documenting their efforts and new strategies as they are being implemented. Below are three key reasons why they really should.

1. Regulatory Expectations

Examiners will expect to see how financial institutions have handled the pandemic and that all of the lessons learned are reflected in their business continuity management plans (BCMP).

Some key questions regulators may ask regarding pandemic response include:

What have you learned from this event?
What have you done to enhance your pandemic plan based on those lessons learned?
Prior to this event, had you analyzed your business processes and their interdependencies, and prioritized them by recovery time?
Have you identified employees with job duties capable of being performed remotely? If so, did they have secure, reliable, remote access?
If those job duties are highly specialized, or highly critical, did you have alternate personnel identified and pre-trained to step in when needed?

2. Key Lessons Learned

All banks and credit unions must take a different approach to pandemic planning that fits well with their institution’s unique needs. They need to consider all of the challenges they’ve faced throughout the pandemic and apply key lessons learned to enhance their operations, including the importance of cross-training staff, enhancing security measures, succession planning, or improving technology for an employee to work at home. Until the pandemic passes, financial institutions should continue to reference their business continuity plans and document the entire process to create a blueprint for reference if a similar situation arises again in the future.

3. Strategic Planning

According to the FFIEC, an entity’s strategic planning should be developed to address all foreseeable risks, and these risks should cover the potential impact on personnel, processes, technology, facilities, and data. Throughout the pandemic, financial institutions should track what they are doing, how they are doing it, and whether any new procedure should be included in their existing crisis management or response plan.

The key is for institutions’ steering or strategic planning committee to stop periodically and document—or backfill information after the fact (at least a month or a quarter later.) Failing to document this process will result in institutions returning to business as usual after the crisis subsides and potentially making serious mistakes if a pandemic situation occurs in the future.

To learn more about pandemic response and key priorities for financial institutions, download our latest white paper, “Navigating the Coronavirus pandemic: Best Practices for Pandemic Planning and Key Lessons Learned for Community Banks and Credit Union.”

08 Oct 2020

Banks, Compliance, Credit Unions Jamie Davis 0 comment

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.”

21 Sep 2020

Banks, Compliance, Credit Unions Tom Hinkel 0 comment

Three Often Overlooked Elements of an Effective and Compliant Incident Response Plan (IRP)

In today’s security environment, it’s not if a cybersecurity incident will impact your institution, but when and how big? That’s why having an effective and compliant incident response plan (IRP) is so important to ensure your institution is prepared for the unexpected and equipped to recover.

When a financial institution experiences a cyber incident, the information security officer (ISO), along with the incident response team, must assess the situation and determine if this incident has resulted (or might reasonably result) in exposure of non-public personal information (NPI). If the answer is “yes,” then the team must activate the IRP to contain and control the situation and ensure quick and efficient response and recovery. When activating an IRP, there are three key elements that we sometimes see financial institutions overlook:

1. Incident Response Team Participation

When building your incident response team, it is important to include representatives from each functional unit of the institution. Too often the incident response team consists of IT personnel only. While an incident might seem to be isolated to a certain department (like IT), there could be residual effects impacting other parts of the organization.

For example, let’s say you have an incident that seems to be limited to a group of customers who received a phishing email appearing to be from the institution asking them to click a link to change their ebanking password.

In this situation, you may be inclined to simply involve IT and deposit operation teams. However, because there could be a ripple effect that goes beyond that one incident, you’ll want to include other departments such as lending, human resources, and accounting. For instance, the customer could have a lending relationship or home equity line with the institution that might be impacted as well. Or, the customer could also be a vendor. Furthermore, with the increased possibility of pretexting during a social engineering attack, the Human Resources department may want to use the incident as an opportunity to conduct refresher training to ensure employees know how to verify customer information. As such, it’s important to have all your bases covered and include all functional units on the incident response team.

2. Designated Spokesperson and Social Media Monitoring

Once you’ve activated your plan, it’s important to understand that you cannot simply hope to contain the incident within your organization. A cyber incident may involve key external stakeholders including the Board and senior management, regulatory agencies, law enforcement, third-party service providers, insurance, legal, customers, and may even attract the attention of the media.

When an incident occurs, it is important to have designated spokespeople pre-selected to communicate with each external stakeholder that needs to be informed. For example, you’d want to have your IT admin in contact with the point person at your outsourced IT company because they most likely have a direct relationship with this vendor. However, you probably wouldn’t want that same person reaching out to regulators or customers. A member of senior management would be the best choice for that. In addition, you should designate one or more individuals to be your media contact. Don’t forget to have someone monitoring social media channels to ensure news about the incident isn’t spreading online potentially exposing you to reputational harm.

When developing an incident response plan, designating spokespeople to communicate with external stakeholders and monitoring online social media channels often gets overlooked because the main focus is usually on how the incident happened and how to fix it quickly. The moment the incident response plan is activated it is critical for the incident response team to assign these roles and keep these individuals updated with any interactions they may have with stakeholders.

3. Detailed Incident Documentation and Log Retention

It is imperative that the incident response team creates detailed documentation outlining everything that occurred from the time the event was first identified, even before it became classified as an incident. Again, this is often overlooked as the team engages in containment and control activities. However, regulators, insurance companies, third-party forensics companies, the Board, law enforcement, etc., will need full details when and if they are drawn into the incident. The documentation should detail who responded, what actions were taken, when each action was taken, (the timeline), and why and how (if known) the incident occurred.

Equally important is the retention of any data logs that might assist with the response and recovery phase. Often insurance carriers will need this information if they are involved, and forensic firms will definitely need it if they are drawn into the investigation phase.

We’ll dive deeper into security event logging and best practices for responding to a cyber incident in a future blog post.