The security industry is certainly not lacking in standards and industry regulations. There are regulations with objectives that range from verifying that companies implement a security management system (ISO27001) and safeguard data privacy (GDPR & CCPA) to regulations ensuring secure handling of health records (HIPAA) and validating that financial institutions are adequately protected against fraud and other types of malicious activity (PCI-DSS & FINRA).
The “Hows” of Compliance
These standards typically dictate the actions, processes, and procedures that need to be implemented to comply, aka – the “hows”. As you can imagine many organizations find themselves having to comply with different standards that in many cases have overlapping requirements.
A Different Approach: The “Whats”
Frameworks take a different approach, they focus more on the “whats,” the outcomes of activities, processes, and procedures. Frameworks are valuable because they provide a structured approach for companies to understand what they need to do to improve their security posture and how they need to prepare in the event of an incident. Some examples of security frameworks include the NIST Cybersecurity Framework (NIST CSF) which was developed for U.S. federal organizations (and those doing business with federal organizations) and the HITRUST Cybersecurity Framework developed for the Health industry. While they were developed to serve specific sectors, both are used today by organizations outside that original scope.
The advantage of a framework is that it can be written in a language that, yes, even non-technical executives can understand. If frameworks take a top-down approach while regulations and standards take a bottom-up approach, the framework “whats” and the regulations and standards “hows” can meet somewhere in the middle. An effective framework helps to bridge the language barrier that exists between security operations and middle management with executives. This is important since many security professionals are challenged to justify spend. More importantly, it facilitates cybersecurity awareness and helps to engage executives when needed.
Case Study: NIST Cybersecurity Framework
If we take for example NIST CSF, you will find that it is written in plain English, requiring a minimal understanding of IT concepts. It specifies a list of sensible things (activities and outcomes) organizations should do to induct cybersecurity into their fabric and corporate culture without forcing people to deal with information technology and cybersecurity tech-speak.
The Framework Core specifies five functions:
- Identify – What processes and assets need protection?
- Protect – What safeguards are available?
- Detect – What techniques can identify incidents?
- Respond – What techniques can contain the impacts of incidents?
- Recover – What techniques can restore capabilities?
The five functions of the Framework Core are broken down into 23 categories and 108 subcategories, these describe the “whats” of a cybersecurity practice or technique. For example, let’s look at one row in the NIST CSF:
| Function | Category | Sub Category |
| Detect (DE) | Detection Processes (DE.DP) Detection processes and procedures are maintained and tested to ensure awareness of anomalous events | DE.DP-3 Detection processes are tested |
Easy to understand? Sure. But how does this item map to the PCI-DSS regulation? And how does an organization take its first steps to implement it?
Mapping Frameworks to Regulations
Mappings to regulations and standards are provided by NIST and 3rd parties through Informative References. These are references to the specific controls of a standard (e.g. PCI DSS) that apply to a line item such as the one above. By separating the technical informative references, NIST CSF remains clear and easy to understand, it provides a common language between operations and executives and it enables companies from different industries to adapt NIST CSF to their specific profile by applying the relevant Informative References to their industry.
In the case above, the line item references PCI DSS v3.2.1 sections 10.6.1, 10.9, 11.2, 11.3 & 12.10. These provide elaboration and guidance on how detection processes should be tested and what should be recorded for compliance purposes. In essence, the Informational References are where the standards and regulations meet the framework, where the “what” and the “how” meet and bridge the language barrier of cybersecurity.
Taking this a step further, security vendors provide a similar mapping to show how their products apply to the framework and the regulations. Breach and Attack Simulation (BAS) companies, for example, could potentially map to the subcategory “Detection processes are tested”, with information on how BAS can safely simulate adversarial behavior across all vectors of the attack kill chain to test monitoring and detection processes.
Cybersecurity Frameworks are extremely valuable to organizations and the security industry at large. They codify activities and outcomes not only for regulatory compliance purposes but also provide a common language between management and operations and between security suppliers and the market.