Issues with FedRAMP_extensions.json file

[vikas-agarwal76]

Below list captures some of the issues identified in FedRAMP_extensions.json file or some suggestions for improvement.

1. Some of the required fields mentioned in pdf files - both common across different OSCAL models, and model specific things are not captured in FedRAMP_extensions.json. For example -
   1. “fedramp-pmo” is a required role
   2. FedRAMP logo should be included in back-matter/resources and linked in Party representing fedramp-pmo
   3. There should be a responsible-party with role-id as “fedramp-pmo” associating it to FedRAMP party.
   4. “system-owner” role is required in SSP.
   5. etc.
2. Is there some documentation which describes the meaning of various fields used in FedRAMP_extensions.json? What can be the expected structure of this file and details of each field / sub-field, possible options? Whether a field is required or not, etc. so that we can process this file programmatically.
3. What is the purpose of “indexes”?
4. Does "extension-namespace" field means all properties captured in “extensions” belong to this namespace?
5. There are 2 “extensions” field - top level, and actual extensions. They should be named differently.
6. Does "extension-name" under extensions give the name of the “prop” in “bindings”? If yes, the at some places the name pf the prop is explicitly captured in bindings and sometimes it is same as "extension-name" and sometimes different.
7. The "revision-history-party-uuid" extension has min. Cardinality of 0, whereas as per pdf it is required.
8. The usage of different fields in “index-has-keys" (for revision-history-party-uuid) is not very clear, even though the intent is clear.
9. The “pattern” specified in bindings is not consistent; sometimes it is full path, sometimes it is relative, sometimes it includes name, and other attributes also. What are different variations possible and how to interpret them? For example - in “authenticator-assurance-level'

"bindings": [
                    {
                        "pattern": "/o:system-security-plan/o:system-characteristics/o:prop"
                    },
                    {
                        "pattern": "system-characteristics/o:prop[@name='authenticator-assurance-level']"
                    },
                    {
                        "pattern": "system-characteristics/o:prop[@name='federation-assurance-level']"
                    },
                    {
                        "pattern": "system-characteristics/o:prop[@name='identity-assurance-level']"
                    }
                ],

In "interconnection-security”. What is the purpose of @value

"bindings": [
                    {
                        "pattern": "o:component[@component-type='interconnection']/o:prop[@name='connection-security'][@ns='https://fedramp.gov/ns/oscal']/@value"
                    }
                ]

In "transport-type" "pattern": "o:component[@component-type='service']/o:protocol/o:port-range/@transport"

In "no-oscal-ssp-title-short" "pattern": "/o:assessment-plan/o:back-matter/o:resource[./o:prop[@name='type'][.='no-oscal-ssp']]/o:prop"

10. How to interpret “expects” field - example - in "sorn-id"

"expects": [
                        {
                            "test": ".[@name='pta-4'][@ns='https://fedramp.gov/ns/oscal']/@value='yes' and .[@name='sorn-id'][@ns='https://fedramp.gov/ns/oscal']"
                        }
                    ]

In "planned-completion-date" constraint

"expects": [
                    {
                        "test": "(o:prop[@name='implementation-status'][@ns='https://fedramp.gov/ns/oscal'][@value='partial']/remarks)"
                    },
                    {
                        "test": "(o:prop[@name='implementation-status'][@ns='https://fedramp.gov/ns/oscal'][@value='planned']/remarks)"
                    },
                    {
                        "test": "(o:prop[@name='implementation-status'][@ns='https://fedramp.gov/ns/oscal'][@value='alternative']/remarks)"
                    },
                    {
                        "test": "(o:prop[@name='implementation-status'][@ns='https://fedramp.gov/ns/oscal'][@value='not-applicable']/remarks)"
                    }
                ]

In “Port Class Exists” constraint "test": "exists(@class)"

11. In many cases "allowed-values" does not have "allow-other”? How should this be interpreted - “yes” or “no”?
12. What is the difference between extensions and constraints? Constraints also define new properties. For example - in "sar-risk-impacted-control", binding "pattern": "/o:assessment-results/o:result/o:risk/o:prop"
13. Why is extensions an object with each extension represented as “id”: {}, whereas, constraint is an array [].
14. In constraint - "planned-completion-date", there is property field. What does this means?

"props": [
                    {
                        "name": "reference",
                        "value": "3.1"
                    }
                ],

15. If caridnality is not present then how it is to be interpreted? For example - in "attachment-type" constraint.

[butler54]

IBM/compliance-trestle#643 The values file I would pay attention to. The Extensions system will have to be started over again and I am trying to work with NIST on that but it is a long-term effort.

[vikas-agarwal76]

Here are some more suggestions -

Use JSONPath for extensions specification in JSON format rather than XPath which is applicable for XML.

Bindings should be broken in 2 parts - Context - set of elements/fields on which this will apply e.g., /*/o:metadata/o:revisions/o:revision Binding - actual element(s) on which the constraints have to be evaluated for each element of the context - o:prop[@name=party-uuid]

Constraint should have an additional field “target” on which the constraint would apply - “target”: @value. Also the constraint should be an array and grouped accordingly. Some constraints apply on value. Others apply on other attributes of binding, like @class attribute should exists or should have a specific value, etc.

[butler54]

@vikas-agarwal76 - I think I would phrase the current issue as this:

Questions interpreting fedramp extensions file - and phrase it as an initial investigation for which we have a number of questions we are not clear on. Let's get it out to the team (with a little frontmatter on why we want automation).

The obvious objective: Can the fedramp extension format be leveraged by other extensions going forward.

Thanks