Category: From the Field

How a New Framework Can Improve Cybersecurity Assessments in Financial Institutions.

In the age of digital banking, maintaining robust cybersecurity risk assessments and control reviews is paramount to protecting sensitive data from potential threats, and passing rigorous IT audits and examinations. Historically, a key tool in the arsenal has been the Cybersecurity Assessment Tool (CAT) developed by the Federal Financial Institutions Examination Council (FFIEC). This blog post will delve into the CAT, its limitations, and the potential for the CRI/NIST framework to enhance cybersecurity assessments within financial organizations.

The FFIEC CAT: A Brief Overview

The CAT, initially released in 2015 and updated in 2017, is a comprehensive tool designed to help financial institutions A). identify their inherent cyber risk exposure, and B). assess their control maturity level. It provides a framework to give the institution a point-in-time snapshot of their current cybersecurity risks and practices.  The Inherent Risks section questions are organized around five domains:  Technologies and Connection Types, Delivery Channels, Online/Mobile Products and Technology Services, Organizational Characteristics, and External Threats.  The Control Maturity section contains almost 500 declarative statements in 5 domains:  Cyber Risk Management and Oversight, Threat Intelligence and Collaboration, Cybersecurity Controls, External Dependency Management, and Cyber Incident Management and Resilience.

While the CAT is a valuable resource for financial institutions, and the defacto gold standard, it has been criticized for its rigidness and lack of clarity in some areas. Rigidity can lead to confusion when applying the tool to real-world situations and may not provide the necessary flexibility for organizations with different cybersecurity needs.  Lack of clarity can introduce subjectivity in the interpretation of various questions and statements.  In our experience this subjectivity has resulted in considerable differences in how the examiners interpret and apply the framework.  Simply put, the basic framework was a good attempt at a standardized set of best practices.  But given the built-in weaknesses, and the fact that it is now 8 years old and many feel it has not kept pace with the cyber threat and control environment, it may be time to consider adopting a new framework.

Introducing the CRI/NIST Framework

To address these limitations, the ABA recently issued an open letter to the FFIEC encouraging them to turn to the National Institute of Standards and Technology (NIST) CSF-based assessment tool called the Financial Sector Profile (now the Cyber Risk Institute (CRI) Profile)*. The profile was developed in conjunction with the Financial Sector Coordinating Council (FSSCC), trade associations, and financial institutions, and contains a forward and backward mapping between their statements and the FFIEC CAT statements, in addition to the BCMP, Operations, Audit, and Management Handbooks.

The framework comprises five core functions: Identify, Protect, Detect, Respond, and Recover. These functions provide a comprehensive outline for organizations to manage their cybersecurity risks effectively. The framework is designed to be adaptable, allowing institutions to prioritize and implement the most relevant security measures for their unique situation.

Benefits of Aligning the CAT with the New Framework

Incorporating and aligning the CRI/NIST framework into the CAT assessment process can greatly enhance cybersecurity within financial organizations. Some key benefits (and potential pitfalls) of this alignment could include:

1. Flexibility and Customization: The NIST-based framework’s adaptable nature allows institutions to focus on the most relevant security measures, ensuring their cybersecurity practices are tailored to their unique risk profiles.  However, adaptability can also introduce differences of opinion among practitioners in how those measures should be implemented.
2. Improved Clarity: By incorporating the NIST-based framework’s clearly defined functions, institutions can gain a better understanding of their cybersecurity requirements and make more informed decisions.  However, a clearer understanding of your cyber risk profile can only lead to better decision-making if (and only if) it can be effectively communicated to senior management.
3. Enhanced Collaboration: The NIST-based framework encourages collaboration between financial institutions, fostering a community-driven approach to cybersecurity and promoting the sharing of best practices.  How (or if) this collaboration occurs remains to be seen, but smaller institutions generally interact with their peers less often than their larger counterparts. 
4. Streamlined Assessment Process: Combining/converging the CAT with the CRI/NIST framework simplifies the assessment process, reducing redundancies and allowing organizations to focus on the most critical cybersecurity issues.  We have long been advocates of a single, shared standard for all guidance and best practices and in our opinion, this is the most valuable take-away from a potential CAT <-> CRI/NIST integration.  A single standard built on a widely accepted framework eliminates the primary weaknesses of clarity and lack of flexibility that surround the current cybersecurity assessment process.

Conclusion

While the FFIEC’s CAT has served as a valuable tool for assessing cybersecurity maturity, its limitations can hinder financial institutions in fully understanding the risks and making the best decisions for protecting their data. By aligning (or even replacing) the CAT with the NIST/CRI Cybersecurity Framework, institutions can benefit from a more flexible, consistent, and customizable approach, ultimately leading to improved cybersecurity measures and a safer financial ecosystem. 

*We have received feedback from some of our OCC regulated institutions that their examiners have already started using the CRI Profile in their examinations.

Way back in 2002, the FTC proposed new standards that would require all “financial institutions” to develop, implement, and maintain “…reasonable administrative, technical, and physical safeguards to protect the security, confidentiality, and integrity of customer information.”   Officially known as Standards for Safeguarding Customer Information, this should sound very familiar to all “traditional” financial institutions, as we adopted the very same safeguards back in 2000 under GLBA.  After a lengthy (10 year) phase-in period, and several extensions, all businesses that fall under the FTC’s definition of a “financial institution” must comply with most of the provisions by June 9, 2023.  As the FTC is defining a financial institution much more broadly than how it is traditionally defined, it is highly likely that some of your customers or members could fall under these new regulations, and be subject to legal action, including civil money penalties for non-compliance.

The FTC defines a financial institution as:

“…any institution the business of which is engaging in an activity that is financial in nature or incidental to such financial activities as described in section 4(k) of the Bank Holding Company Act of 1956, 12 U.S.C. 1843(k). An institution that is significantly engaged in financial activities, or significantly engaged in activities incidental to such financial activities, is a financial institution.”

So far this sounds pretty standard, however, here are the examples the FTC provides for “financial institutions”:

• A retailer that extends credit by issuing its own credit card directly to consumers.
• An automobile dealership that, as a usual part of its business, leases automobiles on a nonoperating basis for longer than 90 days.
• A personal property or real estate appraiser.
• A career counselor that specializes in providing career counseling services to individuals currently employed by or recently displaced from a financial organization.
• A business that prints and sells checks for consumers.
• A business that regularly wires money to and from consumers.
• A check cashing business.
• An accountant or other tax preparation service that is in the business of completing income tax returns.
• A business that operates a travel agency in connection with financial services.
• An entity that provides real estate settlement services.
• A mortgage broker.
• An investment advisory company and a credit counseling service.
• A company acting as a finder in bringing together one or more buyers and sellers of any product or service for transactions that the parties themselves negotiate and consummate.

Some of these are more obvious (mortgage brokers, check printers, real estate settlement), while others are not so obvious (car dealers, travel agents, tax preparation services, career counselor).  This new interpretation exempts more traditional FI’s[1], but is much broader than what most of us have historically considered a financial institution, and may require a new mindset as you evaluate your new and existing customers and members.  Could non-compliance trigger a monetary penalty that could in turn adversely impact the business’s ability to repay a loan?  Given the pending third-party risk management guidance, should you require proof of Safeguard rule compliance for your third-parties going forward?   And if so, is a management declaration or assertion sufficient, or should you also require third-party attestation?

To be clear, we haven’t heard from the federal regulators on how (or if) they will factor this into their Safety & Soundness exams going forward, but it seems reasonable to assume that auditors and examiners may ask if you (at a minimum) track your customer/member base’s exposure to these new rules.  We believe this is one example of a regulation that may actually prove beneficial, as having a clearer understanding of exactly how your business customers and significant third-party providers are managing their information security risks is good for all of us.

[1] The “financial institutions” subject to the Commission’s enforcement authority are those that are not otherwise subject to the enforcement authority of another regulator under section 505 of the Gramm-Leach-Bliley Act.

Since both Windows 7 and Server 2008 R2 will reach end-of-life support in January of 2020, many organizations have already made the jump to Windows 10 and Windows Server 2012, 2016, 2019, or Azure. If you have full control over the asset lifecycle management process for your financial institution you may have already completed this conversion and are working through the headache of teaching your end users the nuances of Windows 10. Because of the complexity of the conversion process (particularly at the server level), we have also started to see trends in outsourcing more information technology tasks to external technology service providers (TSPs). No matter where your financial institution may fall on this DIY to outsourced spectrum, it’s critical to have a well-defined asset lifecycle management process.

Defining Asset Lifecycle

Let’s start by unpacking asset lifecycle to understand why the process is so important that an entire contributing component within the FFIEC Cybersecurity Assessment Tool, and a section of the Information Security IT Handbook, is dedicated to IT Asset Management.

NIST condenses the typical asset lifecycle to three phases:

1. Enrollment
2. Operation
3. End-of-Life

Similarly, the FFIEC defines the lifecycle process as “The multistep process that starts with the initiation, analysis, design, and implementation, and continues through the maintenance and disposal of the system.” For the purposes of this article, we’ll use the 3-phase NIST definition, and assume that the enrollment phase includes initiation, analysis and design; operation includes implementation and maintenance; and end-of-life includes disposal.

The enrollment phase will include planning for new IT assets, procuring those assets, and configuring them for production environments. The operations phase determines how IT assets are maintained and the specific policies that provide structure for performing changes or modifications to them. As IT assets reach the end-of-life phase, they must be properly decommissioned and disposed.

If you’re working with a TSP in this area, this vendor will likely procure and pre-configure the new assets and may even perform the implementation for you. It is important to ensure the service provider is aware of your policies (including your IT risk appetite), and that they will abide by them and follow financial industry best practices. The TSPs should also be able to provide you with a baseline configuration, or checklist for the newly introduced IT assets, to prove that they have been pre-configured to your security specifications. Your own internal asset lifecycle management policy should include receiving this information from your TSP prior to new assets being implemented into your infrastructure.

Inventory Classifications

FFIEC guidance requires IT assets to be both inventoried and classified according to the type of data they will store or process. Classification should be tied to sensitivity and criticality. Sensitivity is typically expressed as private (customer NPI), confidential (non-NPI FI information such as HR records, strategic plans, etc.), and public. Criticality is usually inherited from the process the asset is utilized for, expressed as the recovery time objective for the underlying process.

As technology changes, we are seeing fewer barcodes for physical asset inventories, and more Excel spreadsheets comprised of printer, server, and workstation inventory information. Many TSPs provide an automated central management solution for assets that greatly reduces the overhead of manually managing so many devices. The routine (daily, monthly, quarterly) maintenance for IT assets should also be documented in the asset lifecycle management policy. These tasks are the NIST operation phase that provides documentation for software and OS patches, AV/Anti-malware, data backups, etc.

Destruction and Disposal

A lot of emphasis is placed on the introduction of new IT assets and the support and maintenance of them throughout their operation, but it is equally important to include destruction and disposal procedures for these assets as they reach the end of their lifecycle. When a system reaches End-of-Life it means that a vendor is no longer providing critical security updates or support for those devices, and any new vulnerabilities may be exposed to exploitation. If a TSP assists with decommissioning these devices, their disposal practices should be reviewed and determined to align with your own policies based on the classification or the assets and the retention period for the data. Any devices that house non-public or confidential information should be securely erased or destroyed to ensure the contents are not recoverable, and if this process is outsourced, the TSP should be able to provide validation of this process.

Occasionally, there is a legitimate business need to continue using hardware or software that has reached End-of-Life support. A risk assessment should be performed, and any compensating controls implemented and documented. If residual risks are still too high, this may include segmenting the asset from the rest of the network to limit the risk exposure.

Vendor Management

Whether your financial institution manages the entire asset lifecycle process internally, outsources it completed to TSPs, or is somewhere in between, it is critical to have a structured, well-defined plan that follows these assets from planning and implementation to decommission and salvage. If you outsource any aspect of this process, a robust ongoing vendor management program is critical in providing a level of assurance and in holding them accountable for their obligations throughout the asset lifecycle management process. Of course, with all things outsourced, you cannot outsource the responsibility.

Examiners

Appendix A of the FFIEC IT Handbook provides the examination procedures for establishing an effective lifecycle management policy. Examiners are instructed to do the following:

“Determine whether management plans for the life cycles of the institution’s systems, eventual end of life, and any corresponding business impacts. Review whether the institution’s lifecycle management includes the following:

• Maintaining inventories of systems and applications.
• Adhering to an approved End-of-Life or sunset policy for older systems.
• Tracking changes made to the systems and applications, availability of updates, and the planned end of support by the vendor.
• Planning for the update or replacement of systems nearing obsolescence.
• Outlining procedures for the secure destruction or wiping of hard drives being returned to vendors or donated to prevent the inadvertent disclosure of sensitive information.”