Want more cybersecurity insights? Visit the Cybersecurity channel:
The cybersecurity industry has a framework problem. It’s an alphabet soup problem between SOC2, NIST, ISO, COBIT, CCM, and more. Many of these frameworks were created to support a specific industry or use case despite those that came before it. Additionally, there’s a tremendous amount of overlap that exists in the controls captured from one standard to another.
With that context, one question has stuck with me throughout my career:
Why does the industry continue to invest in creating new standards instead of investing in reciprocity and elimination of duplicative work?
One standard that I have seen invest heavily in reciprocity, especially in the area of cloud security, is the Cloud Security Alliance cloud controls matrix (CCM). If you are a cloud-native organization or building a product that is cloud-native, it can serve as an incredibly useful source of truth for where and how you document controls. Third-party risk management programs frequently require accreditation’s like SOC2 or ISO 27001, both of which can be mapped back to the CCM as a base.
Benchmark for Security Programs
Why do frameworks matter? It’s a good question, and one that many hands-on technical professionals may ponder as they’re filling out questionnaires and updating GRC tools.
Frameworks serve as a benchmark and a guiding light for how to build a security program, identifying what strategic areas to focus on. A well-designed security program cannot be overly optimized in any one area; it must balance security activities across asset classes. A good security framework will have controls that span areas as different as background checks, patching, incident response, all the way through to security training.
They also serve as a communication tool to manage perceived risk to other organizations. Frameworks provide an API of sorts for organizations to understand and reason about one another’s security posture and maturity. For example, if organization A is selling its services to organizations B and C, they can interpret the risk they’re taking on through the lens of a standard.
The confidence in adherence to the standard may be positively influenced with third party accreditation and automated reporting. They can make decisions based on their own applicable risk tolerance and requirements.
Plethora of Frameworks
There is a multitude of security frameworks that exist today, many of which have a cloud security intersection or focus. As a security professional, it’s difficult to know where to focus without explicit requirements being placed in your hand. For example, some industries will have specific requirements associated with them. Financial services, credit card processing, and PCI-DSS serve as a good example. Healthcare organizations align with HIPAA and, in some cases, HITRUST.
If you don’t have one of those industry-guided requirements, it can be dizzying to choose between:
- ISO 27001, 27017, and 27018
- GDPR
- SOC 1/2/3
- PCI DSS
- HITRUST
- Cloud Security Alliance CCM
- NIST 800-53
- HIPAA
- CIS AWS Foundations
- CIS Controls Top 20
- ACSC Essential Eight
The list above is not even exhaustive, yet it highlights the scope of the issue. Security professionals should be able to spend more time securing their organization than documenting that same work.
Reciprocity and Simplicity
As an industry, I believe we should be investing in reciprocity across frameworks instead of creating new ones to meet a need. With a leap in reciprocity and controls mapping, we can potentially sunset certain frameworks and rally around a smaller set of them. Less can be more.
With less cognitive overhead around compliance, the industry can focus more of its collective time and energy on the hands-on work and collaboration this field demands. Fewer overall frameworks or a simpler ecosystem of frameworks may also enable us to collectively move faster. For example, platform providers can invest in accreditation fewer times and the benefits can percolate out to the consumers. Reading through Amazon Web Service’s list of certifications, regulation alignment, and frameworks underscores this point.
Teams can also lean into control mappings and reciprocity to help themselves scale. For example, they can do that by building a robust internally managed version of the CCM with mapped metrics and tooling support where possible. If and when asked for support and alignment with frameworks other than the CCM (which is extremely common), filter all the controls that map to SOC2 based on the work done by the Cloud Security Alliance and you’re mostly there.
Maintaining a source of truth that goes beyond yes/no answers with no context can help avoid the dreaded busy work of answering the same questions time and time again.
