GSA / fedramp-automation

FedRAMP Automation
https://www.fedramp.gov/using-the-fedramp-oscal-resources-and-templates/
Other
293 stars 90 forks source link

`responsible-role` should be unnecessary for inapplicable control requirements #233

Open GaryGapinski opened 2 years ago

GaryGapinski commented 2 years ago

Describe the bug

An implemented-requirement implementation status can be "not-applicable". Guide to OSCAL-based FedRAMP System Security Plans §5.2 states "Every control must have at least one responsible-role defined.". The requirement for a responsible-role should be optional rather than stipulating the existence of an inapplicability czar.

Who is the bug affecting?

Reluctant control implementors.

Is this report specifically related to the Word or Excel files from fedramp.gov?

No.

What version of OSCAL are you using?

1.0.2.

What is affected by this bug?

Unnecessary role definition for inapplicable control requirements.

When does this occur?

Current fedramp-automation validation assertions fail a not-applicable implemented-requirement lacking a responsible-role.

    <sch:pattern
        doc:guide-reference="Guide to OSCAL-based FedRAMP System Security Plans §5.2"
        id="implementation-roles"
        see="Guide to OSCAL-based FedRAMP System Security Plans §5.2">
        <sch:title>Roles related to implemented requirements</sch:title>
        <sch:rule
            context="oscal:implemented-requirement"
            doc:guide-reference="Guide to OSCAL-based FedRAMP System Security Plans §5.2">
            <sch:assert
                diagnostics="implemented-requirement-has-responsible-role-diagnostic"
                doc:guide-reference="Guide to OSCAL-based FedRAMP System Security Plans §5.2"
                fedramp:specific="true"
                id="implemented-requirement-has-responsible-role"
                role="error"
                test="oscal:responsible-role">Each implemented control must have one or more responsible-role definitions.</sch:assert>
        </sch:rule>
        <sch:rule
            context="oscal:responsible-role"
            doc:guide-reference="Guide to OSCAL-based FedRAMP System Security Plans §5.2">
            <sch:assert
                diagnostics="responsible-role-has-role-definition-diagnostic"
                doc:guide-reference="Guide to OSCAL-based FedRAMP System Security Plans §5.2"
                doc:template-reference="System Security Plan Template §13"
                fedramp:specific="true"
                id="responsible-role-has-role-definition"
                role="error"
                test="//oscal:role/@id = current()/@role-id">Each responsible-role must reference a role definition.</sch:assert>
            <sch:assert
                diagnostics="responsible-role-has-user-diagnostic"
                doc:guide-reference="Guide to OSCAL-based FedRAMP System Security Plans §5.2"
                doc:template-reference="System Security Plan Template §13"
                fedramp:specific="true"
                id="responsible-role-has-user"
                role="error"
                test="//oscal:role-id = current()/@role-id">Each responsible-role must be referenced in a system-implementation user
                assembly.</sch:assert>
        </sch:rule>
    </sch:pattern>

How do we replicate the issue?

Declare an implemented-requirement without responsible-role.

Expected behavior (i.e. solution)

Relax requirement for responsible-role for inapplicable control requirements. Correct documentation.

GaryGapinski commented 2 years ago

Correction available in 18F/fedramp-automation#612.