usnistgov / SCAP

The repository will be used to track issues and post specifications related to the Security Automation Protocol (SCAP).
1 stars 0 forks source link

Update XCCDF to support platform specifications inside the check system in order to choose which check-content-ref to perform #2

Open vanderpol opened 3 weeks ago

vanderpol commented 3 weeks ago

Sometimes an XCCDF rule contains different requirements based on the target platform, and it would be useful to be able to select a single check-content-ref to perform based on the outcome of XCCDF's existing platform specifications.

Example: If system is a domain controller, perform OVAL definition 1. If the system is a member server, perform OVAL definition 2.

xccdf:check system="http://oval.mitre.org/XMLSchema/oval-definitions-5" selector="">
      xccdf:check-content-ref href="U_MS_Windows_Server_2022_V2R1_STIG_SCAP_1-3_Benchmark-oval.xml" name="oval:mil.disa.stig.windows2022:def:1" platformIDRef="#xccdf_mil.disa.stig_platform_Windows_DomainController"/>
      <xccdf:check-content-ref href="U_MS_Windows_Server_2022_V2R1_STIG_SCAP_1-3_Benchmark-enhancedV8-oval.xml" name="oval:mil.disa.stig.windows2022:def:2" platformIDRef="#xccdf_mil.disa.stig_platform_Windows_MemberServer"/>
 </xccdf:check>

Where only one of the above platformIDRefs would be true and then be performed.

vanderpol commented 3 weeks ago

@solind, given that our attempts to add logical tests or platform applicability fell through with OVAL, I'm attempting to find a 'simple' way to apply the existing XCCDF platform specifications to a check-content-ref, so that only one check content ref would be performed. Looking for your ideas, or share with anyone else who you might think would be helpful.

solind commented 3 weeks ago

You need the exact same rule to apply to both platforms?

If not, you could have two different rules, each targeting a different check to a different platform.

vanderpol commented 3 weeks ago

@solind, if we were in control of the XCCDF rules, this would be a non-issue, I agree completely. But in this scenario, DISA writes STIGS, and other people like us are trying to create benchmarks based on them, and the results have to tie back to the original STIG XCCDF rule id's. If there isn't enough support for this change, we'll survive, just have a few less automated rules, or sometimes having to end up with OVAL results of ERROR or TRUE = TRUE, so the overall result is correct, we just have to deal with some less than ideal results to get there.

solind commented 3 weeks ago

This could work if you want to redefine what it means to have multiple check-content-refs in a check, Table 11, section 6.4.4.4 in the specification.

vanderpol commented 1 day ago

In Table 11, section 6.4.4.4,

Original: If multiple elements appear, they represent alternative locations from which a benchmark consumer may obtain the check content. Benchmark consumers SHOULD process the alternatives in the order in which they appear in the XML. The first from which content can be successfully retrieved SHOULD be used. (Note that ensuring the validity of this content is not the responsibility of a benchmark consumer.)

Proposed If multiple elements appear, they represent alternative locations from which a benchmark consumer may obtain the check content. Benchmark consumers SHOULD process the alternatives in the order in which they appear in the XML. The first from which content can be successfully retrieved SHOULD be used. (Note that ensuring the validity of this content is not the responsibility of a benchmark consumer.)

If the check-content-ref has a platformIDRef defined, the Benchmark consumer the content should only be processed if the resulting cpe test returns true.

solind commented 1 day ago

I like it!

Maybe add that if none of the checks apply to the identified platform(s), the rule is treated as if it doesn't apply to the target.

And if multiple checks apply to the identified platform(s), the first one in document order whose ref can be resolved is used.

vanderpol commented 1 day ago

Original Table 6.4.4.4: If multiple xccdf:check-content-ref elements appear, they represent alternative locations from which a benchmark consumer may obtain the check content. Benchmark consumers SHOULD process the alternatives in the order in which they appear in the XML. The first xccdf:checkcontent-ref from which content can be successfully retrieved SHOULD be used. (Note that ensuring the validity of this content is not the responsibility of a benchmark consumer.)

Proposed If multiple xccdf:check-content-ref elements appear, they represent alternative locations from which a benchmark consumer may obtain the check content. Benchmark consumers SHOULD process the alternatives in the order in which they appear in the XML. The first xccdf:checkcontent-ref from which content can be successfully retrieved SHOULD be used. (Note that ensuring the validity of this content is not the responsibility of a benchmark consumer.)

If the check-content-ref has a platformIDRef defined, the Benchmark consumer the content should only be processed if the resulting cpe test returns true. If none of the platformIDRefs return true, no checks should be performed and the result should be 'Notapplicable'. If multiple checks apply to the identified platform(s), the first check in document order whose ref can be resolved is used.

solind commented 1 day ago

I made a few corrections to the second paragraph of the new proposal:

If the check-content-ref has a platformIDRef defined, it should only be processed if the corresponding cpe test returns true. If none of the platformIDRefs return true, no checks should be performed and the result should be 'notapplicable'. If multiple checks apply to the identified platform(s), the first check in document order whose ref can be resolved should be used.