-
Notifications
You must be signed in to change notification settings - Fork 179
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
Support for control mapping #1150
Support for control mapping #1150
Conversation
ade0245
to
5509ba1
Compare
8b6ebe6
to
71cb482
Compare
5509ba1
to
8547750
Compare
A draft XML Schema is available that incorporates the draft mapping model. |
Current model defines I am suggeting to allow the degree of coverage is not the same thing with I will have a dummy example to seed the conversation. |
here is the gist provided by @david-waltermire-nist : https://gist.github.com/david-waltermire-nist/ad5fba71ccfe4d5a07b6b8b07238b0d4 Note: this link is also provided above as "draft XML Schema". |
NOTE: This example can be presented in OSCAL as well, but having it first here for discussion purpose might be more beneficial at this point. If we assume two catalogs: Assuming: Since OSCAL is not prescriptive, and for different purposes, (e.g. B1 and B2 could be part of different profiles) mappers/users of the mapping model can describe the relation in any way they find suitable for them, depending on the mapper's (human) view, perspective or needs: OPTION 1 (using current mapping model): I find the information provided by this mapping above insufficient to support transitivity and proper traceability for assessment data and purpose. OPTION 2 (per the comment I left earlier) uuid=2002: A1 uuid=2003: A1 uuid=2004: A1 uuid=2005: A1 I am also thinking that to use the mapping for the implemented controls in SSPs or CDEFs, it is important to allow the mapper to provide more information related to the relationship and some flexibility in tailoring the relationship at different levels in the stack (profile, implementation, assessment) |
@jason-callaway - Your review is greatly appreciated. Could you please also provide the types of relations you identified in your extensive mappings between different control catalogs? Thank you. |
Hi, @iMichaela! I like your relationships of sckg has the following relationship types:
Here's the schema from I'd love to also capture those relationships, particularly A1 ≡ B1 U B2, but I'm unaware of any datasets (aside from CSF) that provide those qualitative mappings. If you know of any that do, please share! |
The mappings superset-of and subset-of can be reversed according to set theory. A superset-of B can be notated as
Part of why we want to create a more formal, mathmatically sound model is to allow for more automated inferencing around mappings. The difficulty part about the current state of mapping is that most mappings are created through opinion and rough consensus, but are not always mathmatically sound. We are trying to strike a good balence in defining relationships that can be easily understood and applied, that lead to mathmatically sound results.
Can you provide definitions for and/or some short examples of use of your relationships? |
The 'union' and 'intersect' were introduced also in issue #1221 . The discussion should be merged. And @david-waltermire-nist is accurate - we want a precise but flexible-enough mathematical model that allows experts like you, @jason-callaway, to use it with ease.
This can also be useful information... so maybe we should consider including a field that identifies if the controls are independent or or not. Because the dependability relationship are also very important for the controls satisfaction and assessments. |
Thanks, @david-waltermire-nist and @iMichaela for your responses! Here are some examples of sckg's relationship types: HASRegimes, families, baselines, and controls themselves can all "have" a child control. Like in the example below, the
DEFINESSometimes a regime has a control that's defined in some other place, like the 800-53r4's Appendix J.
IMPLEMENTSIn the ComplianceAsCode project, controls are broken into
REFERENCESRegimes like DoD CCI (for which the label "regime" isn't completely right but I haven't thought of a better one yet) define their own things -- in this case CCIs -- that reference more traditional regime controls like those from NIST 800-53.
REQUIRESSome regimes like CNSSI 1253 rely on controls from other regimes like NIST 800-53. In this example, the National Security Systems (NSS) baseline requires AC controls from NIST 800-53.
|
@jason-callaway Thank you for all the examples. As I assumed, you are mainly capturing dependencies as opposed to possible relations among independent frameworks (with the CCI exception that could be perceived as independent when actually is not. For example, if:
and
Then
**I will need to know what is left out (e.g. stm_2) because it is a MAJOR difference between the case shown above when parts of the control can be mapped as And If I have another CCI
Then
However, in such cases it would be more useful to actually be able to do the mapping at the statement level.
|
You are quite correct, @iMichaela! The closest thing I have to inter-regime mappings comes from NIST CSF. It lets me do things like map 800-53 controls from the FedRAMP High baseline to PCI DSS requirements.
The issue here is that CSF provides little data in terms of equivalency. For example, the first result suggests: AC-1 ≡ [8.2.2, 7.2, 7.1, 6.4.2, 12.3.10, 12.3.9, 12.3.8, 8.5.1, 8.3, 8.1.5, 12.3, 8.2, 8.1] Is this actually true? I haven't analyzed it -- partly due to a lack of cycles, but also because everything in the graph so far is a un-opinionated transformation of data formats. I think I'm getting away from what's applicable to this PR, so I'll stop now; I just wanted to be clear on the limitations of my data. |
@jason-callaway As for frameworks that requires controls from other frameworks... there si a clear relation that needs to be represented, but part of that requirements needs to be FIRST properly captured in OSCAL catalog and I am not sure yet what is the best practice in this case.
and the OWASP controls are
Then the OSCAL Catalog will have to FIRST represent it.
but will not be super accurate from the OSCAL Catalog D perspective which would need to first represent control D1 properly/completely, and not just state it in pure English statement. Not sure how to do that yet. Such control exists in one catalog that is currently being formatted in OSCAL. But this is a different issue. |
This kind of mapping we are trying to support while allowing the mapper to be more precise so the mapping can be used for traceability and mutual recognition of assessments. |
@david-waltermire-nist I looked at the example mapping and the schema. Here are some comments based on my understanding. Not sure if you already addressed those. I believe there are 4 possible relationship types between source control and target controls (one or more) -
In the example the source and target types are "control". Can we have other types also say "part" - for example "AC-1.a", if I want to specify mapping for a specific part of a source control to a specific part of a target control. I believe the schema allows more than one source control to be specified as part of a mapping, but generally one source will be mapped to one or more targets. |
@vikas-agarwal76 Thank you for the feedback.
For number 4, I would call this "intersects-with".
Yes. This mapping model is intended to support mapping at the part/statement level.
While I agree that one source to one or more targets will be a common case, we are trying to be flexible here to support many-to-many mapping cases as well. The model can handle all these mapping pattern variants. |
@david-waltermire-nist Thanks for the clarifications. I believe a 5th relationship that may be good to capture would be "None" or "Null". This is to explicitly capture cases where no mapping (not even partial) exists for a source control in the target catalog. In this case the target controls will be empty. This will help distinguish cases where no mapping has been specified till now versus no mapping exists at all. One may want to explicitly state that fact for completeness to avoid any ambiguity. |
@david-waltermire-nist I got a few things I would like to sync up on issues that came up when prepping @degenaro to build a copy of the docs locally. I assume these are docs pipeline issues, but 1/2 I cannot tell require finalized Metaschema changes to get "picked up" but I was scratching my head on where the WIP
Let me know or we can discuss during triage, and I can make 1 or 2 separate issues to track, but 2 is the more urgent one obviously. |
Per conversation, I made #1286.
Dave pointed out this requires in branch modifications of the Metaschema and docs pipeline, no separate issue or development branch is need for item 2. |
7869eab
to
a15053f
Compare
After meeting on 6/29, we decided that this PR can be merged. As follow on work we identified the need to create two issues:
|
@iMichaela As we discussed on 6/30/2022, please update your review by CoB 7/1/2022. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am approving the PR with the strong recommendation to review and consider the comments when deemed reasonable and accurate.
@david-waltermire-nist PR review was completed. The issue raised earlier by @vikas-agarwal76 intersects-with my second from the bottom comment (see above) and is not supported in the current version, but we might need to give a second thought to it.
|
This would require making the cardinalities on the target items It would be better to support this using a different construction that would follow the existing mappings to define unmapped particles (i.e., controls, or control statements). A new issue should be created for this. This will allow for more discussion with the community around if this feature is needed and how to support it. @iMichaela Would you please make a new issue for this? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you.
I just want to take a moment to celebrate those who worked on this. You all rock! Thank you! |
* Added mapping model supporting mapping controls and control statements between two catalogs. * Adjusted relationships based on PR #1150 discussions. Added type enumerations. * Included a simple example
* Added mapping model supporting mapping controls and control statements between two catalogs. * Adjusted relationships based on PR #1150 discussions. Added type enumerations. * Included a simple example
* Added mapping model supporting mapping controls and control statements between two catalogs. * Adjusted relationships based on PR usnistgov#1150 discussions. Added type enumerations. * Included a simple example
Have you thought about using NIST 800-53A (A for assessment) keywords and
doing some fuzzy match, with (or without) ontology matching? (NLP ML based
mapping left as a challenge problem for the reader.)
…On Thu, May 5, 2022 at 12:10 PM Jason Callaway ***@***.***> wrote:
You are quite correct, @iMichaela <https://github.com/iMichaela>! The
closest thing I have to inter-regime mappings comes from NIST CSF. It lets
me do things like map 800-53 controls from the FedRAMP High baseline to PCI
DSS requirements.
MATCH (:regime {name: 'FedRAMP'})-[:HAS]->(high:baseline {name: 'High'})
WITH high
MATCH (csf:regime {name: 'NIST CSF'})-[:HAS*]-(b:baseline)
WITH high, b
MATCH (nist:regime {name: 'NIST 800-53'})-[:HAS*]->(nc:control)
WITH high, b, nc
MATCH (pci:regime {name: 'PCI DSS'})-[:HAS*]->(pc:control)
WITH high, b, nc, pc
MATCH (high)-[:REQUIRES]->(nc), (b)-[:REQUIRES]->(nc), (b)-[:REQUIRES]->(pc)
RETURN nc.name AS FedRAMP_High, collect(distinct pc.name) AS PCI ORDER BY FedRAMP_High
[image: Screen Shot 2022-05-05 at 3 04 58 PM]
<https://user-images.githubusercontent.com/3760617/167006193-1e95bec1-db87-4409-aa26-3735b69c2d70.png>
The issue here is that CSF provides little data in terms of equivalency.
For example, the first result suggests:
AC-1 ≡ [8.2.2, 7.2, 7.1, 6.4.2, 12.3.10, 12.3.9, 12.3.8, 8.5.1, 8.3,
8.1.5, 12.3, 8.2, 8.1]
Is this actually true? I haven't analyzed it -- partly due to a lack of
cycles, but also because everything in the graph so far is a un-opinionated
transformation of data formats. I think I'm getting away from what's
applicable to this PR, so I'll stop now; I just wanted to be clear on the
limitations of my data.
—
Reply to this email directly, view it on GitHub
<#1150 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AQWTGFDFEHRMROGVVTR6NJLVIQMLZANCNFSM5PH6DXUA>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
* Added mapping model supporting mapping controls and control statements between two catalogs. * Adjusted relationships based on PR #1150 discussions. Added type enumerations. * Included a simple example
* Added mapping model supporting mapping controls and control statements between two catalogs. * Adjusted relationships based on PR #1150 discussions. Added type enumerations. * Included a simple example
* Added mapping model supporting mapping controls and control statements between two catalogs. * Adjusted relationships based on PR usnistgov#1150 discussions. Added type enumerations. * Included a simple example
* Added mapping model supporting mapping controls and control statements between two catalogs. * Adjusted relationships based on PR usnistgov#1150 discussions. Added type enumerations. * Included a simple example
* Added mapping model supporting mapping controls and control statements between two catalogs. * Adjusted relationships based on PR usnistgov#1150 discussions. Added type enumerations. * Included a simple example
* Added mapping model supporting mapping controls and control statements between two catalogs. * Adjusted relationships based on PR usnistgov#1150 discussions. Added type enumerations. * Included a simple example
* Added mapping model supporting mapping controls and control statements between two catalogs. * Adjusted relationships based on PR usnistgov#1150 discussions. Added type enumerations. * Included a simple example
Committer Notes
This PR provides OSCAL mapping support.
All Submissions:
Changes to Core Features: