Replies: 6 comments 4 replies
-
@mruge-shr - Thank you for documenting the issue. Can you please elaborate if the intent is to have policy documents in stand-alone OSCAL catalog-like formats, or more functionality is expected (aka - a mapping to security controls from different regulatory frameworks, that would have to be implemented by the system in order to have the policy implemented). Understanding how the policy requirements in OSCAL will be used in practice would also be valuable for this research, since there might be more than one way of achieving the policy digitalization in OSCAL, but the most useful approach might be identified through the envisioned integration into the security automation process. Last but not the least: Community. members - please 'vote' (+1 above, under @mruge-shr issue statement) if this topic is of interest to you. And if you want to participate in this research, please state it in a comment.. Thank you. |
Beta Was this translation helpful? Give feedback.
-
My initial thought was to make a CDEF (component-definition) for each major deliverable document. components/capabilities within the CDEF represent sections and paragraphs respectively. When those sections reference, describe, or reference a control or requirement, they use the implemented-requirements to map to them. A longer term goal that I hadn't considered could be a more catalog like approach, where you could import GSA document recommendations, or best practices, with some modifications. Since, many organizations copy the policies from other reputable places. I would like to implement some level of assessment of the sections too. Such as NLP to verify entities referenced, or extract objects and compare against more technical means, such as checking Microsoft365, SCMs, or whatever technical means are used to configure and maintain the settings |
Beta Was this translation helpful? Give feedback.
-
Classically, a modeling exercise such as this begins by assembling some representative samples of data sets ("documents") demonstrating the opportunity. Until that happens all conversation is provisional. And one of the chicken/egg problems one faces is whether to look first at the harder or easier cases. I actually think that rather than seeking to solve a problem also addressed by HTML, OASIS DITA, or NISO STS (just to name three), in this case OSCAL might look for the bigger bang from a lighter lift (doing a little less but getting a lot more done) and using linking to deal with the harder cases. But it's all about those samples or mockups. FWIW the CDEF model was designed to be as "abstractable" as you wanted: we did not wish to limit that. |
Beta Was this translation helpful? Give feedback.
-
It would be good to get a few examples of what a non-technical, "document" in oscal looks like. I am working on a minimum Demo one that can have a single instance of each of the 'props' I think we need to render a simple PDF/HTML, mostly to test and develop on my sphinx extension. I of course will put that here when I do. And i do think its entirely possible that we just say, that doesn't look bad, OSCAL CDEF as it is, is just fine |
Beta Was this translation helpful? Give feedback.
-
Example I have been working with. As good as i could make for a Friday Afternoon ---
component-definition:
uuid: e302b43f-6ccf-4720-ad44-f48cb2596465
metadata:
title: Demo Document
last-modified: 2023-02-23T15:44:01Z
version: "20230109"
oscal-version: 1.0.0
capabilities:
- uuid: bf92dc8a-d8a9-4b85-92d6-8ce1c5e39780
name: Overview
description: ""
incorporates-components:
- component-uuid: 39c57559-3da4-4ed0-997d-c2da639fa498
description: ""
- uuid: 4e31d489-f69a-41e3-9bf2-d309e02279a9
name: Chapter
description: ""
incorporates-components:
- component-uuid: dbeaa5c4-7578-4c99-b2d1-a50322b767eb
description: ""
- component-uuid: dadbf127-ec5b-4d1f-87dd-b42afe901558
description: ""
components:
- uuid: 39c57559-3da4-4ed0-997d-c2da639fa498
title: Scope
description: ""
- uuid: dbeaa5c4-7578-4c99-b2d1-a50322b767eb
title: Default Props
description: ""
props:
## These defaults will usually be fine
# used for ordering, default to 0 so it will do in python order
- name: weight
value: 0
# 0=hide, 1=optional, 2=mandatory
- name: present
value: 0
# to render in graph, markdown, latex, etc. Currently using Type
# Will likely just map to a Sphinx Directive
- name: renderer
value: md
## These are only necessary for Explicit Ordering
# UUID of the parent
- name: parent
value: None
# List of UUIDs that must come before this one
- name: after
value: []
# List of UUIDs that must come after this one
- name: before
value: []
# Autodect input based on path?
# Using Backmatter, instead of direc path?
- uuid: dadbf127-ec5b-4d1f-87dd-b42afe901558
title: System Diagram
description: ""
links:
- href: '#8f91a246-01a1-4549-8a18-723408d4f9b5'
prop:
- name: renderer
value: plantuml
- uuid: cf021f89-f5f1-483a-a4a3-9da2f3b66a22
title: System Branding
description: ""
links:
- href: '#b0fa70e8-10a9-4e86-ae0c-edf89e44003e'
prop:
- name: renderer
value: plantuml
back-matter:
resources:
- uuid: 8f91a246-01a1-4549-8a18-723408d4f9b5
rlinks:
- href: assets/diagram.puml
citation: Alternate Text
- uuid: b0fa70e8-10a9-4e86-ae0c-edf89e44003e
rlinks:
- href: assets/logo.png
citation: Alternate Text |
Beta Was this translation helpful? Give feedback.
-
I am happy to share the proprietary solution I came up with before I started applying OSCAL in the context of PKI policy. I am in the process of rewriting the tool so that it has a much more OSCAL aligned internal representation of policy, but I'm not sure about the structural representation, as you will see. My requirements:
In OSCAL, the structure of the document, expressed as the relationship between groups and controls, is not separated. This may not be a problem in practice as long as I can use a UUID or some other identifier to indicate that the requirement over there in version one is the same requirement as the one over here in this version. Some features to note in my proprietary format:
This is a JSON representation of a version of a policy in my proprietary format: {
"name": "1.1",
"authority": "http://localhost:9000/policypublisher/api/v1/authorities/09692929-7ac7-4afe-b404-72233476c078/?format=json",
"state": "DRAFT",
"published_date": null,
"effective_date": null,
"uuid": "e0973da2-d115-41dd-aa5f-e08ba23338fd",
"url": "http://localhost:9000/policypublisher/api/v1/versions/e0973da2-d115-41dd-aa5f-e08ba23338fd/?format=json",
"sections_in_version": [
"http://localhost:9000/policypublisher/api/v1/sections/411261c3-993e-42f0-adb6-7dfb990282eb/?format=json",
"http://localhost:9000/policypublisher/api/v1/sections/dc7ebe47-756c-4c36-9998-441cab617f4d/?format=json",
"http://localhost:9000/policypublisher/api/v1/sections/7380ecdb-3591-412f-819b-ca78973f5934/?format=json"
],
"statements_in_version": [
"http://localhost:9000/policypublisher/api/v1/statements/1b362fb1-f6d9-42d6-8f4c-b4c54c76799a/?format=json",
"http://localhost:9000/policypublisher/api/v1/statements/b8200f83-003a-4dc3-a155-2559544f1526/?format=json",
"http://localhost:9000/policypublisher/api/v1/statements/45d1f111-ba77-40d6-8d64-f9a802f1fc27/?format=json",
"http://localhost:9000/policypublisher/api/v1/statements/5c610654-610d-452e-abc0-80761174f34e/?format=json"
],
"structure": {
"section-hierarchy": [
{
"over": "411261c3-993e-42f0-adb6-7dfb990282eb",
"under": "dc7ebe47-756c-4c36-9998-441cab617f4d"
}
],
"section-order": [
{
"before": "411261c3-993e-42f0-adb6-7dfb990282eb",
"after": "7380ecdb-3591-412f-819b-ca78973f5934"
}
],
"statement-location": [
{
"section": "411261c3-993e-42f0-adb6-7dfb990282eb",
"statement": "1b362fb1-f6d9-42d6-8f4c-b4c54c76799a"
},
{
"section": "411261c3-993e-42f0-adb6-7dfb990282eb",
"statement": "b8200f83-003a-4dc3-a155-2559544f1526"
},
{
"section": "411261c3-993e-42f0-adb6-7dfb990282eb",
"statement": "45d1f111-ba77-40d6-8d64-f9a802f1fc27"
},
{
"section": "411261c3-993e-42f0-adb6-7dfb990282eb",
"statement": "5c610654-610d-452e-abc0-80761174f34e"
}
],
"statement-order": [
{
"before": "1b362fb1-f6d9-42d6-8f4c-b4c54c76799a",
"after": "45d1f111-ba77-40d6-8d64-f9a802f1fc27"
},
{
"before": "5c610654-610d-452e-abc0-80761174f34e",
"after": "b8200f83-003a-4dc3-a155-2559544f1526"
},
{
"before": "45d1f111-ba77-40d6-8d64-f9a802f1fc27",
"after": "5c610654-610d-452e-abc0-80761174f34e"
}
]
}
} I have attached a pdf representation built from this outline. I can also generate an OSCAL representation from the same data. |
Beta Was this translation helpful? Give feedback.
-
Some teams are looking to use the OSCAL format to rewrite, maintain, and share policy and procedure documents normally kept in PDF and DocX forms.
Documents such as Information Security Policy, Account Management, Privileged User Guides. These documents are often referenced in various compliance frameworks, and to this day, many auditors prefer to examine documentation over system controls.
Some initial Thoughts:
Beta Was this translation helpful? Give feedback.
All reactions