Assertive compliance - using frameworks to extend your coverage

There’s a dirty secret in the IT Compliance world. At its core, it doesn’t change that much. That’s not to say that there hasn’t been any change. The technology that we use changes all the time. The industries that rely on technology change too. How we go about fulfilling compliance requirements change.

But the core of IT Compliance is mostly fixed around maintaining confidentiality, integrity, and data availability. That was the goal when we were tapping away in RACF on mainframes, CAT at the CLI in Unix or Get-ADUser in PowerShell. It is still the goal whether we are storing credit card data, processing health information, or maintaining source code repos. It is a powerful insight. Once we recognize that the objectives are more or less the same at a high level, we can make some assumptions. An activity that covers “User Access Reviews” for PCI Compliance might also cover it (or its equivalent) for GDPR. So, if you’re ensuring that all your users are appropriately authorized to store PCI data, you’ve got a pretty good start regarding GDPR User Access Reviews too. And for that matter, wherever User Access Reviews are required. Spoiler: They are needed everywhere.

Everybody knows the story of the Rosetta Stone. Vast bodies of work were written in Egyptian Hieroglyphs, but nobody alive could read them; when someone discovered a stone tablet that contained the same messages in both Greek and Egyptian, the mystery of Hieroglyphs unraveled. “Frameworks” are the Rosetta Stones of IT Compliance. They allow you to relate a compliance requirement to an activity and cross-reference other compliance requirements. Arguably the NIST Cybersecurity Framework is the most prominent. The NIST Cybersecurity Framework was issued by the National Institute of Standards and Technology, an arm of the US Federal Government. It has since become required for all Federal agencies and, by extension, has been adopted by Federal contractors, large service organizations, and technology firms. It is written in plain language, is rationally organized, and is open-source. We’re big fans of open-source projects. But most importantly, every requirement in the Framework relates to both an activity and its equivalent condition in other standards.

So if we know that a part of our PCI compliance is to send logs to a SIEM for immediate analysis, we can search the NIST Cybersecurity Framework to see where audit logging might fall. We learned then that we are not only PCI compliant (yea!) but also made some headway into CIS’ Critical Security Controls, ISACA’s COBIT5, the International Society of Automation’s 62443 series, the International Standards Organization 27001, and NIST’s SP800-53 series. It should be noted that this extra credit isn’t automatic. You’ll still need to research the associated requirements. But it is a good start, and the chances are good you can re-use your existing activities (with some updates).

There’s another secret to uncover here. Increasing compliance coverage isn’t just about tracing your activities to the relevant standards. It is also about choosing the suitable actions to perform to get the best coverage. We might be a little biased, but we think leveraging logging technologies is where you can truly shine in compliance. For example, the NIST Cybersecurity Framework comprises five functional areas. Logging controls impact all five areas and is critical in four of them. So logging is a great place to start if you want to get a compliance issue under control. That means a robust logging strategy can be the difference between an agile and comprehensive compliance posture and one stuck remediating audit findings. The best practice is to look for multi-platform tools that can also add value in different environments. Don’t put yourself in the position of choosing between serving customers and remaining compliant.