SSP Completeness Checks: Appendices C, D, F, G, H, I, N, P #809
Comments
Analysis
Additional Considerations
|
Important ConsiderationThere are several possible ways policies, plans and procedures may be attached to security controls:
Edited Dec 3, 2024 to cross out 1, 2 and 3a, and emphasize 3b. |
Thanks for the brief today, let's soon discuss how we should act with recommendations on 2 and 3b as the preferred recommendations and how to design constraints around them ASAP. |
|
@aj-stein-gsa I've reached this issue in our priorities. We've both been very focused on other work and haven't resolved the above question of how best to model attachments. As with other areas this is something where we should have a preferred approach as well as accepting a simpler approach in support of legacy Word -> OSCAL SSP conversions. Further, we have allowed other attachments and links to be either a URI fragment or a direct external link. As a result, I believe we should establish 3b as our preferred approach, but accept any of the above (1, 2, 3a and 3b). I think our team has become well skilled at writing xapth that supports these scenarios. I will defer any further analysis on this until you return. Hope to have a clear direction by COB Monday, Dec 2nd @Rene2mt FYSA |
|
I am going to model 3b Tuesday in the example SSP and being defining constraints that will give an error if none of the above methods are used, plus offer a warning if any method other than 3b is used. |
|
In today's conversation with @aj-stein-gsa , @Rene2mt and @brian-ruf we agree that we only accept 3B: |
|
Additional note related to today's earlier conversation. In the future, we intend to investigate annotating the OSCAL baselines to indicate exactly where attachments are expected relative to control statements as well as the nature of the attachment. We are deferring this approach for now due to the deadline for finishing SSP constraints. |
DetailAnalysis of exactly which control statements should have attachments and what attachment types are acceptable. Process vs ProcedureGenerally accepted process improvement principles consider processes to involve more than one party, often crossing organizational boundaries while procedures tend to be something that a single party can complete start to finish for a given task. There is rough alignment with this in NIST SP 800-53. In terms of OSCAL content modeling, please consider "process" and "procedure" to be equivalent terms. Only a single OSCAL component type exists for both processes and procedures (the "process-procedure" component type) and only a "procedure" attachment type exists that is expected to be used for both processes and procedures. Always Required (ERROR)
Separation of DutiesThe SoD Matrix is required by AC-5 parts a and b; however, we are now expecting this in OSCAL format rather than as an attachment. Plus AC-5 does not exist in the Low or LI-SaaS baselines. Questionable as a MandateThe following are very likely to require an attachment as part of properly satisfying the control, and are nearly always accomplished via a Plan, Procedure or similar. These should at least raise a WARNING if no attachment is found. Collaboration with the review team may result in some items in this list either being dropped or moved from WARNING to ERROR.
|
Constraint PatternPRELIMINARY CONSTRAINTSThe following constraints should be executed first:
2a. Does the component have a link statement that identifies a valid back-matter resource? 2b. Does the back-matter resource have a viable attachment? |
CONSTRAINT PATTERN FOR EACH ATTACHMENTExample Pattern<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE metaschema-meta-constraints [
<!ENTITY check-for-attachments SYSTEM "./check-for-attachments.ent">
]>
<!-- cut content -->
<!-- Repeat this structure for each row in the table below. -->
<context>
<let var="root-help-url" expression="https://automate.fedramp.gov/documentation" />
<let var="reference" expression="has-ac-policy" />
<let var="control-id" expression="ac-1" />
<let var="statement-id" expression="concat($control-id, '_smt.a')" />
<let var="component-type" expression="policy" />
<let var="level" expression="ERROR" />
<let var="message" expression="A policy that addresses Access Control must be associated with AC-1 part a." />
<let var="help-url" expression=concat($root-help-url, "/ssp/something") />
&check-for-attachments;
</context>
File: <metapath target="/system-security-plan/control-implementation/implemented-requirement[@control-id=$control_id]/statement[@statement-id=$statement-id]" />
<constraints>
<expect id="$reference" target="." test="count(/system-security-plan/system-implementation/component[@uuid=./@component-uuid] and @type=$component-type) >= 1">
<formal-name>Required Attachment is Present</formal-name>
<prop name="help-url" namespace="https://docs.oasis-open.org/sarif/sarif/v2.1.0" value=$help-url />
<message>$message</message>
</expect>
</constraints>
DATA TO PLUG INTO PATTERNNOTE: In the table, the
QUESTIONCan we define the variables as many times as needed, but put the actual constraint definition in an external file and import it each place it is needed, similar to the way allowed values are handled in the OSCAL metaschema? |
|
@aj-stein-gsa and @Rene2mt I think this is ready to create some tasks. |
|
@wandmagic / @dimitri-zhurkin-vitg I suspect you'll have some good thoughts on how best to replicate this pattern once we feel it is solid. |
This is a ...
fix - something needs to be different
This relates to ...
User Story
As a consumer of FedRAMP automated completeness checks I want the following OSCAL-based SSP items to be automatically verified for completeness by metaschema constraints:
Goals
SSP Completeness checks are defined, tested and documented
Dependencies
No response
Acceptance Criteria
Other information
No response
Tasks
id='has-separation-of-duties-matrix'to check for OSCAL construct instead of attachment.The text was updated successfully, but these errors were encountered: