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 will also be used to collect 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 via three distinct doc varieties: OVAL Definitions, OVAL System Traits and OVAL Outcomes. The particular format for every kind is outlined by a Schema, which is a doc that accommodates guidelines that the construction of the OVAL doc should adhere to. These guidelines embrace directions such because the order that parts should seem, how usually a component can seem, if the ingredient is required or not, which attributes a component has, and what kind of information will 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 of 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, will be written manually or generated robotically. 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 might trigger the interpreter to fail or to generate incorrect information. Subsequently, it is very important 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 judge 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 easy. Nonetheless within the case of OVAL paperwork, a number of schemas are used to outline guidelines for its varied parts. 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, at the least one different schema is required to outline the particular sorts of information that may be queried from a number akin to package deal variations, file data and configuration settings. For these particular schemas, there may be usually one per working system (eg, Home windows, Linux, macOS). This implies we’d like at minimal three totally 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 can even be out there for validation when the importing file accommodates 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 cross the windows-definitions-schema to the lxml processor. Here’s a snippet from the beginning of the windows-definitions-schema file displaying the extra schemas being imported:
There are, nevertheless, nonetheless eventualities the place a Definition file can use parts from multiple extra schema. This can generally happen when utilizing parts from the independent-definitions-schema, which accommodates performance that can be utilized throughout a number of working programs akin to hashing recordsdata, checking surroundings 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 potential 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 parts discovered within the schema that has not been supplied to the Python script.
To resolve this downside, we will use the identical import performance that was proven within the instance above, solely this time utilizing a specifically created check schema. The check 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 will be imported into this file, so it’s not essential to create a separate check schema file for each variation of Definition recordsdata even when they’re written for utterly totally different operation programs. 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.