Closed anweiss closed 2 years ago
Adding more commentary here, and setting aside for the moment who would ultimately be responsible for mappings, we could start by simply leveraging the existing "profile" model to support mappings. Since the "profile" schema already allows for more than one import
element, it's trivial to include additional "catalog"/"framework" imports
which can effectively be inferred as mappings (assuming we'd update the call
element to include some sort of refId
attribute which actually connects the calls together). In this scenario, the calls
subsequently represent both the selected controls from a "catalog" and the mappings.
@wendellpiez thoughts?
@anweiss that is quite an interesting idea: effectively (as I understand it) you are suggesting a semantics of a refId attribute (or such) that would provide a profile with mappings among its controls "on arrival" (i.e. expressed somehow in resolution). I can how this could be useful.
We should throw this idea in the mix as we talk about merge/modify semantics. Since, effectively, to "express a mapping" is a kind of modification potentially with a merge or at any rate "decorate" component (maybe the two controls in question are grouped, they are likely linked in some way) ... really the need here is open ended (for being able to express mappings or even relations in general - a mapping being (I'd argue) an interesting sort of "mutual dependency" relation ... and we already know we have cases where even by default, there will be merge behavior specified) ... so I wonder whether "express a mapping" could not be the first of several sorts of "smart annotation" operations on controls (others might include to include forensic tracing of profile resolution, etc.).
FWIW, a document describing or "declaring" mappings among all these catalogs might readily be expressed in OSCAL, but it would likely be a more free-form "documentary" form (I think) than the profile; outwardly, it would look more like a catalog albeit with many more links than a standalone catalog. Sprint 3's rough prototype of an extraction of CSF YAML into XML (see /working/CSF/CSF-framework-enhanced.xml) offers a taste of what this might look like albeit it is entirely data driven (i.e. it has exactly what the source had and no more, only reformatted and linked up) ... it only happens that the YAML in question describes something like a mapping.
Yea, let's definitely keep this in mind as we address #93
FWIW, I think we may want to support standalone mapping documents in addition to embedded mappings in framework and catalog documents. This would probably idea for the most flexibility and utility.
-------- Original Message -------- From: Andrew Weiss notifications@github.com Date: Sun, January 28, 2018 1:46 PM -0500 To: usnistgov/OSCAL OSCAL@noreply.github.com CC: Subscribed subscribed@noreply.github.com Subject: Re: [usnistgov/OSCAL] OSCAL's role in mappings between standards (#87)
Yea, let's definitely keep this in mind as we address #93https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fusnistgov%2FOSCAL%2Fissues%2F93&data=02%7C01%7Cdavid.waltermire%40nist.gov%7C3c194c623ead498bc81e08d5667f7113%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636527619913095041&sdata=3M5GLMaJJPfGnL6cgo6FhJiqp8GZcUfj4ZiqCR%2B8sjc%3D&reserved=0
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fusnistgov%2FOSCAL%2Fissues%2F87%23issuecomment-361085586&data=02%7C01%7Cdavid.waltermire%40nist.gov%7C3c194c623ead498bc81e08d5667f7113%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636527619913095041&sdata=FY%2BR4MWsuUgGQv2CD5sjTT28SviLCiCPcOyk46sJ2Hc%3D&reserved=0, or mute the threadhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAJaiaPyfF54qvpcALVIEyWI_ej5G8ASOks5tPMCDgaJpZM4RCvqO&data=02%7C01%7Cdavid.waltermire%40nist.gov%7C3c194c623ead498bc81e08d5667f7113%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636527619913095041&sdata=8VyZEDOqK1SKwLxHWRf236gm1dFqJ3HLOAQ8kd%2Bkemw%3D&reserved=0.
Agreed
I am working on the Compliance Mapper project at MITRE as a restful web service that aligns and can return mappings from one standard to another ( such as CIS CSC to 800-53 - for example ) that I chatted with the NIST folks about a few months ago. The need is clear, so my team started working the solution, the question is where should it be hosted and who would maintain it.
I'm sure some folks have worked around this not yet being implemented. What workarounds and lessons have been learned?
Also, Is there perhaps a better understanding of the problem now that we're a few years down the road that can help provide a clear direction for completion? Maybe it can be broken into some iterations to help bulid momentum and reduce the larger overwhelming nature of it?
I am working on the Compliance Mapper project at MITRE as a restful web service that aligns and can return mappings from one standard to another ( such as CIS CSC to 800-53 - for example ) that I chatted with the NIST folks about a few months ago. The need is clear, so my team started working the solution, the question is where should it be hosted and who would maintain it.
I'm curious if anything ever came of this? If so, where did it get hosted?
@flickerfly - No, the NIST team did not receive any contributions from MITRE around such mapping model, but @david-waltermire-nist started the mapping module in collaboration with other contributors and we planned to have it released as part of OSCAL 1.1.0 (please see the list of milestones).
@iMichaela Excellent!
Need to add a few examples to PR #1150 to help illustrate the new catalog mapping features.
@iMichaela As you mentioned that @david-waltermire-nist is working on providing support for the control mapping and it would be available as part of OSCAL 1.1.0. Could you or @david-waltermire-nist please help me understand the timelines for this release and when would support for the control mapping be available and would there be any document similar to the catalog/profile model that we can refer to understand the data format.
Thanks in advance and would greatly appreciate your help in this regard !!
@tajinders - please the PR #1150. Please provide feedback. The community's feedback on the mapping and other enhancements scheduled for OSCAL 1.1.0 will drive the release date. We hope to be in approx 2-3 months, but as we make more progress and receive the feedback, we will provide a more accurate timeline.
Issue for tracking existing mappings and what OSCAL's role in any of them should be. Some examples below: