This word evolved from a conversation with a number of highly regarded professionals (Mike Smith, Dan Philpott and Graydon McKee), with shout-outs to Chris Hoff and Anton Chuvakin for a twitter exchange around measurements (I believe this post is worth 286,497 Chuvakins).
And here (I believe) is one of its best examples:
Recently, Bob Carr (CEO of Heartland Payment Systems) gave a podcast interview to Bill Brenner at CSO Online. During this interview, Carr basically threw his Qualified Security Assessors (QSA) under the bus. He had equated what the QSA is responsible for doing (measuring Heartland against the PCI controls) for actual secure operations. There are two sides to this story I am sure, however I like to think of PCI-DSS as a “tech heavy” control set. To me this means that the controls are very focused on securing the technology but that it could still be maintained or operated poorly. That also means, that the QSA is focused on a very specific set of controls, not on Information System Risk Management (although it does mandate an annual risk assessment).
Carr asserts that the QSA assessments were not helpful for the years that he had to pay for it. I would argue that they were helpful because it showed Visa and Mastercard that Heartland had implemented a minimum set of controls to protect some information for Visa and Mastercard.
Where's the complianciness? Heartland Payment Systems – based on my research of the situation Heartland may have been PCI compliant at the point in time that they were assessed. It could be that security was a little more lax when the assessors were not inbound to conduct testing. It also might have been that a very elaborate show was put on for the assessors and they were not actually compliant, but perhaps practicing complianciness.
Question from the Audience: I thought you only talked about FISMA, where is the complianciness there?
A: Thank you random voice in my head.
It is rampant. FISMA / OMB / NIST Guidance all used come back to one thing, Information System Risk Management. The process of identifying risks to your mission or system and then applying a specific set of policies and controls to mitigate those risks. What has evolved from this, and I only have anecdotal evidence / hearsay to back this up, is that integrators, developers and operators are being told to simply follow NIST guidance. When that is entirely not possible without making some decisions by the customer.
NIST guidance is there to provide options and support. It can lay out things to consider and questions you should be asking yourself. The policies, procedures and processes that are carried out on an information system must be clearly defined at the beginning of the design process by being built into the design requirements.
I feel like now is the best time to mention these ideas because many organization in the government are going to be reviewing NIST 800-53 Rev 3, and having to make some decisions about what their policies are going to be for the next couple of years. My response is Choose Compliance not Complianciness.
Telling a vendor to go look at NIST and build it, will only get you what the vendor is willing to provide by shoehorning the solution into the controls. I'll elaborate. Vendor will read the controls. Vendor will either write the SSP or provide input to the Self Assessment. Those result will be their interpretation of the least effort required by that control. As the federal customer, you will believe that they have implemented that control to the strength that you believe it should be implemented. You have therefore practiced complianciness, at least until the auditor or assessor comes in and tells you what is actually happening (you hope). Because the auditor could in fact perceive the controls to be something entirely different altogether.
If you are part of a government agency, you want to provide a policy that can be based on 800-53 but you need to answer the questions it asks.
And that's the word.
