The SCAP community has periodically discussed adding clarity to the applicability declarations within XCCDF (http://scap.nist.gov/events/2011/saddsp/presentations/Jim_Ronayne-SCAP_language.pdf). As we experimented with using OCIL on an enterprise scale the idea of applicability became more important. If questionnaires are going to be distributed to various individuals the subject of each questionnaire must be clearly defined. By having a clearly defined and machine-readable expression of the intended subject a machine can automatically direct the questionnaires to the appropriate respondent (assuming it already has a list of respondents per subject system). Although this feature is useful when working with OCIL it also has potential benefits when used with OVAL checks. Discussions at previous developer days conferences have suggested wide agreement that more machine-readable applicability definitions are desirable (regardless of whether they are used for automatic selection). SCAP 1.2 took the first steps toward better applicability statements by expanding the platform-specification element to include OVAL and OCIL checks. This proposal seeks to expand the definition even more.
This proposal suggests modifying the cpe-language specification (NISTIR 7698). If these changes are adopted it should be considered whether this specification should be removed from the set of CPE specifications and allowed to stand on its own as a general security automation applicability language (presumably renamed to indicate the generalization). Although we are suggesting additions to what is current a CPE specification nothing in this proposal should be taken to suggest any changes to CPE itself. CPE identifiers would continue to be used as before and this proposal does not suggest changing the scope of what is an identifier.
The primary change recommended by this proposal is the addition of a new complex type in the language. This type, “DataFactRefType”, would be used to express an attribute of an applicable subject. These attributes would usually be items that would be collected by non-SCAP tools. It is different from the other FactRefs in that it is not a standard identifier (CPEFactRefType) and it is not a reference to a check (CheckFactRefType). Data-fact-ref would be included under LogicalTestType so it can be used in logical expressions.
<xsd:any minOccurs="0" maxOccurs="unbounded" processContents="lax" namespace="##other"/>
This addition will allow other schemas to be used to define characteristics of subjects that should be targeted by the benchmark, profile, group, or rule. These characteristics will be more readable for both humans and automated systems. They may also enable automated processing of benchmarks, profiles, groups, and rules.
Similar to the routing proposal, it is expected that it will be better not to initially standardize on the actual attributes that will be used in this extension. Instead, content authors should declare what schema they are using for all their content and interested consumers should decide whether to process those values. The SCAP program may require vendors to support some specific schemas. Tools that encounter a schema they do not understand must assume the item applies and continue to process the content. Eventually SCAP could have an asset management validation that would ensure compliance checking tools could gather asset properties from an asset management system.
SCAP already includes an AI schema for indentifying assets. The asset working group has discussed developing an asset properties schema to include attributes that are not necessarily identifying features of the asset. Work has not yet started on this specification but it is expected that this schema would be the primary source (other than CPE, OVAL, and OCIL checks) for expressing applicability statements in the applicability language. Initial discussions on this topic included consideration of using existing schema such as CIM.
While waiting for the development of the asset_properties specification it is suggested that some attributes from the original DoD ARF 0.41 schema be adopted. The precise meaning of these terms must be clearly indicated. This schema will be proposed separately but includes:
FIPS199 Confidentiality Level (H,M,L)
FIPS199 Integrity Level (H,M,L)
FIPS199 Availability Level (H,M,L)
Function (domain controller, member server, web server, email server, …)
Role (workstation, server, network device, infrastructure)
Asset Type (person, organization, system, software, database, network, service, data, computing device, circuit, website)
MAC Level (1,2,3)
Confidentiality Level (Public, Sensitive, Classified)
Network Zone (Internet facing, DMZ, internal)
Many of these attributes are focused on computing device types of asset but it is expected that other schemas will be developed to better define attributes of other asset types.
These attributes are meant to more precisely define the applicability of a given item (i.e., exclude more potential target assets). The primary use case is for XCCDF items but these features may have use in other applications such as remediation as well. Inclusion of this data in the applicability statement will allow systems to identify differences in content without depending on data in titles (e.g., “domain controller” version of a configuration guide). Many of these attributes cannot be automatically discovered on subject systems so automated processing would be dependent on a reliable data source using the same schema. The simple attribute of “asset type” will be particularly useful in benchmarks that require OCIL because it can instruct a respondent on the scope of his answers.
This proposal also recommends changing the definition of FactRefType to include identifiers from any recognized system. Instead of making the name attribute on FactRefType point to a CPE namePattern the type would be a string and an additional attribute would be added for the system (expressed as anyURI). This would allow a factRef to be a CPE, CVE, CCE, or any other standard identifier. Although these expressions wouldn’t likely be used in XCCDF documents they may be helpful in other documents or references as a way to express certain conditions.
Here is an example using this schema. The platform-specification would be referenced in the appropriate platform tags in an XCCDF document.
Rules that are not checked because of platform-specification processing will be returned with a result of notapplicable. Since the applicability rules will be more complex and dependent on external data sources it is more important for platform-specification results to be included in SCAP results. The community has previous declined to include applicability statement results in SCAP results but adding additional data from outside sources should be reason to reconsider this decision. Initially it may be easiest to establish the common practice of including any facts used in meeting a data-fact-ref in a platform specification in the fact element of TestResult (XCCDF results). This could be standardized by using a name of the form “urn:scap:platform-specification:data-fact-ref:asset_property:mac_level” with a value of “1” (for example). Future updates should include the source and date of the data. More formal inclusion of these results in XCCDF or SCAP results should be considered in future revisions of the specifications.
|Free forum by Nabble||Edit this page|