One area that we have talked about improving for Version 6 of the OVAL
Schema is the OVAL Object. One of the bigger issues that has come up
is when a given object can be represented multiple different ways. For
example, a file object might sometimes need to be split into 'path' and
'filename', but other times might need to be represented as just one
entity that is the full 'filepath' In this email, I would like to dive
deeper into this issue and start to formulate a proposal for the
version 6 schema.
Another example of where this issue arises is with accounts on Windows.
Sometimes we want to represent them as SIDs, while other times we want
to use the trustee name.
Let's look at the Windows <file_object> as currently found in the OVAL
Schema:
<xsd:element name="file_object">
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="oval-def:ObjectType">
<xsd:sequence>
<xsd:choice>
<xsd:element ref="oval-def:set"/>
<xsd:sequence>
<xsd:element name="behaviors" minOccurs="0"/>
<xsd:element name="path"/>
<xsd:element name="filename" nillable="true"/>
</xsd:sequence>
</xsd:choice>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
What we would like to do for Version 6 is the following. Notice the
added choice structure that allows either path/filename or filepath.
<xsd:element name="file_object">
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="oval-def:ObjectType">
<xsd:sequence>
<xsd:choice>
<xsd:element ref="oval-def:set"/>
<xsd:sequence>
<xsd:element name="behaviors" minOccurs="0"/>
<xsd:choice>
<xsd:sequence>
<xsd:element name="path"/>
<xsd:element name="filename" nillable="true"/>
</xsd:sequence>
<xsd:sequence>
<xsd:element name="filepath"/>
</xsd:sequence>
</xsd:choice>
</xsd:sequence>
</xsd:choice>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
Note that the file_state and the file_item would have all three
entities (path, filename, filepath).
On the plus side for this approach is that existing content would not
be invalidated. We would just be allowing the addition of new types of
content that tools would have to be able to recognize.
The downside to this is that it adds a feature that will show up in
only certain objects. Throughout OVAL's history, we have been very
careful to try and keep related things in the language following a
similar design. That way, once you learn the structure of one OVAL
Test you can quickly learn how all the other OVAL Tests work. We feel
that this has really helped the adoption of OVAL.
With the added choice element, some objects will follow a different
structure than other objects, and this might confuse new users as they
are trying to learn OVAL.
On the other hand, the only other solution that I see is to create
entirly different objects, and that does not seem like the right
approach either.
Thoughts?
---------
Andrew Buttner
The MITRE Corporation
[hidden email]
781-271-3515
To unsubscribe, send an email message to
[hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message. If you have difficulties, write to
[hidden email].
