The Challenges of Model Risk Management Oversight of Cybersecurity

At banks, cyber risk has traditionally been assessed and managed by the IT risk function with oversight by the operational risk function. Recently, though, more ownership of the development, implementation, and use of cybersecurity tools and models has been shifting to model risk management functions.

This is partly driven by the growing sophistication of cybersecurity models, which—like other models—increasingly employ artificial intelligence and machine learning.

Consider the emerging discipline of cybersecurity data science (CSDS), which applies machine learning methods to quantify cyber risks and optimize cybersecurity. In CSDS, insights from data and human knowledge are used to detect, prevent, and remediate cybersecurity threats.

The application of data science to cybersecurity has attracted the attention of regulators and elevated the pressure on firms to have model risk management (MRM) teams validate cybersecurity solutions. This article demonstrates challenges in executing this oversight and suggests a few practical solutions.

It makes sense, in theory, for MRM to oversee the development, implementation, and use of all AI and ML models—including those used in cybersecurity. After all, their derivation relies on key mathematical concepts—including linear algebra, probability theory, calculus, optimization, and statistics—that are the life’s work of modelers. On the other hand, cybersecurity models are distinct from most other models given their operation on massive data in real time, their ability to identify malicious behaviors in encrypted data, and their adaptability to new threats.

Regardless of where it sits in the organization, cybersecurity is a crucial operation that only gets more important as bank reliance on technology increases and threats grow more sophisticated—and more costly. According to IBM’s “Cost of a Data Breach Report 2022,” financial organizations suffer an average cost of nearly $6 million per data breach.

Importance of Domain Knowledge

U.S. banks typically use models to:

• Analyze consumer behavior, market conditions, and business strategies.
• Drive or assist business decisions to manage portfolio and client assets.
• Identify and analyze risks to quantify exposures of instruments or positions.
• Meet regulatory requirements, such as capital planning and capital adequacy evaluation, and for reporting needs.

Domain knowledge for these applications is largely rooted in social sciences such as economics, nance, and sociology— areas that many model developers and validators are educated and trained in. Modelers also commonly draw on the systematic training they acquired through engineering, physics, and mathematics.

It takes a range of 18 months to seven years to acquire a master’s or a doctoral degree in a field that is typically required for a modeling-related job. From there, it can take two or more years on the job to become functionally proficient—meaning a model developer has full insight into a bank business or function, and can support, develop, implement, and monitor a model independently with little or no supervision.

The path to cybersecurity knowledge is different.

The Certified Information Systems Security Professional (CISSP) examination, for example, requires knowledge in these domains:

• Security and risk management.
• Asset security.
• Security engineering.
• Communications and network security.
• Identity and access management.
• Security assessment and testing.
• Security operations.
• Software development.

Collier et. al. divide cybersecurity into four domains:

• Physical (hardware and software).
• Information (confidentiality, integrity, and availability of information).
• Cognitive (how information is perceived and analyzed).
• Social (attention to ethics, social norms, and other societal domains).

For its part, the financial sector typically follows the five functions defined by the National Institute of Standards and Technology (NIST): identify, protect, detect, respond, and recover.

Not only is the knowledge needed for cybersecurity different, it is of a different nature than the subject matter typically drawn on in modeling. Cybersecurity functions and capacities do not track with the strong underpinning of social sciences characteristic of financial and regulatory models.

So training current model developers and managers in cybersecurity can be a challenge. Further, the supply of cyber/information security professionals continues to be lower than demand. And it takes the equivalent of a bachelor’s degree in computer science plus five years of relevant work experience to meet the requirement for professional cybersecurity competence.

Domain or subject matter knowledge is critical. Asking the proper questions to effectively challenge the model development process requires understanding the function model validators support. Lack of cybersecurity domain knowledge can be a significant hurdle to turning over cybersecurity to the model risk management function.

This is not to say it’s prohibitive. Validators are accustomed to learning new modeling techniques and businesses. For example, in the absence of additional guidance on the practical interpretation and implementation of the Supervisory Guidance on Model Risk Management (OCC Bulletin 2011-12 or FRB SR 11-7) in Bank Secrecy Act/Anti-Money Laundering (BSA/AML) related models, most banks have validated models covering three common BSA/AML elements: Know your customer (KYC) onboarding and customer risk rating, AML transaction monitoring for suspicious activity detection and reporting, and sanctions screening for potential sanctions match detection.

Validators can certainly master key concepts such as the aforementioned NIST cybersecurity framework, common types of cyberthreats, network design, and even defense strategies. But they must take to heart and overcome the fundamental differences of cybersecurity. For example, compliance has a direct tie to human behavior and money movements that are intertwined with consumers. Cybersecurity is more about computers, networks, systems, and software—with human actions largely invisible.

Subject matter knowledge is not negotiable. The regulatory guidance on MRM states: “Staff doing validation should have the requisite knowledge, skills, and expertise. A high level of technical expertise may be needed because of the complexity of many models, both in structure and in application. These staff also should have a significant degree of familiarity with the line of business using the model and the model’s intended use. A model’s developer is an important source of information but cannot be relied on as an objective or sole source on which to base an assessment of model quality.” When assessing cybersecurity models, validators should demonstrate a proper level of knowledge, skills, and expertise related to cybersecurity that are fully consistent with written supervisory expectations.

At the same time, elements of the prevailing supervisory model validation framework are inapplicable to cybersecurity. The framework is designed for financial and regulatory models stemming from core banking activities. Key components of the validation framework, including the modeling data and conceptual soundness evaluations, are either irrelevant or not applicable to cybersecurity models.

The modeling process is different as well. Areas validators typically cover in analyzing classic regression models include: data source verification; data quality evaluation, including data representativeness; data treatment; key data assumptions; data completeness; and sampling techniques. This is required because regression models are developed to construct relationships between target and explanatory variables using realized events. To uncover associations between variables observed in data and quantify the impacts, a regression model and its output should be adequately explained and supported by hypotheses and mathematical properties established by social and/or mathematical theories. The process of drawing conclusions about an underlying population based on a sample or subset of the data is the foundation of statistical inference. Therefore, developers and validators must understand, among other things:

• How data is gathered from different sources and merged afterwards.
• If any data transformation or treatment is applied.
• Whether specific sampling techniques are employed.
• If differences observed via data evaluation warrant segmentation.

Assessing modeling data is particularly relevant for internally developed models where the differences between the sample and the population are assumed to be reasonably small or justifiably large. This is generally applicable for most vendor models such as FICO, Bloomberg interest rate and mortgage valuation models, and Moody’s RiskCalc and Corelogic models, when the underlying business is mostly related to consumer and commercial banking activities.

The data representativeness and relevancy concept does not apply to cybersecurity data, which moves and grows more quickly . Additionally, cybersecurity data can be generated and collected internationally, and from all sectors—not just bank-related ones. At the same time, data sources can be relatively limited. They are mainly either intelligence sources or metadata derived from network activity, event logs, and malware samples. Put simply, cybersecurity data sources are simultaneously more disparate and focused than financial data. This explains the heavy reliance on vendors by financial institutions of all sizes: Internally developed cybersecurity models built solely on bank-specific data tend to be less useful due to data coverage limitations. Generally, the greater the difference between internal data and external data, the fuller the coverage and better off the model will be. Therefore, the traditional data representativeness and relevancy evaluation comparing the firm’s internal and industry data needs modification to stay relevant.

Further, due to the uniqueness of the structure and type of cyber data, the steps to prepare it for modeling are fundamentally different from those applied to financial data. Most financial data is generally numerical and currency based, and nonnumerical financial data can be easily converted to categorical, and therefore countable, variables. Standardized ways to check data quality—such as producing descriptive statistics of all variables; identifying default, missing, and extreme values and outliers; and profiling target variable and important independent variables—are not applicable to typical log reduction and event-relation activities of cybersecurity.

In the logging of cybersecurity data, many log sources with inconsistent log formats, timestamps, and data can be recorded. Log files can be structured, semi-structured, or unstructured. To process and generate numerical representations of log data, most organizations must implement automated methods of converting logs with different content and formats to a single standard format with consistent data field representations. Log parsing is typically done within a log management system that also performs other functions such as event filtering and event aggregation. Widely disparate cybersecurity program functions and information types contained in logs generally eliminate interprogram comparability, contrary to more common financial modeling practices.

The conceptual soundness evaluation— the assessment of the model’s design and methodology, assumptions, limitations, and performance—is the most relevant dimension to advocate MRM’s oversight of cybersecurity models. But its application to cybersecurity models is not free of challenges, and further reinforces the importance of domain knowledge.

Cybersecurity models almost always follow the defense-in-depth (DiD) strategy, and commonly support an intrusion detection system (IDS) that could be either signature-based, anomaly-based, or a hybrid of the two. While signature-based model development is similar to commonly used anti-money laundering (AML) models at banks, it has important distinctions.

To wit: Since the establishment of the Bank Secrecy Act (BSA) in 1970, numerous other laws have enhanced and amended the BSA to provide law enforcement and regulatory agencies with more effective tools to combat money laundering. As a result, many suspicious activities for AML are defined and/or derived from the regulatory agencies, in addition to those independently identified by the financial institutions. In contrast, there are very limited and non-specific federal laws regulating cybersecurity and privacy in the U.S. Yes, there is the Health Insurance Portability and Accountability Act of 1996 (HIPAA). And the Gramm-Leach-Bliley Act (GLBA) of 1999 requires financial institutions to explain their information-sharing practices to their customers and to protect their customers’ private information. The Interagency Guidelines Establishing Information Security Standards (OCC 12 CFR 30 Appendix B, FRS 12 CFR Parts 208 and 225, FDIC 364 Appendix B) further summarize expectations of boards of directors for overseeing the development and implementation of administrative, technical, and physical safeguards to protect the security, confidentiality, and integrity of customer information. But existing banking cyber regulations are principles based and do not include specificity for types of threat. As a result, malicious cyber indicators are mostly defined by individual organizations with a certain level of industry consensus, creating widely varying differences in anomaly-detection activities.

Recent progress in data mining and ML algorithms has resulted in knowledge- based detection. Traditional models have been supplemented by the dynamic anomaly-based approach. However, the academic literature remains quite scarce for cybersecurity models. While auditors and regulators generally expect that “the design, theory, and logic underlying the model should be well documented and generally supported by published research and sound industry practice,” [12] it is difficult for model validation to leverage academic research to verify and confirm the methodology soundness. Although there is a proliferation of research dedicated to the development and use of ML algorithms, there is no industry standard or regulation guiding evaluation criteria and confirming best use cases for cybersecurity.

Known vs. Unknown Behavior

The regressions modelers use are first developed to construct relationships between variables. When identified relationships are sound and stable, as measured by model robustness, accuracy, and stability over time, regression models can forecast known or “normal” behavior in the future.

Cybersecurity models have two primary objectives. One is to identify “known” attacks via signature matching. This application is similar to most models developed for financial purposes, AML, and fraud detection. The other is to capture “unknown” events for detection and prevention purposes, which means some cyber events in the future are not expected to mirror what has happened in the past. Detecting abnormal behaviors that are not captured in the training data is not something conventional regression models are designed for. Instead, techniques for classification and pattern detection such as support vector machines (SVM), K-nearest neighbor (KNN), and decision trees are common algorithms to consider. Other algorithms such as artificial neural network (ANN), recurrent neural network (RNN), long short-term memory (LSTM), and convolutional neural network are also more effective at anomaly detection and analysis. Deep learning models are also very powerful for log data representation. Explanation of those deep learning methodologies and the processing components that implement the deep learning theory, including the mathematical specification and the numerical techniques and approximations, becomes very challenging for validators without sufficient computer science knowledge—let alone a reasonable discussion of merits and limitations of the chosen ML approach. Cybersecurity is a specialized field of computer science with a narrower and more focused skill set. Even validators with a general computer science background may find it challenging to assess cybersecurity models.

Another conceptual soundness challenge relates to model performance evaluation and outcomes analysis. A regression model can show whether changes observed in the dependent variable are associated with changes in one or more of the explanatory variables. Put differently, many ML algorithms do not support sensitivity analysis due to an absence of parameters. Further, the constantly evolving nature of cyberattack tactics, techniques, and procedures implies much more frequent refresh and redevelopment of existing cyber models for them to stay effective versus their financial counterparts. Dynamic update of the model is desirable and necessary because minimizing variation between the training data and the production data ensures timely detection of abnormal behaviors. A cybersecurity model’s effectiveness would be severely reduced if its use is interrupted because dynamic changes need to be assessed and approved by model risk management.

Finally, the impact of implementing a flawed cybersecurity model is low compared to implementing problematic models that support key bank operations such as credit and market risk models. For example, a defense in-depth strategy is multi-dimensional with a series of defensive mechanisms layered to protect valuable data, information, and operational technology infrastructure. If one mechanism—such as the cybersecurity model attached to a particular program or system—fails, another model, program, and/or system may also be in place to avoid or mitigate an attack. Therefore, a single point model failure is highly unlikely to automatically lead to penetration of systems and networks due to the presence of other, mutually reinforcing tools, controls, and defense layers. Contrast this with the intended target of MRM regulations—where abuse of customers, a regulatory violation, and/ or a significant financial loss to the bank are likely outcomes of a single model failure.

Conclusion

Applying MRM oversight to cybersecurity models would likely involve modifications of standard validation activities. The validation team needs to conduct a self-assessment on domain knowledge and decide how to mitigate any lack of expertise in cybersecurity operations, cyber data, and general IT information. And management must determine whether MRM needs to acquire IT and cyber talent, and/or if the firm can leverage outside expertise. Then, management should identify elements in SR 11-7 that are not applicable or relevant for cybersecurity model validation. Management must set clear expectations (through policies and standards) between MRM and the cybersecurity business on what can and cannot be done and why, and only then assign appropriate risk ranking for cybersecurity models. Financial institutions should perform a comprehensive assessment of the pros and cons before committing to such responsibilities.

Disclaimer

The views presented in this research are solely those of the author and do not necessarily represent those of Ally Financial Inc. (AFI) or any subsidiaries of AFI.

---

 LIMING BROTCKE, PHD leads the Consumer and Commercial Banking Business Line Risk Data Science function at Ally Financial after heading the Model Validation Group for three and a half years. Prior to joining Ally, she worked at the Federal Reserve Bank of Chicago focusing on large and LISCC (Large Institution Supervision Coordinating Committee) bank supervision and regulation pertaining to credit risk, model risk, CECL implementation, and AI/ML practice. She has extensive industry experience in financial model development, implementation, performance monitoring, and validation from working at Ally, Citigroup, and Discover Financial Services. Liming can be reached at Liming.Brotcke2@Ally.com.