A Boston Consulting Group Study conducted in 2017 observed that banking industry spent a whopping $321B from 2009-2016 on penalties for regulatory violations. As recent as this current month, compliance lapses at Deutsche Bank have led it to face a $150M fine. The regulator said "Deutsche Bank failed to adequately monitor the activity of customers that the Bank itself deemed to be high risk".
We discussed in this primer article as to why and how regulations help banks to stay safe and secure. While cybersecurity enforcement is one of the primary motivators for having regulations in banking industry, preventing fraud and money laundering is another big reason. Banks, and for that matter all kinds of businesses, struggle to meet the requirements of various regulations. In fact, the cost of complying with regulations has been increasing every year. A report by KPMG estimated that firms’ annual compliance spend is US$270B with regtech projected to make up 34% of all regulatory spending by 2020. Thomson Reuters Regulatory Intelligence's (TRRI) 2019 survey on cost of compliance highlighted specifically the increasing burden of tracking regulatory change. They monitor approximately 1000 regulatory bodies across industry verticals. Those regulatory bodies generated about 57,398 changes in 2019 alone averaging to 220 change alerts per day.
The bottomline is that tracking and keeping pace with regulatory change is extremely important but very hard and expensive. Cost of missing them is even higher often leading to severe fines for violations as well as huge loss of customer trust.
Why complying with regulations is hard and expensive ?
Each industry has multiple regulatory bodies covering domain specific requirements. A typical business, such as a bank or a telecom company, may need to comply with few tens of regulations. Due to ever-changing nature of technology these regulatory standards constantly evolve and undergo revisions.
The most recent example of a major regulatory change that had global impact, across industries, is the GDPR regulation. It came into effect in 2018 and changed how entire industries as well as countries looked at data privacy. Capgemini Research Institute reported in 2019 that after a year of GDPR becoming active, only 28% of organizations reviewed had achieved successful compliance. Enforcement Tracker, provides a list of several ongoing violation cases against many organizations. The three biggest fines levied so far include a 50M Euro penalty against Google, a 110M Euro fine against Marriott International and a 204M Euro fine levied against British Airways.
To understand the complexity involved in meeting these regulations and dealing with frequent changes, let us dissect the regulatory ecosystem. The figure below shows four layers of the ecosystem each of which deals with a different kind of regulatory documents.
The first layer consists of the documents published by regulatory bodies. These include well known regulations such as PCI-DSS from the payment card industry, HIPAA from the healthcare industry etc. Such regulation documents typically run into hundreds of pages of legal text often containing thousands of regulatory requirements, called obligations.
These obligations need to be read, understood and interpreted by legal subject matter experts (i.e. SMEs). As an example, requirement 8 of PCI-DSS regulation states that each person should be assigned a unique identification (ID) so that accountability of their actions could be established. This regulatory obligations layer essentially defines the responsibilities of an organization as specified in the regulatory document.
While the first layer captures the "What?" part, the second layer starts to peel into how it needs to be done. It consists of cybersecurity frameworks such as NIST-CSF and standard control definitions such as NIST-800-53 or CIS Controls or even an organization specific framework. These documents translate the regulatory requirements into specific actions, often called controls, that an organization needs to implement to meet those requirements. These controls could be process oriented (i.e. involving actions to be taken by a human such as physically locking a facility) or technical that can be automated. For the purposes of this article, we shall focus on technical controls.
Continuing with the PCI-DSS example, the control corresponding to requirement 8.1 in PCI-DSS maps onto control PR.AC-1 in NIST Cybersecurity Framework, as shown in the figure below. PR.AC-1 spells out how identity and authentication could be implemented. It indicates the need for a system to be put in place that can issue, revoke, manage, verify as well as audit identities and credentials for users, devices and processes. One may notice that this is still not sufficient enough detail to start enforcing compliance on actual devices, operating system, middleware and applications but gives a good direction to the organization in terms of how they need to go about it.
An interesting aspect of the above mapping from NIST-CSF is that it is essentially a crosswalk, i.e. it maps one regulatory document to a bunch of other documents. Here, NIST-CSF controls are mapped to requirements in PCI-DSS, NIST SP 800-53, CIS CSC, COBIT 5 and others. Crosswalks are created by legal SMEs who understand the regulations and interpret them to arrive at these relational mappings [NIST-CSF:PCI-DSS, NIST-CSF:HIPAA]. They serve two purposes. First, they help identify any gaps by checking whether all the requirements of a regulation are being covered by the controls. Second, they help in harmonizing common requirements across multiple regulations so that organizations do not end up implementing the same requirement multiple times. We shall come back to crosswalks in a minute.
The third layer of regulatory documents, often called policies, are a collection of fine grained checks that together serve the need for a given set of controls, for a specific target. The target could be an infrastructure element such as linux operating system, or a device such as a firewall or router or a middleware such as database, app server or even end application. These documents contain very specific configuration statements that could be programmed into a script and executed for desired effect. Examples of such policies include CIS Benchmarks or NIST STIGs. A snippet of CIS Benchmark checks corresponding to the identity and authentication example from PCI, for Redhat Linux is shown below.
As one may observe the steps at this level are quite fine grained, and specified for each platform (Redhat Enterprise Linux in this case). The instructions include rationale, an audit procedure as well as a remediation procedure. These can be translated into executable code for automation. Also, one may notice that the extensive coverage within a platform as well. Items 5.1.1 - 5.1.7 above cover several the aspects of securing just the cron daemon through various configuration settings.
The last layer of regulatory compliance ecosystem consists of actual scripts, programs or tools that execute the above checks and return the results back for compliance assessment. There are several technologies that have come up in last few years to make this layer very developer friendly and effective across multiple platforms. Some notable ones include Redhat Ansible, Chef, Puppet, SaltStack etc. The second, third and fourth layers, i.e. controls, policies and implementation together provide the ability to automate compliance assessment. A critical output of the compliance assessment is the evidence. Evidence could be in the form of logs or checks required to prove to an auditor that policies were implemented as intended and compliance was maintained at all times.
Keeping pace with the change
Now, each of these layers of the regulatory ecosystem undergo constant change. Regulatory bodies keep revising the regulations to cover new business scenarios (such as the need for stronger protection of personal data) or to prevent newer kinds of cyber attacks with sensitive workloads increasingly shifting to public clouds. On the other side, newer technology platforms such as containers, infrastructure on edge etc., are driving new security requirements leading to constant addition and revision of controls and policies.
Imagine a large customer's hybrid cloud environment consisting of few tens of cloud services spread across multiple public clouds, couple of hundreds of virtual machines and containers spread across on-prem and cloud infrastructure. On top of this different teams would have several middleware and applications. Now, any change in the regulatory obligations needs to be evaluated against each of these deployments. Needless to say, understanding such change, articulating its impact on the entire infrastructure and having an action plan to fix any gaps is a huge task. Today this is mostly done manually !!
Further complication here is that each of these layers - regulations, controls, policies and implementation are usually managed by separate teams needing different skillsets. For regulations, a significant amount of time and effort is spent by legal SMEs to read the regulatory documents, understand the changes and interpreting their impact on the organization's controls and policies. Given that these documents often run into hundreds of pages and thousands of obligations, this exercise becomes extremely expensive often taking weeks or months for just regulatory interpretation alone.
Once the changed regulatory requirements are understood, their impact on the organization's controls and policies needs to be laid out. This implies identifying gaps in the current compliance program with respect to new changes, identifying controls that are no longer needed and articulating what actions need to introduced or modified to stay compliant. This function is typically performed by Compliance Officers. Next, Compliance Engineers take those additional or modified actions in terms of additional controls and determine what additional policies need to be implemented. Finally, the actual implementation is done to meet the new requirements.
Given the manual nature of this activity today and the fact that multiple personas residing in loosely connected teams deal with their part of the overall problem, regulatory change management are highly resource consuming activities today.
Turning documents into data to automate change management
With a new regulation coming in or a major revision introduced, the time taken to put that into effect often runs into months and years. Each such exercise today suffers from extremely high costs and delays leading to unplugged security loopholes that could be exploited.
Automated impact identification - AI technology has advanced substantially, in terms of reading, parsing and understanding natural language or code intermixed documents. SME input with AI assistance is used to construct mappings from regulatory documents in one layer to next essentially building a graph of inter-connected regulatory obligations and controls. Essentially this is a critical step that transforms the knowledge possessed by SMEs and maintained in formatted documents to data that is queryable.
Tracing the impact of any change then becomes a function of navigating this graph using known relationships among requirements, controls, policies and implementation. For instance, let us say that a regulation R maps onto a control set C that gets implemented by policy P and set of implementations I. Any change in R can then lead to gaps created or changes needed in corresponding controls in C and further to modifications needed in the policies or implementation.
Semi-automated maintenance - The next problem to tackle is to keep the graph of these mappings up-to-date. AI comes to rescue again. Text comparison techniques allow changes among revisions to be detected and identified. These changes with their semantics could be inspected by an SME to perform a quick change assessment on the graph. Recall that these changes may need to be detected among several hundreds or thousands of controls. AI helps in focusing the human input on a small subset while highlighting key differences, enabling speed.
Semi-automatically updated graphs of these regulatory mappings is what we term as Live Crosswalks. While semi-automated regulatory change management is a strong usecase of such a construct, as discussed in this article, Live Crosswalks also enable compliance visibility. The connection from regulations to implementation defines the path through which compliance measurements need to be aggregated to construct a view of regulatory compliance automatically.
Disclaimer: Any views expressed in this article are personal views of the author.