The Problem of Interpretation

BY JUSTIN ARBUCKLE

This is the third in a series that describes the compliance landscape. The previous articles can be found here and here.

In this article we’ll talk about how the interpretation of regulatory intent is increasingly being deferred by regulators to domain-specific bodies or councils. This is often signaled in legislation as ‘best practice’ or ‘industry norms.’

In our previous post, we discussed how, in most large organizations, what we receive as compliance requirements are like photocopies of photocopies. The image is still discernible but its boundaries are fuzzy. Unfortunately, once we commit to a strategy for implementation we tend to let ourselves be bound by it, even when the original motivations for the strategy no longer apply or when there are technical advances that would now be a better fit.

In such situations you’ll often hear technologists make an appeal to the source. In frustration they ask, “Show me where it says that we have to do X?” Sadly, this is often not effective.

Take a common request from a CISO that “every action on a box must be authorized and traceable.” That seems reasonable enough. But what are the boundaries? Does that include system agents communicating with other agents? Or does it apply solely to human actors? Does that exclude third-party combined logins?

Perhaps going to the source will help, but what source? Here are some possible candidates:

Cloud Controls from the Cloud Security Alliance — AIS-04 — stipulates “Policies and procedures shall be established and maintained in support of data security to include (confidentiality, integrity and availability) across multiple system interfaces, jurisdictions and business functions to prevent improper disclosure, alteration, or destruction.” They helpfully trace this to component regulation sub sections in HIPPA, HITECH, PCI-DSS, ISO, NIST etc. From the same source, AIS-01 essentially says that industry best practice should be used. So, wanting to get specifics, where should we go? Looking at industry specific bodies doesn’t help very much.

The FFIEC statement on cloud computing is dated July 2012 and there hasn’t been one since. Here is an extract relevant to our investigation, “Storage of data in the cloud could increase the frequency and complexity of security incidents. Therefore, management processes of financial institutions should include effective monitoring of security-related threats, incidents, and events on both financial institutions’ and servicers’ networks; comprehensive incident response methodologies; and maintenance of appropriate forensic strategies for investigation and evidence collection.”

If you head over to the Center for Internet Security their controls are slightly more detailed, such as CSC 3–4, “Follow strict configuration management, building a secure image that is used to build all new systems that are deployed in the enterprise. Any existing system that becomes compromised should be re-imaged with the secure build.” Seems we need to go deeper. You could try googling ‘linux security’?

If you had started with a high-level regulation like PCI-DSS you would have found a good statement of outcome but little guidance on implementation.

What we increasingly see is that legislation is deferring technology implementation guidelines to technology domain specific bodies or councils. This is often signaled in legislation as ‘best practice’ or ‘industry norms.’

A selection of the various implementation frameworks available is shown in the diagram below.

Referring to an industry council or body for technical implementation guidance is a very good thing and it helps to solve the ‘interpretation problem.’ With a specific list of what constitutes best practices, the technologist has a concrete example of what to do and what to propose to auditors. It is unlikely that these standards, such as the CSA standards, are fundamentally different from what you would have done anyway, but the presence of documentation and the existence of an externally verified and maintained standard provides a formal mechanism for mapping the outcome presented by the auditors to your scenarios for implementation.

If we have a better idea of what key tasks are involved in being compliant, and have agreement across the business, what’s the problem?

Compliance regimes evolve, as do the underlying standards. Your infrastructure and applications change as do those who manage them. Even with a better view of what to implement, doing so at scale is difficult and you are unlikely to be consistently successful across your landscape.

You need to find:

• A way to keep systems compliant, as standards evolve, without you having to start the whole compliance audit process over again.
• A way to manage complexity so that you can start shallow and deepen fast as you learn the impact of the controls on your business.

In the next article in this series we’ll describe the importance of expressing compliance as code. With this approach, you can innovate at velocity without sacrificing regulatory compliance.