Quantcast

comments on 800-126 with impacts on XCCDF

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

comments on 800-126 with impacts on XCCDF

Charles Schmidt (MITRE)
Administrator
Hello,

Below are some of my comments on the new draft of 800-126 (SCAP 1.2) which
have some impact on XCCDF, either with regards to limitations that SCAP
places on XCCDF, or, in one case, a possible place where it might make sense
to change the XCCDF spec. (Page numbers are from the bottom of the page.)

Page 19, section 3.5.1, paragraph 2, last sentence: "Use of the @name
attribute is REQUIRED except for the patches up-to-date rule, as defined in
Section 3.3.6.4." This seems an odd requirement - that authors cannot make
use of nameless check-refs unless they are looking at patches. I can think
of many cases where one might wish to use a nameless check-ref, including an
OVAL file that represents a list of known vulnerabilities and an OVAL file
that represents tests from an external authority (e.g., Rule =  "be sure to
follow all the recommendations handed down from body XYZ"). Given that
vendors will need to support nameless checks anyway to support the patch
case, it seems wasteful of their efforts to prevent nameless checks from
being put to other purposes. Maybe this can be changed to a SHOULD
recommendation?

Page 34, section 4.5, item 9: "In <xccdf:target-facts>, an
<xccdf:target-id-ref> SHALL be specified ..." <target-id-ref> is not a
sub-element of <target-facts>. Either the XCCDF spec should be changed so
that <target-id-ref> (and the <any> tag that allows arbitrary identifying
structures) to be a sub-element of <target-facts>, or the reference to
<target-facts> should be removed here. The former approach might not be a
bad idea since it would consolidate the new structures within a reasonable
parent block.

Page 35, section 4.5.1, paragraph 3: "An <xccdf:rule-result> of "pass" SHALL
indicate that the check content evaluated within the rule complied with one
of the following..." This set of stipulations, in effect, prohibit the use
of the @negate property in checks. They go beyond what I thought was
intended in Table 20 because they don't just map check results to XCCDF
results - they map XCCDF results to the *meanings* of check results. If this
is desired, there should be an explicit statement that "SCAP content MUST
NOT use the @negate attribute" added to the requirements for XCCDF use.
Alternately, the stipulations in this section could be removed and Table 20
could instead be used to define the mappings with the tweak that the table
should explicitly map definition results to check results rather than
rule-results. This tweak to Table 20 and the surrounding text should
probably be done anyway since, by mapping OVAL definition results directly
to rule-result/result values, it leaves undefined cases where there is not a
1-1 mapping between an OVAL def result and a rule-result (such as during
complex-checks or for patch checks where multi-check="false").

Charles

smime.p7s (4K) Download Attachment
Loading...