Banking on Cyber SCRM

By Ravi Nayyar

On 18 November, the US’s federal banking regulators — Board of Governors of the Federal Reserve System (‘the Board’), the Federal Deposit Insurance Corporation (‘FDIC’) and the Office of the Comptroller of the Currency (‘OCC’; collectively, ‘the Regulators’) — let us know about forthcoming notification requirements for breaches of cyber resilience for the sector. These requirements will be assigned to, as defined in a new rule (‘the Rule’), banking organisations and bank service providers from April 2022.

While the notification requirement for actual banking organisations is sensible in light of the nature of the payments and banking systems as critical infrastructure, what is quite interesting is the notification requirement for bank service providers. The Regulators are honing in on the first tier of the cyber supply chain of banking organisations.

Naturally, I’m interested because of my research area. But my antennae also prick up because this contributes to a trend of regulators paying close attention to the risks invited by the now-digital bedrock of the banking business model and thus the cyber supply chain risk management (‘cyber SCRM’) practices of banking organisations.

Notification Requirement for Banking Organisations

Let’s start with the notification requirement for banking organisations.

What Is it?

From April 2022, banking organisations will be required to report a notification incident to their primary federal regulator (as defined by US federal law) ‘as soon as possible and no later than 36 hours after the banking organization determines that a notification incident has occurred’.

A notification incident is defined as a:

computer-security incident that has materially disrupted or degraded, or is reasonably likely to materially disrupt or degrade, a banking organization’s —

(i) 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;

(ii) 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

(iii) 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.

A computer-security incident is defined as ‘an occurrence that results in actual harm to the confidentiality, integrity, or availability of an information system or the information that the system processes, stores, or transmits’.

Given the above, the forthcoming notification requirement is triggered by highly serious breaches of cyber resilience. Look at the use of ‘material’ and ‘materially’ as qualifiers. And indeed the insertion of ‘reasonably likely to’ in the final rule, which effects regulatory intent that organisations ‘not be required to make such a notification for adverse outcomes that are merely possible, or within imagination’.

Some of the examples that the Regulators provide of what are generally considered notification incidents reinforce the tight characterisation of the scope of the notification requirement:

• large-scale DDoS attacks ‘that disrupt customer account access for… more than 4 hours’;
• a failed system upgrade causing ‘widespread user outages for customers and [employees]’;
• ‘an unrecoverable system failure that results in activation of a banking organization’s business continuity or disaster recovery plan’;
• malware ‘on a banking organization’s network that poses an imminent threat to the banking organization’s core business lines or critical operations’ or that necessitates the disconnection of systems supporting said business lines from the Internet; and
• a ransomware attack which ‘encrypts a core banking system or backup data’.

The ransomware example reflects how the broader American critical infrastructure policy conversation is animated to a large extent by ransomware.

Just Add Basic Governance

When combined with the wording of the rule, incidents captured by the Rule would arguably be easily detectable (let alone identifiable as notification incidents), given their actually threatening or representing an existential threat to the banking organisation’s ability to operate. It is thus reasonable to assume that the officers of the victim banking organisation would have been or would be briefed about such serious breaches.

An organisation with a basic governance framework for cyber resilience would arguably ensure that procedures for escalating reports to the Board (as required, say, for Australian banks) are humming during any breach, let alone a notification incident. And ensure that, as the Regulators note in the Federal Register notice for the Rule, relevant personnel ‘have a sufficient understanding of their lines of business to be able to determine which business lines would, upon failure’ bring the notification requirement into play. This is analogous to how Australian banks are required to classify IT systems ‘by criticality and sensitivity’ in a fashion reflective of the extent to which a breach affecting a system can ‘affect, financially or non-financially, the entity or the interests of [their customers]’.

So, the Regulators are not asking banking organisations to reinvent the wheel when it comes to managing cyber risk. Especially when incident detection, response and reporting are not new concepts in cyber resilience. Plus, any banking organisation which cares about the viability of its business would agree with the Regulators who justify the Rule with reference to the more serious and numerous cyberattacks against the financial sector, incidents that can ‘adversely affect banking organizations’ networks, data, and systems, and ultimately their ability to resume normal operations’.

Tellingly, based on their review of agency data and Suspicious Activity Reports that involve cyber attacks against banking organisations in 2019 and 2020, the Regulators estimated that ‘approximately 150 notification incidents occurred annually’ with the potential for that figure to grow.

150.

No wonder the Board regards ‘cyber risk and technology management… [as] important areas of supervisory concern’. No wonder it requires banking organisations to ‘take proactive steps to mitigate cyber risk’ and has designated cyber risk management as one of its upcoming supervisory priorities for large financial institutions.

Already Have to Disclose Serious Breaches, Right?

In terms of the regulatory perimeter for breach notification, note that US banking organisations that are public companies already have to, and do, disclose breaches of cyber resilience to the US Securities and Exchange Commission (‘the SEC’) in current reports provided on Form 8-K. The SEC has encouraged companies to do so. It can be safely assumed that an undisclosed notification incident would meet the definition of ‘material nonpublic information’ which would have to be disclosed on Form 8-K under Regulation FD (17 CFR § 243.100). The SEC has made clear that materiality analysis for breaches of cyber resilience is informed by factors like ‘harm to a company’s reputation, financial performance, and customer and vendor relationships, as well as the possibility of litigation or regulatory investigations or actions, including regulatory actions by state and federal governmental authorities and non-U.S. authorities’.

It would thus take a lot to argue that the regulatory perimeter laid down by the Rule does not thus intersect with the one laid down by the SEC for filing current reports.

These factors call into question how uniquely burdensome the Rule would be because banking organisations that are public companies already have to keep checking their systems for breaches that trigger SEC disclosure requirements. The Rule would merely require them to notify their primary federal regulator as well.

Per the Regulators’ comments in the Federal Register notice, the notification requirement is not designed to be a broad, catch-all provision which imposes an inordinate compliance burden on the regulated population. Even then, the Regulators make clear that they ‘generally do not expect to take supervisory action’ against banking organisations that erroneously notify incidents under the Rule.

≤ 36 Hours

The Regulators justify the reporting timeframe with reference to the importance of relevant agencies getting ‘timely notice of significant emergent incidents, while providing flexibility to the banking organization to determine the content of the notification’. This is a limited reporting requirement to prevent creating an undue compliance burden which can distract from the banking organisation’s incident response procedures, in particular, the gathering of more data about the incident.

The Regulators make clear that they ‘do not expect that a banking organization would typically be able to [immediately] determine that a notification incident has occurred’ on registering a breach of cyber resilience. Rather, that the organisation would ‘take a reasonable amount of time to’ make that determination, especially if the breach occurs outside business hours. This is why the 36-hour countdown starts from when the determination is made, not retrospectively when the breach has occurred.

The Regulators still stress that they expect banking organisations not to wait the entire 36 hours before reporting a notification incident if said organisations are of high criticality to their sector: ‘An effective practice of banking organizations that provide sector-critical services is to provide same-day notification to their primary federal regulator of a notification incident’.

To see how the 36-hour time limit compares to similar regimes for the reporting of serious breaches of cyber resilience by banking organisations, check out the following table. ‘APRA’ refers to the Australian Prudential Regulation Authority.

Source: Author.

What’s Truly at Stake

Presidential Policy Directive 21 designates the financial services sector as a critical infrastructure sector. So the Rule is kinda important.

But arguably the most critical justification for the notification requirement for banking organisations is the Regulators’ concern about the implications of cyber risks faced directly by banking organisations for financial stability. Something affecting the ability of an economy to, well, function.

The Board devoted a few pages of its 2021 Financial Stability Report to exploring the issue. It pointed to how breaches of cyber resilience are ‘among the top risks cited in financial stability surveys in the United States and globally, presenting both microprudential and macroprudential concerns’. The Board also warns that breaches affecting financial stability ‘must first exploit firm-level vulnerabilities’. Merely a few malicious actors can cause havoc by targeting the right organisations, creating consequences such as ‘a lack of availability or accessibility of critical services, data, or funding; a loss of confidence, resulting in runs and asset fire sales; or disruptions to payment flows or price discovery’. Making matters worse is how traditional measures to safeguard financial stability may not directly mitigate the actual cyber risks faced by banks, rather working as after-the-fact damage limitation tools.

The concerns of the Board were echoed merely a month beforehand by its Australian counterpart, the Reserve Bank of Australia (‘the RBA’), when it warned that:

Given the large number of attempts a significant cyber event that has the potential for systemic implications is at some point inevitable.

The Financial Stability Board — which coordinates the efforts of national financial regulators and international standard-setting bodies to promote international financial stability — shared these sentiments in late 2020 by stating:

A significant cyber incident, if not properly contained, could seriously disrupt the financial system, including critical financial infrastructure, leading to broader financial stability implications.

Not ideal when one considers the interdependencies between banking organisations, per the Board’s 2021 Financial Stability Report (emphasis added):

A study by Federal Reserve Bank of New York staff simulated the extent of a hypothetical cyberattack that prevents one of the five most active banks from sending payments for one day… Using data from 2018, the study found that, on average across trading days that year, 31 percent of banking-sector assets (excluding the directly affected bank) would face compromised liquidity. The majority of forgone payments in a disruption support other financial market activity, so the original disruption could have broad ramifications.

So Give the Regulators a SITREP

The relative reluctance of banking organisations to disclose their vulnerabilities or breaches makes it harder for regulators to contain cyber (and subsequent financial stability) risks to the originally affected firm because they are, in essence, flying blind.

As the Board lamented only in November:

At the firm level, consistent data on cyber incidents are needed.

In light of these risks and the ‘narrow’ scope of the reporting requirement, it is all the more critical that the Regulators are notified of serious breaches ‘as soon as possible’.

Per the Federal Register notice for the Rule, the Regulators require data reported by banking organisations to identify the spread of a breach and how it must be quarantined from cyber resilience and financial stability perspectives. They can identify which organisations are particularly affected and thus concentrate assistance appropriately, including with partner agencies like the Cybersecurity and Infrastructure Security Agency (‘CISA’).

The Regulators can move faster during a breach, not just in terms of helping victim organisations do incident response, but also by alerting other organisations to prevent their victimisation and putting out more tailored security and capital/liquidity advisories. They can respond to crises — such as runs on banks if public confidence therein dives following notification incidents — in a swifter, more targeted fashion; mitigating ‘or entirely prevent[ing], these adverse liquidity events, thereby enhancing the resilience of the banking system’.

In the longer-term, being notified of notification incidents will provide a good amount of data for the Regulators to use to bolster the (cyber) resilience of the sector. As they make clear in the Federal Register notice, they can leverage such data to tailor firm- and sector-level supervision. Which is great if agencies want to deal with the rather serious aforementioned risks proactively, rather than chase their tails when, say, there’s a run on a systemically important bank as it recovers from being bricked.

Now, onto the forthcoming obligation for Bank Service Providers.

Notification Requirement for Bank Service Providers

Wait, What Are Bank Service Providers?

The Rule will define Bank Service Provider (‘BSP’) as a ‘bank service company or other person that performs covered services’, except for a designated financial market utility. ‘Covered services’ are defined as ‘services performed, by a person, that are subject to the Bank Service Company Act (12 U.S.C. 1861–1867)’.

Per 12 USC §§ 1861(b)(4), 1863 and the definition of ‘banking organization’ in the Rule, BSPs can perform the following covered services for banking organisations (emphasis added):

check and deposit sorting and posting, computation and posting of interest and other credits and charges, preparation and mailing of checks, statements, notices, and similar items, or any other clerical, bookkeeping, accounting, statistical, or similar functions performed for a depository institution.

The FDIC has interpreted ‘similar functions’ to include ‘data processing, Internet banking, or mobile banking services’. The OCC shares this interpretation, evident in its joint action with the FDIC against FUNDTech Corporation, a BSP.

Therefore, BSPs include technology vendors for banking organisations, such as cloud service providers and payment platforms.

Per 12 USC §§ 1813(q), 1867(c)(2), a banking organisation must notify (depending on the organisation type) the OCC, the FDIC or the Board of their ‘service relationship[s]’ (whether or not under a contract) with a BSP. This notification must occur within 30 days after the earlier of when the covered services are first provided or the contract with the BSP is signed. (The FDIC even has a handy form to use to make said notification.) Australian readers, this is analogous to the obligation of APRA-regulated entities under CPS 231 s 37.

Per 12 USC § 1867(c)(1), the performance of covered services by the BSP is ‘subject to regulation and examination by [the relevant Regulator] to the same extent as if such services were being performed by the [banking organisation] itself on its own premises’. In general, regulators expect banking organisations to manage risk from outsourcing arrangements effectively. Australian readers, this is analogous to CPS 231 ss 34–6 that provide for APRA to have access to information from, and the premises of, service providers that have entered outsourcing agreements with APRA-regulated entities.

So BSPs are already subject to regulation, as are the outsourcing relationships between banking organisations and BSPs. Cyber SCRM for the financial series sector is thus covered to a sizeable degree by US federal banking law.

What Is the New Notification Requirement for BSPs?

From April 2022, except in the case of ‘scheduled maintenance, testing, or software update previously communicated to a [BSP’s] banking organization customer’, a BSP will be:

required to notify at least one bank-designated point of contact at 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 materially disrupted or degraded, or is reasonably likely to materially disrupt or degrade, covered services provided to such banking organization for four or more hours.

Note that this is an obligation of the BSP towards its customer, not of the BSP towards the federal banking regulator of its customer. It is also narrow, given the qualifier, ‘materially’, and the duration of the actual or reasonably likely disruption to covered services which would trigger the reporting obligation.

Cyber SCRM for the Win!

The notification requirement for BSPs targets the first tier of banking organisations’ supply chains. The Rule thus represents another acknowledgement by regulators in advanced economies of the importance of cyber SCRM in the financial services sector.

The digital dependencies of modern banking are certainly live issues, implied by the nature of the examples detailed above of what are generally considered to be notification incidents.

As the Regulators acknowledge in the Federal Register notice for the Rule (emphasis added):

banking organizations have become increasingly reliant on third parties to provide essential services. Such third parties may also experience computer-security incidents that could disrupt or degrade the provision of services to their banking organization customers or have other significant impacts on a banking organization…

[In the Notice of Proposed Rulemaking, the Regulators] conservatively assumed the entire population of bank service providers who have self-selected the North American Industry Classification System (NAICS) industry “Computer System Design and Related Services” (NAICS industry code 5415) as their primary business activity to be the estimated number of bank service providers… Even though there may be some bank service providers that do not self-identify under NAICS code 5415, the agencies believe the number of incidents involving bank service providers will be generally consistent with original NPR findings.

As an Australian, I am also reminded of how Geoff Summerhayes, then Executive Board Member of APRA, warned that (emphasis added):

In an environment where an attack on one of us could be an attack on any of us, our financial system is only as resilient to cyber attacks as the weakest link in the chain.

Note that Mr Summerhayes made these comments while announcing APRA’s push to expand its regulatory perimeter to ‘the broader ecosystem of suppliers and providers they [Australian banking organisations] rely upon’, including technology vendors.

Hence, said reliance of modern banking on technology vendors is a source of cyber risk for their customers, especially because of the rise in the number and sophistication of supply chain attacks around the world, as flagged by the European Union Agency for Cybersecurity (‘ENISA’) only this year. ENISA also warned that organisations must factor cyber SCRM into their cyber resilience controls. This was merely a few months before the Australian Cyber Security Centre (‘the ACSC’) detailed supply chain attacks as one of the key trends in attacks that it observed in the 2020–21 financial year. The ACSC stressed that (emphasis added):

The threat from supply chain compromises remains high — it is difficult for both vendors and their customers to protect their networks against well-resourced actors with the ability to compromise widely used software products.

(For my views on the negative externalities encouraged by cyber supply chain risk, check out my pieces on the ACSC’s 2020–21 Annual Cyber Threat Report and vulnerabilities in QNX software.)

And that is just for malicious attacks. Don’t forget the non-malicious outages at technology vendors and service providers that have caused, and will cause, headaches for major institutions downstream. For example, the content delivery network, Akamai, suffered an ‘unanticipated’ outage in June 2021 due to a routing table value used by a version of its DDoS protection system being ‘inadvertently exceeded’. The end result: three of Australia’s four largest banks were unable to provide online banking services for at least an hour.

Little wonder that the Board warned only in November this year of the role of ‘complex and often unrecognized interdependencies across firms, including a layer of exposures to shared technologies and third-party service providers’ in helping shocks to the financial system spread.

Little wonder that the Regulators thus argue that BSPs must be required to ‘prompt[ly]’ report serious breaches to their affected customer. This is about ensuring that the customer has a degree of visibility into the first tier of their supply chains. The cyber SCRM undercurrent is evident in the Regulators making clear that notification by the BSP is necessary because a breach at the BSP may trigger a notification incident at the customer banking organisation which would require reporting to the latter’s primary federal regulator. To back this up, one of the examples that the Regulators provide of what is generally considered a notification incident is the following (emphasis added):

A bank service provider that is used by a banking organization for its core banking platform to operate business applications is experiencing widespread system outages and recovery time is undeterminable.

That brings home the interplay between the notification requirement for banking organisations and that for BSPs.

And thus the nature of the Rule as a cyber SCRM regulatory tool.

Again, What’s Truly at Stake

Supply chain risk for banking organisations stemming from their BSPs certainly triggers the cyber-borne financial stability risks discussed in the section on the notification requirement for banking organisations. Something regulators from multiple jurisdictions have raised.

The Bank of England (‘the BoE’) sounded the alarm in July 2021 in relation to cloud service providers. It stressed financial stability risk posed by the ‘highly concentrated’ cloud services market and the acceleration of plans by banking organisations to move functions to the cloud since 2020. The BoE called for additional regulation as well as multilateral cooperation to mitigate risks to financial stability posed by cloud service providers and other ‘critical third parties’ to which banking organisations have increasingly outsourced ‘vital services’. In September, the BoE reiterated these calls.

The Board highlighted how ‘interconnectedness from financial and digital exposures, data and operational dependencies, [and] markets with dominant firms and a lack of available substitutes for critical services’ can cause one breach of cyber resilience to snowball across the financial system (emphasis added). The bolded words echo the BoE’s concerns about the financial sector’s growing dependence on a handful of external technology vendors to function and all the lovely consequences that brings.

In defining the Australian financial system as ‘an ecosystem of an estimated 17,000 interconnected financial entities, markets, and financial market infrastructures’, Mr Summerhayes highlighted how a breach at, say, an ‘IT service provider… can have a cascading impact on the whole system’.

The Rule seeks to mitigate these risks borne from the banking cyber supply chain. The Regulators will be able to, depending on the breach, leverage the interplay between the notification requirements for BSPs and for banking organisations to accelerate their response to a financial crisis induced by a notification incident. If a banking organisation reports the incident as a supply chain attack via a BSP (which has already notified the former), the Regulators can use that data to assess the scale of the breach of the supply chain and, depending on their legal authorities, seek information from other banking organisations served by the impacted BSP (eg a large cloud service provider). They can build a richer intelligence picture of the spread of the crisis.

The Regulators can thus better plan their response together with partner agencies like CISA. Over the longer-term, the Regulators can build on the fruits of that situational awareness by: publishing more tailored advisories for banking organisations and BSPs; performing more informed horizon scanning and thus making better law reform recommendations; and conducting enforcement actions when organisations fail to mitigate (emerging) risks appropriately.

Safe > Sorry

As the Regulators note, BSP contracts typically require notification ‘as soon as possible’ to banking organisation customers of ‘material incident[s] during the normal course of business’. Per 12 USC § 1867(c)(1), BSPs’ controls are subject to the same regulation and examination as their customers.

But there must be a reason why the Regulations are nevertheless mandating breach notification for BSPs ‘independent of any contractual provisions’.

The state does not want to be left watching the banking system burn as contract law likely fails to appropriately manage banking organisations’ cyber supply chain risks, accompanying financial stability risks and, ultimately, national security risks. Rightly so, given what’s truly at stake, as above.

After all, it only takes one vector (eg a dominant technology vendor) for a threat actor to work their way into multiple banking organisations’ systems and wreak absolute havoc. Look at what happened in 2017 in Ukraine. Over 22 banks were bricked after the update servers belonging to a vendor of ubiquitous accounting software were hijacked by Russian military intelligence operatives to spread ransomware.

The Regulators would hardly want this meltdown of a banking system caused by the breach of BSP in the United States, would they?

And, based on the FDIC’s examination of BSP contracts among its regulated population in 2019, there is certainly cause for concern about the adequacy of contract law as a cyber risk management tool in the American banking sector (emphasis added):

… Other contracts did not sufficiently detail the technology service provider’s security incident responsibilities such as notifying the financial institution, regulators, or law enforcement.

… some contracts do not clearly define key terms used in contractual provisions relating to business continuity and incident response. Undefined and unclear key contract terms could contribute to ambiguity in financial institution rights and service provider responsibilities, and could increase the risk that technology service provider business disruptions or security incidents will impair financial institution operations or compromise customer information.

Not ideal when one considers the bits in bold. The words, ‘negative externalities’, certainly come to mind, as do they focus it.

It can be argued that the notification requirement for BSPs was brought in because the Regulators do not want said issues with contractual drafting — in the hands of private parties legally answerable to shareholders in the absence of specific statutory requirements — to persist with respect to breach notification.

To apply Mr Summerhayes’ words describing a limb of APRA’s Cyber Security Strategy for 2020–24, the Rule thus seeks to ‘raise the level of maturity’ of supplier oversight by banking organisations.

What better way to do it and provide certainty about breach reporting requirements than through black letter law?

Bringing it Home

Borne from its nature as a tangle of entities of different sizes and providing different services, the digital dependencies of the financial sector are not going anywhere.

As Mr Summerhayes remarked just over a year ago (emphasis added):

… this expanded inter-connectivity has further heightened cyber-risks; not only is a successful attack on one entity more likely to create problems beyond the target itself, the successful penetration of an entity can allow sophisticated actors to use these digital connections as a backdoor into other targets.

Attackers are increasingly targeting cyber supply chains in general these days. 2017 saw a nation state do so in an attack which decimated the networks of over 22 banks in Ukraine. How can one say that they will not succeed in causing a financial crisis, and paralysing an economy, by bricking banks elsewhere — especially in the United States — via (one of) their BSP(s)?

There is a clear case for the state to step in to regulate the management of risks stemming from the tangle banking organisations find themselves in, whether it is cyber or broader financial stability risk.

Therefore, the Rule is a sensible step in the direction of mitigating cyber risks stemming from those dependencies. Not just in relation to cyber governance frameworks internal to banking organisations but also their cyber SCRM frameworks.

That said, there are a few questions from the Rule which require further investigation by folks more qualified than I:

• Should the 36-hour time limit be reduced to 12 hours to mimic the forthcoming obligation of Australian banks to report ‘critical cyber security incidents’?
• Should BSPs be required to notify the ‘appropriate Federal banking agency’ (as defined by 12 USC § 1813(q)) of their affected customer(s) in addition to said customer(s)?
• Should banks remain the canaries in the coal mine, in terms of regulatory reporting, for the cyber resilience of BSPs that are not public companies and thus not captured by SEC disclosure requirements?
• Will BSPs be more open with their banking organisation customers about the state of their cyber resilience frameworks come April 2022?
• Will the Rule help ease imbalances in bargaining power between BSPs like large cloud services providers and banking organisation customers, such that the latter can audit such large BSPs’ controls?
• Above all, does the Rule provide a suitable template for countries like the US of A that seek to mandate breach reporting by critical infrastructure operators but have slow federal parliamentary processes: having sectoral regulators use their powers, if any, to make delegated legislation?

Anyhoo, our American colleagues have just had Critical Infrastructure Security and Resilience Month. And we’re going into Christmas holidays around the joint.

So let’s end on a positive note, courtesy of Mr Summerhayes:

But if interconnectivity is the problem, it also points towards a solution. In an environment where an attack on one of us could be an attack on any of us, we are all — governments, regulators, organisations and individuals — links in a chain — and we are in this battle together. By sharing information and expertise, pooling resources and taking prompt action to plug gaps and fix weak links, we create a community of cyber defenders that is greater than the sum of its parts. In doing so, we help to keep the chain as strong as possible, and lock out those who would do us harm.