As a user, I want to leverage controls provided in OSCAL

[afeld]

Kind of surprised we didn't have an issue open for this already.

@usnistgov's OSCAL project is a new schema meant to express control information in a precise way - it can be thought of as a more detailed version of the OpenControl schemas. This is very much in line with the @opencontrol community's interest in compliance as code, and is appealing as an officially-supported standard from a government agency.

Compliance Masonry is a tool to turn structured compliance information into human-readable documentation. It is my opinion that the @opencontrol community shouldn't care what those input formats are: the OpenControl schemas, OSCAL, or whatever else. Thankfully, there is a clear mapping between these two:

• OSCAL Catalog ~= OpenControl Standard
• OSCAL Profile ~= OpenControl Certification

In terms of using OSCAL with Compliance Masonry, there are a couple of ways to go about it:

1. Recommend that people use oscalkit as a standalone tool to convert OSCAL to OpenControl.
   • Pro: No change to Masonry needed - keeps the tools "small and sharp"
   • Con: Yet another thing to install and run.
2. Incorporate oscalkit into Masonry directly, so it can read from either.
   • Pro: Allows for more seamless workflows.
   • Con: Complicates Masonry.

Curious to hear thoughts, particularly from people who have been involved in both (like @iMichaela @JJediny @anweiss @david-waltermire-nist @redhatrises).

[redhatrises]

@afeld personally like #2. While more complex, it is more robust for masonry and expands its capabilities.

[anweiss]

Also agree with #2. The CLI functions provided by oscalkit are meant to be simplistic and mostly provide examples of how one can use the core OSCAL SDK. It is anticipated that other Go projects, like Compliance Masonry, would simply bring in the SDK as a dependency and subsequently provide more functionality for day-to-day use; especially since much of the oscalkit code is automatically generated from the upstream OSCAL metaschemas.

[openprivacy]

I'm a fan of #1 for several reasons:

1. UNIX pipe philosophy: OSCAL translation could be a pre-processor step (I like "small and sharp")
2. Keeps feature mismatch issues isolated in oscalkit. If OSCAL contains features OpenControl doesn't (or vice versa) there's a clear location to record such issues
3. We don't know if both frameworks will continue development or if one will subsume the other or.... Keeping them separate allows for better "competition" and flexibility in feature growth

[afeld]

For folks that are interested in both formats, adding some documentation about their relationship here: opencontrol/schemas#84

[trevor-vaughan]

I'm OK with either option as long as OpenControl tries to keep parity with OSCAL over time where possible.

[iMichaela]

It depends on what the team is targeting:

1. [Recommend that people use oscalkit as a standalone tool to convert OSCAL to OpenControl] - makes the developers happy but users not that much
   2.[Incorporate oscalkit into Masonry directly, so it can read from either] - makes the users happier while developers need to maintain the Masonry. But as @anweiss stated, oscalkit code is automatically generated from the upstream OSCAL metaschemas, and OSCAL SDK can be treated as a dependency.

@openprivacy: OSCAL is not trying to "compete" with OpenControl. I believe in collaboration for a better outcome.

[trevor-vaughan]

Coming from a user perspective, basically I don't want to write two different things.

OSCAL, coming from NIST will, like SCAP, most likely be required by Federal systems at some point (I think). That leaves OpenControl as a less desirable alternative unless the two systems are seamlessly intertwined.

Does that make sense?

[JJediny]

I put together a rough crosswalk between opencontrol and NIST OSCAL. This is not official and may contain mistakes in some mappings/concepts:

Exported as Markdown:

Compliance-as-Code Frameworks Crosswalk

OpenControl Standard

name:

{{ key }}:

• family:
• name:
• description:

OpenControl Certification

name:

standards:

• {{ key }}:

opencontrol.yaml

name

schema_version

metadata

• description
• maintainers

dependencies

• systems
  • url
  • revision
• certifications
  • url
  • revision
• standards
  • url
  • revision

components

certifications

standards

OpenControl Component

name:

satisfies:

• standard_key:
• control_key:
• narrative:

  •   - key: 
    

  •     text: |
    

• implementation_status:
  • partial
  • complete
  • planned
  • none
• covered_by:

  •   - verification_key: 
    

  •     system_key: 
    

  •     component_key: 
    

references:

• name:
• path:
• type:

verifications:

• key:
• name:
• path:
• type:
• steps:
• filename:
• test_passed:
  • true
  • false

• last_run: 
  

documentation_complete:

• true
• false

schema_version:

OSCAL System Security Plan

system-security-plan:

• id:
• metadata:

  • title:
    

  • authors: []
    

  • publication-date:
    

  • version:
    

    •   iso-date:
      

    •   STRVALUE:
      

  • document-ids: []
    

  • properties: []
    

  • hashed-links: []
    

  • resources: []
    

  • roles: []
    

  • parties: []
    

  • notes:
    

    •   prose: []
      

  • extra-meta:
    

    •   metadata-groups: []
      

    •   metadata-fields: []
      

    •   notes:
      

      •     prose: []
        

• imports: []
• system-characteristics:

  • system-name:
    

  • security-sensitivity-level:
    

  • system-id:
    

    •   type:
      

    •   STRVALUE:
      

  • system-name-short:
    

  • description:
    

    •   prose: []
      

  • system-information:
    

    •   ssp-information-type: []
      

    •   ssp-designations: []
      

  • security-impact-level:
    

    •   security-objective-confidentiality:
      

    •   security-objective-integrity:
      

    •   security-objective-availability:
      

  • security-eauth:
    

    •   security-auth-ial:
      

    •   security-auth-aal:
      

    •   security-auth-fal:
      

    •   security-eauth-level:
      

  • status:
    

  • status-other-description:
    

  • deployment-model:
    

  • deployment-model-other-description:
    

  • service-models: []
    

  • service-model-descriptions: []
    

  • leveraged-authorizations:
    

    •   ssp-leveraged-authorization: []
      

  • authorization-boundary:
    

    •   ssp-boundary-diagram: []
      

  • network-architecture:
    

    •   ssp-network-boundary: []
      

  • data-flow:
    

    •   ssp-data-flow-diagram: []
      

  • users:
    

    •   roles: []
      

    •   statistics:
      

      •     internal-user-total-current:
        

      •     internal-user-total-future:
        

      •     external-user-total-current:
        

      •     external-user-total-future:
        

• system-implementation:

  • interconnected:
    

  • ports-protocols-services:
    

    •   ssp-service: []
      

  • ssp-interconnection: []
    

  • components: []
    

  • system-inventory:
    

    •   inventory-items: []
      

• control-implementation:

  • controls: []
    

• references:

  • id:
    

  • links: []
    

  • refs: []
    

• attachment:

  • id:
    

  • title:
    

  • description:
    

    •   prose: []
      

  • format:
    

  • date:
    

  • version:
    

    •   iso-date:
      

    •   STRVALUE:
      

  • attachment-type:
    

  • base64:
    

    •   filename:
      

    •   STRVALUE:
      

OSCAL Profile

profile:

• id:
• title:
• metadata:

  • title:
    

  • authors: []
    

  • publication-date:
    

  • version:
    

    •   iso-date:
      

    •   STRVALUE:
      

  • document-ids: []
    

  • properties: []
    

  • resources: []
    

  • roles: []
    

  • parties: []
    

  • notes:
    

    •   prose: []
      

  • extra-meta:
    

    •   metadata-groups: []
      

    •   metadata-fields: []
      

    •   notes:
      

      •     prose: []
        

• imports:
  • href:
  • include:
    • id-selectors:
      • control-id
      • subcontrol-id
• merge:

  • combine:
    

    •   method:
      

    •   STRVALUE:
      

  • as-is: false
    

    • true

  • custom:
    

    •   groups: []
      

    •   id-selectors: []
      

    •   pattern-selectors: []
      

• modify:

  • param-settings: []
    

  • alterations: []
    

OSCAL Catalog

catalog:

• id:
• model-version:
• metadata:

  • title:
    

  • authors: []
    

  • publication-date:
    

  • version:
    

    •   iso-date:
      

    •   STRVALUE:
      

  • document-ids: []
    

  • properties: []
    

  • resources: []
    

  • roles: []
    

  • parties: []
    

  • notes:
    

    •   prose: []
      

  • extra-meta:
    

    •   metadata-groups: []
      

    •   metadata-fields: []
      

    •   notes:
      

      •     prose: []
        

• sections: []
• groups: []
• controls:

  • id:
    

  • class:
    

  • title:
    

  • parameters:
    

  • properties:
    

  • links:
    

  • parts:
    

  • subcontrols:
    

  • ref-list:
    

  • prose
• back:

  • id:
    

  • ref-list:
    

    •   id:
      

    •   title:
      

    •   prose: []
      

    •   links: []
      

    •   references: []
      

    •   reference-lists: []
      

  • resources: []
    

Narrative

General System Description

System Function or Purpose

Information System Components and Boundaries

Types of Users

Network Architecture

Hardware Inventory

Software Inventory

Network Inventory

Data Flow

Ports, Protocols, and Services

System Interconnections

Leveraged Authorization(s)

• Service Model
• Deployment Model

Supporting Documents

Configuration Management Plan

Incident Response Plan

Privacy Impact Assessment

Contingency Plan

Business Impact Analysis

Digital Identity Acceptance Statement

Continuous Monitoring Plan

Authority to Operate (ATO)

FIPS-199 Categorization Approval

Acceptance of Risk (AOR)

Continuous Monitoring Program

• Change Request
• Vulnerability/Configuration Scans
• Penetration Testing Reports
• Logging/Monitoring Auditing
• Contingency Response Testing
• Incident Response Testing
• Account/User Auditing
• System Inventory
• FISMA Assessment/Audit

Plan of Action & Milestones (POA&M)

[david-waltermire]

@JJediny Thanks for doing this. What tool did you use to make this? Looks interesting. I'll give this a deeper look a bit later.

I also wanted to point out that we have made OSCAL YAML productions using prettyjson based on the OSCAL JSON formatted content. You can find them on the OSCAL repo under the respective sub directories. They follow the same OSCAL information models as the JSON and XML.

[JJediny]

@david-waltermire-nist thats great news about the yaml version. To create this, I used the json schema version to generate a sample json input, then just converted to yaml for modeling in a mind map (i used https://www.freeplane.org to do the initial modeling and then imported into https://www.xmind.net/download/zen/ to produce a better visual output for it). Source files attached here:

OpenControl-to-OSCAL-Schema.zip

[david-waltermire]

FYI. We released OSCAL 1.0.0 Milestone 1, which ships the content in YAML format.