OSCAL SSP schema review against an actual SSP Template

[JJediny]

User Story:

As an OSCAL stakeholder, I want to make sure there is a balance between the flexibility/expandability of the System Security Plan (SSP) schema; between its practical use in templating an SSP.

Goals:

We conducted a raw mapping of the current draft of the oscal-ssp schema (as of today), using a converted markdown format of the FEDRAMP Tailored SSP template. Work is DRAFT here: http://fedramp-ssp.netlify.com/fedramp-tailored

The review showed the truly great value/potential in this; but also the need to improve and reduce the footprint of the SSP schema, to make it intuitive as a simple presentation layer for an SSP.

Acceptance Criteria

• Improve the reusability of common data elements, based on a mapping to the FEDRAMP tailored appendix B SSP template the following elements we're seldom used but at the same time common across multiple levels of the hierarchy. It seems appropriate to establish a common schema and reuse it throughout.

Note: at the end of the issue the full review and note the use of common-but-not-used to show why these elements should be made into a single object for reuse.

common:
  id:
  name:
  description:
  properties:
  annotations:
  links:
  remarks:
  parties-ids: ? not sure its use

• Address document versioning in a one-to-many method. Currently only system-security-plan.metadata.version exists. Suggest this is turned into a nested property in versions:

system-security-plan: 
  id: UUID
  metadata: 
    title:
    # need the concept of a `versions:` to address multiple iterations/versions for publications required disclosure
    #versions:
    #  version:
    #    published: 
    #    last-modified: 
    #    version: 
    #    oscal-version: 1.0
    #    uri: over links for uniqueid href and integrity
    published: ^
    last-modified: ^
    version: ^
    oscal-version: ^
    document-ids: # seems redundant with overarching `id`
    properties: 
    links: 
    roles:  # seems redundant with responsible-parties
    parties: # seems redundant with responsible-parties

• Address the use of and the ideally the removal and consolidation of services into components and interconnections into leveraged-authorizations. There are currently the following overlapping concepts:

• components

• services

• ssp-interconnections

• services.ssp-protocols

• services.protocols

• components should just href control-implementations & implemented-component, those last two elements should not be at the ssp layer.

The current schema should do away with any implementation/inheritance of controls and delegate all of that into the control implementation layer of the schema and only ref the component by id. However, at that same time components SHOULD at the SSP layer have declared ports/protocols/interconnections as child elements for rendering into the SSP (instead of using services/ssp-interconnections). Suggest removingcontrol-implementation & implemented-component from ssp layer of the schema altogether and move all ports/protocol information into components.

• interconnections - doesn't have the needed attributes to fill in the required fields for the FEDRAMPed tailored SSP table.

• Currently, there is no ability to list the full set of "Inventory" lists with the schema.

  system-inventory: 
      # missing `software-items` for 11.2 Software Inventory
      # missing `network-items` for 11.3 Network Inventory
      # missing `hardware-items` for 11.1 Hardware Inventory
      inventory-items:
        inventory-item:
          id: common-but-not-used
          assest-id: common-but-not-used
          description: common-but-not-used
          properties: common-but-not-used
          annotations: common-but-not-used
          links: common-but-not-used
          responsible-parties: common-but-not-used
          remarks: common-but-not-used

Happy to break these issues out into their own issue post-discussion.

All Comments contained in YAML here from the exercise:

title: FEDRAMP Tailored SSP Template
permalink: /fedramp-tailored
layout: home
system-security-plan: 
  id: UUID
  metadata: 
    title:
    # need a versions concept to address multiple iterations/versions for publications required disclosure
    #versions:
    #  version:
    #    published: 
    #    last-modified: 
    #    version: 
    #    oscal-version: 1.0
    #    uri: over links for uniqueid href and integrity
    published: ^
    last-modified: ^
    version: ^
    oscal-version: ^
    document-ids: # seems redundant with overarching `id`
    properties: 
    links: 
    roles:  # seems redundant with responsible-parties
    parties: # seems redundant with responsible-parties
    responsible-parties: 
      information-system-owner: 
        party-ids: John Doe
        properties: System Owner
        annotations: 
        links: 
        remarks:
      independent-assessor: 
        party-ids: Company X
        properties: Third Party Assessor
        annotations: 
        links: 
        remarks:
      authorizing-offical: 
        party-ids: Jane Doe
        properties: AO
        annotations: 
        links: 
        remarks:
      authorizing-offical-management-poc: 
        party-ids: Jane Doe
        properties: Management POC
        annotations: 
        links: 
        remarks:           
      authorizing-offical-technical-poc: 
        party-ids: Jane Doe
        properties: Technical POC
        annotations: 
        links: 
        remarks:
      information-system-security-officer: 
        party-ids: Jane Doe
        properties: ISSO
        annotations: 
        links: 
        remarks: 
      information-system-security-manager: 
        party-ids: Jane Doe
        properties: ISSM
        annotations: 
        links: 
        remarks:                 
    remarks: 
  import-profile: 
    href: 
    # seems like a `checksum:` would be helpful to automate wget/curl/alike
    remarks: 
  system-characteristics: 
    system-ids: #would be nice if FEDRAMP could coin these upfront to start using prior to even review/authorization.
    system-name: SHORTNAME-FULLSYSTEMNAME
    system-name-short: SHORTNAME
    description: "System purpose or function"
    properties: common-but-not-used
    annotations: common-but-not-used
    links: common-but-not-used
    date-authorized: YYYY-MM-DD
    security-sensitivity-level: Low
    system-information: 
      properties: common-but-not-used
      annotations: common-but-not-used
      links: common-but-not-used
      information-types: common-but-not-used
      #system-information-impact-method: fips-199
    security-impact-level: 
      security-objective-confidentiality: fips-199-low # Low
      security-objective-integrity: fips-199-low # Low
      security-objective-availability: fips-199-low # Low
      # doesn't break out the 3x3 matrix required for evaluation of FIPS-199 -> L,L,L | L, M, L | M, L, L is a moderate system ^ only allows average of 3 per criteria.
    status: 
      state: operational
      remarks: "System status explained here."
    leveraged-authorizations:
      AWS:
        id: FEDRAMP-ID
        name: "Leveraged Service Provider Owner"
        properties: common-but-not-used
        annotations: common-but-not-used
        links: common-but-not-used
        party-id: 
        #^ seems redundant with overall `id`
        date-authorized: YYYY-MM-DD
        remarks:
      GCP:
        id: FEDRAMP-ID
        name: "Leveraged Service Provider Owner"
        properties: 
        annotations:
        links:
        party-id:
        date-authorized: YYYY-MM-DD
        remarks:    
    authorization-boundary: 
      description: "Provide an explicit definition
of the system’s Authorization Boundary"
      properties: common-but-not-used
      annotations: common-but-not-used
      links: common-but-not-used
      diagrams:           
        AuthorizationBoundary: 
          description: 
          properties: 
          links: "https://cloud.gov/img/example-diagram-1.svg"
          caption: 
          remarks:           
      remarks: common-but-not-used
    network-architecture: 
      description: Optional overview of Network Architecture
      properties: common-but-not-used
      annotations: common-but-not-used
      links: common-but-not-used
      diagrams: 
        NetworkArchitecture: 
          description: 
          properties: 
          links: "https://cloud.gov/img/example-diagram-2.svg"
          caption: 
          remarks: 
      remarks: common-but-not-used
    data-flow: 
      description: Optional overview of Data Flow
      properties: common-but-not-used
      annotations: common-but-not-used
      links: common-but-not-used
      diagrams: 
        DataFlow: 
          description: 
          properties: 
          links: "https://cloud.gov/img/example-diagram-2.svg"
          caption: 
          remarks: 
      remarks: common-but-not-used
    responsible-parties:
    #reponsible-parties should have all been declared, seems over engineered for a fringe use-case - seems more approrpriate to treat the relationship under a common #ref schema model like others included within a `#ref/schema/common` model (e.g. everything labeled `common-but-not-used`).
      responsible-party: 
        party-ids: common-but-not-used
        properties: common-but-not-used
        annotations: common-but-not-used
        links: common-but-not-used
        remarks: common-but-not-used
    remarks: 
  system-implementation: 
    properties: common-but-not-used
    annotations: common-but-not-used
    links: common-but-not-used
    users: 
      sysadmin: 
        title: System Adminstrator
        short-name: 
        description: Add/remove users and hardware, install and configure software, OS updates, patches and hotfixes, perform backups.
        properties: Internal
        annotations: Privileged (P)
        links: 
        role-ids: 
        authorized-privileges: Full administrative access (root)
        remarks: Moderate
      client-adminstrator: 
        title: Client Administrator
        short-name: 
        description: Add/remote client users. Create, modify, and delete client applications.
        properties: External
        annotations: Non-Privileged (NP)
        links: 
        role-ids: 
        authorized-privileges: Portal administration
        remarks: N/A
      program-director: 
        title: Program Director
        short-name: 
        description: Reviews, approves and enforces policy.
        properties: Internal
        annotations: No Logical Access (NLA)
        links: 
        role-ids: 
        authorized-privileges: Project administration
        remarks: Limited            
    # the element below doesnt exist in schema - which might be an error but most other fields have a catch-all `remarks` which is a very helpful field.
    remarks: |
        "There are currently \<*number*\> internal personnel and \<*number*\> external personnel. Within one year, it is anticipated that there will be \<*number*\> internal personnel and \<*number*\> external personnel."
    components: 
      web-server: 
        name: 
        component-type: 
        description: 
        properties: 
        annotations: 
        links: 
        status: 
          state: operational
          remarks: 
        responsible-roles: 
        remarks: 
    # services seems overly redundant with components, and the other fields for control-implementation don't seem appropriate to manage at the SSP level/layer. Component at this level should allow for declaring ports/protocols/interconnections and `href` to its control-implementation. Services and Interconnections seem to overly complicate the schema. 
    # There is no obv rational to prepend `ssp-*` to anything this seems to overlycomplicate its use/mapping).    
    services:
      service:
        id: common-but-not-used
        name: ServiceName
        description: common-but-not-used
        properties: common-but-not-used
        annotations: common-but-not-used
        links: common-but-not-used
        ssp-protocol: #? how is this different from the protocol array below
        purpose: Purpose
        remarks: common-but-not-used
        protocol:
          title: common-but-not-used
          description: common-but-not-used
          type: common-but-not-used
          properties: common-but-not-used
          port-ranges:
            start: 80
            end: 443
            transport: TLS 1.2
      ssp-interconnection: # suggest to rename to `interconnection`
        id: common-but-not-used
        remote-system-name:
        annotations: common-but-not-used
        links: common-but-not-used
        responsible-parties: # seems more appropriate to associated this to `leveraged-authorizations` make sure the elements missing from the table are optional there as a nested properity.
        remarks: common-but-not-used
    system-inventory: 
      # missing `software-items` for 11.2 Software Inventory
      # missing `network-items` for 11.3 Network Inventory
      # missing `hardware-items` for 11.1 Hardware Inventory
      inventory-items:
        inventory-item:
          id: common-but-not-used
          assest-id: common-but-not-used
          description: common-but-not-used
          properties: common-but-not-used
          annotations: common-but-not-used
          links: common-but-not-used
          responsible-parties: common-but-not-used
          remarks: common-but-not-used
      # If the system is inventorying and using components in the SSP, it should be assumed they're implemented or planned for this next section of the schema should be up for consideration of removing.    
      implemented-components:
        implemented-component:
          use:
          properties: common-but-not-used
          annotations: common-but-not-used
          links: common-but-not-used
          responsible-parties: common-but-not-used
          remarks: common-but-not-used
      remarks: 
    remarks: 
  # If the system is inventorying and using components in the SSP, it should be assumed they're implemented or planned for this next section of the schema should be up for consideration of removing/moving into the pure `components` field.    
  control-implementation: 
    description: 
    implemented-requirements: 
      implemented-requirement:
        id: common-but-not-used
        control-id:
        description: common-but-not-used
        properties: common-but-not-used
        annotations: common-but-not-used
        links: common-but-not-used
        by-components:
        responsible-roles: common-but-not-used
        set-params:
        statements:
          statement:
            description:
            properties:
            links:
            responsible-roles:
            by-components:
            remarks:
        remarks: common-but-not-used
  back-matter: 
    citations: 
    resources: 

[david-waltermire]

@JJediny First of all, thank you for this review. This is extremely helpful.

I'd like to address your summary feedback.

1. With regards to common elements, the duplication is an artifact of the Metaschema-based schema generation system we use for OSCAL. We can look into a way to streamline this through an update to the Metaschema syntax and the schema generation process.
2. For the one-to-many versions, this sounds reasonable. Maybe a version-history would suffice, with the same data fields you suggest?
3. I like the idea of consolidating services into components and interconnections into leveraged-authorizations. We could even have a type for leveraged-authorizations that would allow for specificity of the type of authorization (e.g., interconnection, common-control-provider, etc.).
4. You suggest removing control-implementation & implemented-component from SSP layer of the schema altogether and move all ports/protocol information into components. I need to better understand what you are trying to accomplish. We treat components as potential implementations, while inventory-items are "concrete" implementations, This allows a component, like a server operating system to be specialized as an inventory-item. This is also why ports/protocols appear on inventory-item, since some of these might not be known unless you talk about a specific server instance.
5. We will need to review the FEDRAMPed tailored SSP table regarding interconnections. We can add fields or FedRAMP can use properties/annotations to extend. Need to look deeper to figure out what the best course of action is.
6. Regarding software-items for 11.2 Software Inventory, network-items for 11.3 Network Inventory, and hardware-items for 11.1 Hardware Inventory, I'd like to discuss this with you in a higher-bandwidth setting. Maybe a phone call or F2F. This will help us find a path forward.

I have also included some detailed comments below marked [daw:].

title: FEDRAMP Tailored SSP Template
permalink: /fedramp-tailored
layout: home
system-security-plan: 
  id: UUID
  metadata: 
    title:
    # need a versions concept to address multiple iterations/versions for publications required disclosure
    #versions:
    #  version:
    #    published: 
    #    last-modified: 
    #    version: 
    #    oscal-version: 1.0
    #    uri: over links for uniqueid href and integrity
    published: ^
    last-modified: ^
    version: ^
    oscal-version: ^
    document-ids: # seems redundant with overarching `id`
    properties: 
    links: 
    roles:  # seems redundant with responsible-parties [daw: This is where all roles are defined within the document. They are then referenced in responsible-parties/responsible-roles.]
    parties: # seems redundant with responsible-parties [daw: This is where all parties are defined within the document. They are then referenced in responsible-parties/responsible-roles.]
    responsible-parties: 
      information-system-owner: 
        party-ids: John Doe
        properties: System Owner
        annotations: 
        links: 
        remarks:
      independent-assessor: 
        party-ids: Company X
        properties: Third Party Assessor
        annotations: 
        links: 
        remarks:
      authorizing-offical: 
        party-ids: Jane Doe
        properties: AO
        annotations: 
        links: 
        remarks:
      authorizing-offical-management-poc: 
        party-ids: Jane Doe
        properties: Management POC
        annotations: 
        links: 
        remarks:           
      authorizing-offical-technical-poc: 
        party-ids: Jane Doe
        properties: Technical POC
        annotations: 
        links: 
        remarks:
      information-system-security-officer: 
        party-ids: Jane Doe
        properties: ISSO
        annotations: 
        links: 
        remarks: 
      information-system-security-manager: 
        party-ids: Jane Doe
        properties: ISSM
        annotations: 
        links: 
        remarks:                 
    remarks: 
  import-profile: 
    href: 
    # seems like a `checksum:` would be helpful to automate wget/curl/alike [daw: all hrefs can point via a fragment to a back-matter/resource which has this functionality. a back-matter/resource can also be BASE64 encoded and attached.]
    remarks: 
  system-characteristics: 
    system-ids: #would be nice if FEDRAMP could coin these upfront to start using prior to even review/authorization. [daw: I think that is the idea.]
    system-name: SHORTNAME-FULLSYSTEMNAME
    system-name-short: SHORTNAME
    description: "System purpose or function"
    properties: common-but-not-used
    annotations: common-but-not-used
    links: common-but-not-used
    date-authorized: YYYY-MM-DD
    security-sensitivity-level: Low
    system-information: 
      properties: common-but-not-used
      annotations: common-but-not-used
      links: common-but-not-used
      information-types: common-but-not-used
      #system-information-impact-method: fips-199
    security-impact-level: 
      security-objective-confidentiality: fips-199-low # Low [daw: OSCAL is intended to support other criticality taxonomies, such as those defined by ISO. We did this so we could add iso-low or something similar. Applications of OSCAL, like FedRAMP can require specific taxinomic values.]
      security-objective-integrity: fips-199-low # Low
      security-objective-availability: fips-199-low # Low
      # doesn't break out the 3x3 matrix required for evaluation of FIPS-199 -> L,L,L | L, M, L | M, L, L is a moderate system ^ only allows average of 3 per criteria. [daw: I am not sure what you mean here. Can you give a more thourough example?]
    status: 
      state: operational
      remarks: "System status explained here."
    leveraged-authorizations:
      AWS:
        id: FEDRAMP-ID
        name: "Leveraged Service Provider Owner"
        properties: common-but-not-used
        annotations: common-but-not-used
        links: common-but-not-used
        party-id: 
        #^ seems redundant with overall `id` [daw: The `id` is the identifier of the leveraged-authorization. the `party-id` is a reference to the party in the metadata.]
        date-authorized: YYYY-MM-DD
        remarks:
      GCP:
        id: FEDRAMP-ID
        name: "Leveraged Service Provider Owner"
        properties: 
        annotations:
        links:
        party-id:
        date-authorized: YYYY-MM-DD
        remarks:    
    authorization-boundary: 
      description: "Provide an explicit definition
of the system’s Authorization Boundary"
      properties: common-but-not-used
      annotations: common-but-not-used
      links: common-but-not-used
      diagrams:           
        AuthorizationBoundary: 
          description: 
          properties: 
          links: "https://cloud.gov/img/example-diagram-1.svg"
          caption: 
          remarks:           
      remarks: common-but-not-used
    network-architecture: 
      description: Optional overview of Network Architecture
      properties: common-but-not-used
      annotations: common-but-not-used
      links: common-but-not-used
      diagrams: 
        NetworkArchitecture: 
          description: 
          properties: 
          links: "https://cloud.gov/img/example-diagram-2.svg"
          caption: 
          remarks: 
      remarks: common-but-not-used
    data-flow: 
      description: Optional overview of Data Flow
      properties: common-but-not-used
      annotations: common-but-not-used
      links: common-but-not-used
      diagrams: 
        DataFlow: 
          description: 
          properties: 
          links: "https://cloud.gov/img/example-diagram-2.svg"
          caption: 
          remarks: 
      remarks: common-but-not-used
    responsible-parties:
    #reponsible-parties should have all been declared, seems over engineered for a fringe use-case - seems more approrpriate to treat the relationship under a common #ref schema model like others included within a `#ref/schema/common` model (e.g. everything labeled `common-but-not-used`). [daw: All responsible parties are declared in metadata. This is an identifier reference to one of those entries.]
      responsible-party: 
        party-ids: common-but-not-used
        properties: common-but-not-used
        annotations: common-but-not-used
        links: common-but-not-used
        remarks: common-but-not-used
    remarks: 
  system-implementation: 
    properties: common-but-not-used
    annotations: common-but-not-used
    links: common-but-not-used
    users: 
      sysadmin: 
        title: System Adminstrator
        short-name: 
        description: Add/remove users and hardware, install and configure software, OS updates, patches and hotfixes, perform backups.
        properties: Internal
        annotations: Privileged (P)
        links: 
        role-ids: 
        authorized-privileges: Full administrative access (root)
        remarks: Moderate
      client-adminstrator: 
        title: Client Administrator
        short-name: 
        description: Add/remote client users. Create, modify, and delete client applications.
        properties: External
        annotations: Non-Privileged (NP)
        links: 
        role-ids: 
        authorized-privileges: Portal administration
        remarks: N/A
      program-director: 
        title: Program Director
        short-name: 
        description: Reviews, approves and enforces policy.
        properties: Internal
        annotations: No Logical Access (NLA)
        links: 
        role-ids: 
        authorized-privileges: Project administration
        remarks: Limited            
    # the element below doesnt exist in schema - which might be an error but most other fields have a catch-all `remarks` which is a very helpful field. [daw: We can add this. Good catch.]
    remarks: |
        "There are currently \<*number*\> internal personnel and \<*number*\> external personnel. Within one year, it is anticipated that there will be \<*number*\> internal personnel and \<*number*\> external personnel."
    components: 
      web-server: 
        name: 
        component-type: 
        description: 
        properties: 
        annotations: 
        links: 
        status: 
          state: operational
          remarks: 
        responsible-roles: 
        remarks: 
    # services seems overly redundant with components, and the other fields for control-implementation don't seem appropriate to manage at the SSP level/layer. Component at this level should allow for declaring ports/protocols/interconnections and `href` to its control-implementation. Services and Interconnections seem to overly complicate the schema. [daw: I agree about migrating services to components. I need to understand more about what you are suggest be at the SSP level/layer.]
    # There is no obv rational to prepend `ssp-*` to anything this seems to overlycomplicate its use/mapping). [daw: not sure what this means.]   
    services:
      service:
        id: common-but-not-used
        name: ServiceName
        description: common-but-not-used
        properties: common-but-not-used
        annotations: common-but-not-used
        links: common-but-not-used
        ssp-protocol: #? how is this different from the protocol array below [daw: I need to check, but this might be redundant.]
        purpose: Purpose
        remarks: common-but-not-used
        protocol:
          title: common-but-not-used
          description: common-but-not-used
          type: common-but-not-used
          properties: common-but-not-used
          port-ranges:
            start: 80
            end: 443
            transport: TLS 1.2
      ssp-interconnection: # suggest to rename to `interconnection` [daw: yep.]
        id: common-but-not-used
        remote-system-name:
        annotations: common-but-not-used
        links: common-but-not-used
        responsible-parties: # seems more appropriate to associated this to `leveraged-authorizations` make sure the elements missing from the table are optional there as a nested properity. [daw: yes. I commented on this above.]
        remarks: common-but-not-used
    system-inventory: 
      # missing `software-items` for 11.2 Software Inventory [daw: Need to understand this data better. We should talk about this.]
      # missing `network-items` for 11.3 Network Inventory [daw: Need to understand this data better. We should talk about this.]
      # missing `hardware-items` for 11.1 Hardware Inventory [daw: Need to understand this data better. We should talk about this.]
      inventory-items:
        inventory-item:
          id: common-but-not-used
          assest-id: common-but-not-used
          description: common-but-not-used
          properties: common-but-not-used
          annotations: common-but-not-used
          links: common-but-not-used
          responsible-parties: common-but-not-used
          remarks: common-but-not-used
      # If the system is inventorying and using components in the SSP, it should be assumed they're implemented or planned for this next section of the schema should be up for consideration of removing.    
      implemented-components:
        implemented-component:
          use:
          properties: common-but-not-used
          annotations: common-but-not-used
          links: common-but-not-used
          responsible-parties: common-but-not-used
          remarks: common-but-not-used
      remarks: 
    remarks: 
  # If the system is inventorying and using components in the SSP, it should be assumed they're implemented or planned for this next section of the schema should be up for consideration of removing/moving into the pure `components` field. [daw: This is built to allow for controls to be specified at the system level to support current SSPs that are not defined at a component-level of granularity.]
  control-implementation: 
    description: 
    implemented-requirements: 
      implemented-requirement:
        id: common-but-not-used
        control-id:
        description: common-but-not-used
        properties: common-but-not-used
        annotations: common-but-not-used
        links: common-but-not-used
        by-components:
        responsible-roles: common-but-not-used
        set-params:
        statements:
          statement:
            description:
            properties:
            links:
            responsible-roles:
            by-components:
            remarks:
        remarks: common-but-not-used
  back-matter: 
    citations: 
    resources: 

[JJediny]

Note: I use field/attribute/element interchangeably below to represent an object in the schema...

@JJediny First of all, thank you for this review. This is extremely helpful.

I'd like to address your summary feedback.

1. With regard to common elements, the duplication is an artifact of the Metaschema-based schema generation system we use for OSCAL. We can look into a way to streamline this through an update to the Metaschema syntax and the schema generation process.

Understood, my comment was meant to make this common element explicit, and make its schema reusable in a ref model (if when and where appropriate). That way we get the benefit of concept reuse as well, we could start documenting how those fields should be used in a particular context/usage.

e.g. as-is:
    components: 
      web-server: 
        name: 
        component-type: 
        description: 
        properties: 
        annotations: 
        links: 
        status: 
          state: operational
          remarks: 
        responsible-roles: 
        remarks: 

VS

    components: 
      web-server: 
        common:
          name:
          description: 
          properties: 
          annotations: 
          links:
          remarks: 
        component-type: 
        status: 
          state: operational
          remarks: 
        responsible-roles: 

^ the later helps the user understand what is unique vs what are the common attributes

2. For the one-to-many versions, this sounds reasonable. Maybe a version-history would suffice, with the same data fields you suggest?

I think the current fields but under a nested versions field would work fine but a remarks field is needed to explain what was done similar to a commit message to explain what high-level change happened version-to-version:

    versions:
      version:
        published: 2020-00-00
        last-modified: 2020-10-00
        version: 1.0
        oscal-version: 1.0
        uri: link
        remarks: "Swapped out two new components for old ones, blah"
      version:
        published: 2020-10-00
        last-modified: 2021-10-00
        version: 1.1
        oscal-version: 1.1
        uri: link
        remarks: "Added two new interconnections and rearchitected 2 components, blah"

3. I like the idea of consolidating services into components and interconnections into leveraged-authorizations. We could even have a type for leveraged-authorizations that would allow for the specificity of the type of authorization (e.g., interconnection, common-control-provider, etc.).

Interconnections on the second review; seem appropriate, but they are missing the following attributes:

• IP Address and Interface
• External Organization Name and IP Address of System
• External Point of Contact and Phone Number
• Connection Security (IPSec VPN, SSL, Certificates, Secure File Transfer etc.)
• Data Direction (incoming, outgoing, or both)
• Information Being Transmitted
• Port or Circuit Numbers

That said interconnections should have an id model to ref -> leverage-authorizations. These are raw elements from the SSP template ^, some of the data like ip/dns/contact info/ports should be redacted from public domain as they are ~CUI, but at the same time, the schema should support populating them none-the-less.

4. You suggest removing control-implementation & implemented-component from SSP layer of the schema altogether and move all ports/protocol information into components. I need to better understand what you are trying to accomplish. We treat components as potential implementations, while inventory-items are "concrete" implementations, This allows a component, like a server operating system to be specialized as an inventory-item. This is also why ports/protocols appear on inventory-item, since some of these might not be known unless you talk about a specific server instance.

~components should/could be anything related to the control implementation; whether technical and/or policy implementation. Saying an SSP implements some controls is co-mingling the concept of implementation. An SSP should import an IR/CP/CM plan as a component, the same way it does an apache/nginx mod-security component; and its control implementation should be managed entirely separately from the System leveraging them for best reuse/updating.

The separation of the SSP from control implementation is the cleanest IMHO. Adding those mixed concepts at the SSP layer only complicates things and makes the schema more complex to implement the same thing at two schema layers.

5. We will need to review the FEDRAMPed tailored SSP table regarding interconnections. We can add fields or FedRAMP can use properties/annotations to extend. Need to look deeper to figure out what the best course of action is.

^

6. Regarding software-items for 11.2 Software Inventory, network-items for 11.3 Network Inventory, and hardware-items for 11.1 Hardware Inventory, I'd like to discuss this with you in a higher-bandwidth setting. Maybe a phone call or F2F. This will help us find a path forward.

^ This is a great ask of the FEDRAMP team to santize real-world examples of what is traditional cataloged for these and match attributes in the schema for them.

I have also included some detailed comments below marked [daw:].

title: FEDRAMP Tailored SSP Template
permalink: /fedramp-tailored
layout: home
system-security-plan: 
  id: UUID
  metadata: 
    title:
    # need a versions concept to address multiple iterations/versions for publications required disclosure
    #versions:
    #  version:
    #    published: 
    #    last-modified: 
    #    version: 
    #    oscal-version: 1.0
    #    uri: over links for uniqueid href and integrity
    published: ^
    last-modified: ^
    version: ^
    oscal-version: ^
    document-ids: # seems redundant with overarching `id`
    properties: 
    links: 
    roles:  # seems redundant with responsible-parties [daw: This is where all roles are defined within the document. They are then referenced in responsible-parties/responsible-roles.]

It seems costly to ask users to duplicate defining them (as a mapping/matching check?); when the user is defining them and establishing them under responsible-roles once. Referencing to them should only be done as hard id to where they are being defined? Prob missing something here?

parties: # seems redundant with responsible-parties [daw: This is where all parties are defined within the document. They are then referenced in responsible-parties/responsible-roles.]

^

responsible-parties: 
  information-system-owner: 
    party-ids: John Doe
    properties: System Owner
    annotations: 
    links: 
    remarks:
  independent-assessor: 
    party-ids: Company X
    properties: Third Party Assessor
    annotations: 
    links: 
    remarks:
  authorizing-offical: 
    party-ids: Jane Doe
    properties: AO
    annotations: 
    links: 
    remarks:
  authorizing-offical-management-poc: 
    party-ids: Jane Doe
    properties: Management POC
    annotations: 
    links: 
    remarks:           
  authorizing-offical-technical-poc: 
    party-ids: Jane Doe
    properties: Technical POC
    annotations: 
    links: 
    remarks:
  information-system-security-officer: 
    party-ids: Jane Doe
    properties: ISSO
    annotations: 
    links: 
    remarks: 
  information-system-security-manager: 
    party-ids: Jane Doe
    properties: ISSM
    annotations: 
    links: 
    remarks:                 
remarks: 

import-profile:
href:
# seems like a checksum: would be helpful to automate wget/curl/alike [daw: all hrefs can point via a fragment to a back-matter/resource which has this functionality. a back-matter/resource can also be BASE64 encoded and attached.]

^ agree to dismiss

remarks: 

system-characteristics:
system-ids: #would be nice if FEDRAMP could coin these upfront to start using prior to even review/authorization. [daw: I think that is the idea.]

👍

system-name: SHORTNAME-FULLSYSTEMNAME
system-name-short: SHORTNAME
description: "System purpose or function"
properties: common-but-not-used
annotations: common-but-not-used
links: common-but-not-used
date-authorized: YYYY-MM-DD
security-sensitivity-level: Low
system-information: 
  properties: common-but-not-used
  annotations: common-but-not-used
  links: common-but-not-used
  information-types: common-but-not-used
  #system-information-impact-method: fips-199
security-impact-level: 
  security-objective-confidentiality: fips-199-low # Low [daw: OSCAL is intended to support other criticality taxonomies, such as those defined by ISO. We did this so we could add iso-low or something similar. Applications of OSCAL, like FedRAMP can require specific taxinomic values.]
  security-objective-integrity: fips-199-low # Low
  security-objective-availability: fips-199-low # Low
  # doesn't break out the 3x3 matrix required for evaluation of FIPS-199 -> L,L,L | L, M, L | M, L, L is a moderate system ^ only allows average of 3 per criteria. [daw: I am not sure what you mean here. Can you give a more thourough example?]

See the first bullet, in response, has to do with the additive information types being reviewed to intially determine the system fip profile. There could be 50/8/6/5 types of "information types" reviewed individually/independently; if one of them is L/M/L then the system could be determined to be Moderate; so the cumulative determination of the system being L/L/L is dependent on the X number of reviews for each information-type under each of the 3 categories. The schema doesnt support one-to-many information-types.

status: 
  state: operational
  remarks: "System status explained here."
leveraged-authorizations:
  AWS:
    id: FEDRAMP-ID
    name: "Leveraged Service Provider Owner"
    properties: common-but-not-used
    annotations: common-but-not-used
    links: common-but-not-used
    party-id: 
    #^ seems redundant with overall `id` [daw: The `id` is the identifier of the leveraged-authorization. the `party-id` is a reference to the party in the metadata.]

party-ids as a concept; I do not understand how it is being used/leveraged?

    date-authorized: YYYY-MM-DD
    remarks:
  GCP:
    id: FEDRAMP-ID
    name: "Leveraged Service Provider Owner"
    properties: 
    annotations:
    links:
    party-id:
    date-authorized: YYYY-MM-DD
    remarks:    
authorization-boundary: 
  description: "Provide an explicit definition

of the system’s Authorization Boundary"
properties: common-but-not-used
annotations: common-but-not-used
links: common-but-not-used
diagrams:
AuthorizationBoundary:
description:
properties:
links: "https://cloud.gov/img/example-diagram-1.svg"
caption:
remarks:
remarks: common-but-not-used
network-architecture:
description: Optional overview of Network Architecture
properties: common-but-not-used
annotations: common-but-not-used
links: common-but-not-used
diagrams:
NetworkArchitecture:
description:
properties:
links: "https://cloud.gov/img/example-diagram-2.svg"
caption:
remarks:
remarks: common-but-not-used
data-flow:
description: Optional overview of Data Flow
properties: common-but-not-used
annotations: common-but-not-used
links: common-but-not-used
diagrams:
DataFlow:
description:
properties:
links: "https://cloud.gov/img/example-diagram-2.svg"
caption:
remarks:
remarks: common-but-not-used
responsible-parties:
#reponsible-parties should have all been declared, seems over engineered for a fringe use-case - seems more approrpriate to treat the relationship under a common #ref schema model like others included within a #ref/schema/common model (e.g. everything labeled common-but-not-used). [daw: All responsible parties are declared in metadata. This is an identifier reference to one of those entries.]

If it is only being referenced by id the field should just be calling back to a single responsible-parties list defined under the contact section & use their short-name as the id here to explain the interactions/co-roles between parties:

responsible-parties:
  SSP-updaters:
    reponsible-parties: 
      - isso
      - system-owner
    remarks:  "the ISSO and System Owner will update the plan every X months"

But ^ is more appropriately managed as a component implementation of the control requirement; which I think shows this part of the schema is not needed as this requirement is better associated/written up as a control implementation

  responsible-party: 
    party-ids: common-but-not-used
    properties: common-but-not-used
    annotations: common-but-not-used
    links: common-but-not-used
    remarks: common-but-not-used
remarks: 

system-implementation:
properties: common-but-not-used
annotations: common-but-not-used
links: common-but-not-used
users:
sysadmin:
title: System Adminstrator
short-name:
description: Add/remove users and hardware, install and configure software, OS updates, patches and hotfixes, perform backups.
properties: Internal
annotations: Privileged (P)
links:
role-ids:
authorized-privileges: Full administrative access (root)
remarks: Moderate
client-adminstrator:
title: Client Administrator
short-name:
description: Add/remote client users. Create, modify, and delete client applications.
properties: External
annotations: Non-Privileged (NP)
links:
role-ids:
authorized-privileges: Portal administration
remarks: N/A
program-director:
title: Program Director
short-name:
description: Reviews, approves and enforces policy.
properties: Internal
annotations: No Logical Access (NLA)
links:
role-ids:
authorized-privileges: Project administration
remarks: Limited
# the element below doesnt exist in schema - which might be an error but most other fields have a catch-all remarks which is a very helpful field. [daw: We can add this. Good catch.]
remarks: |
"There are currently <number> internal personnel and <number> external personnel. Within one year, it is anticipated that there will be <number> internal personnel and <number> external personnel."
components:
web-server:
name:
component-type:
description:
properties:
annotations:
links:
status:
state: operational
remarks:
responsible-roles:
remarks:
# services seems overly redundant with components, and the other fields for control-implementation don't seem appropriate to manage at the SSP level/layer. Component at this level should allow for declaring ports/protocols/interconnections and href to its control-implementation. Services and Interconnections seem to overly complicate the schema. [daw: I agree about migrating services to components. I need to understand more about what you are suggest be at the SSP level/layer.]

Doubling down on this comment, components should be used and services removed; components at the SSP level should have port/protocol metadata and href/uri the external or relative path where the control implementation of the component is documented in a separate file as a dependency.

There is no obv rational to prepend ssp-* to anything this seems to overlycomplicate its use/mapping). [daw: not sure what this means.]

Just that it's not helpful/and can only confuse the user to prepend ssp- to an attribute/element in the ssp schema.

services:
  service:
    id: common-but-not-used
    name: ServiceName
    description: common-but-not-used
    properties: common-but-not-used
    annotations: common-but-not-used
    links: common-but-not-used
    ssp-protocol: #? how is this different from the protocol array below [daw: I need to check, but this might be redundant.]

^

    purpose: Purpose
    remarks: common-but-not-used
    protocol:
      title: common-but-not-used
      description: common-but-not-used
      type: common-but-not-used
      properties: common-but-not-used
      port-ranges:
        start: 80
        end: 443
        transport: TLS 1.2
  ssp-interconnection: # suggest to rename to `interconnection` [daw: yep.]

interconnections should be their own top-level element under system-implementation as a one-to-many attribute.

interconnections:
  interconnection:
    another:
    field:
    attribute:
    element:

    id: common-but-not-used
    remote-system-name:
    annotations: common-but-not-used
    links: common-but-not-used
    responsible-parties: # seems more appropriate to associate this to `leveraged-authorizations` make sure the elements missing from the table are optional there as a nested property. [daw: yes. I commented on this above.]
    remarks: common-but-not-used
system-inventory: 
  # missing `software-items` for 11.2 Software Inventory [daw: Need to understand this data better. We should talk about this.]
  # missing `network-items` for 11.3 Network Inventory [daw: Need to understand this data better. We should talk about this.]
  # missing `hardware-items` for 11.1 Hardware Inventory [daw: Need to understand this data better. We should talk about this.]

Commented at the top about this

  inventory-items:
    inventory-item:
      id: common-but-not-used
      assest-id: common-but-not-used
      description: common-but-not-used
      properties: common-but-not-used
      annotations: common-but-not-used
      links: common-but-not-used
      responsible-parties: common-but-not-used
      remarks: common-but-not-used
  # If the system is inventorying and using components in the SSP, it should be assumed they're implemented or planned for this next section of the schema should be up for consideration of removing.    
  implemented-components:
    implemented-component:
      use:
      properties: common-but-not-used
      annotations: common-but-not-used
      links: common-but-not-used
      responsible-parties: common-but-not-used
      remarks: common-but-not-used
  remarks: 
remarks: 

If the system is inventorying and using components in the SSP, it should be assumed they're implemented or planned for this next section of the schema should be up for consideration of removing/moving into the pure components field. [daw: This is built to allow for controls to be specified at the system level to support current SSPs that are not defined at a component-level of granularity.]

Commented previously but I don't think it helps the user to think about control implementation in two places of the schema, both technical/policy controls can be represented as separate components are better handled as external imports/vendoring/dependencies.

control-implementation:
description:
implemented-requirements:
implemented-requirement:
id: common-but-not-used
control-id:
description: common-but-not-used
properties: common-but-not-used
annotations: common-but-not-used
links: common-but-not-used
by-components:
responsible-roles: common-but-not-used
set-params:
statements:
statement:
description:
properties:
links:
responsible-roles:
by-components:
remarks:
remarks: common-but-not-used
back-matter:
citations:
resources:

[brian-ruf]

30-Jan-2020 Status

Will review this in detail in an upcoming working session. Possibly next week.

[david-waltermire]

This is partially addressed by PR #619 which added version histories.

[david-waltermire]

PR #643 represents further work on addressing this issue.

• Renaming ssp-interconnections to interconnections
• Renaming ssp-protocols to protocols