Security Automation and Continuous Monitoring M. Cokus Internet-Draft D. Haynes Intended status: Informational D. Rothenberg Expires: March 11, 2017 The MITRE Corporation J. Gonzalez Department of Homeland Security September 7, 2016 OVAL(R) Common Model draft-cokus-sacm-oval-common-model-01 Abstract This document specifies Version 5.11.1 of the Common Model of the Open Vulnerability and Assessment Language (OVAL). It contains definitions of the constructs and enumerations that are used throughout the other core models in the OVAL Language both eliminating duplication and facilitating reuse. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 11, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must Cokus, et al. Expires March 11, 2017 [Page 1] Internet-Draft OVAL Common Model September 2016 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. GeneratorType . . . . . . . . . . . . . . . . . . . . . . . . 3 3. MessageType . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. CheckEnumeration . . . . . . . . . . . . . . . . . . . . . . 5 5. ClassEnumeration . . . . . . . . . . . . . . . . . . . . . . 6 6. SimpleDatatypeEnumeration . . . . . . . . . . . . . . . . . . 7 7. ComplexDatatypeEnumeration . . . . . . . . . . . . . . . . . 10 8. DatatypeEnumeration . . . . . . . . . . . . . . . . . . . . . 11 9. ExistenceEnumeration . . . . . . . . . . . . . . . . . . . . 11 10. FamilyEnumeration . . . . . . . . . . . . . . . . . . . . . . 12 11. MessageLevelEnumeration . . . . . . . . . . . . . . . . . . . 14 12. OperationEnumeration . . . . . . . . . . . . . . . . . . . . 14 13. OperatorEnumeration . . . . . . . . . . . . . . . . . . . . . 16 14. Definition, Test, Object, State, and Variable Identifiers . . 16 14.1. DefinitionIDPattern . . . . . . . . . . . . . . . . . . 16 14.2. ObjectIDPattern . . . . . . . . . . . . . . . . . . . . 16 14.3. StateIDPattern . . . . . . . . . . . . . . . . . . . . . 16 14.4. TestIDPattern . . . . . . . . . . . . . . . . . . . . . 17 14.5. VariableIDPattern . . . . . . . . . . . . . . . . . . . 17 15. ItemIDPattern . . . . . . . . . . . . . . . . . . . . . . . . 17 16. EmptyStringType . . . . . . . . . . . . . . . . . . . . . . . 17 17. NonEmptyStringType . . . . . . . . . . . . . . . . . . . . . 17 18. Any . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 19. Signature . . . . . . . . . . . . . . . . . . . . . . . . . . 17 20. OVAL Common Model Schema . . . . . . . . . . . . . . . . . . 18 21. Intellectual Property Considerations . . . . . . . . . . . . 59 22. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 59 23. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59 24. Security Considerations . . . . . . . . . . . . . . . . . . . 59 25. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 60 25.1. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . 60 26. References . . . . . . . . . . . . . . . . . . . . . . . . . 60 26.1. Normative References . . . . . . . . . . . . . . . . . . 60 26.2. Informative References . . . . . . . . . . . . . . . . . 61 Appendix A. Terms and Acronyms . . . . . . . . . . . . . . . . . 61 Appendix B. Regular Expression Support . . . . . . . . . . . . . 63 B.1. Supported Regular Expression Syntax . . . . . . . . . . . 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 68 Cokus, et al. Expires March 11, 2017 [Page 2] Internet-Draft OVAL Common Model September 2016 1. Introduction The Open Vulnerability and Assessment Language (OVAL) [OVAL-WEBSITE] is an international, information security community effort to standardize how to assess and report upon the machine state of systems. For over ten years, OVAL has been developed in collaboration with any and all interested parties to promote open and publicly available security content and to standardize the representation of this information across the entire spectrum of security tools and services. OVAL provides an established framework for making assertions about a system's state by standardizing the three main steps of the assessment process: representing the current machine state; analyzing the system for the presence of the specified machine state; and representing the results of the assessment which facilitates collaboration and information sharing among the information security community and interoperability among tools. This draft is part of the OVAL contribution to the IETF SACM WG and is intended to serve as a starting point for its endpoint posture assessment data modeling needs. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. GeneratorType The GeneratorType provides a structure for recording information about how and when the OVAL Content was created, for what version of the OVAL Language it was created, and any additional information at the discretion of the content author. Cokus, et al. Expires March 11, 2017 [Page 3] Internet-Draft OVAL Common Model September 2016 +-----------------+----------+-------+------------------------------+ | Property | Type | Count | Description | +-----------------+----------+-------+------------------------------+ | product_name | string | 0..1 | Entity that generated the | | | | | OVAL Content. This value | | | | | SHOULD be expressed as a CPE | | | | | Name. | | | | | | | product_version | string | 0..1 | Version of the entity that | | | | | generated the OVAL Content. | | | | | | | schema_version | double | 1 | Version of the OVAL Language | | | | | that the OVAL Content is | | | | | expected to validate | | | | | against. | | | | | | | timestamp | DateTime | 1 | The date and time of when | | | | | the OVAL Content, in its | | | | | entirety, was originally | | | | | generated. This value is | | | | | independent of the time at | | | | | which any of the components | | | | | of the OVAL Content were | | | | | created. | | | | | | | extension_point | any | 0..* | An extension point that | | | | | allows for the inclusion of | | | | | any additional information | | | | | associated with the | | | | | generation of the OVAL | | | | | Content. | +-----------------+----------+-------+------------------------------+ Table 1: GeneratorType Construct The extension_point property is not considered a part of the OVAL Language proper, but rather, an extension point that allows organizations to expand the OVAL Language to better suit their needs. 3. MessageType The MessageType construct is used to relay messages from tools at run-time. The decision of how to use these messages is left to the tool developer as an implementation detail based upon the context in which the message is used. Cokus, et al. Expires March 11, 2017 [Page 4] Internet-Draft OVAL Common Model September 2016 +----------+-------------------------+-------+----------------------+ | Property | Type | Count | Description | +----------+-------------------------+-------+----------------------+ | level | MessageLevelEnumeration | 0..1 | The level of the | | | | | message. Default | | | | | Value: 'info' | | | | | | | message | string | 1 | The actual message | | | | | relayed from the | | | | | tool. | +----------+-------------------------+-------+----------------------+ Table 2: MessageType Construct 4. CheckEnumeration The CheckEnumeration enumeration defines the acceptable values that can be used to determine the final result of an evaluation based on how many of the individual results that make up an evaluation are true. This enumeration is used in different contexts throughout the OVAL Language. See the Check Enumeration Evaluation section of [I- D.draft-haynes-sacm-oval-processing-model], for more information on how this enumeration is used. Cokus, et al. Expires March 11, 2017 [Page 5] Internet-Draft OVAL Common Model September 2016 +---------+---------------------------------------------------------+ | Value | Description | +---------+---------------------------------------------------------+ | all | The final result is 'true' only if all of the | | | individual results under consideration are 'true'. | | | | | at | The final result is 'true' only if one or more of the | | least | individual results under consideration are 'true'. | | one | | | | | | none | DEPRECATED (5.3) In Version 5.3 of the OVAL Language, | | exist | the checking of existence and state were separated into | | | two distinct checks CheckEnumeration (state) and | | | ExistenceEnumeration (existence). Since | | | CheckEnumeration is now used to specify how many | | | objects should satisfy a given state for a test to | | | return true, and no longer used for specifying how many | | | objects must exist for a test to return true, a value | | | of 'none exist' is no longer needed. The final result | | | is 'true' only if zero of the individual results under | | | consideration are 'true'. | | | | | none | The final result is 'true' only if zero of the | | satisfy | individual results under consideration are 'true'. | | | | | only | The final result is 'true' only if one of the | | one | individual results under consideration is 'true'. | +---------+---------------------------------------------------------+ Table 3: CheckEnumeration Construct 5. ClassEnumeration The ClassEnumeration defines the different classes of OVAL Definitions where each class specifies the overall intent of the OVAL Definition. Cokus, et al. Expires March 11, 2017 [Page 6] Internet-Draft OVAL Common Model September 2016 +---------------+---------------------------------------------------+ | Value | Description | +---------------+---------------------------------------------------+ | compliance | This class describes OVAL Definitions that check | | | to see if a system's state is compliant with a | | | specific policy. An evaluation result of 'true', | | | for this class of OVAL Definitions, indicates | | | that a system is compliant with the stated | | | policy. | | | | | inventory | This class describes OVAL Definitions that check | | | to see if a piece of software is installed on a | | | system. An evaluation result of 'true', for this | | | class of OVAL Definitions, indicates that the | | | specified software is installed on the system. | | | | | miscellaneous | This class describes OVAL Definitions that do not | | | belong to any of the other defined classes. | | | | | patch | This class describes OVAL Definitions that check | | | to see if a patch should be installed on a | | | system. An evaluation result of 'true', for this | | | class of OVAL Definitions, indicates that the | | | specified patch should be installed on the | | | system. | | | | | vulnerablity | This class describes OVAL Definitions that check | | | to see if the system is in a vulnerable state. An | | | evaluation result of 'true', for this class of | | | OVAL Definitions, indicates that the system is in | | | a vulnerable state. | +---------------+---------------------------------------------------+ Table 4: ClassEnumeration Construct 6. SimpleDatatypeEnumeration The SimpleDatatypeEnumeration defines the legal simple datatypes that are used to describe the values in the OVAL Language. Simple datatypes are those that are based upon a string representation without additional structure. Each value in the SimpleDatatypeEnumeration has an allowed set of operations listed in the table below. These operations are based upon the full list of operations which are defined in the OperationEnumeration. +-------------------+-----------------------------------------------+ | Value | Description | +-------------------+-----------------------------------------------+ Cokus, et al. Expires March 11, 2017 [Page 7] Internet-Draft OVAL Common Model September 2016 | binary | Data of this type conforms to the W3C | | | Recommendation for hex-encoded binary data | | | [W3C-HEX-BIN]. Valid operations are: "equals" | | | and "not equal". | | | | | boolean | Data of this type conforms to the W3C | | | Recommendation for boolean data | | | [W3C-BOOLEAN]. Valid operations are: "equals" | | | and "not equal". | | | | | evr_string | Data of this type conforms to the format | | | EPOCH:VERSION-RELEASE and comparisons | | | involving this type MUST follow the algorithm | | | of librpm's rpmvercmp() function. Valid | | | operations are: "equals", "not equal", | | | "greater than", "greater than or equal", | | | "less than", and "less than or equal". | | | | | debian_evr_string | Data of this type conforms to the format | | | EPOCH:UPSTREAM_VERSION-DEBIAN_REVISION and | | | comparisons involving this datatype should | | | follow the algorithm outlined in Chapter 5 of | | | the "Debian Policy Manual" | | | [DEBIAN-POLICY-MANUAL]. An implementation of | | | this is the cmpversions() function in dpkg's | | | enquiry.c. Valid operations are: "equals", | | | "not equal", "greater than", "greater than or | | | equal", "less than", and "less than or | | | equal". | | | | | fileset_revision | Data of this type conforms to the version | | | string related to filesets in HP-UX. An | | | example would be 'A.03.61.00'. Valid | | | operations are: "equals", "not equal", | | | "greater than", "greater than or equal", | | | "less than", and "less than or equal". | | | | | float | Data of this type conforms to the W3C | | | Recommendation for float data [W3C-FLOAT]. | | | Valid operations are: "equals", "not equal", | | | "greater than", "greater than or equal", | | | "less than", and "less than or equal". | | | | | ios_version | Data of this type conforms to Cisco IOS Train | | | strings. These are in essence version strings | | | for IOS. Please refer to Cisco's IOS | | | Reference Guide for information on how to | | | compare different Trains as they follow a | Cokus, et al. Expires March 11, 2017 [Page 8] Internet-Draft OVAL Common Model September 2016 | | very specific pattern. [CISCO-IOS] Valid | | | operations are: "equals", "not equal", | | | "greater than", "greater than or equal", | | | "less than", and "less than or equal". | | | | | int | Data of this type conforms to the W3C | | | Recommendation for integer data [W3C-INT]. | | | Valid operations are: "equals", "not equal", | | | "greater than", "greater than or equal", | | | "less than", "less than or equal", bitwise | | | and" and "bitwise or". | | | | | ipv4_address | The ipv4_address datatype represents IPv4 | | | addresses and IPv4 address prefixes. Its | | | value space consists of the set of ordered | | | pairs of integers where the first element of | | | each pair is in the range [0,2^32) (the | | | representable range of a 32-bit unsigned | | | int), and the second is in the range [0,32]. | | | The first element is an address, and the | | | second is a prefix length. The lexical space | | | is dotted-quad CIDR-like notation ('a.b.c.d' | | | where 'a', 'b', 'c', and 'd' are integers | | | from 0-255), optionally followed by a slash | | | ('/') and either a prefix length (an integer | | | from 0-32) or a netmask represented in the | | | dotted-quad notation described previously. | | | Examples of legal values are '192.0.2.0', | | | '192.0.2.0/32', and | | | '192.0.2.0/255.255.255.255'. Additionally, | | | leading zeros are permitted such that | | | '192.0.2.0' is equal to '192.000.002.000'. If | | | a prefix length is not specified, it is | | | implicitly equal to 32. [RFC791] Valid | | | operations are: "equals", "not equal", | | | "greater than", "greater than or equal", | | | "less than", "less than or equal", "subset | | | of", and "superset of". | | | | | ipv6_address | The ipv6_address datatype represents IPv6 | | | addresses and IPv6 address prefixes. Its | | | value space consists of the set of ordered | | | pairs of integers where the first element of | | | each pair is in the range [0,2^128) (the | | | representable range of a 128-bit unsigned | | | int), and the second is in the range [0,128]. | | | The first element is an address, and the | | | second is a prefix length. The lexical space | Cokus, et al. Expires March 11, 2017 [Page 9] Internet-Draft OVAL Common Model September 2016 | | is CIDR notation given in IETF specification | | | RFC 4291 for textual representations of IPv6 | | | addresses and IPv6 address prefixes (see | | | sections 2.2 and 2.3). If a prefix-length is | | | not specified, it is implicitly equal to 128. | | | [RFC4291] Valid operations are: "equals", | | | "not equal", "greater than", "greater than or | | | equal", "less than", "less than or equal", | | | "subset of", and "superset of". | | | | | string | Data of this type conforms to the W3C | | | Recommendation for string data [W3C-STRING]. | | | Valid operations are: "equals", "not equal", | | | "case insensitive equals", "case insensitive | | | not equal", and "pattern match". | | | | | version | Data of this type represents a value that is | | | a hierarchical list of non-negative integers | | | separated by a single character delimiter. | | | Any single non-number character may be used | | | as a delimiter and the delimiter may vary | | | between component of a given version string. | | | Valid operations are: "equals", "not equal", | | | "greater than", "greater than or equal", | | | "less than", and "less than or equal". | +-------------------+-----------------------------------------------+ Table 5: SimpleDatatypeEnumeration Construct 7. ComplexDatatypeEnumeration The ComplexDatatypeEnumeration defines the complex datatypes that are supported the OVAL Language. These datatypes describe the values with some structure beyond simple string like content. One simple example of a complex dataytype is an address. The address might be composed of a street, city, state, and zip code. These for field together comprise the complete address. Each value in the ComplexDatatypeEnumeration has an allowed set of operations listed in the table below. These operations are based upon the full list of operations which are defined in the OperationEnumeration. Cokus, et al. Expires March 11, 2017 [Page 10] Internet-Draft OVAL Common Model September 2016 +--------+----------------------------------------------------------+ | Value | Description | +--------+----------------------------------------------------------+ | record | Data of this type represents a collection of named | | | fields and values. Valid operations are: * equals | +--------+----------------------------------------------------------+ Table 6: ComplexDatatypeEnumeration Construct 8. DatatypeEnumeration The DatatypeEnumeration defines the complete set of all valid datatypes. This set is created as the union of the SimpleDatatypeEnumeration and the ComplexDatatypeEnumeration. This type is provided for convenience when working with the OVAL Language. 9. ExistenceEnumeration The ExistenceEnumeration defines the acceptable values that can be used to specify the expected number of components under consideration must exist. +---------------------+---------------------------------------------+ | Value | Description | +---------------------+---------------------------------------------+ | all_exist | The final existence result is 'true' only | | | if all of the components under | | | consideration exist. | | | | | any_exist | The final existence result is 'true' only | | | if zero or more of the components under | | | consideration exist. | | | | | at_least_one_exists | The final existence result is 'true' only | | | if one or more of the components under | | | consideration exist. | | | | | none_exist | The final existence result is 'true' only | | | if zero of the components under | | | consideration exist. | | | | | only_one_exists | The final existence result is 'true' only | | | if one of the components under | | | consideration exist. | +---------------------+---------------------------------------------+ Table 7: ExistenceEnumeration Construct Cokus, et al. Expires March 11, 2017 [Page 11] Internet-Draft OVAL Common Model September 2016 10. FamilyEnumeration The FamilyEnumeration defines the high-level family that an operating system belongs to. Cokus, et al. Expires March 11, 2017 [Page 12] Internet-Draft OVAL Common Model September 2016 +-----------------------+-------------------------------------------+ | Value | Description | +-----------------------+-------------------------------------------+ | android | The android value describes the Android | | | mobile operating system. | | | | | asa | The asa value describes the Cisco ASA | | | security devices. | | | | | apple_ios | The apple_ios value describes the iOS | | | mobile operating system. | | | | | catos | This value describes Cisco CatOS | | | operating systems. | | | | | ios | This value describes Cisco IOS operating | | | systems. | | | | | iosxe | This value describes Cisco IOS XE | | | operating systems. | | | | | junos | This value describes Juniper JunOS | | | operating systems. | | | | | macos | This value describes Apple Mac OS | | | operating systems. | | | | | pixos | This value describes Cisco PIX operating | | | systems. | | | | | undefined | This value is reserved for operating | | | systems where the high-level family is | | | not available in the current enumeration. | | | | | unix | This value describes UNIX operating | | | systems. | | | | | vmware_infrastructure | This value describes the VMWare | | | Infrastructure. | | | | | windows | This value describes Microsoft Windows | | | operating systems. | +-----------------------+-------------------------------------------+ Table 8: FamilyEnumeration Construct Cokus, et al. Expires March 11, 2017 [Page 13] Internet-Draft OVAL Common Model September 2016 11. MessageLevelEnumeration The MessageLevelEnumeration defines the different levels that can be associated with a message. +---------+---------------------------------------------------------+ | Value | Description | +---------+---------------------------------------------------------+ | debug | This level is reserved for messages that should only be | | | displayed when the tool is run in verbose mode. | | | | | error | This level is reserved for messages where an error was | | | encountered, but the tool could continue execution. | | | | | fatal | This level is reserved for messages where an error was | | | encountered and the tool could not continue execution. | | | | | info | This level is reserved for messages that contain | | | informational data. | | | | | warning | This level is reserved for messages that indicate that | | | a problem may have occurred. | +---------+---------------------------------------------------------+ Table 9: MessageLevelEnumeration Construct 12. OperationEnumeration The OperationEnumeration defines the acceptable operations in the OVAL Language. The precise meaning of an operation is dependent on the datatype of the values under consideration. See the OVAL Entity Datatype and Operation Evaluation section of [I-D.draft-haynes-sacm- oval-processing-model] for additional information. +-------------+-----------------------------------------------------+ | Value | Description | +-------------+-----------------------------------------------------+ | equals | This operation evaluates to 'true' if the actual | | | value is equal to the stated value. | | | | | not equal | This operation evaluates to 'true' if the actual | | | value is not equal to the stated value. | | | | | case | This operation evaluates to 'true' if the actual | | insensitive | value is equal to the stated value when performing | | equals | a case insensitive comparison. | | | | | case | This operation evaluates to 'true' if the actual | Cokus, et al. Expires March 11, 2017 [Page 14] Internet-Draft OVAL Common Model September 2016 | insensitive | value is not equal to the stated value when | | not equal | performing a case insensitive comparison. | | | | | greater | This operation evaluates to 'true' if the actual | | than | value is greater than the stated value. | | | | | less than | This operation evaluates to 'true' if the actual | | | value is less than the stated value. | | | | | greater | This operation evaluates to 'true' if the actual | | than or | value is greater than or equal to the stated value. | | equal | | | | | | less than | This operation evaluates to 'true' if the actual | | or equal | value is less than or equal to the stated value. | | | | | bitwise and | This operation evaluates to 'true' if the result of | | | the BITWISE AND operation between the binary | | | representation of the stated value and the actual | | | value is equal to the binary representation of the | | | stated value. This operation is used to determine | | | if a specific bit in a value is set. | | | | | bitwise or | This operation evaluates to 'true' if the result of | | | the BITWISE OR operation between the binary | | | representation of the stated value and the actual | | | value is equal to the binary representation of the | | | stated value. This operation is used to determine | | | if a specific bit in a value is not set. | | | | | pattern | This operation evaluates to 'true' if the actual | | match | value matches the stated regular expression. The | | | OVAL Language supports a common subset of the Perl | | | 5 Compatible Regular Expression Specification. | | | | | subset of | This operation evaluates to 'true' if the actual | | | set is a subset of the stated set. | | | | | superset of | This operation evaluates to 'true' if the actual | | | set is a superset of the stated set. | +-------------+-----------------------------------------------------+ Table 10: OperationEnumeration Construct Cokus, et al. Expires March 11, 2017 [Page 15] Internet-Draft OVAL Common Model September 2016 13. OperatorEnumeration The OperatorEnumeration defines the acceptable logical operators in the OVAL Language. See the Operator Enumeration Evaluation section of [I-D.draft-haynes-sacm-oval-processing-model] for additional information. +-------+-----------------------------------------------------------+ | Value | Description | +-------+-----------------------------------------------------------+ | AND | This operator evaluates to 'true' only if every argument | | | is 'true'. | | | | | ONE | This operator evaluates to 'true' only if one argument is | | | 'true'. | | | | | OR | This operator evaluates to 'true' only if one or more | | | arguments are 'true'. | | | | | XOR | This operator evaluates to 'true' only if an odd number | | | of arguments are 'true'. | +-------+-----------------------------------------------------------+ Table 11: OperatorEnumeration Construct 14. Definition, Test, Object, State, and Variable Identifiers 14.1. DefinitionIDPattern The DefinitionIDPattern defines the URN format associated with OVAL Definition identifiers. All OVAL Definition identifiers MUST conform to the following regular expression: oval:[A-Za-z0-9_\-\.]+:def:[1-9][0-9]* 14.2. ObjectIDPattern The ObjectIDPattern defines the URN format associated with OVAL Object identifiers. All OVAL Object identifiers MUST conform to the following regular expression: oval:[A-Za-z0-9_\-\.]+:obj:[1-9][0-9]* 14.3. StateIDPattern The StateIDPattern defines the URN format associated with OVAL State identifiers. All OVAL State identifiers MUST conform to the following regular expression: Cokus, et al. Expires March 11, 2017 [Page 16] Internet-Draft OVAL Common Model September 2016 oval:[A-Za-z0-9_\-\.]+:ste:[1-9][0-9]* 14.4. TestIDPattern The TestIDPattern defines the URN format associated with OVAL Test identifiers. All OVAL Test identifiers MUST conform to the following regular expression: oval:[A-Za-z0-9_\-\.]+:tst:[1-9][0-9]* 14.5. VariableIDPattern The VariableIDPattern defines the URN format associated with OVAL Variable identifiers. All OVAL Variable identifiers MUST conform to the following regular expression: oval:[A-Za-z0-9_\-\.]+:var:[1-9][0-9]* 15. ItemIDPattern The ItemIDPattern defines the format associated with OVAL Item identifiers. All OVAL Item identifiers are unsigned integer values. 16. EmptyStringType The EmptyStringType defines a string value with a maximum length of zero. 17. NonEmptyStringType The NonEmptyStringType defines a string value with a length greater than zero. 18. Any The Any datatype represents an abstraction that serves as the basis for other user defined datatypes. This Any datatype does not constrain its data in anyway. This type is used to allow for extension with the OVAL Language. 19. Signature The Signature type provides a structure for applying a digital signature to OVAL Content. Any binding or representation of the OVAL Language MUST specify the format and structure of this type. This type is defined in an external namespace and when referenced in this document will be prefix with the external namespace alias as follows, ext:Signature. Cokus, et al. Expires March 11, 2017 [Page 17] Internet-Draft OVAL Common Model September 2016 20. OVAL Common Model Schema The XML Schema that implements this OVAL Common Model can be found below. The following is a description of the common types that are shared across the different schemas within Open Vulnerability and Assessment Language (OVAL). Each type is described in detail and should provide the information necessary to understand what each represents. This document is intended for developers and assumes some familiarity with XML. A high level description of the interaction between these type is not outlined here. Core Common 5.11.1 4/22/2015 09:00:00 AM Copyright (C) 2010 United States Government. All Rights Reserved. The deprecated_info element is used in documenting deprecation Cokus, et al. Expires March 11, 2017 [Page 18] Internet-Draft OVAL Common Model September 2016 information for items in the OVAL Language. It is declared globally as it can be found in any of the OVAL schemas and is used as part of the appinfo documentation and therefore it is not an element that can be declared locally and based off a global type.. The element_mapping element is used in documenting which tests, objects, states, and system characteristic items are associated with each other. It provides a way to explicitly and programatically associate the test, object, state, and item definitions. Element for containing notes; can be replaced using a substitution group. The ElementMapType is used to document the association between OVAL test, object, state, and item entities. The local name of an OVAL test. Cokus, et al. Expires March 11, 2017 [Page 19] Internet-Draft OVAL Common Model September 2016 The local name of an OVAL object. The local name of an OVAL state. The local name of an OVAL item. Defines a reference to an OVAL entity using the schema namespace and element name. The target_namespace attributes indicates what XML namespace the element belongs to. If not present, the namespace is that of the document in which the ElementMapItemType instance element appears. Cokus, et al. Expires March 11, 2017 [Page 20] Internet-Draft OVAL Common Model September 2016 The DeprecatedInfoType complex type defines a structure that will be used to flag schema-defined constructs as deprecated. It holds information related to the version of OVAL when the construct was deprecated along with a reason and comment. The required version child element details the version of OVAL in which the construct became deprecated. The required reason child element is used to provide an explanation as to why an item was deprecated and to direct a reader to possible alternative structures within OVAL. The optional comment child element is used to supply additional information regarding the element's deprecated status. Cokus, et al. Expires March 11, 2017 [Page 21] Internet-Draft OVAL Common Model September 2016 The GeneratorType complex type defines an element that is used to hold information about when a particular OVAL document was compiled, what version of the schema was used, what tool compiled the document, and what version of that tool was used. Additional generator information is also allowed although it is not part of the official OVAL Schema. Individual organizations can place generator information that they feel are important and these will be skipped during the validation. All OVAL really cares about is that the stated generator information is there. The optional product_name specifies the name of the application used to generate the file. Product names SHOULD be expressed as CPE Names according to the Common Platform Enumeration: Name Matching Specification Version 2.3. The optional product_version specifies the version of the application used to generate the file. Cokus, et al. Expires March 11, 2017 [Page 22] Internet-Draft OVAL Common Model September 2016 The required schema_version specifies the version of the OVAL Schema that the document has been written in and that should be used for validation. The versions for both the Core and any platform extensions used should be declared in separate schema_version elements. The required timestamp specifies when the particular OVAL document was compiled. The format for the timestamp is yyyy-mm-ddThh:mm:ss. Note that the timestamp element does not specify when a definition (or set of definitions) was created or modified but rather when the actual XML document that contains the definition was created. For example, the document might have pulled a bunch of existing OVAL Definitions together, each of the definitions having been created at some point in the past. The timestamp in this case would be when the combined document was created. The Asset Identification specification (http://scap.nist.gov/specifications/ai/) provides a standardized way of reporting asset information across different organizations. Asset Identification Cokus, et al. Expires March 11, 2017 [Page 23] Internet-Draft OVAL Common Model September 2016 elements can hold data useful for identifying what tool, what version of that tool was used, and identify other assets used to compile an OVAL document, such as persons or organizations. To support greater interoperability, an ai:assets element describing assets used to produce an OVAL document may appear at this point in an OVAL document. The core version MUST match on all platform schema versions. One (and only one) schema_version element MUST be present and omit the platform attribute to represent the core version. Warning: The platform attribute should be set to the URI of the target namespace for this platform extension. Cokus, et al. Expires March 11, 2017 [Page 24] Internet-Draft OVAL Common Model September 2016 This platform's version () MUST match the core version being used: . The platform attribute is available to indicate the URI of the target namespace for any platform extension being included. This platform attribute is to be omitted when specifying the core schema version. The MessageType complex type defines the structure for which messages are relayed from the data collection engine. Each message is a text string that has an associated level Cokus, et al. Expires March 11, 2017 [Page 25] Internet-Draft OVAL Common Model September 2016 attribute identifying the type of message being sent. These messages could be error messages, warning messages, debug messages, etc. How the messages are used by tools and whether or not they are displayed to the user is up to the specific implementation. Please refer to the description of the MessageLevelEnumeration for more information about each type of message. The NotesType complex type is a container for one or more note child elements. Each note contains some information about the definition or tests that it references. A note may record an unresolved question about the definition or test or present the reason as to why a particular approach was taken. The CheckEnumeration simple type defines acceptable check values, which are used to determine the final result of something based on the results of individual components. When used to define the relationship between Cokus, et al. Expires March 11, 2017 [Page 26] Internet-Draft OVAL Common Model September 2016 objects and states, each check value defines how many of the matching objects (items except those with a status of does not exist) must satisfy the given state for the test to return true. When used to define the relationship between instances of a given entity, the different check values defines how many instances must be true for the entity to return true. When used to define the relationship between entities and multiple variable values, each check value defines how many variable values must be true for the entity to return true. Below are some tables that outline how each check attribute effects evaluation. The far left column identifies the check attribute in question. The middle column specifies the different combinations of individual results that the check attribute may bind together. (T=true, F=false, E=error, U=unknown, NE=not evaluated, NA=not applicable) For example, a 1+ under T means that one or more individual results are true, while a 0 under U means that zero individual results are unknown. The last column specifies what the final result would be according to each combination of individual results. Note that if the individual test is negated, then a true result is false and a false result is true, all other results stay as is. || num of individual results || check attr is || || final result is || T | F | E | U | NE | NA || --------------||-----------------------------||----------------- || 1+ | 0 | 0 | 0 | 0 | 0+ || True || 0+ | 1+ | 0+ | 0+ | 0+ | 0+ || False ALL || 0+ | 0 | 1+ | 0+ | 0+ | 0+ || Error || 0+ | 0 | 0 | 1+ | 0+ | 0+ || Unknown || 0+ | 0 | 0 | 0 | 1+ | 0+ || Not Evaluated || 0 | 0 | 0 | 0 | 0 | 1+ || Not Applicable --------------||-----------------------------||----------------- Cokus, et al. Expires March 11, 2017 [Page 27] Internet-Draft OVAL Common Model September 2016 || num of individual results || check attr is || || final result is || T | F | E | U | NE | NA || --------------||-----------------------------||----------------- || 1+ | 0+ | 0+ | 0+ | 0+ | 0+ || True || 0 | 1+ | 0 | 0 | 0 | 0+ || False AT LEAST ONE || 0 | 0+ | 1+ | 0+ | 0+ | 0+ || Error || 0 | 0+ | 0 | 1+ | 0+ | 0+ || Unknown || 0 | 0+ | 0 | 0 | 1+ | 0+ || Not Evaluated || 0 | 0 | 0 | 0 | 0 | 1+ || Not Applicable --------------||-----------------------------||----------------- || num of individual results || check attr is || || final result is || T | F | E | U | NE | NA || --------------||-----------------------------||----------------- || 1 | 0+ | 0 | 0 | 0 | 0+ || True || 2+ | 0+ | 0+ | 0+ | 0+ | 0+ || ** False ** || 0 | 1+ | 0 | 0 | 0 | 0+ || ** False ** ONLY ONE ||0,1 | 0+ | 1+ | 0+ | 0+ | 0+ || Error ||0,1 | 0+ | 0 | 1+ | 0+ | 0+ || Unknown ||0,1 | 0+ | 0 | 0 | 1+ | 0+ || Not Evaluated || 0 | 0 | 0 | 0 | 0 | 1+ || Not Applicable --------------||-----------------------------||----------------- || num of individual results || check attr is || || final result is || T | F | E | U | NE | NA || --------------||-----------------------------||----------------- || 0 | 1+ | 0 | 0 | 0 | 0+ || True || 1+ | 0+ | 0+ | 0+ | 0+ | 0+ || False NONE SATISFY || 0 | 0+ | 1+ | 0+ | 0+ | 0+ || Error || 0 | 0+ | 0 | 1+ | 0+ | 0+ || Unknown || 0 | 0+ | 0 | 0 | 1+ | 0+ || Not Evaluated || 0 | 0 | 0 | 0 | 0 | 1+ || Not Applicable --------------||-----------------------------||----------------- A value of 'all' means that a final result of true is Cokus, et al. Expires March 11, 2017 [Page 28] Internet-Draft OVAL Common Model September 2016 given if all the individual results under consideration are true. A value of 'at least one' means that a final result of true is given if at least one of the individual results under consideration is true. A value of 'none exists' means that a test evaluates to true if no matching object exists that satisfy the data requirements. 5.3 Replaced by the 'none satisfy' value. In version 5.3 of the OVAL Language, the checking of existence and state were separated into two distinct checks CheckEnumeration (state) and ExistenceEnumeration (existence). Since CheckEnumeration is now used to specify how many objects should satisfy a given state for a test to return true, and no longer used for specifying how many objects must exist for a test to return true, a value of 'none exist' is no longer needed. See the 'none satisfy' value. This value has been deprecated and will be removed in version 6.0 of the language. DEPRECATED ATTRIBUTE VALUE IN: ATTRIBUTE VALUE: A value of 'none satisfy' means that a final result of true is given if none the individual results under consideration are true. A value of 'only one' means that a final result of true is given if one and only one of the individual results under consideration are true. The ClassEnumeration simple type defines the different classes of definitions. Each class defines a certain intent regarding how an OVAL Definition is written and what that definition is describing. The specified class gives a hint about the definition so a user can know what the definition writer is trying to say. Note that the class does not make a statement about whether a true result is good or bad as this depends on the use of an OVAL Definition. These classes are also used to group definitions Cokus, et al. Expires March 11, 2017 [Page 30] Internet-Draft OVAL Common Model September 2016 by the type of system state they are describing. For example, this allows users to find all the vulnerability (or patch, or inventory, etc) definitions. A compliance definition describes the state of a machine as it complies with a specific policy. A definition of this class will evaluate to true when the system is found to be compliant with the stated policy. Another way of thinking about this is that a compliance definition is stating "the system is compliant if ...". An inventory definition describes whether a specific piece of software is installed on the system. A definition of this class will evaluate to true when the specified software is found on the system. Another way of thinking about this is that an inventory definition is stating "the software is installed if ...". The 'miscellaneous' class is used to identify definitions that do not fall into any of the other defined classes. A patch definition details the machine state of whether a patch executable should be installed. Cokus, et al. Expires March 11, 2017 [Page 31] Internet-Draft OVAL Common Model September 2016 A definition of this class will evaluate to true when the specified patch is missing from the system. Another way of thinking about this is that a patch definition is stating "the patch should be installed if ...". Note that word SHOULD is intended to mean more than just CAN the patch executable be installed. In other words, if a more recent patch is already installed then the specified patch might not need to be installed. A vulnerability definition describes the conditions under which a machine is vulnerable. A definition of this class will evaluate to true when the system is found to be vulnerable with the stated issue. Another way of thinking about this is that a vulnerability definition is stating "the system is vulnerable if ...". The SimpleDatatypeEnumeration simple type defines the legal datatypes that are used to describe the values of individual entities that can be represented in a XML string field. The value may have structure and a pattern, but it is represented as string content. The binary datatype is used to represent hex-encoded data that is in raw (non-printable) form. Cokus, et al. Expires March 11, 2017 [Page 32] Internet-Draft OVAL Common Model September 2016 This datatype conforms to the W3C Recommendation for binary data meaning that each binary octet is encoded as a character tuple, consisting of two hexadecimal digits {[0-9a-fA-F]} representing the octet code. Expected operations within OVAL for binary values are 'equals' and 'not equal'. The boolean datatype represents standard boolean data, either true or false. This datatype conforms to the W3C Recommendation for boolean data meaning that the following literals are legal values: {true, false, 1, 0}. Expected operations within OVAL for boolean values are 'equals' and 'not equal'. The evr_string datatype represents the epoch, version, and release fields as a single version string. It has the form "EPOCH:VERSION-RELEASE". Comparisons involving this datatype should follow the algorithm of librpm's rpmvercmp() function. Expected operations within OVAL for evr_string values are 'equals', 'not equal', 'greater than', 'greater than or equal', 'less than', and 'less than or equal'. The debian_evr_string datatype represents the epoch, upstream_version, and debian_revision fields, for a Debian package, as a Cokus, et al. Expires March 11, 2017 [Page 33] Internet-Draft OVAL Common Model September 2016 single version string. It has the form "EPOCH:UPSTREAM_VERSION-DEBIAN_REVISION". Comparisons involving this datatype should follow the algorithm outlined in Chapter 5 of the "Debian Policy Manual" (https://www.debian.org/doc/debian-policy/ ch-controlfields.html#s-f-Version). An implementation of this is the cmpversions() function in dpkg's enquiry.c. Expected operations within OVAL for debian_evr_string values are 'equals', 'not equal', 'greater than', 'greater than or equal', 'less than', and 'less than or equal'. The fileset_revision datatype represents the version string related to filesets in HP-UX. An example would be 'A.03.61.00'. For more information, see the HP-UX "Software Distributor Administration Guide" (http://h20000.www2.hp.com/bc/docs/ support/SupportManual/c01919399/c01919399.pdf). Expected operations within OVAL for fileset_version values are 'equals', 'not equal', 'greater than', 'greater than or equal', 'less than', and 'less than or equal'. The float datatype describes standard float data. This datatype conforms to the W3C Recommendation for float data meaning it is patterned after the IEEE single-precision 32-bit floating point type. The format consists of a decimal followed, optionally, by the character 'E' or 'e', followed by an integer exponent. The special values positive Cokus, et al. Expires March 11, 2017 [Page 34] Internet-Draft OVAL Common Model September 2016 and negative infinity and not-a-number have are represented by INF, -INF and NaN, respectively. Expected operations within OVAL for float values are 'equals', 'not equal', 'greater than', 'greater than or equal', 'less than', and 'less than or equal'. The ios_version datatype describes Cisco IOS Train strings. These are in essence version strings for IOS. Please refer to Cisco's IOS Reference Guide for information on how to compare different Trains as they follow a very specific pattern. Expected operations within OVAL for ios_version values are 'equals', 'not equal', 'greater than', 'greater than or equal', 'less than', and 'less than or equal'. The int datatype describes standard integer data. This datatype conforms to the W3C Recommendation for integer data which follows the standard mathematical concept of the integer numbers. (no decimal point and infinite range) Expected operations within OVAL for int values are 'equals', 'not equal', 'greater than', 'greater than or equal', 'less than', 'less than or equal', 'bitwise and', and 'bitwise or'. The ipv4_address datatype represents IPv4 addresses and Cokus, et al. Expires March 11, 2017 [Page 35] Internet-Draft OVAL Common Model September 2016 IPv4 address prefixes. Its value space consists of the set of ordered pairs of integers where the first element of each pair is in the range [0,2^32) (the representable range of a 32-bit unsigned int), and the second is in the range [0,32]. The first element is an address, and the second is a prefix length. The lexical space is dotted-quad CIDR-like notation ('a.b.c.d' where 'a', 'b', 'c', and 'd' are integers from 0-255), optionally followed by a slash ('/') and either a prefix length (an integer from 0-32) or a netmask represented in the dotted-quad notation described previously. Examples of legal values are '192.0.2.0', '192.0.2.0/32', and '192.0.2.0/255.255.255.255'. Additionally, leading zeros are permitted such that '192.0.2.0' is equal to '192.000.002.000'. If a prefix length is not specified, it is implicitly equal to 32. The expected operations within OVAL for ipv4_address values are 'equals', 'not equal', 'greater than', 'greater than or equal', 'less than', 'less than or equal', 'subset of', and 'superset of'. All operations are defined in terms of the value space. Let A and B be ipv4_address values (i.e. ordered pairs from the value space). The following definitions assume that bits outside the prefix have been zeroed out. By zeroing the low order bits, they are effectively ignored for all operations. Implementations of the following operations MUST behave as if this has been done. The following defines how to perform each operation for the ipv4_address datatype. Let P_addr mean the first element of ordered pair P Cokus, et al. Expires March 11, 2017 [Page 36] Internet-Draft OVAL Common Model September 2016 and P_prefix mean the second element. equals: A equals B if and only if A_addr == B_addr and A_prefix == B_prefix. not equal: A is not equal to B if and only if they don't satisfy the criteria for operator "equals". greater than: A is greater than B if and only if A_prefix == B_prefix and A_addr > B_addr. If A_prefix != B_prefix, i.e. prefix lengths are not equal, an error MUST be reported. greater than or equal: A is greater than or equal to B if and only if A_prefix == B_prefix and they satisfy either the criteria for operators "equal" or "greater than". If A_prefix != B_prefix, i.e. prefix lengths are not equal, an error MUST be reported. less than: A is less than B if and only if A_prefix == B_prefix and they don't satisfy the criteria for operator "greater than or equal". If A_prefix != B_prefix, i.e. prefix lengths are not equal, an error MUST be reported. less than or equal: A is less than or equal to B if and only if A_prefix == B_prefix and they don't satisfy the criteria for operator "greater than". If A_prefix != B_prefix, i.e. prefix lengths are not equal, an error MUST be reported. subset of: A is a subset of B if and only if every IPv4 address in subnet A is present in subnet B. In other words, A_prefix >= B_prefix and the high B_prefix bits of A_addr and B_addr are equal. superset of: A is a superset of B if and only if B is a Cokus, et al. Expires March 11, 2017 [Page 37] Internet-Draft OVAL Common Model September 2016 subset of A. The ipv6_address datatype represents IPv6 addresses and IPv6 address prefixes. Its value space consists of the set of ordered pairs of integers where the first element of each pair is in the range [0,2^128) (the representable range of a 128-bit unsigned int), and the second is in the range [0,128]. The first element is an address, and the second is a prefix length. The lexical space is CIDR notation given in IETF specification RFC 4291 for textual representations of IPv6 addresses and IPv6 address prefixes (see sections 2.2 and 2.3). If a prefix-length is not specified, it is implicitly equal to 128. The expected operations within OVAL for ipv6_address values are 'equals', 'not equal', 'greater than', 'greater than or equal', 'less than', 'less than or equal', 'subset of', and 'superset of'. All operations are defined in terms of the value space. Let A and B be ipv6_address values (i.e. ordered pairs from the value space). The following definitions assume that bits outside the prefix have been zeroed out. By zeroing the low order bits, they are effectively ignored for all operations. Implementations of the following operations MUST behave as if this has been done. The following defines how to perform each operation for the ipv6_address datatype. Let P_addr mean the first element of ordered pair P and P_prefix mean the second element. Cokus, et al. Expires March 11, 2017 [Page 38] Internet-Draft OVAL Common Model September 2016 equals: A equals B if and only if A_addr == B_addr and A_prefix == B_prefix. not equal: A is not equal to B if and only if they don't satisfy the criteria for operator "equals". greater than: A is greater than B if and only if A_prefix == B_prefix and A_addr > B_addr. If A_prefix != B_prefix, an error MUST be reported. greater than or equal: A is greater than or equal to B if and only if A_prefix == B_prefix and they satisfy either the criteria for operators "equal" or "greater than". If A_prefix != B_prefix, an error MUST be reported. less than: A is less than B if and only if A_prefix == B_prefix and they don't satisfy the criteria for operator "greater than or equal". If A_prefix != B_prefix, an error MUST be reported. less than or equal: A is less than or equal to B if and only if A_prefix == B_prefix and they don't satisfy the criteria for operator "greater than". If A_prefix != B_prefix, an error MUST be reported. subset of: A is a subset of B if and only if every IPv6 address in subnet A is present in subnet B. In other words, A_prefix >= B_prefix and the high B_prefix bits of A_addr and B_addr are equal. superset of: A is a superset of B if and only if B is a subset of A. Cokus, et al. Expires March 11, 2017 [Page 39] Internet-Draft OVAL Common Model September 2016 The string datatype describes standard string data. This datatype conforms to the W3C Recommendation for string data. Expected operations within OVAL for string values are 'equals', 'not equal', 'case insensitive equals', 'case insensitive not equal', 'pattern match'. The version datatype represents a value that is a hierarchical list of non-negative integers separated by a single character delimiter. Note that any non-number character can be used as a delimiter and that different characters can be used within the same version string. So '#.#-#' is the same as '#.#.#' or '#c#c#' where '#' is any non-negative integer. Expected operations within OVAL for version values are 'equals', 'not equal', 'greater than', 'greater than or equal', 'less than', and 'less than or equal'. For example '#.#.#' or '#-#-#-#' where the numbers to the left are more significant than the numbers to the right. When performing an 'equals' operation on a version datatype, you should first check the left most number for equality. If that fails, then the values are not equal. If it succeeds, then check the second left most number for equality. Continue checking the numbers from left to right until the last number has been checked. If, after testing all the previous numbers, the last number is equal then the two versions are equal. When performing other operations, such as 'less than', 'less than or equal', 'greater than, or Cokus, et al. Expires March 11, 2017 [Page 40] Internet-Draft OVAL Common Model September 2016 'greater than or equal', similar logic as above is used. Start with the left most number and move from left to right. For each number, check if it is less than the number you are testing against. If it is, then the version in question is less than the version you are testing against. If the number is equal, then move to check the next number to the right. For example, to test if 5.7.23 is less than or equal to 5.8.0 you first compare 5 to 5. They are equal so you move on to compare 7 to 8. 7 is less than 8 so the entire test succeeds and 5.7.23 is 'less than or equal' to 5.8.0. The difference between the 'less than' and 'less than or equal' operations is how the last number is handled. If the last number is reached, the check should use the given operation (either 'less than' and 'less than or equal') to test the number. For example, to test if 4.23.6 is greater than 4.23.6 you first compare 4 to 4. They are equal so you move on to compare 23 to 23. They are equal so you move on to compare 6 to 6. This is the last number in the version and since 6 is not greater than 6, the entire test fails and 4.23.6 is not greater than 4.23.6. Version strings with a different number of components shall be padded with zeros to make them the same size. For example, if the version strings '1.2.3' and '6.7.8.9' are being compared, then the short one should be padded to become '1.2.3.0'. The Cokus, et al. Expires March 11, 2017 [Page 41] Internet-Draft OVAL Common Model September 2016 ComplexDatatypeEnumeration simple type defines the complex legal datatypes that are supported in OVAL. These datatype describe the values of individual entities where the entity has some complex structure beyond simple string like content. The record datatype describes an entity with structured set of named fields and values as its content. The only allowed operation within OVAL for record values is 'equals'. Note that the record datatype is not currently allowed when using variables. The DatatypeEnumeration simple type defines the legal datatypes that are used to describe the values of individual entities. A value should be interpreted according to the specified type. This is most important during comparisons. For example, is '21' less than '123'? will evaluate to true if the datatypes are 'int', but will evaluate to 'false' if the datatypes are 'string'. Another example is applying the 'equal' operation to '1.0.0.0' and '1.0'. With datatype 'string' they are not equal, with datatype 'version' they are. Cokus, et al. Expires March 11, 2017 [Page 42] Internet-Draft OVAL Common Model September 2016 The ExistenceEnumeration simple type defines acceptable existence values, which are used to determine a result based on the existence of individual components. The main use for this is for a test regarding the existence of objects on the system. Below are some tables that outline how each ExistenceEnumeration value effects evaluation of a given test. Note that this is related to the existence of an object(s) and not the object(s) compliance with a state. The left column identifies the ExistenceEnumeration value in question. The middle column specifies the different combinations of individual item status values that have been found in the system characteristics file related to the given object. (EX=exists, DE=does not exist, ER=error, NC=not collected) For example, a 1+ under EX means that one or more individual item status attributes are set to exists, while a 0 under NC means that zero individual item status attributes are set to not collected. The last column specifies what the result of the existence piece would be according to each combination of individual item status values. || item status value count || attr value || || existence || EX | DE | ER | NC || piece is ---------------||---------------------------||------------------ || 1+ | 0 | 0 | 0 || True || 0 | 0 | 0 | 0 || False || 0+ | 1+ | 0+ | 0+ || False all_exist || 0+ | 0 | 1+ | 0+ || Error || 0+ | 0 | 0 | 1+ || Unknown || -- | -- | -- | -- || Not Evaluated || -- | -- | -- | -- || Not Applicable ---------------||---------------------------||------------------ Cokus, et al. Expires March 11, 2017 [Page 43] Internet-Draft OVAL Common Model September 2016 || item status value count || attr value || || existence || EX | DE | ER | NC || piece is ---------------||---------------------------||------------------ || 0+ | 0+ | 0 | 0+ || True || 1+ | 0+ | 1+ | 0+ || True || -- | -- | -- | -- || False any_exist || 0 | 0+ | 1+ | 0+ || Error || -- | -- | -- | -- || Unknown || -- | -- | -- | -- || Not Evaluated || -- | -- | -- | -- || Not Applicable ---------------||---------------------------||------------------ || item status value count || attr value || || existence || EX | DE | ER | NC || piece is ---------------||---------------------------||------------------ || 1+ | 0+ | 0+ | 0+ || True || 0 | 1+ | 0 | 0 || False at_least_ || 0 | 0+ | 1+ | 0+ || Error one_exists || 0 | 0+ | 0 | 1+ || Unknown || -- | -- | -- | -- || Not Evaluated || -- | -- | -- | -- || Not Applicable ---------------||---------------------------||------------------ || item status value count || attr value || || existence || EX | DE | ER | NC || piece is ---------------||---------------------------||------------------ || 0 | 0+ | 0 | 0 || True || 1+ | 0+ | 0+ | 0+ || False none_exist || 0 | 0+ | 1+ | 0+ || Error || 0 | 0+ | 0 | 1+ || Unknown || -- | -- | -- | -- || Not Evaluated || -- | -- | -- | -- || Not Applicable ---------------||---------------------------||------------------ || item status value count || attr value || || existence || EX | DE | ER | NC || piece is ---------------||---------------------------||------------------ || 1 | 0+ | 0 | 0 || True || 2+ | 0+ | 0+ | 0+ || False || 0 | 0+ | 0 | 0 || False Cokus, et al. Expires March 11, 2017 [Page 44] Internet-Draft OVAL Common Model September 2016 only_one_ || 0,1 | 0+ | 1+ | 0+ || Error exists || 0,1 | 0+ | 0 | 1+ || Unknown || -- | -- | -- | -- || Not Evaluated || -- | -- | -- | -- || Not Applicable ---------------||---------------------------||------------------ A value of 'all_exist' means that every object defined by the description exists on the system. A value of 'any_exist' means that zero or more objects defined by the description exist on the system. A value of 'at_least_one_exists' means that at least one object defined by the description exists on the system. A value of 'none_exist' means that none of the objects defined by the description exist on the system. A value of 'only_one_exists' means that only one Cokus, et al. Expires March 11, 2017 [Page 45] Internet-Draft OVAL Common Model September 2016 object defined by the description exists on the system. The FamilyEnumeration simple type is a listing of families that OVAL supports at this time. Since new family values can only be added with new version of the schema, the value of 'undefined' is to be used when the desired family is not available. Note that use of the undefined family value does not target all families, rather it means that some family other than one of the defined values is targeted. The android value describes the Android mobile operating system. The asa value describes the Cisco ASA security devices. The apple_ios value describes the iOS mobile operating system. The catos value describes the Cisco CatOS operating system. Cokus, et al. Expires March 11, 2017 [Page 46] Internet-Draft OVAL Common Model September 2016 The ios value describes the Cisco IOS operating system. The iosxe value describes the Cisco IOS XE operating system. The junos value describes the Juniper JunOS operating system. The macos value describes the Mac operating system. The pixos value describes the Cisco PIX operating system. The undefined value is to be used when the desired family is not available. The unix value describes the UNIX operating Cokus, et al. Expires March 11, 2017 [Page 47] Internet-Draft OVAL Common Model September 2016 system. The vmware_infrastructure value describes VMWare Infrastructure. The windows value describes the Microsoft Windows operating system. The MessageLevelEnumeration simple type defines the different levels associated with a message. There is no specific criteria about which messages get assigned which level. This is completely arbitrary and up to the content producer to decide what is an error message and what is a debug message. Debug messages should only be displayed by a tool when run in some sort of verbose mode. Error messages should be recorded when there was an error that did not allow the collection of specific data. Cokus, et al. Expires March 11, 2017 [Page 48] Internet-Draft OVAL Common Model September 2016 A fatal message should be recorded when an error causes the failure of more than just a single piece of data. Info messages are used to pass useful information about the data collection to a user. A warning message reports something that might not correct but information was still collected. The OperationEnumeration simple type defines acceptable operations. Each operation defines how to compare entities against their actual values. The 'equals' operation returns true if the actual value on the system is equal to the stated entity. When the specified datatype is a string, this results in a case-sensitive comparison. Cokus, et al. Expires March 11, 2017 [Page 49] Internet-Draft OVAL Common Model September 2016 The 'not equal' operation returns true if the actual value on the system is not equal to the stated entity. When the specified datatype is a string, this results in a case-sensitive comparison. The 'case insensitive equals' operation is meant for string data and returns true if the actual value on the system is equal (using a case insensitive comparison) to the stated entity. The 'case insensitive not equal' operation is meant for string data and returns true if the actual value on the system is not equal (using a case insensitive comparison) to the stated entity. The 'greater than' operation returns true if the actual value on the system is greater than the stated entity. The 'less than' operation returns true if the actual value on the system is less than the Cokus, et al. Expires March 11, 2017 [Page 50] Internet-Draft OVAL Common Model September 2016 stated entity. The 'greater than or equal' operation returns true if the actual value on the system is greater than or equal to the stated entity. The 'less than or equal' operation returns true if the actual value on the system is less than or equal to the stated entity. The 'bitwise and' operation is used to determine if a specific bit is set. It returns true if performing a BITWISE AND with the binary representation of the stated entity against the binary representation of the actual value on the system results in a binary value that is equal to the binary representation of the stated entity. For example, assuming a datatype of 'int', if the actual integer value of the setting on your machine is 6 (same as 0110 in binary), then performing a 'bitwise and' with the stated integer 4 (0100) returns 4 (0100). Since the result is the same as the state mask, then the test returns true. If the actual value on your machine is 1 (0001), then the 'bitwise and' with the stated integer 4 (0100) returns 0 (0000). Since the result is not the same as the stated mask, then the test fails. Cokus, et al. Expires March 11, 2017 [Page 51] Internet-Draft OVAL Common Model September 2016 The 'bitwise or' operation is used to determine if a specific bit is not set. It returns true if performing a BITWISE OR with the binary representation of the stated entity against the binary representation of the actual value on the system results in a binary value that is equal to the binary representation of the stated entity. For example, assuming a datatype of 'int', if the actual integer value of the setting on your machine is 6 (same as 0110 in binary), then performing a 'bitwise or' with the stated integer 14 (1110) returns 14 (1110). Since the result is the same as the state mask, then the test returns true. If the actual value on your machine is 1 (0001), then the 'bitwise or' with the stated integer 14 (1110) returns 15 (1111). Since the result is not the same as the stated mask, then the test fails. The 'pattern match' operation allows an item to be tested against a regular expression. When used by an entity in an OVAL Object, the regular expression represents the unique set of matching items on the system. OVAL supports a common subset of the regular expression character classes, operations, expressions and other lexical tokens defined within Perl 5's regular expression specification. For more information on the supported regular expression syntax in OVAL see: http://oval.mitre.org/language/ about/re_support_5.6.html Cokus, et al. Expires March 11, 2017 [Page 52] Internet-Draft OVAL Common Model September 2016 The 'subset of' operation returns true if the actual set on the system is a subset of the set defined by the stated entity. The 'superset of' operation returns true if the actual set on the system is a superset of the set defined by the stated entity. The OperatorEnumeration simple type defines acceptable operators. Each operator defines how to evaluate multiple arguments. Below are some tables that outline how each operator effects evaluation. The far left column identifies the operator in question. The middle column specifies the different combinations of individual results that the operator may bind together. (T=true, F=false, E=error, U=unknown, NE=not evaluated, NA=not applicable) For example, a 1+ under T means that one or more individual results are true, while a 0 under U means that zero individual results are unknown. The last column specifies what the final result would be according to each combination of individual results. Note that if the individual test is negated, then a true result is false and a false result is true, all other results stay as Cokus, et al. Expires March 11, 2017 [Page 53] Internet-Draft OVAL Common Model September 2016 is. || num of individual results || operator is || || final result is || T | F | E | U | NE | NA || -------------||-----------------------------||------------------ || 1+ | 0 | 0 | 0 | 0 | 0+ || True || 0+ | 1+ | 0+ | 0+ | 0+ | 0+ || False AND || 0+ | 0 | 1+ | 0+ | 0+ | 0+ || Error || 0+ | 0 | 0 | 1+ | 0+ | 0+ || Unknown || 0+ | 0 | 0 | 0 | 1+ | 0+ || Not Evaluated || 0 | 0 | 0 | 0 | 0 | 1+ || Not Applicable -------------||-----------------------------||------------------ || num of individual results || operator is || || final result is || T | F | E | U | NE | NA || -------------||-----------------------------||------------------ || 1 | 0+ | 0 | 0 | 0 | 0+ || True || 2+ | 0+ | 0+ | 0+ | 0+ | 0+ || ** False ** || 0 | 1+ | 0 | 0 | 0 | 0+ || ** False ** ONE ||0,1 | 0+ | 1+ | 0+ | 0+ | 0+ || Error ||0,1 | 0+ | 0 | 1+ | 0+ | 0+ || Unknown ||0,1 | 0+ | 0 | 0 | 1+ | 0+ || Not Evaluated || 0 | 0 | 0 | 0 | 0 | 1+ || Not Applicable -------------||-----------------------------||------------------ || num of individual results || operator is || || final result is || T | F | E | U | NE | NA || -------------||-----------------------------||------------------ || 1+ | 0+ | 0+ | 0+ | 0+ | 0+ || True || 0 | 1+ | 0 | 0 | 0 | 0+ || False OR || 0 | 0+ | 1+ | 0+ | 0+ | 0+ || Error || 0 | 0+ | 0 | 1+ | 0+ | 0+ || Unknown || 0 | 0+ | 0 | 0 | 1+ | 0+ || Not Evaluated || 0 | 0 | 0 | 0 | 0 | 1+ || Not Applicable -------------||-----------------------------||------------------ || num of individual results || operator is || || final result is || T | F | E | U | NE | NA || -------------||-----------------------------||------------------ ||odd | 0+ | 0 | 0 | 0 | 0+ || True ||even| 0+ | 0 | 0 | 0 | 0+ || False Cokus, et al. Expires March 11, 2017 [Page 54] Internet-Draft OVAL Common Model September 2016 XOR || 0+ | 0+ | 1+ | 0+ | 0+ | 0+ || Error || 0+ | 0+ | 0 | 1+ | 0+ | 0+ || Unknown || 0+ | 0+ | 0 | 0 | 1+ | 0+ || Not Evaluated || 0 | 0 | 0 | 0 | 0 | 1+ || Not Applicable -------------||-----------------------------||------------------ The AND operator produces a true result if every argument is true. If one or more arguments are false, the result of the AND is false. If one or more of the arguments are unknown, and if none of the arguments are false, then the AND operator produces a result of unknown. The ONE operator produces a true result if one and only one argument is true. If there are more than argument is true (or if there are no true arguments), the result of the ONE is false. If one or more of the arguments are unknown, then the ONE operator produces a result of unknown. The OR operator produces a true result if one or more arguments is true. If every argument is false, the result of the OR is false. If one or more of the arguments are unknown and if none of arguments are true, then the OR operator produces a result of unknown. Cokus, et al. Expires March 11, 2017 [Page 55] Internet-Draft OVAL Common Model September 2016 XOR is defined to be true if an odd number of its arguments are true, and false otherwise. If any of the arguments are unknown, then the XOR operator produces a result of unknown. Define the format for acceptable OVAL Definition ids. An urn format is used with the id starting with the word oval followed by a unique string, followed by the three letter code 'def', and ending with an integer. Define the format for acceptable OVAL Object ids. An urn format is used with the id starting with the word oval followed by a unique string, followed by the three letter code 'obj', and ending with an integer. Cokus, et al. Expires March 11, 2017 [Page 56] Internet-Draft OVAL Common Model September 2016 Define the format for acceptable OVAL State ids. An urn format is used with the id starting with the word oval followed by a unique string, followed by the three letter code 'ste', and ending with an integer. Define the format for acceptable OVAL Test ids. An urn format is used with the id starting with the word oval followed by a unique string, followed by the three letter code 'tst', and ending with an integer. Define the format for acceptable OVAL Variable ids. An urn format is used with the id starting with the word oval followed by a unique string, followed by the three letter code 'var', and ending with an integer. Define the format for acceptable OVAL Item ids. The format is an Cokus, et al. Expires March 11, 2017 [Page 57] Internet-Draft OVAL Common Model September 2016 integer. An item id is used to identify the different items found in an OVAL System Characteristics file. Define the format for acceptable OVAL Language version strings. The EmptyStringType simple type is a restriction of the built-in string simpleType. The only allowed string is the empty string with a length of zero. This type is used by certain elements to allow empty content when non-string data is accepted. See the EntityIntType in the OVAL Definition Schema for an example of its use. The NonEmptyStringType simple type is a restriction of the built-in string simpleType. Empty strings are not allowed. This type is used by comment attributes where an empty value is Cokus, et al. Expires March 11, 2017 [Page 58] Internet-Draft OVAL Common Model September 2016 not allowed. 21. Intellectual Property Considerations Copyright (C) 2010 United States Government. All Rights Reserved. DHS, on behalf of the United States, owns the registered OVAL trademarks, identifying the OVAL STANDARDS SUITE and any component part, as that suite has been provided to the IETF Trust. A "(R)" will be used in conjunction with the first use of any OVAL trademark in any document or publication in recognition of DHS's trademark ownership. 22. Acknowledgements The authors wish to thank DHS for sponsoring the OVAL effort over the years which has made this work possible. The authors also wish to thank the original authors of this document Jonathan Baker, Matthew Hansbury, and Daniel Haynes of the MITRE Corporation as well as the OVAL Community for its assistance in contributing and reviewing the original document. The authors would also like to acknowledge Dave Waltermire of NIST for his contribution to the development of the original document. 23. IANA Considerations This memo includes no request to IANA. 24. Security Considerations While OVAL is just a set of data models and does not directly introduce security concerns, it does provide a mechanism by which to represent endpoint posture assessment information. This information could be extremely valuable to an attacker allowing them to learn about very sensitive information including, but, not limited to: security policies, systems on the network, criticality of systems, software and hardware inventory, patch levels, user accounts and much more. To address this concern, all endpoint posture assessment Cokus, et al. Expires March 11, 2017 [Page 59] Internet-Draft OVAL Common Model September 2016 information should be protected while in transit and at rest. Furthermore, it should only be shared with parties that are authorized to receive it. Another possible security concern is due to the fact that content expressed as OVAL has the ability to impact how a security tool operates. For example, content may instruct a tool to collect certain information off a system or may be used to drive follow-up actions like remediation. As a result, it is important for security tools to ensure that they are obtaining OVAL content from a trusted source, that it has not been modified in transit, and that proper validation is performed in order to ensure it does not contain malicious data. 25. Change Log 25.1. -00 to -01 There are no textual changes associated with this revision. This revision simply reflects a resubmission of the document so that it remains in active status. 26. References 26.1. Normative References [CISCO-IOS] CISCO, "Cisco IOS Reference Manual", 2014, . [DEBIAN-POLICY-MANUAL] Debian, "Debian Policy Manual", 2014, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, . [RFC791] IETF, "Internet Protocol", 1981, . Cokus, et al. Expires March 11, 2017 [Page 60] Internet-Draft OVAL Common Model September 2016 [W3C-BOOLEAN] W3C, "W3C Recommendation for Integer Data", 2004, . [W3C-FLOAT] W3C, "W3C Recommendation for Floating Point Data", 2004, . [W3C-HEX-BIN] W3C, "W3C Recommendation for Hex Binary Data", 2004, . [W3C-INT] W3C, "W3C Recommendation for Integer Data", 2004, . [W3C-STRING] W3C, "W3C Recommendation for String Data", 2004, . 26.2. Informative References [OVAL-WEBSITE] The MITRE Corporation, "The Open Vulnerability and Assessment Language", 2015, . Appendix A. Terms and Acronyms Cokus, et al. Expires March 11, 2017 [Page 61] Internet-Draft OVAL Common Model September 2016 +-----------+-------------------------------------------------------+ | Term | Definition | +-----------+-------------------------------------------------------+ | OVAL | An action that can further specify the set of OVAL | | Behavior | Items that matches an OVAL Object. | | | | | OVAL Test | An OVAL Test is the standardized representation of an | | | assertion about the state of a system. | | | | | OVAL | An OVAL Object is a collection of OVAL Object | | Object | Entities that can uniquely identify a single OVAL | | | Item on the system. | | | | | OVAL Item | An OVAL Item is a single piece of collected system | | | state information. | | | | | OVAL | An OVAL Construct that is specified in the oval- | | Component | def:ComponentGroup. | | | | | OVAL | An OVAL Function is a capability used in OVAL | | Function | Variables to manipulate a variable's value. | | | | | OVAL | An OVAL Variable represents a collection of values | | Variable | that allow for dynamic substitutions and reuse of | | | system state information. | | | | | OVAL | An OVAL Object Entity is a standardized | | Object | representation for specifying a single piece of | | Entity | system state information. | | | | | OVAL | An OVAL State Entity is a standardized representation | | State | for checking a single piece of system state | | Entity | information. | | | | | OVAL Item | An OVAL Item Entity is a standardized representation | | Entity | for a single piece of system state information. | +-----------+-------------------------------------------------------+ Table 12: Terms and Acronyms Definitions Cokus, et al. Expires March 11, 2017 [Page 62] Internet-Draft OVAL Common Model September 2016 +---------+------------------------------------------------+ | Acronym | Definition | +---------+------------------------------------------------+ | CCE | Common Configuration Enumeration | | | | | CPE | Common Platform Enumeration | | | | | CVE | Common Vulnerabilities and Exposures | | | | | DHS | Department of Homeland Security | | | | | DNS | Domain Name System | | | | | IP | Internet Protocol | | | | | MAC | Media Access Control | | | | | NAC | Network Access Control | | | | | NIST | National Institute of Standards and Technology | | | | | NSA | National Security Agency | | | | | OVAL | Open Vulnerability and Assessment Language | | | | | SIM | Security Information Management | | | | | UML | Unified Modeling Language | | | | | URI | Uniform Resource Identifier | | | | | URN | Uniform Resource Name | | | | | W3C | World Wide Web Consortium | | | | | XML | eXtensible Markup Language | +---------+------------------------------------------------+ Table 13: Acronyms Appendix B. Regular Expression Support The OVAL Language supports a common subset of the regular expression character classes, operations, expressions, and other lexical tokens defined within Perl 5's regular expression specification. This common subset was identified through a survey of several regular expression libraries in an effort to ensure that the regular expression elements supported by OVAL will be compatible with a wide Cokus, et al. Expires March 11, 2017 [Page 63] Internet-Draft OVAL Common Model September 2016 variety of regular expression libraries. A listing of the surveyed regular expression libraries is provided later in this document. B.1. Supported Regular Expression Syntax Perl regular expression modifiers (m, i, s, x) are not supported. These modifiers should be considered to always be 'OFF, unless specifically permitted by documentation on an OVAL Language construct. Character matching assumes a Unicode character set. Note that no syntax is supplied for specifying code points in hex; actual Unicode characters must be used instead. The following regular expression elements are specifically identified as supported in the OVAL Language. For more detailed definitions of the regular expression elements listed below, refer to their descriptions in the Perl 5.004 Regular Expression documentation. A copy of this documentation has been preserved for reference purposes [10]. Regular expression elements that are not listed below should be avoided as they are likely to be incompatible or have different meanings with commonly used regular expression libraries. Please note that while only a subset of the Perl 5 regular expression syntax is supported, content can be written that may still run in some OVAL interpreter tools. This practice should be avoided in order to maintain the portability of content across multiple tools. In the event that an attempt was made to evaluate a string against a malformed regular expression, an error must be reported. An example of a malformed regular expression is the pattern "+". An unsupported regular expression should only be reported as an error if the evaluating tool is not capable of analyzing the pattern. A malformed regular expression may remain ignored if the preceding existence check can determine the evaluation flag. Cokus, et al. Expires March 11, 2017 [Page 64] Internet-Draft OVAL Common Model September 2016 +---------------+---------------------------------------------------+ | Metacharacter | Description | +---------------+---------------------------------------------------+ | \ | Quote the next metacharacter | | | | | ^ | Match the beginning of the line | | | | | . | Match any character (except newline) | | | | | $ | Match the end of the line (or before newline at | | | the end) | | | | | | | Alternation | | | | | () | Grouping | | | | | [] | Character class | +---------------+---------------------------------------------------+ Table 14: Metacharacters +------------+--------------------------------------------+ | Quantifier | Description | +------------+--------------------------------------------+ | * | Match 0 or more times | | | | | + | Match 1 or more times | | | | | ? | Match 1 or 0 times | | | | | {n} | Match exactly n times | | | | | {n, } | Match at least n times | | | | | {n, m} | Match at least n but not more than m times | +------------+--------------------------------------------+ Table 15: Greedy Quantifiers Cokus, et al. Expires March 11, 2017 [Page 65] Internet-Draft OVAL Common Model September 2016 +------------+--------------------------------------------+ | Quantifier | Description | +------------+--------------------------------------------+ | *? | Match 0 or more times | | | | | +? | Match 1 or more times | | | | | ?? | Match 0 or 1 time | | | | | {n}? | Match exactly n times | | | | | {n,}? | Match at least n times | | | | | {n,m}? | Match at least n but not more than m times | +------------+--------------------------------------------+ Table 16: Reluctant Quantifiers +-----------------+--------------------------------+ | Escape Sequence | Description | +-----------------+--------------------------------+ | \t | tab (HT, TAB) | | | | | \n | newline (LF, NL) | | | | | \r | return (CR) | | | | | \f | form feed (FF) | | | | | \033 | octal char (think of a PDP-11) | | | | | \x1B | hex char | | | | | \c[ | control char | +-----------------+--------------------------------+ Table 17: Escape Sequences Cokus, et al. Expires March 11, 2017 [Page 66] Internet-Draft OVAL Common Model September 2016 +-----------------+-------------------------------------------------+ | Character Class | Description | +-----------------+-------------------------------------------------+ | \w | Match a "word" character (alphanumeric plus | | | "_") | | | | | \W | Match a non-word character | | | | | \s | Match a whitespace character | | | | | \S | Match a non-whitespace character | | | | | \d | Match a digit character | | | | | \D | Match a non-digit character | +-----------------+-------------------------------------------------+ Table 18: Character Classes +-----------+-----------------------------+ | Assertion | Description | +-----------+-----------------------------+ | \b | Match a word boundary | | | | | \B | Match a non-(word boundary) | +-----------+-----------------------------+ Table 19: Zero Width Assertions +------------+-----------------------------------------+ | Extension | Description | +------------+-----------------------------------------+ | (?:regexp) | Group without capture | | | | | (?=regexp) | Zero-width positive lookahead assertion | | | | | (?!regexp) | Zero-width negative lookahead assertion | +------------+-----------------------------------------+ Table 20: Extensions Cokus, et al. Expires March 11, 2017 [Page 67] Internet-Draft OVAL Common Model September 2016 +---------------+---------------------------------------------------+ | Regular | Description | | Expression | | +---------------+---------------------------------------------------+ | [chars] | Match any of the specified characters | | | | | [^chars] | Match anything that is not one of the specified | | | characters | | | | | [a-b] | Match any character in the range between "a" and | | | "b, inclusive | | | | | a|b | Alternation; match either the left side of the | | | "|" or the right side | | | | | \n | When 'n' is a single digit: the nth capturing | | | group matched | +---------------+---------------------------------------------------+ Table 21: Version 8 Regular Expressions Authors' Addresses Michael Cokus The MITRE Corporation 903 Enterprise Parkway, Suite 200 Hampton, VA 23666 USA Email: msc@mitre.org Daniel Haynes The MITRE Corporation 202 Burlington Road Bedford, MA 01730 USA Email: dhaynes@mitre.org David Rothenberg The MITRE Corporation 202 Burlington Road Bedford, MA 01730 USA Email: drothenberg@mitre.org Cokus, et al. Expires March 11, 2017 [Page 68] Internet-Draft OVAL Common Model September 2016 Juan Gonzalez Department of Homeland Security 245 Murray Lane Washington, DC 20548 USA Email: juan.gonzalez@dhs.gov Cokus, et al. Expires March 11, 2017 [Page 69]