OVAL is the Open Vulnerability Evaluation Language, which makes use of XML primarily based paperwork to outline vulnerabilities primarily based on traits of a number system. It may also be used to assemble details about the host. When an OVAL file is evaluated, it generates a report file with the outcomes of the vulnerability analysis or a system traits file containing data gathered from the host.
OVAL Definitions, OVAL System Traits and OVAL Outcomes
These capabilities are achieved by three distinct doc varieties: OVAL Definitions, OVAL System Traits and OVAL Outcomes. The precise format for every kind is outlined by a Schema, which is a doc that comprises guidelines that the construction of the OVAL doc should adhere to. These guidelines embody directions such because the order that components should seem, how typically a component can seem, if the aspect is required or not, which attributes a component has, and what kind of knowledge might be contained inside a component.
Validation of an XML file is the method of evaluating whether or not it conforms to the format described by the schema. If it conforms to the schema, it’s thought-about legitimate.
An OVAL interpreter is an executable which evaluates OVAL Definition recordsdata and produces OVAL System Attribute recordsdata and OVAL Outcomes. Since System Traits and Outcomes are each generated by the interpreter when an OVAL Definition file is processed, it’s the interpreter’s accountability to make sure that the recordsdata it generates adhere to the desired schemas.
The OVAL Definition file, which particulars the data to be queried from a number and the way that information ought to be evaluated, might be written manually or generated routinely. Which means Definition recordsdata could also be generated incorrectly because of errors or typos that fail to adapt to the schema. Usually, invalid Definition recordsdata ought to be rejected by the interpreter, however in some instances, it may trigger the interpreter to fail or to generate incorrect information. Subsequently, you will need to be sure that Definition recordsdata conform to the schema earlier than passing them to an OVAL interpreter.
An possibility for validation is to write down a script to guage generated Definition recordsdata. The Python library lxml has capabilities for processing, modifying and producing XML paperwork in addition to validating XML paperwork towards a schema. The next code can be utilized to carry out XML validation:
schema_validator = lxml.etree.XMLSchema(file=)
is_valid = schema_validator.validate()
With this code validating XML towards a single schema is pretty simple. Nonetheless within the case of OVAL paperwork, a number of schemas are used to outline guidelines for its varied elements. At minimal, an OVAL Definition file makes use of the oval-common-schema and the oval-definitions-schema. These schemas outline the final construction of OVAL and the construction of the Definition file respectively. Along with these, not less than one different schema is required to outline the particular kinds of information that may be queried from a number akin to bundle variations, file data and configuration settings. For these particular schemas, there’s typically one per working system (eg, Home windows, Linux, macOS). This implies we want at minimal three completely different schemas to validate an OVAL Definition. That is problematic given lxml can solely settle for a single schema file.
Validating an OVAL file in Python
This limitation is mitigated by the flexibility to import schema recordsdata into one other schema file. As soon as imported, the extra schema recordsdata may even be obtainable for validation when the importing file comprises the extra schemas. The OVAL schema recordsdata make use of this performance, and the OS particular schema recordsdata import the required oval-common-schema and the oval-definitions-schema. Subsequently, for many instances, to validate an OVAL file in Python with lxml, solely the schema file for the OS the OVAL XML is written for must be specified. For instance, a file written for querying a Home windows host would wish to go the windows-definitions-schema to the lxml processor. Here’s a snippet from the beginning of the windows-definitions-schema file exhibiting the extra schemas being imported:
There are, nevertheless, nonetheless situations the place a Definition file can use components from a couple of extra schema. This can generally happen when utilizing components from the independent-definitions-schema, which comprises performance that can be utilized throughout a number of working methods akin to hashing recordsdata, checking setting variables and studying file contents. A Definition file written for Home windows that makes use of each the Home windows schema and Impartial schema wouldn’t be doable to validate with lxml by passing in any single one of many default schema recordsdata. Passing in solely one of many required schemas would trigger the validation to fail on components discovered within the schema that has not been supplied to the Python script.
To resolve this drawback, we are able to use the identical import performance that was proven within the instance above, solely this time utilizing a specifically created take a look at schema. The take a look at schema solely must import the opposite schema recordsdata required for profitable validation. It doesn’t itself include any of the doc construction guidelines discovered within the different schemas. Any variety of schemas might be imported into this file, so it’s not essential to create a separate take a look at schema file for each variation of Definition recordsdata even when they’re written for fully completely different operation methods. Right here’s an instance of a single file that imports all of the supported OVAL schema recordsdata:
Utilizing this instance because the validator schema within the Python script above permits correct validation of any OVAL Definition file whatever the mixture of the presently supported schemas it employs.