Introduction to OVAL: Open vulnerability and Assessment Language
Good day, colleagues!
All of you have repeatedly encountered the problem of analyzing vulnerabilities on a target system. The main stumbling block of which is the fragmentation of the data supply vendor.
In one place you can find the vulnerability itself, in another its assessment, in the third necessary conditions for checking and in the fourth link to the patch.
Especially to solve this problem, there is a language describing vulnerabilities OVAL
This language standardizes the ways of presenting information, the process of analyzing the system and the format of the output. Thus, we get a single XML file that already describes the vulnerability, the definition method, the link to the patch, the link to CVE, and more. Also, this format is the standard for accepting information for security scanners.
')
By itself, the language is a fairly flexible formalized environment, which allows both to use patterned constructions and to modify them to your liking. Thus, the same models are used to present various information. A full description of the language can be found in this document . I want to introduce you to the aspects of presenting information about vulnerabilities. Or rather, with the final product.
The final form in which you get vulnerability data in OVAL will be in XML format.
For convenience of understanding, we will consider in more detail on the example of vulnerability OVAL for RedHat
Let's see what we find inside.
First of all, what will help us a lot when automating the processing of OVAL files is the schema and namespaces:
This is a description of what options and where we will be waiting.
Next comes the block automatically filled by the generator. The traditional "what, where, when":
Further information is divided into several large semantic blocks: definitions, tests, objects and states.
Definitions actually contains the vulnerability information itself, tests are described in the tests block, checks are listed in the objects section, and the states part describes the formal test condition applied to objects.
For clarity, let's analyze line by line one element of the block “definition”:
The main information is presented in the form of root tag attributes:
id = "oval: org.mitre.oval: def: 975" is an identification number unique within this namespace. From it you can find out that it is oval: created by org.mitre.oval that this is definition: def: number 975.
version = "2" - Version Information
class = “vulnerability” - the definition class (in our case it is a vulnerability, for a patch it would be a “patch”)
Next comes the general information, separated by a tag.
As can be seen from the "talking" tags, this is the "Red Hat OpenSSL do_change_cipher_spec Function Denial of Service" vulnerability,
which the OpenSSL product in the Unix family of the Red Hat Linux 9 platform is exposed to.
Next comes the generic reference field, which provides a link to the CVE source. Any kind of information of this type can be filed here (link to bugzilla, for example).
The tag is also easy-to-understand and carries a textual description of the vulnerability.
Next comes the optional service information about the repository <oval_repository>. Its main purpose is to provide information on the change of status of the definition. The key field is “status”.
The next block is the most delicious. It carries information about the necessary criteria and checks to determine this vulnerability, combined by logical conditions. The condition is the criteria blocks with the parameter of the logical operator clause that can be nested. Thus, having the possibility of negation (negate = "false" / "true"), the operators AND and OR we have a full-fledged algebra. If necessary, here you can describe the condition of any complexity. Links to the required test is the criterion block, which points to a unique element of the type “test” contained in this OVAL file.
Pass on such a link, and look at it:
As we can see from the content, this is a test for the fact that Red Hat 9 is installed.
This check must be performed at least once (“at least one”) and verify the presence of such an object in at least one instance (“at_least_one_exists”).
The following are references to the object and state required for a positive outcome. These blocks are also required to be in the same OVAL repository.
Let's follow the link to the specified object:
And from here we learn that it is necessary to check the version of redhat-release rpm.
Let's find out the necessary conditions - let's move on to the state specified in the test:
And in the description you can see that it is necessary to compare the RPM version with 9. (9)
Thus, adding up the logical chains along the conditions specified in the criteria, we obtain the necessary conditions to determine the presence of vulnerability and the fulfillment of the definition conditions.
I hope, on this small example, you became clear how to submit information to OVAL-vulner.
The main interest of the format is its extreme flexibility. To add additional data, it is enough to adjust the scheme and point to the link. But, I will tell you about the ways of forming these files another time.
Thanks for reading, I hope I told you something new.
All of you have repeatedly encountered the problem of analyzing vulnerabilities on a target system. The main stumbling block of which is the fragmentation of the data supply vendor.
In one place you can find the vulnerability itself, in another its assessment, in the third necessary conditions for checking and in the fourth link to the patch.
Especially to solve this problem, there is a language describing vulnerabilities OVAL
This language standardizes the ways of presenting information, the process of analyzing the system and the format of the output. Thus, we get a single XML file that already describes the vulnerability, the definition method, the link to the patch, the link to CVE, and more. Also, this format is the standard for accepting information for security scanners.
')
By itself, the language is a fairly flexible formalized environment, which allows both to use patterned constructions and to modify them to your liking. Thus, the same models are used to present various information. A full description of the language can be found in this document . I want to introduce you to the aspects of presenting information about vulnerabilities. Or rather, with the final product.
The final form in which you get vulnerability data in OVAL will be in XML format.
For convenience of understanding, we will consider in more detail on the example of vulnerability OVAL for RedHat
Let's see what we find inside.
First of all, what will help us a lot when automating the processing of OVAL files is the schema and namespaces:
<oval_definitions xsi: schemaLocation = " oval.mitre.org/XMLSchema/oval-definitions-5 oval-definitions-schema.xsd http : //oval.mitre.org/XMLSchema/oval-definitions-5#linux linux-definitions- schema.xsd http://oval.mitre.org/XMLSchema/oval-common-5 oval-common-schema.xsd http://oval.mitre.org/XMLSchema/oval-definitions-5#unix unix-definitions- schema.xsd " >
This is a description of what options and where we will be waiting.
Next comes the block automatically filled by the generator. The traditional "what, where, when":
<generator >
<oval: product_name > The OVAL Repository </ oval: product_name >
<oval: schema_version > 5.10 </ oval: schema_version >
<oval: timestamp > 2012-01-11T06: 12: 25.053-05: 00 </ oval: timestamp >
</ generator >
Further information is divided into several large semantic blocks: definitions, tests, objects and states.
Definitions actually contains the vulnerability information itself, tests are described in the tests block, checks are listed in the objects section, and the states part describes the formal test condition applied to objects.
For clarity, let's analyze line by line one element of the block “definition”:
<definition id = "oval: org.mitre.oval: def: 975" version = "2" class = "vulnerability" >
<metadata >
<title > Red Hat OpenSSL do_change_cipher_spec Function Denial of Service </ title >
<affected family = "unix" >
<platform > Red Hat Linux 9 </ platform >
<product > OpenSSL </ product >
</ affected >
<reference source = "CVE" ref_id = "CVE-2004-0079" ref_url = " cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0079" />
<description > The do_change_cipher_spec function in OpenSSL 0.9.6c to 0.9.6k, and 0.9.7a to 0.9.7c, allows remote attackers
to a cause of denial of service (crash) via a crafted SSL / TLS handshake that triggers a null dereference. </ description >
<oval_repository >
<dates >
<submitted date = "2004-03-20T12: 00: 00.000-04: 00" >
<contributor organization = "The MITRE Corporation" > Matt Busby </ contributor >
</ submitted >
<modified date = "2004-05-05T12: 00: 00.000-04: 00" comment = "Corrected syntax errors in sql verion of the definition." >
<contributor organization = "The MITRE Corporation" > Matt Busby </ contributor >
</ modified >
<status_change date = "2004-05-25T12: 00: 00.000-04: 00" > INTERIM </ status_change >
<status_change date = "2004-06-16T12: 00: 00.000-04: 00" > ACCEPTED </ status_change >
<modified comment = "Corrected regex to match only reasonable values ​​for the machine class.
Implemented by Jon Baker of the MITER Corporation. " Date = " 2007-04-10T15: 39: 00.888-04: 00 " >
<contributor organization = "Maitreya Security" > Thomas R. Jones </ contributor >
</ modified >
<status_change date = "2007-04-10T15: 41: 24.326-04: 00" > INTERIM </ status_change >
<status_change date = "2007-04-25T19: 53: 11.788-04: 00" > ACCEPTED </ status_change >
</ dates >
<status > ACCEPTED </ status >
</ oval_repository >
</ metadata >
<criteria comment = "Software section" operator = "AND" >
<criterion comment = "Red Hat 9 is installed" negate = "false" test_ref = "oval: org.mitre.oval: tst: 3153" />
<criterion comment = "ix86 architecture" negate = "false" test_ref = "oval: org.mitre.oval: tst: 3152" />
<criterion comment = "openssl version is less than 0.9.7a-20" negate = "false" test_ref = "oval: org.mitre.oval: tst: 1484" />
<criterion comment = "openssl-devel version is less than 0.9.7a-20" negate = "false" test_ref = "oval: org.mitre.oval: tst: 1483" />
<criterion comment = "openssl-perl version is less than 0.9.7a-20" negate = "false" test_ref = "oval: org.mitre.oval: tst: 1482" />
<criterion comment = "openssl096 version is less than 0.9.6-25.9" negate = "false" test_ref = "oval: org.mitre.oval: tst: 1481" />
<criterion comment = "openssl096b version is less than 0.9.6b-15" negate = "false" test_ref = "oval: org.mitre.oval: tst: 1480" />
</ criteria >
</ definition >
The main information is presented in the form of root tag attributes:
id = "oval: org.mitre.oval: def: 975" is an identification number unique within this namespace. From it you can find out that it is oval: created by org.mitre.oval that this is definition: def: number 975.
version = "2" - Version Information
class = “vulnerability” - the definition class (in our case it is a vulnerability, for a patch it would be a “patch”)
Next comes the general information, separated by a tag.
As can be seen from the "talking" tags, this is the "Red Hat OpenSSL do_change_cipher_spec Function Denial of Service" vulnerability,
which the OpenSSL product in the Unix family of the Red Hat Linux 9 platform is exposed to.
Next comes the generic reference field, which provides a link to the CVE source. Any kind of information of this type can be filed here (link to bugzilla, for example).
The tag is also easy-to-understand and carries a textual description of the vulnerability.
Next comes the optional service information about the repository <oval_repository>. Its main purpose is to provide information on the change of status of the definition. The key field is “status”.
The next block is the most delicious. It carries information about the necessary criteria and checks to determine this vulnerability, combined by logical conditions. The condition is the criteria blocks with the parameter of the logical operator clause that can be nested. Thus, having the possibility of negation (negate = "false" / "true"), the operators AND and OR we have a full-fledged algebra. If necessary, here you can describe the condition of any complexity. Links to the required test is the criterion block, which points to a unique element of the type “test” contained in this OVAL file.
Pass on such a link, and look at it:
<rpminfo_test id = "oval: org.mitre.oval: tst: 3153" version = "1" check = "at least one" comment = "Red Hat 9 is installed" check_existence = "at_least_one_exists" >
<object object_ref = "oval: org.mitre.oval: obj: 1414" />
<state state_ref = "oval: org.mitre.oval: ste: 2949" />
</ rpminfo_test >
As we can see from the content, this is a test for the fact that Red Hat 9 is installed.
This check must be performed at least once (“at least one”) and verify the presence of such an object in at least one instance (“at_least_one_exists”).
The following are references to the object and state required for a positive outcome. These blocks are also required to be in the same OVAL repository.
Let's follow the link to the specified object:
<rpminfo_object id = "oval: org.mitre.oval: obj: 1414" version = "1" comment = "the redhat-release rpm" >
redhat-release </ name >
</ rpminfo_object >
And from here we learn that it is necessary to check the version of redhat-release rpm.
Let's find out the necessary conditions - let's move on to the state specified in the test:
<rpminfo_state id = "oval: org.mitre.oval: ste: 2949" version = "1" >
<version operation = "equals" > 9 </ version >
</ rpminfo_state >
And in the description you can see that it is necessary to compare the RPM version with 9. (9)
Thus, adding up the logical chains along the conditions specified in the criteria, we obtain the necessary conditions to determine the presence of vulnerability and the fulfillment of the definition conditions.
I hope, on this small example, you became clear how to submit information to OVAL-vulner.
The main interest of the format is its extreme flexibility. To add additional data, it is enough to adjust the scheme and point to the link. But, I will tell you about the ways of forming these files another time.
Thanks for reading, I hope I told you something new.
Source: https://habr.com/ru/post/136046/
All Articles