Skip to content ↓ | Skip to navigation ↓

Some of my more recent work is centered on making sense of the available security and compliance frameworks and standards, and I’ve got to be honest with you, it’s not that easy!  While some might argue these things no longer matter, the truth is (as I’ve said before) compliance isn’t dead – it’s just going to adapt as we build out measurable security processes.  These processes will still need to support compliance requirements, and they will need to do so in an automated manner – we need something in this industry that we presently lack: A machine-readable expression of compliance sources with which the lowest level tests can be associated.  No, we don’t need more frameworks or standards, what we need is a way to automate them.

I ended up surveying several compliance sources including CobiT 4.1, PCI DSS 2.0, ISO 27001, and NIST 800-53, and a variety of benchmark-level sources.  What I determined (I think) is that we might successfully map benchmark requirements into PCI DSS, which can be mapped into ISO 27001 controls, which can be mapped into the CobiT control objectives, which can then be mapped into a law or regulation, such as SOX.

Mapping Abstractions: Taking tests to laws and regulations
Mapping Abstractions: Taking tests to laws and regulations

I set forth some examples to my colleagues and one of them made an astute observation, having just studied for the CRISC certification: “I noticed that what we call a ‘Framework’ doesn’t always line up with their [ISACA] definitions.  For example, ISACA calls CobiT, ValIT, and RiskIT ‘Frameworks;’ (sic) while PCI DSS is a ‘Standard’.”  This is astute because it belies the fact that our industry hasn’t stabilized our vocabulary in the industry around these efforts and because some compliance sources straddle the boundaries we might like to impose.

At the heart of the matter, of course, is that we want to quickly, easily, and clearly associate the tests we perform with the correct portion of a given compliance source, irrespective of terminology.  This would suggest that we ought to pay the most attention to those points in each of the compliance sources to which we map tests.  Put another way, if we seek to substantiate a CobiT Control Objective with a particular set of tests, then we should be allowed to do so.  If we seek to substantiate a PCI DSS requirement, then whatever construct we use to express these relationships should allow us to do that as well.

All that being said, it seems to me that we would benefit from arriving at some notional vocabulary around which we can all have a shared meaning.  To that end, I would propose that we represent a “Compliance Context” as any compliance source other than a benchmark level, that each Compliance Context have one or more composite “Control Context” entities, and that each Control Context be associated with one or more Requirement entities.  To use an example, we might consider ISO 27001 as the Compliance Context, and 11.4.2 of ISO 27002 to be the Control Context to which we will associate specific Requirements.  Substantiating tests would then be associated with the appropriate Requirements.

Beyond the problem of expression, however, we also have a problem of authority.  To my knowledge, there is no one, definitive source of authoritative test-to-requirement association.  Further, some Compliance Contexts, such as PCI DSS, spell out Requirements before we even start (PCI DSS 8.5, for example).  In most cases, however, the Requirements are going to be spelled out by the enterprise seeking to comply with a given Compliance Context.  So, we may be able to construct expressions for a Compliance Context, but in most cases we will be unable to provide authoritative guidance with respect to how a Requirement substantiates a control by the set of tests associated with that Requirement.  This suggests that we might need to consider a separate expression for Requirements – one that need not be contained in the expression we use for Frameworks and their Controls.

Therein is the heart of this post.  Do we need a Compliance Context expression?  If so, how do we simplify the matter such that all we must worry about are the Control Contexts required by that expression?  How do we handle the “lower level” Compliance Contexts in a manner (such as PCI DSS) that does not break the model?  How would we make it easy for a given enterprise to build their own set of Requirements for given Control Contexts?  How do we properly associate tests to Requirements, and how do we provide some authoritative “umph” behind those associations?