PoC A: Completed OSCAL Catalog, Profile & Component Definition for Object Storage Service

[mlysaght2017]

Feature Request

Description of Problem:

The PoC aims to help decision making related to #139

It's still unclear how we want to assess the security of services and use OSCAL as part of that assessment. This PoC will investigate how the OSCAL Control Layer (Catalog Model and Profile Model) and Implementation Layer (Component Definition Model) can be used if the logical controls and their associated control objectives are represented in the CCC catalog.

Potential Solutions:

OSCAL Control Layer:

Catalog:

This approach will have the following information in one OSCAL CCC Catalog:

• Threat Informed Logical Controls
  • Guidance (generic implementation guidance)
  • Examples (implementation examples)
  • Control objectives (useful in assessing the outcome of a control)
  • Assessment methods accepted for each control
  • Something else (e.g. metrics)

A secondary threat-centric analysis can then be performed (automatically) reporting on which threats are properly defended through a bridging to MITRE ATT&CK TTPs via existing mappings (if they exist)

OSCAL Implementation Layer:

Component Definition:

This approach will have the following information in the OSCAL Component Definitions for each service

• Detailed guidance, for each service, of how logical controls should be satisfied
• This will allow to be more specific per service, as opposed to the generic guidance

DoD:

• [ ] A service agnostic OSCAL Control Catalog leveraging existing controls from well known frameworks (NIST 800-53, CSA CCM, CIS, etc). The Control Catalog should be demo'd in OSCAL format and expressed in either XML, JSON or YAML.
• [ ] The Control Catalog should include Control Objectives
  • If Control Objectives are general then they should be added into the Catalog
  • If Control Objectives are service specific, then the Profiles will be tailored to include them.
• [ ] A service-specific (CCC Object Storage) OSCAL Component Definition that will provide implementation guidance. The Component Definition should be demo'd in OSCAL format and expressed in either XML, JSON or YAML.

[iMichaela]

@mlysaght2017 -

1. The catalog of Threat Informed Logical Controls should be one OSCAL artifact used by all.
2. OSCAL profiles (baselines) can be generated for each service just to emphasize the controls that must be implemented, otherwise, the import can point to the catalog.
3. The Profiles (or the Catalog) should be used in OSCAL Component Definitions generated for each service that will provide the implementation guidance.
4. Control objectives (if general), should be added into the Catalog, if service-specific, then the Profiles will be tailored to include them. NOTE: Any OSCAL profile can be "resolved" into a mini Catalog when needed.
5. Assessment methods go hand in hand with the objectives (same approach)
6. Metrics can be defined using props and links and stored as external artifacts for flexibility, in case they have distinct life cycle.

QUESTION: How will the Component Definition in MD will be re-formatted in OSCAL to be useful and consumed by any GRC tool of choice that 'speaks' OSCAL? Any vision here or do we need to brainstorm, build the tool?

[github-actions[bot]]

This issue will be closed as stale in 7 days. Please update this issue if it is still needed.

[github-actions[bot]]

Closed as stale. An update may reopen this issue.