Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mapping Frameworks #185

Open
ab-smith opened this issue Mar 30, 2024 · 7 comments · May be fixed by #584
Open

Mapping Frameworks #185

ab-smith opened this issue Mar 30, 2024 · 7 comments · May be fixed by #584

Comments

@ab-smith
Copy link
Contributor

ab-smith commented Mar 30, 2024

  • I want to do an assessment on one framework and automatically get my posture on another one
  • will be helpful to move from, let's say CSF to CMMC to assess the same project on a different scope
  • will be helpful when a framework gets an upgrade to avoid redoing the assessment
  • will be useful for reporting: I've just finished CSF assessment. How am I doing against ISO for instance?

Frameworks don't overlap necessarily, but if it can get half the work pre-done, it's a win

Multiple frameworks already have part of it done and we can improve that

@42mst
Copy link

42mst commented Apr 16, 2024

@ab-smith
As already mentioned in the discussion sector: What about this case;

Do you think this documentation/data-model.md model is sufficient enough in the long run?

Initial situation:

ISO27001 <-> NIST
ISO27001 <-> CCB
Client A is currently NIST compliant

Goal:

Client A needs to implement the latest CCB requirements to be NIS2 compliant.

Current Model:

Currently that means in your model that each control needs to be mapped against each other control which would create a huge overhead.
Maybe ( I´m not sure about that) it would make more sense to have a - let´s say - top level framework, like the ISO27001
All controls need to be mapped to that
To achieve the described goal you would have/need to implement a transitive relationship between the frameworks and by that the controls
--> NIST <-> ISO27001 <-> CCB
By that the top-level framework will always be the connecting element.

@ab-smith
Copy link
Contributor Author

ab-smith commented May 2, 2024

Hey, sorry @42mst I missed your comment on this one. As a matter of fact, what we are building currently is pretty close to what you're describing using a graph representation; for instance:

image

we will set the filled arrows, and the dashed ones will be deduced.

makes sense?

@42mst
Copy link

42mst commented May 3, 2024

@ab-smith
Yes makes sense. Are you planning to do it on a subset first? There are also ready-to-use mappings. I will list a couple of them in here:
NIS2 - ISO 2.pdf
sp800-53r4-to-r5-comparison-workbook.xlsx
Zuordnung_ISO_und_IT_Grundschutz.pdf
27002 2013 2022 Controls Mapping.xlsx
C5_2020_Referenztabelle.xlsx
Copy of CCF-VER2.xlsx
CyFun mapping Public_v20231106.xlsx

Doing this in combination with the #240 will be a gamechanger.

@ab-smith
Copy link
Contributor Author

Hey, we will use the existing mappings as a starting point and keep the same approach of letting the community review and enrich them

@AndrzejRPiotrowski
Copy link
Contributor

By mapping, can it be used in a way that - having 1 evidence connected to existing Standard (i.e. ISO27001) we will map same evidence to NIST. And if evidence changes it will apply to 2 standards.

Currently i have found difficult to control evidence that are mapped to several standards.

@ab-smith
Copy link
Contributor Author

@AndrzejRPiotrowski as a matter of fact, our recommendation is to have evidences attached to applied controls rather than the requirements and it will offers a better reusability and ease of mapping.

@AndrzejRPiotrowski
Copy link
Contributor

@ab-smith
Still, if You have a new requirement or requirement did changed, it should be visible that existing evidence is bad.
It's something worth show in the future (maybe as suggestion that "requirement did changed" check for applied control.

Thinking here if naming convention should be added

@nas-tabchiche nas-tabchiche self-assigned this Jun 26, 2024
@nas-tabchiche nas-tabchiche linked a pull request Jun 26, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants