OVAL integration in OpenVAS / System Characteristics

[Jan-Oliver Wagner-2]

Hi,

I am sending this on behalf of my collegue who still waits for getting approved
for the OVAL mainling lists:
 

Hello,

We are currently in the process of adding OVAL support to the OpenVAS
Vulnerability Scanner (see
http://n2.nabble.com/Integrating-OVAL-(ovaldi)-into-OpenVAS-td24066.html).

We are not yet sure as to what would be the best way to support OVAL, so I
would very much appreciate comments from people involved in the OVAL
community.

OpenVAS scans remote machines and collects information on a per-machine basis
in a so called Knowledge Base (KB). We want to be able to use this KB to
check for security issues specified in OVAL definition files.

Our first idea was to add code to ovaldi for probes that would retrieve
information from the KB instead of accessing the real system (see
http://www.openvas.org/openvas-cr-13.html). While I'm confident this would
work, I'm no longer sure if this is the best way to go.

A better way IMHO would be to make OpenVAS an OVAL System Characteristics
Producer (as specified at
http://oval.mitre.org/compatible/requirements.html#system_characteristics).
This would enable use to use more OVAL compatible tools and not just ovaldi.
If I understand the specifications correctly, this would be the preferable
way, wouldn't it?

A first step for this approach would be to make OpenVAS create a System
Characteristics file from its KB. While the generator, system_info and
system_data entities should be relatively easy, I'm having trouble with the
collected_items entity as it seems to refer to certain OVAL tests.

We would like to create the SC file first and fill it with all the information
available in the KB that might be of use to the OVAL definitions and then
hand it to ovaldi or any other SC consumer. This means we do not know
beforehand which test will be used against this file and cannot refer to any
specific tests in the collected_items section.

I tried removing/emptying the collected_items section (or the IDs) from an
existing SC file and fed this file to ovaldi, but it did not work as I
expected.

So my question at this point is: Would it be possible to leave out the
references to the OVAL test and still use the resulting SC file as input for
an OVAL scan? Or am I missing something here?

I read in Jons tutorial (at https://nvd.nist.gov/scap/docs/conference 
presentations/workshops/OVAL Tutorial 3 - System Characteristics.pdf) that
this might be possible, but was unable to find more information on this.

I think OVAL would make a great addition to the OpenVAS framework and I would
like to get OVAL support into OpenVAS as soon as possible, so I'd really
appreciate any comments on this.

Regards,

Michael

To unsubscribe, send an email message to LISTSERV@... with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to OVAL-DEVELOPER-LIST-request@....

[bakerj]

Jan and Michael,

I have included comments inline below.

>-----Original Message-----
>From: Jan-Oliver Wagner [mailto:jan-oliver.wagner@...]
>Sent: Tuesday, August 19, 2008 4:16 AM
>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>Subject: [OVAL-DEVELOPER-LIST] OVAL integration in OpenVAS / System
>Characteristics
>
>Hi,
>
>I am sending this on behalf of my collegue who still waits for getting
>approved
>for the OVAL mainling lists:
>
>
>Hello,
>
>We are currently in the process of adding OVAL support to the OpenVAS
>Vulnerability Scanner (see
>http://n2.nabble.com/Integrating-OVAL-(ovaldi)-into-OpenVAS-
>td24066.html).
>
>We are not yet sure as to what would be the best way to support OVAL, so
>I
>would very much appreciate comments from people involved in the OVAL
>community.
>
>OpenVAS scans remote machines and collects information on a per-machine
>basis
>in a so called Knowledge Base (KB). We want to be able to use this KB to
>check for security issues specified in OVAL definition files.
>
>Our first idea was to add code to ovaldi for probes that would retrieve
>information from the KB instead of accessing the real system (see
>http://www.openvas.org/openvas-cr-13.html). While I'm confident this
>would
>work, I'm no longer sure if this is the best way to go.
>
>A better way IMHO would be to make OpenVAS an OVAL System
>Characteristics
>Producer (as specified at
>http://oval.mitre.org/compatible/requirements.html#system_characteristic
>s).
>This would enable use to use more OVAL compatible tools and not just
>ovaldi.
>If I understand the specifications correctly, this would be the
>preferable
>way, wouldn't it?
>

I agree this sounds like a better solution. We have always wanted to support applications creating their own system-characteristics (SC) file for other application to assess. As you said by creating an output SC file OpenVAS should be able to interoperate with any tool that can consume an SC file.

How do you control what OpenVAS writes to the its output SC file? Typically we drive the contents of the SC file off the needs of an OVAL Definition document. The generated SC file is assumed to be complete when it is used for analysis. This means that a compatible interpreter should make the assumption that if a item needed for evaluation is not found in the SC file it can safely assume that the item does not exist. I tend to think of this as a requirement that the SC file is complete for all the data needed for the evaluation of a given OVAL Definition document.

>A first step for this approach would be to make OpenVAS create a System
>Characteristics file from its KB. While the generator, system_info and
>system_data entities should be relatively easy, I'm having trouble with
>the
>collected_items entity as it seems to refer to certain OVAL tests.
>
>We would like to create the SC file first and fill it with all the
>information
>available in the KB that might be of use to the OVAL definitions and
>then
>hand it to ovaldi or any other SC consumer. This means we do not know
>beforehand which test will be used against this file and cannot refer to
>any
>specific tests in the collected_items section.
>
>I tried removing/emptying the collected_items section (or the IDs) from
>an
>existing SC file and fed this file to ovaldi, but it did not work as I
>expected.
>
>So my question at this point is: Would it be possible to leave out the
>references to the OVAL test and still use the resulting SC file as input
>for
>an OVAL scan? Or am I missing something here?
>
>I read in Jons tutorial (at https://nvd.nist.gov/scap/docs/conference
>presentations/workshops/OVAL Tutorial 3 - System Characteristics.pdf)
>that
>this might be possible, but was unable to find more information on this.
>

As you discovered this is not something that the OVAL Interpreter currently supports. It has always be on the list of capabilities to support as a nice to have, but never quite made it to the top of the list.

>I think OVAL would make a great addition to the OpenVAS framework and I
>would
>like to get OVAL support into OpenVAS as soon as possible, so I'd really
>appreciate any comments on this.
>
>Regards,
>
>Michael
>
>To unsubscribe, send an email message to LISTSERV@... with
>SIGNOFF OVAL-DEVELOPER-LIST
>in the BODY of the message.  If you have difficulties, write to OVAL-
>DEVELOPER-LIST-request@....

To unsubscribe, send an email message to LISTSERV@... with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to OVAL-DEVELOPER-LIST-request@....

[mwiegand]

Am Montag, 22. September 2008 23:18:40 schrieb Baker, Jon:
> How do you control what OpenVAS writes to the its output SC file? Typically
> we drive the contents of the SC file off the needs of an OVAL Definition
> document. The generated SC file is assumed to be complete when it is used
> for analysis. This means that a compatible interpreter should make the
> assumption that if a item needed for evaluation is not found in the SC file
> it can safely assume that the item does not exist. I tend to think of this
> as a requirement that the SC file is complete for all the data needed for
> the evaluation of a given OVAL Definition document.

I agree, it should be in the responsibility of the collecting tool (be it an
ovaldi probe or a different approach) to collect a complete SC file for the
purpose required.

The only drawback I can see with this approach that this could lead to the SC
file becoming quite large if the purpose is not known beforehand, as it is
the case in this context. This might cause a slowdown in ovaldi, especially
if it has to search the SC file in absence of a collected_objects element.

But from our experience so far this seems to be minor issue. We did test runs
with a SC file containing a few hundered entries and the somewhat crude
search method I provided in my patch and did not notice any adverse effects.

> As you discovered this is not something that the OVAL Interpreter currently
> supports. It has always be on the list of capabilities to support as a nice
> to have, but never quite made it to the top of the list.

Well, I hope the patch I send in on September 16 will prove useful towards
that end. I'm looking forward to hearing your opinion regarding the patch.

Regards,

  Michael

--
Michael Wiegand                                   OpenPGP key: D7D049EC
Intevation GmbH, Osnabrück                    http://www.intevation.de/
Amtsgericht Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

To unsubscribe, send an email message to LISTSERV@... with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to OVAL-DEVELOPER-LIST-request@....