The Safe Systems Compliance Team – Page 2

06 Dec 2021

Hot Topics The Safe Systems Compliance Team 0 comment

UPDATE – New Proposed Cyber Incident Notification Rules Finalized

Last updated March 30, 2022.

Currently, financial institutions are required to report a cyber event to their primary federal regulator under very specific circumstances. This requirement dates back to GLBA, Appendix B to Part 364 and states that FI incident response plans (IRP’s) should contain procedures for: “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…”. Customer notification guidance is very similar. Institutions should provide notice to their customers as soon as possible: “If the institution determines that misuse of its information about a customer has occurred or is reasonably possible.” (It’s important to note here that a strict interpretation of “…access to or use of…” would generally not include a denial of access (DDoS) type of attack, or a ransomware attack that locks files in place. We strongly suggest modifying the definition of “misuse” in your incident response plan to say “…access to, denial of access to, or unauthorized use of…”.) However, with the issuance of the final rule (officially called “Computer-Security Incident Notification Requirements for Banking Organizations and Their Bank Service Providers”) institutions will have additional considerations that will require changes to your policies and procedures.

Background

Late in 2020 the FDIC issued a joint statement press release with the OCC and the Federal Reserve announcing the proposed changes. As is the case for all new regulations, they were first published in the Federal Register, which started the clock on a 90-day comment period, which ended on April 12 of 2021. (We took an early look at this back in July.)

The new rule was approved on November 2021 by the OCC, Federal Reserve, and FDIC¹ collectively, with a proposed effective date of April 1, 2022, and a compliance date of May 1, 2022. Simply put, it will require “…a banking organization to provide its primary federal regulator with prompt notification of any “computer-security incident” that rises to the level of a “notification incident.”

To fully understand the requirements and new expectations of this rule, there are actually three terms we need to understand; a computer security incident, a notification incident, and “materiality”.

Keys to Understanding the New Rule

A computer-security incident could be anything from a non-malicious hardware or software failure or the unintentional actions of an employee, to something malicious and possibly criminal in nature. The new rule defines computer security incidents as those that 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, or is reasonably likely to materially disrupt or degrade, a banking organization’s:

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
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; or
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.

The third term that needs to be understood is “materiality“. This term is used 97 times in the full 80 page press release, so it is clearly something the regulators expect you to understand and establish; for example, what is a “material portion of your customer base”, or “material loss of revenue”, or a “material disruption” of your operations? Unfortunately the regulation does not provide a universal definition of materiality beyond agreeing that it should be evaluated on an enterprise-wide basis. Essentially, each banking organization should evaluate whether the impact is material to their organization as a whole. This would seem to suggest that these material threshold levels would need to be defined ahead of time, perhaps as a function of establishing Board-approved risk appetite levels or perhaps it could be tied to the business impact analysis? Future clarification may be necessary on the best approach to establishing the determination of materiality in your organization, but since the term is at the centerpiece of the rule, and initiation of the 36 hour threshold for notification doesn’t begin until it has been established, we can definitely expect materiality to be a part of the discussion in the event of regulator scrutiny in this area.

Any event that meets the criteria of a notification incident would require regulator notification “as soon as possible”, and no later than 36 hours after you’ve determined that a notification event has occurred. It’s important to understand that the 36 hour clock does not start until there has been a determination that the incident has been classified as a notification event, which only happens after you’ve determined you’ve experienced a computer-security incident.

The Safe Systems Compliance Team has created a detailed decisioning flowchart to assist with your understanding of this new rule. Click here for a copy of the flowchart.

Notification can be provided to the “…appropriate agency supervisory office, or other designated point of contact, through email, telephone, or other similar method that the agency may prescribe.” No specific information is required in the notification other than that a notification incident has occurred. The final rule also does not prescribe any specific form or template that must be used, and there are no recordkeeping requirements beyond what may be in place if a Suspicious Activity Report (SAR) is filed in connection with the incident. The agencies have all issued additional “point-of-contact” guidance:

For FDIC institutions:

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

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

For 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

One final note, we’ve received indications that at least some State Banking regulators will require concurrent notification of any incident that rises to the level of a notification incident. Check with your State regulators on if (and how) they plan to coordinate with this new rule.

Third-party Notification Rules

In addition to FI notification changes, there will also be new expectations for third-party service providers, like core providers and significant technology service providers (as defined in the BSCA). Basically, it would require a service-provider to “…notify at least one bank-designated point of contact at affected banking organization customers immediately after experiencing a computer-security incident that it believes in good faith could disrupt, degrade, or impair services provided subject to the BSCA for four or more hours.”

Furthermore, if you are notified by a third-party that an event has occurred, and the event has or is likely to result in your customers being unable to access their accounts (i.e. it rises to the level of a notification incident), you would also be required to report to your regulator. However, it’s important to note here that not all third-party notification incidents will also be considered bank regulator notification incidents. It is also significant that the agencies will most likely not cite your organization because a bank service provider fails to comply with its notification requirement, so you will likely not be faulted if a third-party fails to notify you.

Next Steps

There will undoubtedly be clarification on the specifics of rule implementation as we digest feedback from regulatory reviews next year, and we’ll keep you posted as we know more. In the meantime, aside from having internal discussions about what constitutes “materiality” in your organization, the new rules will likely also require some modifications to your Incident Response Plan (IRP), and possibly to key vendor contracts. For FDIC institutions, the “as soon as possible” regulator notification provisions of FIL-27-2005 already in your IRP will have to be amended. For all critical vendors, ensure that contracts contain verbiage committing them to the 4 hour outage criteria for notification, and that you’ve identified a contact person or persons within your organization to receive the alert.

¹ As of this date the NCUA has not signed off on these rules, although they may at some point.

14 Sep 2021

Reading Between the Lines The Safe Systems Compliance Team 0 comment

FFIEC Replaces, and Expands, the Operations Handbook

Back in June of this year the FFIEC released an update to the 2004 Operations Handbook called Architecture, Infrastructure, and Operations (AIO). As the lengthier name implies, this was not simply an update, it also greatly expanded the scope of operations to include architecture and infrastructure principles and practices. This reflects the tight integration between and among the various separate but related functions that comprise the IT environment, and the recognition that inadequate coordination and oversight of these components may result in various risks including credit, liquidity, operational, compliance, and reputation. Similar to the BCMP Handbook back in 2019, it encourages financial institutions to take an enterprise-wide, process-based approach.

Another similarity between this IT Handbook and the others released in the past couple years is the use of the term “entities” instead of “institutions” to describe the intended audience. “Entities” include depository financial institutions, nonbank financial institutions, bank holding companies, and third-party service providers. (Emphasis added.) Using the “entities” terminology effectively eliminates the distinction between the expectations for an institution and those of the key third-parties that provide the interdependencies necessary for the delivery of an institutions’ products and services. And this provides perhaps the most important take-away from this Handbook for the vast majority of institutions that out-source core and technology services; architecture and infrastructure (and to a lesser degree, operations) are largely the responsibility of your provider. Indeed the Handbook seems to recognize this, making no fewer than 70 references to the importance of understanding the “complexity” of the entity as specific principles and practices are considered. This applies to the entity and the examiner alike, and hopefully will translate into a more optimal examination experience for smaller, less complex (and largely outsourced) community financial institutions as examiners adjust their scope and objectives accordingly. (Of course it’s important to understand that the AIO burden does not necessarily decrease in these outsourced scenarios, it simply shifts to the third-party oversight!)

Another similarity between recent Handbooks is the claim that the “…booklet does not impose requirements on entities. Instead, this booklet describes principles and practices that examiners review to assess an entity’s AIO functions.” We’ve always found this statement to be somewhat contradictory, as anything an examiner may use to evaluate, or grade, your practices becomes in effect a defacto requirement. Nonetheless, this statement (along with the aforementioned entity “complexity”) may provide just enough leeway for the basis of honest differences in opinion between how (and if) specific principles and practices are implemented within your institution. In fact, this could prove to be very useful as a “push-back” if an auditor or examiner tries to use the booklet to rationalize the implementation of a specific practice.

All that said, here are a few actionable observations from the booklet:

The importance of a strategic planning process to assure that the IT strategic plan aligns with the overall enterprise-wide strategic plans. Make sure your project planning includes a way to link one or more specific enterprise goals and objectives to every IT initiative.
The importance of IT asset management (ITAM). Specifically, “Management should have a comprehensive inventory of its electronic (or digital) and physical information assets to adequately safeguard them against reasonably foreseeable threats.” Simply put, you can’t secure it if you don’t know you have it.
The importance of oversight of third-party service providers. This goes without saying, but especially for smaller institutions where system architecture and infrastructure are outsourced. Expect significantly increased scrutiny in this area. (A case in point, we’re keeping an eye on this.)
The importance of accurately depicting the interconnectivity between entity assets and third-parties by creating and maintaining up-to-date network, data flow, and business process flow diagrams.
The importance of building resilience into your AIO components and functions by proactively anticipating the impact of a disruptive event in the design, implementation, and operation of your IT systems and processes.
The importance of an internal control self-assessment process for management and work teams to monitor and continuously improve the effectiveness of IT operations controls.

It would be prudent to review the entire operational controls section of the booklet, as many of these apply regardless of whether you have a dedicated data center, or only a server room or closet.

In summary, we’ll have to see how (and how quickly) the new expectations will be integrated into the existing IT examination work program, but we think it’s safe to assume the items above will certainly be among the areas of increased focus. As always, Appendix A contains the Examination Procedures and can be a valuable pre-exam resource. (This 11-year-old post is still relevant!) It also bears repeating that even if you outsource the “A” and “I” components, the day-to-day “O” elements* are still largely your responsibility, as are Board and management committee reporting.

* IT operations include the tactical management of technology assets and daily delivery of services to capture, transmit, process, and store transactions and information that support the entity’s overall business processes.

17 Aug 2021

Quick Bytes The Safe Systems Compliance Team 0 comment

New FFIEC Guidance for Access and Authentication

In response to an expanded cybersecurity threat landscape, the FFIEC just issued an update to agency expectations for access and authentication to financial institution products and systems. This update replaces both the 2005 and the 2011 authentication guidance, and has been extended beyond digital banking (ebanking) customers to include everyone and everything that might have access, such as employees, third parties, and system-to-system communications. Perhaps in recognition of the highly outsourced and interconnected nature of these services, the guidance makes it clear that the guidance is applicable “…whether the financial institution or a third party, on behalf of the financial institution, provides the accessed information systems and authentication controls.” (Emphasis added.)

The new guidance recognizes that the potential access points by which an attacker might compromise an institution have greatly increased due to new technologies and remote access capabilities and because of this, existing authentication methods (like single-factor authentication) may no longer be sufficient. They also cite recent data breaches at financial institutions as well as their service providers, such as credit bureaus. They strongly suggest that multi-factor authentication (MFA) in combination with other layered controls like least-privilege user access can be more effective at mitigating risks.

As with everything else, this should be supported by a risk assessment, both prior to implementation of the service and/or authorization of access, and periodically thereafter. The assessment should include inputs enterprise-wide and from a range of business functions, and include the following elements:

The sources of risk, such as:
- An inventory of all information systems and components
- All digital products and customers, as well as all high-risk customers¹
- All users accessing the system, including employees, service accounts, and third-parties
- All high-risk users²
The reasonably foreseeable threats to the risk sources
The practices and controls employed to address the threats

Fully half of the guidance consists of an appendix with examples of practices and controls in the following areas:

Authentication Solutions
Password Controls
Access and Transaction Controls
Customer Call Centers and IT Help Desks Controls
Customer Controls
Transaction Logging and Monitoring Controls
System Access Controls for Users
Privileged User Controls
System and Network Design and Architecture Controls
Email Systems Controls
Internet Browser Controls

We expect that regulators will be scrutinizing your access and authentication practices, and our advice is (based on the results of your risk assessment) to use this appendix as a checklist of controls you either have already implemented, or plan to implement.

¹ High risk customers are those that initiate high dollar amount and high volume of transactions, where the sensitivity and amount of information accessed is higher, the irrevocability of the transaction, and the likelihood and impact of fraud.
² High risk users are those with access to critical systems and data; privileged users, including security administrators; remote access to information systems; and key positions such as senior management.

22 Jul 2021

Hot Topics The Safe Systems Compliance Team 0 comment

New Proposed Cyber Incident Notification Rules

Update: Since publishing this post, these rules have been finalized. We have a new post covering those details here.

We first wrote about incident notification over ten years ago, and based on feedback from our cyber testing experience, financial institutions are still struggling with the issue of whether or not to notify their customers and primary regulators. The conversation often comes down, to “do we have to notify?” Some institutions may choose to notify out of an abundance of caution, but most won’t unless it’s absolutely required, as regulator notification opens the door to additional examiner scrutiny, and customer notification may result in increased reputation risk. To confuse the issue a bit more, notification requirements are currently defined differently for a regulator than for a customer. And all this is about to change!

Notification Rules Background

Financial institutions are currently required to report an event to their primary federal regulator under very specific circumstances. This requirement dates back to GLBA, Appendix B to Part 364 and states that FI incident response plans (IRPs) should contain procedures for: “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…”

Customer notification guidance is very similar. Institutions should provide notice to their customers as soon as possible: “If the institution determines that misuse of its information about a customer has occurred or is reasonably possible.” (It’s important to note here that a strict interpretation of “…access to or use of…” would generally not include a denial of access (DDoS) type of attack or a ransomware attack that locks files in place. We suggest modifying the language of “misuse” to “…access to, denial of access to, or use of…”.)

Announcement of New Proposed Notification Rules

Late last year the FDIC issued a joint press release with the OCC and the Federal Reserve¹ announcing the proposed changes. The working title is a mouthful: Computer-Security Incident Notification Requirements for Banking Organizations and Their Bank Service Providers. As is the case for all new regulations, the proposed notification rules were first published in the Federal Register, which started the clock on a 90 day comment period that ended on April 12 of this year. When (or if) the rules will become law will depend on how long it takes regulators to compile, digest, and reconcile the comments received, which can take as long as 6 months to a year from the end of the comment period.

3 Key Terms of the New Regulator Notification Rule

One of the new rules “…would require a banking organization to provide its primary federal regulator with prompt notification of any computer-security incident that rises to the level of a notification incident.” There are actually three terms we need to understand here: a computer security incident, a significant security incident, and a notification incident.

A computer security incident could be anything from a non-malicious hardware or software failure or the unintentional actions of an employee to something malicious and possibly criminal in nature. Computer security incidents are those that:

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; or
Constitute a violation or imminent threat of violation of security policies, security procedures, or acceptable use policies.

In addition to the GLBA NPI guidance, banking organizations are already required to report certain instances of disruptive cyber-events and cyber-crimes through the filing of Suspicious Activity Reports (SARs) within 30 days, but no regulator notification is required unless these criteria are met. Even so, if notification is provided, the concern is that the 30-day window may not be timely enough to prevent other events.

This new rule would define a significant computer security incident as one that meets any of these criteria:

Could jeopardize the viability of the operations of an individual banking organization
Result in customers being unable to access their deposit and other accounts
Impact the stability of the financial sector

The proposed rule refers to these significant computer security incidents as notification incidents — the two terms are synonymous, so any event that meets the above criteria would require regulator notification “as soon as possible”, and no later than 36 hours after you’ve determined that a notification event has occurred.

We’ll see what the final rules look like, but at the moment there are no proposed changes to the customer notification requirements.

New Third-Party Expectations

In addition to FI notification changes, there will also be new expectations for third-party service providers, like core providers and significant technology service providers (as defined in the BSCA). Because these vendors are “…also are vulnerable to cyber threats, which have the potential to disrupt, degrade, or impair the provision of banking services to their banking organization customers,” it would require a service-provider to “…notify at least two individuals at affected banking organization customers immediately after experiencing a computer-security incident that it believes in good faith could disrupt, degrade, or impair services provided subject to the BSCA for four or more hours.” Presumably, if you are notified by a third party that an event has occurred, and the event has or is likely to result in your customers being unable to access their accounts, you would also be required to report to your regulator.

Reviewing the submitted comments, there are still many questions to be answered and terms to be clarified, but with cybersecurity dominating the news recently we can definitely count on regulatory changes to the “do we have to notify?” discussion coming fairly soon.

¹ As of this date the NCUA has not signed off on these proposed rules changes, although they may at some point.

14 Jan 2021

From the Field The Safe Systems Compliance Team 0 comment

A Look Back at 2020 and a Look Ahead to 2021: A Regulatory Compliance Update

From SafeSystems.com/Safe-Systems-Blog

Safe Systems recently published a two-part regulatory compliance blog series that looked back at 2020 and ahead to 2021. In Part 1, we explored how regulations related to the Pandemic dominated the compliance landscape early in 2020 forcing financial institutions to make adjustments to their procedures and practices on the fly. In Part 2, we summarized the regulatory focus on cybersecurity (particularly ransomware) and looked ahead to 2021.

12 Nov 2020

Hot Topics The Safe Systems Compliance Team 0 comment

Hot Topic: Ransomware on the Radar (Updated)

Both the State banking regulators and the Treasury Department have issued recent advisories to financial institutions regarding the ransomware threat. Ransomware is defined as a form of malicious software (“malware”) designed to block access to a computer system or data, often by encrypting data or programs, in order to extort ransom payments from victims in exchange for decrypting the information and restoring victims’ access to their systems or data. In some cases, in addition to the attack, the perpetrators threaten to publish sensitive files belonging to the victims, which can be individuals or business entities affiliated or associated with the financial institution.

US Department of the Treasury

First, the Treasury, via the Office of Foreign Assets Control (“OFAC”) and the Financial Crimes Enforcement Network (“FinCEN”), issued a pair of advisories in early October. FinCEN provided general information about the threat of ransomware and the existing requirements for filing Suspicious Activity Reports (SAR’s) for any ransomware payments conducted by, at, or through the financial institution. Because most ransomware demands involve bitcoin (also referred to as “convertible virtual currency” or CVC), conversion of the bitcoin into funds and transmitted via the ACH, wire, or credit card networks, institutions facilitating the transactions may run afoul of anti-money laundering and/or anti-terrorism laws.

In a related advisory, OFAC reminded institutions of the risks (i.e. sanctions and financial penalties) associated with facilitating ransomware payments on behalf of victims targeted by malicious cyber-enabled activities. Taken together, the two advisories discourage financial institutions from participating in transactions involving ransomware payments. Although this may seem like common sense, the increasing use of cyber insurance to control the financial risks of ransomware may remove the institution from being in the driver’s seat when it comes to negotiating with the ransomware perpetrators. Many (if not most) cyber insurance carriers require that, in order to cover a potential claim from a cyber event, they be notified early in the event, and that they take the lead role in any negotiations with the perpetrators. The FinCEN advisory also reminds institutions that any payments negotiated by third-parties on behalf of the institution remain the responsibility (i.e. liability) of the institution.

State Bank Regulators

Finally, starting this past October we’ve seen multiple occurrences of a Ransomware Self-Assessment Tool (R-SAT) being delivered to financial institutions subject to State oversight (i.e. all state chartered institutions). Developed by the Bankers Electronic Crimes Task Force, State Bank Regulators (CSBS), and the United States Secret Service, the R-SAT was created “…to help financial institutions assess their efforts to mitigate risks associated with ransomware and identify gaps for increasing security.” Although the email accompanying the document states that “…The tool does not establish new regulatory expectations,” institutions are being advised to complete the 16 question assessment and be prepared to discuss it with the state examiners at their next visit. (Although there are only 16 questions, most have multiple components, making the actual number of required responses closer to 60 – 65.)

This is causing confusion among many institutions, because anything requiring completion prior to an examination essentially becomes a defacto requirement. So how should institutions react to this new assessment? Is there anything new to be gained by completing this assessment that may justify the additional time commitment?

Since this is very new, we’ve reached out to IT auditors as well as our regulatory contacts at the state and federal level to get their opinions. It appears that the intention is to possible expand usage of this assessment beyond State examiners, as the document states that “This could also assist other third parties (such as auditors, security consultants and regulators).” So far though, the auditors and federal level examiners appear to be blindsided by this as well, so more to come on that, but our initial impression is that the questionnaire seems more of a conversation starter about ransomware best practices as opposed to a prescriptive checklist of “must-do” items. Indeed, the document is organized around the five functions of the NIST Cybersecurity Framework; Identify, Protect, Detect, Respond, and Recover.

Next Steps

Regarding the OFAC advisories, you and your cyber insurance company need to be aware that if they are involved in facilitating ransomware payments on your behalf, you must also consider whether you may be in violation of regulatory obligations under Financial Crimes Enforcement Network (FinCEN) regulations on payments to specially designated nationals. Our experience is that most cyber insurance carriers are not up to speed with current guidance, potentially putting you at risk.

Regarding the R-SAT, until we receive more feedback from the field, our position is that (as with everything else) taking a risk-based approach is best. That means completion of this document should be “optional” IF:

If your existing information security risk assessment already identifies all reasonably anticipated risks and threats and associated controls, then ransomware is already addressed. (Ransomware is simply one malware threat in the cyber-threat universe.)
If you’ve been completing the FFIEC CAT each year, you should have a pretty good idea of your risks and controls (including protective and detective), and how they’ve been trending over the past few years.
If you’ve been conducting a gap analysis based on the results, you’ve already addressed any misalignments between your current cyber risk profile and your desired profile. (In fact, question #2 on the R-SAT asks, “Has a GAP analysis been performed to identify controls that have not been implemented but are recommended in the standards and frameworks that you use?”)
If your Incident Response Plan has expanded the definition of “misuse of data” to include not just unauthorized access to data, but also unauthorized denial of access to data.
And finally, if your BCMP assesses the probability and impact of destructive malware, and if you’ve been periodically incorporating a ransomware scenario into your annual BCMP and Incident Response testing exercises, you’ve already validated your ability to respond and recover from a ransomware attack.

Our advice would be to consider completing the R-SAT if you feel you haven’t adequately addressed ransomware elsewhere, and then only as a stopgap until you’ve enhanced your InfoSec risk assessment, your BCMP and Incident Response Plans, and conducted a cybersecurity gap analysis. But if you’ve already checked those boxes, (and unless you have extra time on your hands) we strongly recommend calling the state examiner’s attention to your existing and on-going cyber threat identification, detection, response and recovery efforts, and leave it at that.

UPDATE

We reached out to, and have heard back from, a State examiner on how they intend to utilize the R-SAT. Here is a summary of their reply:

“…we intend to use this as a consultative tool in appropriate situations with our banks and credit unions.”
“…we will not be requiring compulsory use.”
“We are hoping that the conversations with institutions will entail questions/conversations such as “have you looked at it”, “do you find it helpful”, “these are items that can enhance your current process.”
“We do believe that most of this should already be in place from an incident management and business continuity stand point.”
The approach outlined in this article is “consistent with their thoughts.”

All State examiners may not have the exact same approach, so we’ll continue to update this as feedback comes in.

(Note: As stated earlier, we are awaiting more feedback from examiners and auditors in the field, so you may want to bookmark this page and check back periodically for any updates.)

← Previous 123…6 Next →