Security risk and compliance teams are in a constant state of flux as they struggle to keep up with the alphabet soup of security framework, standards, and regulations. Consider the following scenario:
Common Control Framework Challenges
You have just completed your assessment using the NIST Cybersecurity Framework (NIST CSF). You now have a crisp understanding of where you stand and what your current state profile is as per the NIST CSF framework. A few weeks later, your executive management has just heard about the benefits of FedRAMP pentesting, such as the ability to bid on large, multimillion-dollar government contracts and because you are a global company, your Chief Compliance Officer has also notified you about GDPR. You panic and start to look for commonalities between FedRAMP, NIST CSF, and GDPR.
I’m shocked at how many times this same scenario is played over and over in almost every vertical in cybersecurity from the financial sector and healthcare to manufacturing. The only things that change in that scenario are new sets of acronyms. Multiple security frameworks with rapidly emerging requirements and lots of redundancy are nothing but common.
Common Control Frameworks
This is where the notion and the idea of the “Common Control Framework” come into play. The main idea is that somehow if we are able to comply with a single requirement from a framework, in theory, we should be able to reuse the adherence of that requirement for ALL the frameworks. This is the holy grail of cybersecurity compliance and risk management.
The Common Controls Experts
There are several approaches to achieving this common controls framework both in theory and in practice. We could also argue for days on defining what a “requirement” is and what a “control” is. We could also start to discuss the science of compliance and take a pure, academic, and theoretical approach to the Common Controls development topic. The industry is full of these types of experts and we would say that for the most part, these individuals are helping the industry in a major way. But because these discussions are always focused on the “why,” they rarely lead to the actual know-how in developing a practical common control framework for the modern organization. In this blog, we will break it down the fundamental basic building blocks and then build our framework from there.
What You Need to Know:
There are only two methods of developing a common control framework for the organization – and knowing the subtle differences can make your life easier.
Method 1: Controls Harmonization
Harmonization is the creation of a brand-new language set from several source languages taking into consideration content & context. In theory, the intent and meaning of the words and sentences remain intact, but the language and actual words have been changed with a new harmonized meaning defined.
Wouldn’t it be more efficient if everyone spoke a single language, such as English, globally? Better yet, what if we only knew English and no other language? That’s the idea here — very good in theory, but in reality, people will always speak many different languages. Security is no different — domain experts and legal experts will always create a new language set (hence the radical changes and updates in cyber regulatory and standards development landscape).
But, if we can actually achieve usage of a single language as an industry, globally, it would have significant benefits and it would be the most efficient way to operate not only as security professionals but also as humans. Maybe it would give us the ability to reconstruct the technological Tower of Babel. UCF (Unified Compliance Framework) is an example of this type of construct. The benefits of having a single language can truly be amazing both at work and in personal life, but totally unrealistic and unachievable for a modern-day company.
Method 2: Control Mapping
This comes after learning both the pros and cons of harmonization. Today, most brilliant and forward-thinking security professionals are using the mapping method. The main idea behind this method is to keep the original language intact as much as possible while mapping and matching the intent and meaning of each sentence and word. We call this the most practical and realistic approach because this is how humans fundamentally interact with each other globally. You can see this working in real life where two different languages are being spoken by individuals and kept mainly intact, but an interpreter or linguist is translating between the two — the map is developed in the mind of the linguist.
Language interpretation is an extreme example of mapping — formally, we call it translation. In fact, I argue that someone who can develop complex security mapping tables could be an excellent linguist. I had a chance to work formally as a linguist in the Middle East with the U.S. Military as an enlisted member. During our Defense Language Proficiency Testing (DLPT), one of the criteria that is tested is how well you can map one word to another and remember the map. The better you are at mapping and maintaining a mental map — the better your chances of picking up learning a complex language, such as Arabic or Chinese Mandarin.
Some real-life examples of mapping for cybersecurity frameworks can be seen in HITRUST Framework, Cloud Security Alliance Framework, and even the U.S. Government as it formally uses mapping in NIST SP 800-53 Appendix H – NIST RMF to ISO 27001 Mapping Table. The downside to mapping is continuous mapping for new frameworks. However, the benefits are that it allows you to actually break away from a single monolithic language that is brittle when a new regulation is introduced.
Catch our next blog on WE ARE COMPLIANT WHY DO WE NEED A SECURITY PROGRAM?
To learn more about how Ignyte Assurance Platform’s translation and mapping engine works, Request a Demo today.