OVAL Language Design Document

Transcription

1 OVAL Language Design Dcument Versin The MITRE Crpratin. All rights reserved.

2 Intrductin...3 OVAL Overview...3 Implementatin f the Language...3 OVAL Definitin Schema...4 <generatr>...4 <definitins>...4 <tests>...5 <bjects>...6 <states>...6 <variables>...6 OVAL System Characteristics Schema...7 <generatr>...7 <system_inf>...7 <cllected_bjects>...7 <system_data>...8 OVAL Results Schema...8 <generatr>...8 <directives>...8 <val_definitins>...9 <results>...9 Additinal Infrmatin...9 2

3 Intrductin The purpse f this dcument is t present a detailed discussin f the design f the OVAL Language. It als serves as an intrductin t thse interested in gaining a greater understanding f the language, hw it can be used, and hw it can be incrprated int a security applicatin. The language requirements are specified within the OVAL Language Requirements dcument, and serve as the basis fr the design presented within this dcument. Thrughut this dcument, specific requirements are called when thse requirements are addressed by implementatin details being discussed. OVAL Overview Open Vulnerability and Assessment Language (OVAL ) is an internatinal, infrmatin security, cmmunity standard t prmte pen and publicly available security cntent, and t standardize the transfer f this infrmatin acrss the entire spectrum f security tls and services. OVAL includes a language used t encde system details, and an assrtment f cntent repsitries held thrughut the cmmunity. The language standardizes the three main steps f the assessment prcess: representing cnfiguratin infrmatin f systems fr testing; analyzing the system fr the presence f the specified machine state (vulnerability, cnfiguratin, patch state, etc.); and reprting the results f this assessment. The repsitries are cllectins f publicly available and pen cntent that utilize the language. The OVAL cmmunity has develped three schemas written in Extensible Markup Language (XML) t serve as the framewrk and vcabulary f the OVAL Language. These schemas crrespnd t the three steps f the assessment prcess: an OVAL System Characteristics schema fr representing system infrmatin, an OVAL Definitin schema fr expressing a specific machine state, and an OVAL Results schema fr reprting the results f an assessment. Cntent written in the OVAL Language is lcated in ne f the many repsitries fund within the cmmunity. One such repsitry, knwn as the OVAL Repsitry, is hsted by The MITRE Crpratin. It is the central meeting place fr the OVAL Cmmunity t discuss, analyze, stre, and disseminate OVAL Definitins. Each definitin in the OVAL Repsitry determines whether a specified sftware vulnerability, cnfiguratin issue, prgram, r patch is present n a system. The infrmatin security cmmunity cntributes t the develpment f OVAL by participating in the creatin f the OVAL Language n the OVAL Develpers Frum and by writing definitins fr the OVAL Repsitry thrugh the OVAL Cmmunity Frum. An OVAL Bard cnsisting f representatives frm a brad spectrum f industry, academia, and gvernment rganizatins frm arund the wrld versees and apprves the OVAL Language and mnitrs the psting f the definitins hsted n the OVAL Web site. This means that the OVAL, which is funded by US-CERT at the U.S. Department f Hmeland Security fr the benefit f the cmmunity, reflects the insights and cmbined expertise f the bradest pssible cllectin f security and system administratin prfessinals wrldwide. Implementatin f the Language The OVAL Language has been created t facilitate the exchange f infrmatin between security vendrs and tls. The language is cmpsed f three XML schemas; the OVAL Definitin schema expresses a specific machine state, the OVAL System Characteristics schema stres cnfiguratin infrmatin gathered frm a system, and the OVAL Results schema presents the utput frm a cmparisn f an OVAL Definitin against an OVAL System Characteristics instance. 3

4 OVAL Definitin Schema The OVAL Definitin schema prvides the framewrk fr cnstructing lgical statements f the fllwing frm: Is perating system X installed? AND Is service Y enabled? AND Is user Z allwed t use service Y? Each f these questins is represented by a specific machine cnfiguratin parameter, and an assciated value. The cllectin f these questins results in an expressin f a desired machine state, which can be applied t a specific system t determine its cnfiguratin in cmparisn. At the highest level, and OVAL Definitin dcument cnsists f six distinct sectins; generatr, definitins, tests, bjects, states, and variables. Each dcument typically cnsists f ne r mre individual OVAL Definitins, where the infrmatin in the tests, bjects, states and variables sectins can be shared acrss multiple definitins (Req. 2.2). The entire dcument can be signed using an ptinal digital signature (envelped) which is based upn the W3C XML Signature standard ( 1.4) <generatr> The generatr sectin is prvided as an infrmatin resurce t tls cnsuming the definitin dcument. The purpse f this sectin is t allw cnsumers t determine the tl that was used t generate the dcument (Req. 2.8), the schema versin t which the dcument applies (Req. 2.6), and a timestamp fr when the dcument was generated (Req. 2.7). Nte that the timestamp element des nt specify when a definitin (r set f definitins) was created r mdified but rather when the actual XML dcument cntaining the definitin(s) was created. <definitins> The definitins sectin serves as the cntainer fr each f the definitins cntained within an instance dcument. Each definitin is distinguished by a glbally unique identifier f the frm val:organizatin DNS Name:ID Type:ID Value where (Reqs. 2.11, 2.13): Generatr Definitins Definitin Metadata Criteria Tests Objects States Variables Digital Signature Figure 1 : OVAL Definitin Dcument Organizatin DNS Name is f the frm rg.mitre.val, and nt nly prvides a level f uniqueness t the ID, but als prvides a surce fr questins and infrmatin abut a specific definitin. ID Type dentes the entity t which the ID is being applied (Req. 2.12), and can be ne f the fllwing values: def Definitin bj Object ste State tst Test var Variable ID Value is an integer that is unique t the DNS name and ID Type pair that precedes it. Nte, the ID frmat is nt specific t the definitin ID, but extends acrss all f the glbally reusable cmpnents in the language - definitins, bjects, states, tests, and variables. 4

5 Each definitin can be further decmpsed int a <metadata> and a <criteria> sectin. The <metadata> sectin prvides descriptive header infrmatin assciated with the definitin, including; shrt title, affected platfrm infrmatin, definitin descriptin, and references t mre infrmatin (Req. 2.14). It is imprtant t nte that the affected platfrm infrmatin is prvided slely fr infrmatinal purpses and is nt meant t be used when examining the state f a system. Fr example, the affected platfrm sectin may cntain the string Windws XP, but the actual OVAL statement t test fr the existence f Windws XP n a system is cntained elsewhere in the definitin. It has als been recgnized that rganizatins may have meta-data requirements that are either, t specific t becme part f the fficial OVAL Language, r can nt be added t the schema in a timely enugh manner. Fr these reasns, an <xsd:any> element has been included as part f the <metadata> sectin. The purpse fr this element is that it allws an area f a schema in this case the <metadata> sectin t be extended, such that any infrmatin can be included at the <xsd:any> directive, but it is nt cnsidered during validatin f the dcument against the schema. The <criteria> sectin prvides the means fr cmpsing a lgical cmbinatin and nesting f tests (Req. 2.3) and/r ther definitins (Req. 2.1). The resultant lgical expressin is the actual definitin statement fr the issue in questin. In practice, the criteria is cmpsed f a cllectin f individual criterin statements, and nested criteria blcks, which are bund by the lgic peratrs AND, OR, and XOR. Each criterin statement cntains a reference t an individual system level test, a negatin flag fr cntrlling the interpretatin f a test s TRUE/FALSE result (Req. 2.4), and a cmment describing the intent f the test. In additin t the <metadata> and <criteria> sectins, an ptinal <ntes> sectin can be included within the definitin. The purpse f the ntes sectin is t prvide mre detailed dcumentatin abut specific technical aspects f the definitin. Each individual definitin can be digitally signed using an XML signature. Nte that it is just the <definitin> element (and all its children) being signed in this case and nt the referenced tests, bjects, and states. <tests> The tests sectin cntains all f the individual system level tests needed by the definitins (Req. 2.10). Fr each platfrm r applicatin addressed by OVAL, there is a crrespnding set f tests t express the varius cnfiguratin states fr that entity (Req. 2.15). The structure f each test, with respect t the infrmatin being cllected, is meant t reflect the structure f the infrmatin fr the crrespnding entity n the end hst (Req. 2.16). Fr example, fr the Micrsft Windws platfrm, there are tests fr Active Directry, the Registry, and file data. Fr Red Hat Linux, there are tests fr RPM, uname, and file data. The tests are intended t be specific t the entity being tested, s even thugh there is are file data tests fr bth Micrsft Windws, and Red Hat Linux, the nature f each f these tests is different, because the representatin f a file in each envirnment is different. While the intent f each individual test may be very different, the structure f each test is actually very similar. A test statement includes a unique id, a versin, a cmment, a check, an bject reference, and a state reference. The test ID, the frmat f which is described in the <definitins> sectin abve, is referenced in the criteria sectin within a definitin t build the definitin statement. The test versin is prvided t enable tracking and management f mdificatins t a test ver its lifetime. The test cmment prvides a brief descriptin f the purpse f the test. ID Tests Test Versin Cmment Check Object Reference State Reference The check value is used t define the relatinship between the bjects returned frm Figure 2 : OVAL Definitin the Object Reference, and the state returned frm the State Reference, when analysis Test Structure is perfrmed. The allwable values fr the check attribute are all, at least ne, nly ne, and nne exists. The meaning f these values with respect t the bject/state relatinship is as fllws: all All f the identified bjects must match the state 5

6 at least ne At least ne f the identified bjects must match the state nly ne One and nly ne bject must match the state nne exists Nne f the bjects can match the state The final tw cmpnents within a test are references t an bject and a state. The binding f these tw entities represents the specific, end system, cnfiguratin state that is being tested. A cmplete definitin f bjects and states is presented later in this dcument. Each individual test can be digitally signed using an XML signature. Nte that it is just the <xxxx_test> element (and all its children) being signed in this case and nt the referenced bjects, and states. <bjects> The bjects sectin cntains all f the system entities (e.g. files, Registry keys, packages ) that are being analyzed by a definitin (Req. 2.10). Fr each bject f interest n the platfrms supprted by the OVAL Language, there is a crrespnding schema detailing the prperties being examined fr that bject. Fr example, in the case f a Micrsft Windws Registry bject, the prperties being examined are the hive, key, and name, which represent the path cmpnents t a specific Registry key value. The reasn fr dedicating a specific sectin f the definitin t bjects is, in many cases, the same bjects are being examined ver and ver again. By assigning unique ID s t the bjects and maintaining them in a separate sectin, it allws the same bjects t be referenced frm multiple tests, and eases the task f data cllectin. Fr sme bjects, it may be desirable t cntrl the way in which it is gathered, r the amunt f data gathered. Fr this reasn, <behavir> and <filter> elements prvide a means t perfrm such actins n an bject. A <behavir> is meant t cntrl the way in which data is gathered fr an bject. Fr example, in the case f an bject that represents a directry, a <behavir> wuld state whether t recurse the directry, and in which directin the recursin shuld ccur. In the case f a <filter>, it is used t bund, r restrict the number f matching bjects cllected. Each filter is used t remve a specific subset f bjects frm a defined bject set. Fr example, an OVAL Object might be defined t represent all f the files in a particular directry. A filter may then be applied t remve all f the files frm this set whse size is greater than 100K. Each individual bject can be digitally signed using an XML signature. <states> The states sectin cmplements the bjects sectin, in that it cntains the values against which the actual system bjects are being cmpared (Req. 2.10). Returning t the Micrsft Windws Registry example frm the bject sectin the bject defines the Registry path t traverse, while the crrespnding state defines the specific value f interest, and the peratin t be perfrms when cnducting a cmparisn. As explained in the bject sectin, it is pssible t reference a single bject frm multiple tests. It is als pssible that the value cmparisn being cnducted against a specific bject can differ frm ne test t the next. Therefre, the states are defined in a distinct sectin, and each has an assciated unique ID t allw fr greater flexibility in the reuse and cmbinatin f bjects and states within a test. Each individual state can be digitally signed using an XML signature. <variables> It is nt always the case that all f the values within a definitin are knwn at the time a definitin is written (Req. 2.5, 2.10). Sme values can vary based upn an rganizatin s plicy r the specific cnfiguratin f a machine. As a result, the variables sectin cntains placehlders fr values that must be filled in at definitin executin time with ne exceptin. There are three types f variables defined in OVAL, external, lcal, and cnstant. External variables are values that have t be btained frm an utside surce e.g. user, cnfiguratin file - and plugged int the definitin at run time. Lcal variables are als intrduced int the definitin at run time, but they represent values that can be retrieved frm bjects n the system itself. Fr example, an envirnment variable hlds the file path t an applicatin, and the definitin needs that value in rder t build the full path t ne f the applicatin s files. The value f the lcal variable btained frm the envirnment variable can differ frm ne system t the next, depending 6

7 upn hw the applicatin was installed. Finally, cnstant variables represent cmmn static values used acrss a number f definitins. These variables have been brken ut and hard cded int the individual definitin dcument t ensure cnsistency acrss definitins. One final interesting aspect f variables is that it may be necessary t change the value f an individual variable during a single analysis f a definitin dcument. Fr example, a variable may be reused within multiple definitins, but its value may vary frm ne definitin t the next, based upn the cntext f the definitin itself. In these cases, when the OVAL System Characteristics, and OVAL Results dcuments are created, an instance attribute is assciated with each variable t ensure that the crrect value is assciated with the crrect definitin. Each individual variable can be digitally signed using an XML signature. OVAL System Characteristics Schema The OVAL System Characteristics schema defines a standard XML frmat fr string system cnfiguratin infrmatin. This cnfiguratin infrmatin includes OS parameters, installed sftware applicatin settings, and ther security relevant cnfiguratin values. The purpse f this schema is t prvide a database f system characteristics against which the OVAL Definitins can be cmpared in rder t analyze a system fr a defined machine state. In essence, the schema defines a standard system characteristics exchange frmat that can be incrprated int a variety f tls, such as thse listed in the OVAL- Cmpatible Prducts and Services sectin n the OVAL Web site. At the highest level, and OVAL System Characteristics dcument cnsists f fur distinct sectins; generatr, system_inf, cllected_bjects, and system_data. Each instance dcument cnsists f the cnfiguratin data cllected frm a single system. Envelping the entire dcument is an ptinal digital signature which is based upn the W3C XML Signature standard ( (Req. 1.4). <generatr> The generatr sectin is prvided as an infrmatin resurce t tls cnsuming the system characteristics dcument. The purpse f this sectin is t enable cnsumers t determine what tl was used t generate the dcument (Req. 3.4), the schema versin t which the dcument applies (Req. 3.2), and a timestamp fr when the dcument was generated (Req. 3.3). <system_inf> The system_inf sectin cntains the details abut the installed perating system, system architecture, and netwrk interfaces. The primary reasn fr gathering this infrmatin is t prvide a binding between a specific system and its crrespnding system characteristics file (Req. 3.5). <cllected_bjects> Generatr System Inf Cllected Objects Object Object System Data Item Item Digital Signature Figure 3 : OVAL System Characteristics Dcument The cllected_bjects sectin prvides a mapping between the bjects cntained within a specific Definitin dcument and the crrespnding items gathered frm the system (Req. 3.7). Each cllected bject element maintains the bject id frm the Definitin file, a reference pinter t the assciated item(s) within the system_data sectin, and a flag which cnveys the result f lcating and gathering the bject frm the system (Req. 3.6). The set f flags are: cmplete Every instance f the bject was cllected and stred in the system characteristics file. des nt exist The bject culd nt be lcated n the system. errr An errr ccurred while cllecting the bject infrmatin 7

8 incmplete Only a subset f the matching bjects n the system were cllected. nt cllected N attempt was made t gather the bject infrmatin frm the system. nt applicable The specified bject is nt applicable t the system being characterized. Nte that existence f the bject n the system can nt be inferred frm the 'incmplete' and 'nt cllected' flags. Due t the fact that bjects in the definitin can be represented as pattern matches, and that multiple items n the system can match the pattern, it is pssible fr a cllected bject t have the reference multiple items. Fr example, a Windws File Object might use the fllwing pattern match, C:\Windws\*.dll. This will result in a system characteristics dcument with an individual item fr each DLL file in the C:\Windws directry, with each item having a unique reference identifier. The definitin is expected t cntain the necessary instructins fr hw t handle multiple items cntained within the system characteristics dcument. <system_data> The system_data sectin cntains infrmatin abut the actual items gathered frm the system. Fr each item in this sectin, there is a unique reference identifier, and a status flag t reprt the result f the data cllectin. A single item may be referenced in mre than ne cllected bject sectin. OVAL Results Schema The OVAL Results schema defines a standard XML frmat fr string the results f an OVAL evaluatin f a system. The results data cntains the current state f a system s cnfiguratin as cmpared against a set f OVAL Definitins. The OVAL Results Schema allws applicatins t cnsume this data, interpret it, and take the necessary actins t mitigate the vulnerabilities and cnfiguratin issues (fr example, install patches, alter system cnfiguratin settings, and/r take external precautins t limit access t the affected systems). This schema als defines a standard vulnerability and miscnfiguratin exchange frmat that can be incrprated int a variety f tls, such as thse listed in the OVAL-Cmpatible Prducts and Services sectin n the OVAL Web site. At the highest level, an OVAL Results dcument cnsists f fur distinct sectins; generatr, directives, OVAL Definitins, and results. Each instance dcument can cnsist f results frm multiple systems, analyzed against the same set f OVAL Definitins. Envelping the entire dcument is an ptinal digital signature which is based upn the W3C XML Signature standard ( (Req. 1.4). <generatr> The generatr sectin is prvided as an infrmatin resurce t tls cnsuming the results dcument. The purpse f this sectin is t enable cnsumers t determine what tl was used t generate the dcument (Req. 4.4), the schema versin t which the dcument applies (Req. 4.2), and a timestamp fr when the dcument was generated (Req. 4.3). <directives> Generatr Directives OVAL Definitins Results System Definitins Tests System Characteristi Digital Signature An OVAL Result dcument cntains a lt f data, much f which is nt always needed by thse cnsuming it. In rder t accmmdate the needs f all f the varius results users, many f the elements within the schema are Figure 4 : OVAL Results Dcument cnfigured as ptinal. The rle f the directives is t allw the Results Prducer t indicate which elements are included in the dcument and which are nt (Req. 4.1). Fr the Results Cnsumer, the directives allw fr a quick determinatin as t whether the cntents f the dcument fulfill its needs r nt. The directives defined in this sectin are: 8

9 definitin_true Reprt definitins whse result evaluated t true. definitin_false Reprt definitins whse result evaluated t false. definitin_unknwn Reprt definitins whse result evaluated t unknwn. definitin_errr Reprt definitins whse result evaluated t errr. definitin_nt_evaluated Reprt definitins that were nt evaluated. definitin_nt_applicable Reprt definitins that d nt apply t the system in questin. With each directive, there are assciated tw attributes: reprted (true/false) State f assciated directive within the dcument. In effect, this attribute serves as a flag t indicate whether the infrmatin assciated with a given directive is cntained within a result dcument. cntent (thin/full) Depth with which assciated directive results are reprted. A value f 'thin' means nly a minimal amunt f infrmatin is prvided. This is the id assciated with an evaluated OVAL Definitin and the result f the evaluatin. The criteria child element f a definitin is nt present when prviding thin results. In additin, system characteristic infrmatin fr the bjects used by the given definitin is als nt present. A value f 'full' means that very detailed infrmatin is prvided allwing in-depth reprts t be generated frm the results. In additin t the results f the evaluated definitin, the results f all extended definitins and tests included in the criteria, as well as the actual infrmatin cllected frm the system, is present. <val_definitins> The val_definitins sectin is in fact the actual set f OVAL Definitins that were analyzed in rder t generate the results dcument (Req ). While including this dcument within the results certainly expands the size f the dcument, it eliminates the need t always have the definitins dcument present when analyzing the results dcument. It is believed that the cnvenience and reliability gained by including this infrmatin within the results, utweighs the impact f the larger dcument. Inclusin f the definitins dcument within the results dcument is ptinal. <results> The results sectin serves as a cntainer fr the analysis results f ptentially numerus systems against the OVAL Definitin dcument included in the val_definitins sectin. The results sectin is cmpsed f a number f system elements. Within each system element are the fllwing sub-elements: definitins The analysis results fr each OVAL Definitin against a specific system (Req. 4.6). tests The analysis results fr each test cntained within the OVAL Definitins against a specific system (Req. 4.7). val_system_characteristics The val_system_characteristics sectin is a cpy f the OVAL System Characteristics dcument fr the system, which was generated as a result f analyzing the given OVAL Definitins dcument (Reqs. 4.5). As with the val_definitins sectin abve, this infrmatin is prvided as a cnvenience t ensure that the results cnsumer has access t all f the infrmatin that was available t the results prducer. Unlike the val_definitins sectin, it is required t have the System Characteristics dcument present. Additinal Infrmatin Fr a mre detailed definitin f each f the OVAL Language elements, please cnsult the element dictinaries r refer t the dcumentatin cntained within the individual schema dcuments. Fr these dcuments and additinal 9

10 infrmatin abut OVAL, please visit t the OVAL Web site at r send an t val@mitre.rg. 10