Updated: 20 December, 2024
2 October, 2024
Cybersecurity in general and application security (AppSec) in particular are extremely challenging topics. They run broad and deep and success in one area is just not enough. A systematic solution is provided by the myriad of various (compliance) cybersecurity standards, frameworks and maturity models. CIS Controls, Cloud Controls Matrix (CCM), ISO27001, NIST SSDF, NIST CSF, BSIMM, OWASP SAMM, Cybersecurity Fundamentals, DevSecOps Maturity Model just to name a few. Amongst one of the most promising solutions is the OWASP Software Assurance Maturity Model that is rapidly becoming an industry standard within the AppSec domain. Nonetheless organizations often have to deal with more than one overlapping, complementing and even competing standards. Hence, mapping cybersecurity compliance standards and frameworks is essential in order to make sure that organizations are not reinventing the wheel. Amongst the key pressing questions nearly every organization has to deal with are:
- How adopting one standard can help with conforming to another one? For instance, a company that has adopted NIST CSF 2.0 would like to get an ISO 27001 certification? Or an organization is leveraging OWASP SAMM and would like to map it to NIST SSDF.
- Where can one find information on how to satisfy a particular program framework? For instance, what are the typical controls an organization needs to implement in order to conform to NIST SSDF RV.2.2 (Plan and implement risk responses for vulnerabilities)?
- What capabilities does a product need to demonstrate to conform to a specific standard?
- What are the key changes between different major versions of standards (e.g., NIST CSF 1.0 to CSF 2.0)?
In this blog, we explore this topic in depth. We start by discussing the use cases for having mappings. Then we focus on the currently existing solutions. Finally, we outline what the future could possibly hold when it comes to mappings between different standards.
Key takeaways
- Most organizations have to deal with multiple security standards and frameworks. Hence mapping compliance standards is extremely valuable and has many use-cases.
- Creating manual mappings between any two standards is labor intensive and simply not feasible. E.g., 10 standards would require 45 mappings.
- OpenCRE from OWASP is a game changer as it requires creating a mapping to Common Requirements Enumeration. From there it can generate mappings to all other standards in OpenCRE. For instance, if standards A and B are mapped to OpenCRE, OpenCRE can generate a mapping from A to B.
- Creating a mapping to OpenCRE remains a challenging exercise. Imperfect mappings will lead to compounding imperfections. Hence it is essential to involve the standard governing bodies to verify the mappings and give their stamp of approval.
- Not everyone is familiar with OpenCRE, but mapping experts could be familiar with a standard that is already in OpenCRE. We have implemented a hybrid solution that would allow mapping to a standard supported by OpenCRE and leveraging transitive mappings to map to any standard in OpenCRE.
Why do we need mappings between different security standards and frameworks?
Most organizations have to deal with multiple security standards and frameworks. For instance, an organization that has adopted OWASP Software Assurance Maturity Model (SAMM) for managing their application security program might need a ISO27001 certification to participate in a tender. An organization that is a vendor to a U.S. federal agency and processes credit card payment information has to conform to NIST SSDF and PCI DSS. If that organization also decides to provide financial services in the EU the Digital Operational Resilience Act (DORA) would be also applicable. This is not the only use case for having the need to map between different standards. We provide a bullet list of example use cases for mappings between standards and frameworks:
- Risk officers need to figure out how the current adoption of OWASP SAMM will allow the company to conform to NIST SSDF.
- Ops employees need additional guidance on how to implement processes recommended by CIS framework within Microsoft Azure cloud environment.
- Organization’s security experts who assess technology products and services need to understand which device features described in guidance NIST SP 800-53 help the organization implement the cybersecurity measures outlined in guidance NIST CSF 2.0.
- Users of ISO27001:2022 need to know which clauses have significantly changed from version ISO27001:2013.
Mapping types: level of granularity and conceptual relationship between sources
When creating a mapping between two standards it is essential to select the right level of granularity. For instance, NIST SP 800-53 defines 20 control families, each family contains multiple controls and some contain control enhancements. Mapping to the 20 control families would be a lot faster and easier. But clearly that would not be as valuable to mapping users. At the same time mapping to the lowest level is also not always practical. Hence, selecting the right granularity is not always obvious and you might need to take into account the potential use cases you would like to offer when creating a mapping.
Relationship types
Mapping science is extremely complex. It goes beyond specifying that two concepts from different compliance standards are related. Depending on the specific use case you might need to know how the different concepts between two standards are related. For example a mapping may say that SAMM practice Policy and Compliance is related to NIST SP800-53’s control AC-2 (Account Management). However the mapping does not indicate whether the two controls are equivalent, whether they overlap, whether one helps achieve the other, etc. As a result, mapping consumers should guess its meaning and context. Nonetheless, even this sort of simple crosswalk mappings are valuable. They can save some time by pointing people to relevant information. Though users will have to read and comprehend the concepts in both standards to understand the nature of the relationship.
There are 4 relationship types when creating mappings:
- Related or crosswalk indicates that two entities are related without any additional characterization.
- Supports indicates how a support concept can help achieve a supported concept.
- Set theory relationship mapping (A∩B = ∅, A∩B ≠ ∅, A⊂B, A⊃B, A=B) derived from set theory. In human language two concepts are unrelated, overlapping, subset, superset or equivalent.
- Hierarchical structure that usually relates concepts defined within a single source. For instance, SAMM defines 5 business functions. Each function is composed of 3 security practices.
The current state-of-the-practice for mappings is still in its infancy and even having accurate crosswalk mappings between most common standards is highly desirable.
Manually mapping two standards
Even for an expert creating a crosswalk mapping between two standards might not be as straightforward as it seems. First of all, you want to only capture the strongest direct relationship between two concepts and not look at indirect or tenuous relationships. Secondly, this exercise will be time-consuming and different experts are likely to end up with minor differences depending on their interpretation of each standard. Hence, it is a good idea to have at least two or more experts involved in creating a mapping. Aside from mapping complexities the number of mappings between a set of standards increases substantially as the number of standards grows. For 5 different standards there are 10 mappings, for 10 standards there are 45 mappings.
Open Common Requirements Enumeration: the meta standard
OpenCRE (Open Common Requirement Enumeration) is an open-source platform that connects various standards, guidelines and frameworks. Its primary goal is to create a unified view of cybersecurity best practices by linking related concepts from different frameworks, such as NIST, OWASP, ISO, CWE, and more. The idea behind OpenCRE is to leverage a star topology to map each standard to OpenCRE. We then leverage the transitivity principle to generate mappings to other standards in OpenCRE. The transitivity principle is defined as follows: if A maps to B and B maps to C then A maps to C. It is based on this principle that we can leverage OpenCRE to map compliance standards.
Approved mappings to OpenCRE
Unfortunately the transitivity principle for generating mappings between standards suffers from a drawback. Imperfect mappings may have compounding effects. One of the causes of imperfections is the relationship strength. For instance, if concepts A and B from two standards are weakly related to entity X in OpenCRE then the relationship between A and B might be very weak and irrelevant. Another scenario is having concepts A and B so weakly related to entity X in OpenCRE that this relationship is ignored. However the direct relationship between A and B might be strong and worth a mapping.
Hence, ensuring a perfect mapping to OpenCRE will be extremely valuable for the overall effort. To achieve that we believe that the standard governing bodies would need to be involved to create approved mappings for the relevant standard to OpenCRE.
The OWASP SAMM core team has done that and the quality of SAMM to OpenCRE mapping has been improved. Although the changes were relatively minor, we believe that the impact has been substantial.
Hybrid mappings
Last, but not least the transitivity idea could be taken a step further. The idea here is very simple. Let’s say a standard A maps to a standard B. If standard B maps to OpenCRE then we could immediately leverage OpenCRE to create mappings from A to any other standard mapped to OpenCRE. One of the main advantages of this idea is that we could expand OpenCRE’s reach almost instantly at no cost. Moreover, experts might be more inclined to create a mapping between two standards they aready know well. Hence, we could leverage this as a stepping stone for creating mappings to OpenCRE. Clearly, we need to keep in mind that the transitivity imperfections will have an even larger impact on the end result.
Conclusion
In this blog, we have discussed the value of mapping different cybersecurity compliance standards. In conclusion, mappings are crucial for aligning cybersecurity compliance standards and frameworks. Despite technological advancements, expert involvement remains essential for creating high-quality mappings. Investing in these mappings can streamline security and compliance efforts. It will make processes more robust and reduce the burden on security professionals.
