# Component Provided Controls vs Implemented Controls

## Problem Statement

In the SSP/Statements/By Component structure, there are some inconsistencies across docs.

If one looks at the schema page:
https://pages.nist.gov/OSCAL/reference/latest/system-security-plan/json-reference/#/system-security-plan/control-implementation/implemented-requirements/statements/by-components

…it references that here you *“Define how the referenced component implements a set of controls.”*

If the system has a Firewall Appliance component, then the SSP/Statements/By Component->”this system” will have the SC-7 implemented by the respective component Firewall and can document so, and then the SSP/Statements/By Component->”firewall appliance” component of the same SSP will describe the controls the appliance implements, like AC-3 needed to secure the appliance.

In this scenario, how can the information regarding the SC-7 and AC-3 be represented in a Component Definition, so a GRC tool understands the difference and how to process the controls when populating the SSP.

It is also important to be able to indicate or link in a way the SC-7 control's assessment to the assessment of all controls like AC-3 implemented by the component “Firewall appliance” because if the appliance is not secured properly, the fact that the system used a Firewal appliance does not automatically warants the satisfaction of SC-7.

The SC-7 control can be perceived as an _exported_ as in _provided-to_ "this system" component but different than an _inherited_ control (see leverage authorization concept where a control implemented by an infrastructure, like Physical Security control, is inherited by all SaaS services).


# Related (Known) OSCAL Issues - WIP

## Provide Link Relations for by-component links in SSP #1022

https://github.com/usnistgov/OSCAL/issues/1022#event-8185208099

The issue would address the representation in the SSP of the above information above :

system-security-plan
  control-implementation
  - implemented-requirements
    - control[@id="SC-7"]
      - by-component[@component-uuid="#this-system-uuid"]
        - link[@rel="provided-by", @href="#firewall-appliance-uuid"]
        - description: narrative describing how this system has the Firewall appliance that protects the system's boundaries
    - control[@id="AC-3"]            
      - by-component[@component-uuid="firewall-appliance-uuid"]
        - description: narrative describing hoe the access to the firewall appliance is implemented
        

# Component Definition Outline

The challenge remains when trying to represent in the Componentent Definition of the Firewall appliance both the SC-7 for the system's boundary protection and the controls satisfied/implemented by the appliance to secure its operations and the traffic rules.

The CDef Outline follows:

component-definition [1]: {
    uuid [1]: uuid,
    metadata [1]: { … },
    import-component-definitions [0 or 1]: [ … ],
    components [0 or 1]: [
    An array of component objects [1 to ∞] {
        uuid [1]: uuid,
        type [1]: string,
        title [1]: markup-line,
        description [1]: markup-multiline,
        purpose [0 or 1]: markup-line,
        props [0 or 1]: [ … ],
        links [0 or 1]: [ … ],
        responsible-roles [0 or 1]: [ … ],
        protocols [0 or 1]: [ … ],
        control-implementations [0 or 1]: [
            An array of control-implementation objects [1 to ∞] {
            uuid [1]: uuid,
            source [1]: uri-reference,
            description [1]: markup-multiline,
            props [0 or 1]: [ … ],
            links [0 or 1]: [ … ],
            set-parameters [0 or 1]: [ … ],
            implemented-requirements [1]: [
            An array of implemented-requirement objects [1 to ∞] {
                uuid [1]: uuid,
                control-id [1]: token,
                description [1]: markup-multiline,
                props [0 or 1]: [ … ],
                links [0 or 1]: [ … ],
                set-parameters [0 or 1]: [ … ],
                responsible-roles [0 or 1]: [ … ],
                statements [0 or 1]: [ … ],
                remarks [0 or 1]: markup-multiline,
              }
            ],
          }
        ],
        remarks [0 or 1]: markup-multiline,
    }
],
capabilities [0 or 1]: [ … ],
back-matter [0 or 1]: { … },