Back when I first started the Information Security Program at National Instruments, Sarbanes Oxley (SOX) compliance was my primary concern. In fact, it was what my management used to justify me moving into NI's first full-time security role and I was told to "Beat SOX to the point where a monkey could do it." With that as my stated objective, I worked to develop our IT audit program around the hybrid COBIT and COSO controls that made up our SOX framework. I managed and performed all of the testing across our IT environments and worked directly with our third-party audit firm who performed the independent validation of our controls. Within a couple of years, I had a firm grasp on our SOX audit work and was able to transition the performance of most of the testing to employee #2 on my fledgling security team. But my job had only just begun.
With my hands now free from the majority of our SOX work, I began to focus my attention to other areas that needed security work. I started working on application security and frameworks like the OWASP Top 10 became of interest to me. I created a formal vulnerability management program which expanded my team's reach into operational and network security, as well. Suddenly, I found myself looking to use frameworks like ISO27001, NIST 800-53, and the CIS Critical Security Controls to use as a best practice approach with our IT teams.
As NI continued to grow as a company, our processing of credit cards went over a threshold and, suddenly, compliance with the Payment Card Industry Data Security Standard (PCI DSS) came to the forefront, requiring us to do a self-assessment across a large number of new requirements for our organization. Of course, based on my track record with SOX, the business came to me for answers, and I delivered.
Fast forward a few more years and we're doing business with the federal government, who is requiring us to adhere to NIST 800-171, DFARS and FAR. GDPR comes on the scene over in the EU, where we have both customers and employees, so we're now being asked the implications of that. And we've even started to incorporate the NIST Cybersecurity Framework (CSF) controls into our security program as a form of baselining and roadmapping our security program, which I talk about in more detail here. All this, and a number of other frameworks that I'll refrain from mentioning because it gives me an anxiety attack. Ultimately, we're talking about one to two dozen different frameworks that my organization was either tracking or attempting to adhere to, and the subsequent governance and compliance efforts to manage each one, independently, took up a massive amount of time and effort for my team.
With this "old school" approach to compliance, I treated each framework as an individual. I worked my way through each control in the framework, gathered my evidence, and validated compliance for it, and then I moved on to the next framework to do the same work all over again. But the reality is that often times this results in me testing the same thing more than once. Here's an example:
- NIST CSF ID.GV-1 says "Organizational cybersecurity policy is established and communicated"
- ISO 27001 5.2 requires that top management establish an information security policy
- AICPA SOC2 CC5.3 says "The entity deploys control activities through policies that establish what is expected and in procedures that put policies into action."
- PCI DSS 12.1 requires you to "Establish, publish, maintain, and disseminate a security policy."
What we see here is essentially four different ways of saying the same thing, so why would we go through the effort of testing this four different times in four different ways?
A Common Control Framework fixes this problem by creating a singular control set and then mapping those controls to the controls in other frameworks that say the same thing. For instance, these four controls above are referenced in the ComplianceForge Secure Controls Framework (SCF) as GOV-02, which states that "Mechanisms exist to establish, maintain and disseminate cybersecurity and privacy policies, standards and procedures." More importantly, the SCF shows us that this control maps to NIST CSF ID.GV-1, ISO 27001 5.2, AICPA SOC2 CC5.3 and PCI DSS 12.1, along with controls in a number of other frameworks. Here's an example of how we've represented this common control in SimpleRisk:
Now, here's where the massive benefit of using a common control framework comes in. Once I've come to the realization that all of these controls are asking for the same thing, there's no reason why I can't test the common control once, and then use that result for all of the other frameworks. So, in SimpleRisk, we define a single test for the common control like this:
I run that test through its paces, gather my evidence, and capture the pass/fail status. Once completed, I can report on the status of that test across any of the frameworks that it's included in:
I've now saved countless hours by testing this control once and using it everywhere it is mapped, rather than wasting time trying to run these same tests for each framework.
I'd be remiss if I ended this post here, making you think that the ComplianceForge Secure Controls Framework is the only common control framework out there. While it is the one that SimpleRisk has the most comprehensive integration with, and they allow anyone to leverage their controls for free, we also have API level integration with the Unified Compliance Framework (UCF). I've also run across other frameworks in my research, like the Adobe Common Controls Framework, but licensing restrictions have prevented us from integrating them into SimpleRisk in the same way we have the SCF.
The next time you find yourself pulling your hair out over all of the time you're spending trying to comply with all of your different framework requirements, maybe it'd be worth giving a common control framework a try? The SimpleRisk Core is free and open source (MPL 2.0) and offers our integration with the ComplianceForge SCF free for any registered instance. Give it a try today!
