Extension points for "applicability information"

[bgro]

Currently, Benchmark, Group, Rule, and fix element allow addition of applicability information as CPE information.

To allow for organization-specific applicability information as well as future extensions that can be carried out without issuing a new XCCDF version, XCCDF should allow an extension point

<applicability> 
    <applicability_info system=’…’> …
    </applicability_info> 
</applicability>

or similar that can be specified for benchmarks, groups, rules, fixes, checks.

[DavidRies]

This makes sense in the abstract, but I'm having trouble imagining how it would work. Here are a couple immediate questions I have:

1. Should org-specific settings be limited to tailorings?

Generally speaking, SCAP content does not include organization-specific guidance/settings outside of that which can be tailored. Benchmarks are generally designed to be used and not edited. The format doesn't support editing very well (all sorts of version control issues).

2. Would engines be able to support this?

Another issue is how would an engine support this? If you added your own system and for applicability and your own applicability tests/ids... you would have to write your own engine to support it.

[bgro]

My two cents:

ad 1 if we have extensibility akin to the system mechanism for checks and fixes, then I think we cannot restrict org-specific settings to tailoring, since we do not know what org-specific settings will be included.

ad 2 True, the same holds for the system mechanism for checks and fixes: no tool other than oscap is currently able to process the fixes included in the Compliance-as-Code baselines. We can lament that fact, but there it is. Conversely, you may argue that providing a bit of freedom in what is put into XCCDF may lead to extensions that eventually gain community support and are standardized.

Also, writing your own engine may not always be a show-stopper. I could

• add additional information in a structured way, which I want to present to readers in a PDF/HTML rendering -- for that, all I have to do is to do some XSLT-magic that processes the XCCDF and either do the whole conversion on my own or preprocess the XCCDF (by inserting human-readable stuff into a standard field) and hand it over to an existing tool. One example would be "role" information: who is responsible for a certain rule?

• add additional information which I then use for processing and generating custom profiles in a way that is currently not possible with the profiling mechanism. Again, the tooling I require is then restricted to XSLT (or similar).

It was somebody from MITRE, who said during one of the workshops that there is not much 'X' in 'XCCDF'. Proving more extensibility does have its challenges, but I think well defined extensibility is a lot better than forcing organizations to shoehorn information they want to add in some crazy way (witness IASE's use of HTML-encoded XML tags within the description section) into the format.

[DavidRies]

I'm having trouble understanding this one. I keep thinking that if an end-user organization wants to use their own applicability system and they were to add this into the XCCDF... it wouldn't work unless they wrote their own code to handle it. And, if an organization is using their applicability system and their own engine--that's fine. Anyone can do that today (and people do!). But, it doesn't seem appropriate for standardization because it doesn't facilitate interoperability.

I think I might be missing the bigger picture. Is this a need that you or your customers have? Can you provide some content (or examples) of the problem this would solve and how it could be used?

[solind]

It might be helpful if you can explain what this would add over and above what's possible in XCCDF already using platforms. With platforms, you can already use a CPE list and/or benchmark-defined platform specification, with logical tests combining checks that can reference non-OVAL systems, such as OCIL or SCE. You can tie platforms to benchmarks, profiles, groups, rules, etc. This has an applicability-specifying effect in the evaluation already.

[bgro]

Here are the slides presented during the 2020-01-15 Telco
scap_v2_siemens_extensible_applicability_usecases.pdf

[djhaynes]

Bernd prepared slides on applicability. He mentioned that there is a need for extensibility with respect to applicability including target audience for the rules as well as the asset classification based on confidentiality, integrity, and availability (CIA).

• There was some confusion around the use of the word “applicability” here. It was clarified that “applicability” may not be the correct term and this is really just metadata

• It was noted that this data could go in the XCCDF metadata construct which is extensible to support any XML element.

• It was explained that the use case around this is if you look at the Windows Server benchmark, the rules are human readable in the title. There would be a machine-readable part to indicate which rules apply for a domain controller versus a member server. Then depending on which version, it would generate the appropriate profile in a pre-processing step. Otherwise, there would be too many profiles. It was mentioned that profiles were designed for this and you could add a platform tag to the profile that links to an OVAL test that determines applicability.

• It was asked why you couldn’t use profiles for this as this is what they were designed for. It was explained how profiles are hard to maintain and it is easier to maintain this information in the rule. Then, whoever writes the rules can back-trace information to the profiles.

• It was pointed out that Dublin Core might have constructs that would address Bernd’s use cases.

• There was agreement that the group should look at using the metadata construct and see if that solves this use case as well as look at what fields should be standardized around because they are more broadly applicable. It was also mentioned that the OVAL Repository metadata could be used as a guide for this since it represents custom content in the OVAL metadata construct. More information about the use of the OVAL Repository metadata can be found here: https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!topic/oval-xccdf-enhancements/DDFG7TPVLNo.

ACTION: Bernd will look into the XCCDF metadata construct and see if it fits his needs.

[bgro]

As Section 6.2.4 of the XCCDF 1.2 standard states (see below): Metadata elements can be used in a benchmark, group, rule, profile, value (also in test results, etc.). Furthermore the specifications of these elements show, that an arbitrary number of consecutive metadata sections can be used.

So indeed, it turns out that I had overlooked this possibility and could encode each of my "applicability" sections as a meta-data element and encode the "type/system" of the applicability using the xmlns declaration, something like this:

applicability:
  - system: com.siemens.cert.acp
    c: '123'
    i: '123'
    a: '123'
  - system: com.siemens.cert.scapolite.target_audience
    roles:
      - asset_manager

into

<xccdf:metadata xmlns:acp="com.siemens.cert.acp">
 <acp:c>123</acp:c>
 <acp:i>123</acp:i>
 <acp:a>123</acp:a>
</xccdf:metadata>
<xccdf:metadata xmlns:ta="com.siemens.cert.scapolite.target_audience">
 <ta:role>asset_manager</ta:role>
</xccdf:metadata>

So, while neither the Dublin Core metadata nor the OVAL metadata does define fields that fit my purpose, that does not matter, since I can define my own metadata schemata.

Thus: I am fine with using xccdf:metadata for my purpose and thank the community here for pointing out to me what I should have discovered myself :flushed:

The questions that, I think, remain to consider:

1) Whether the section should be reworded in order to provide clearer guidance on what metadata could be used for (cf. the encoding of what looks a lot like metadata in DISA's encoded XML-elements as part of the description section)

2) Whether there are use cases that should be standardized (where?) and maybe presented as example in this section.

3) Section 6.2.4 is rather "strict" about what metadata may and may not be used for. Particularly, metadata should not change processing of XCCDF content for carrying out an assessment. I understand the thinking behind this requirement, and if I use XCCDF for the purposes of my own constituency, I am free to ignore it, I guess. But maybe a consideration could be added that there may be community-specific processing by community-specific tooling that makes use of XCCDF metadata actually is a valid usecase?

As a reminder, here is the current wording of the metadata section in the current XCCDF standard:

6.2.4\<xccdf:metadata>Element

XCCDF supports inclusion of metadata about a document, including title, name of author(s), organization providing the guidance, version number, release date, update URL, and a description. This is particularly useful for facilitating the discovery and retrieval of XCCDF checklists from public repositories.

When used, the \<xccdf:metadata> element shallcontain document metadata expressed in XML. The metadata element can appear one or more times as a child of the \<xccdf:Benchmark>, \<xccdf:Rule>, \<xccdf:Group>, \<xccdf:Value>, \<xccdf:Profile>, \<xccdf:TestResult>, \<xccdf:rule-result>, and\<xccdf: Tailoring > elements. The _\<xccdf:Benchmark>element SHOULD contain metadata information formatted using the Dublin Core Metadata Initiative (DCMI) Simple DC Element specification, as described in [DCES] and [DCXML]. Benchmark consumersshould be prepared to process Dublin Core metadata in the \<xccdf:metadata>_ element. An example of the Dublin Core format is shown below.

\<xccdf:metadata xmlns:dc="http://purl.org/dc/elements/1.1/">\<dc:title>Security Benchmark for Ethernet Hubs\</dc:title>\<dc:creator>James Smith\</dc:creator>\<dc:publisher>Center for Internet Security\</dc:publisher>\<dc:subject>network security for layer 2 devices\</dc:subject>\</xccdf:metadata>

Elements that support the \<xccdf:metadata> element MAY use any desired metadata format; for \<xccdf:Benchmark>, this is in addition to the Dublin Core recommendations already mentioned. Any XML metadata structures, including ad hoc structures, may be included in an_\<xccdf:metadata>_element. Because any structures can appear in this field, authors should tag metadata withthe _xmlnsprefix [XMLNAME] and, if available, the@xsi:schemaLocation_ attribute in order to identify the metadata structure utilized.Metadata should comply with existing commercial or government metadata specifications to allow benchmarks to be discovered and indexed.

Metadata is a powerful feature for authors. However, XCCDF puts some limits on the use of metadata:

• Metadata shOULD not replace the functionality of existing fields within XCCDF. If the information matches the common use of some other XCCDF field, the information must appear in that XCCDF field. It MAY also appear in the \<xccdf:metadata> element.
• Metadata shall not change the processing model as outlined in Section 7. Benchmark consumer products shall perform XCCDF assessments in the same way regardless of the presence of metadata. Metadata may still be used to support assessment features that are outside the purview of XCCDF—for example, to hold post-processing instructions to be performed on the completed XCCDF resultsor to display additional information to the user before or during the assessment.
• Metadata SHOULD not alter the character content of the XCCDF properties used to generate output during document generation. Contents of the \<xccdf:metadata> element MAY be added to the output above and beyond the XCCDF properties. Metadata may contain instructions that cause different stylistic conventions to be adopted in the conversion of an XCCDF document to prose.

[solind]

Hi @bgro,

I don't see any problem stuffing machine-readable information into metadata fields that could be used to govern the creation of xccdf:Profile elements (i.e., Tailorings). Then it would be the profile/tailoring that governs the evaluation process, as opposed to the metadata.

To me such a solution fits both the letter and spirit of section 6.2.4 of the XCCDF specification, as well as your use-case!

[djhaynes]

Bernd: We may want to consider rewording the text in the metadata element.

David Ries: Maybe we can add in a sentence and a couple of examples to help people use this feature going forward.

[djhaynes]

@bgro and @DavidRies, can you work together to come up with draft text for updates to the metadata element? Then, we can get feedback from the community at the workshop.

[bgro]

I will fork the Markdown-version of the current XCCDF content and make a proposal of what kind of guidance could be added regading this issue.

[bgro]

Please refer to

https://github.com/scapcommunity/XCCDF/pull/30/files

in order to view the suggestion of how to modify the XCCDF spec.

[DavidRies]

This looks good to me. This clarification is helpful.

[bgro]

To my understanding, this issue is DONE and ready for NISTification