Hello everyone! Based on OSCAL's current direction with rules & tests, could the below example of control <> rule <> test <> component relationships be critiqued at a conceptual level, models aside? CC @Apostolos-Delis
Context
Tech: The organization is on AWS.
Control framework under assessment: "Custom"
Control XYZ: All applicable data is encrypted at-rest within {{system_name}}'s environment
Rule (1): Cloud infrastructure datastores are encrypted at-rest utilizing AES-256 or an equivalent, at minimum
Test (1): AWS S3 buckets are encrypted at-rest via server-side encryption utilizing AES-256
Test (2): RDS databases are encrypted at-rest utilizing AES-256
Rule (2): End user devices are encrypted at-rest utilizing AES-256 or an equivalent, at minimum
Test (1): User devices are encrypted at-rest utilizing AES-256 via Microsoft Intune
Test (2): User devices are encrypted at-rest utilizing AES-256 via JumpCloud
The OSCAL SSP XML Schema allows <set-parameter>
subordinate to both <implemented-requirement>
and <statement>``<by-component>
. I have not found any documentation which asserts that <set-parameter>
as a <implemented-requirement>
child is overridden by <set-parameter>
at any <implemented-requirement>``<statement>``<by-component>
. Furthermore, I cannot find any documentation which confines <set-parameter>
@param-id
to a statement which cites the parameter in a related <insert>
. Document order cannot be used (since <statement>
s have no explicit ordering; they may have a hierarchy but no hierarchy is mandated).
I intend to interpret <statement>``<by-component>``<set-parameter>
as trumping <implemented-requirement>
<set-parameter>
(for corresponding parameter identifiers) .
I also intend to constrain <statement>``<by-component>``<set-parameter>
to be valid only when the referenced parameter occurs in the same statement.
Having multiple <set-parameter>
s for a single parameter seems a bit odd with or without any explicitly defined primacy.
Hello party people. There was wonderful participation in the 2nd OSCAL REST API Standardization meeting. Many desired the creation of a GitHub repository to create issues, discuss work, and move forward on the REST API standardization effort. First, let's pick a home for that repo. Please review the discussion post and feel free to vote or ad your own recommendation.
https://github.com/usnistgov/OSCAL/discussions/1202
They are linked in the above issue, but here is a direct link to the meeting notes as well.
<?xml version="1.0" encoding="UTF-8"?>
<?xml-model schematypens="http://www.w3.org/2001/XMLSchema" title="OSCAL complete schema" href="https://raw.githubusercontent.com/usnistgov/OSCAL/v1.0.2/xml/schema/oscal_complete_schema.xsd" ?>
<catalog
uuid="d30847a0-d1be-4c68-9dc7-b3d43dc71c12"
xmlns="http://csrc.nist.gov/ns/oscal/1.0">
<metadata>
<title />
<last-modified >2022-04-18T20:45:25Z</last-modified>
<version>0.1</version>
<oscal-version>1.0.2</oscal-version>
</metadata>
<param
id="one">
<value>always</value>
</param>
<group>
<title />
<param id="one">
<value>sometimes</value>
</param>
<control
id="one">
<title />
<part id="one_smt" name="statement">
<p>Be careful <insert type="param" id-ref="one"/>.</p>
</part>
</control>
</group>
</catalog>
I have a question re 800-60v2 Revision 1 information types. For C.3.5.9, the tl;dr is "this is a kind of meta information type, you make a synthetic impact categorization for the confidentiality, impact, and availability triad.
Since OSCAL has a base
and selected
attributed for information-type
s in the system-information
of the system-characteristics
of a system-security-plan
. Per the docs, the base
has a cardinality of 1 (so, required), what would I put if there technically is no base
value? SP800-60v2r1 docs above.
{
"uuid": "5820d24a-487a-4748-8bd2-ea4318337816",
"title": "Information sharing information",
"description":"TBD",
"categorizations": [
{
"system": "https://doi.org/10.6028/NIST.SP.800-60v2r1",
"information-type-ids": [
"C.3.5.9"
]
}
],
"confidentiality-impact": {
"base": "????",
"selected": "fips-199-moderate"
},
"integrity-impact": {
"base": "????",
"selected": "fips-199-moderate"
},
"availability-impact": {
"base": "????",
"selected": "fips-199-moderate"
}
}
parameters
versus params
and their relationship to set-parameters
. Also discussed was how the `implemented-requirement pertains to control implementation statements (or so they are often called in pre-OSCAL SSPs and misc security documents). What others?
I posed a question during the 2022-04-29 OSCAL Model Review regarding how to declare an authoritative DNS service component.
I chose the following. Comments welcomed.
<component type="DNS-authoritative-service"
uuid="d7d0d99c-a14b-4f3e-b126-e7dc0dd90454">
<title>Authoritative DNS service</title>
<description>
<p>Authoritative DNS service for the following zones.</p>
</description>
<prop name="asset-type" value="service"/>
<prop name="DNS-zone" value="example.com.">
<remarks>
<p>An example of a DNS zone (sometimes referred to as a domain or sub-domain). The zone name resembles a host name but is
specifically a DNS resource name of the SOA RR for the zone.</p>
</remarks>
</prop>
<prop name="DNS-zone" value="example.org"/>
<status state="operational"/>
<protocol name="domain"><!-- ☚ Note the use of IANA service name (https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml) --></protocol>
<remarks>
<p>Each zone must have a DNS SOA RR at the authoritative service.</p>
</remarks>
</component>
The related Schematron validation is on an ephemeral (at this time) branch.
control-implementations
or something else?
Trestle v1.0.1 Release
We have recently released stable / production version of Trestle v1.0.1 (an Open Source OSCAL SDK) supporting latest NIST OSCAL v1.0.2 standard. Trestle is an ensemble of tools that enable the creation, validation, and governance of documentation artifacts for compliance needs. This stable version includes many new capabilities, updates to streamline the command line interface by making the options consistent across various commands, and numerous bug fixes. It can be installed as a Python package from PyPi - https://pypi.org/project/compliance-trestle/ or can be downloaded from Github - https://github.com/IBM/compliance-trestle
Hi @david-waltermire-nistthanks, I was able to load the NIST SP800-53 Catalog from https://raw.githubusercontent.com/usnistgov/oscal-content/main/nist.gov/SP800-53/rev5/json/NIST_SP-800-53_rev5_catalog.json
Now I'm trying to model the CIS Controls to OSCAL following this TRESTLE demo: https://github.com/MaurizioCasciano/compliance-trestle-demos/tree/CIS-Controls/CIS_controls
CIS Controls seems to have two extra fields I would like to map in OSCAL format: Asset Type and Security Function. To which control OSCAL property could they be mapped? Is there something equivalent with the NIST SP 800-53 controls?
@GaryGapinski re the discussion in today's meeting about semantic relations for different things
The nature of the reference depends on the types of the nodes in the graph. E.g., control to control, control to resource, resource to control, control to group, etc.
being only encoded in @rel
is the nature solely defined by @rel (despite the related nodes)?
the wonderful answer is: it depends on the types of nodes in the graph as you put it. We talked about identifiers but you can tell it talking about this thing when we talk about identifiers and their uniqueness in usnistgov/OSCAL#941.
s1.1.1-prm11
is a typo? I wasn't able to find a reference to it anywhere else but the document does have s1.1.1-prm1
- https://github.com/usnistgov/oscal-content/blob/main/examples/catalog/yaml/basic-catalog.yaml#L61