Community Participation > Archives > OVAL Board Minutes: 1:00-2:15 p.m. EDT, 19 August 2004

OVAL Board Minutes

1:00-2:15 p.m. EDT, 19 August 2004

Attendees

Board Members:
Raffael Marty - ArcSight
Kent Landfield - Citadel
James Foster - CSC
Darwin Ammala - Harris
Bill Wall - Harris
Dan Bezilla - Secure Elements
Mark Cox - Red Hat
Jay Beale - Bastille Linux
David Waltermire - CIS
Matthew Wojcik - MITRE
Other Attendees:
Gene Skiba - eEye
Marc Maiffret - eEye
Robert Martin - MITRE

Agenda

  • OVAL status update
  • System Characteristics & OVAL Results schema enhancements
  • OVAL Compatibility

Meeting Summary

OVAL status update:

  • MITRE continues Red Hat and Windows coverage
    • MITRE still only author of new definitions
    • MITRE is working to encourage others, especially primary-source vendors
  • Approximately 120 new definitions since last Board meeting in May
  • Compatibility & other community outreach is major focus
    • ArcSight posted first OVAL Compatibility declaration
    • Working actively with others who have agreed to make declarations
  • Tool development
    • Interpreter maintenance is ongoing
    • Porting interpreter to other platforms in pending, but back-burner
    • Solicited others to port, but no takers yet
    • Significant work in progress on definition authoring tools, but not ready for redistribution (in-house tool). Functions include:
      • Test library searching
      • Test consistency (eliminate different versions of same test)
      • Avoid redundancy
      • Avoid XML syntax drudgery
  • Policy Compliance definition work in progress
    • DISA gold disk collaboration
    • CIS collaboration
    • Some Cisco IOS configuration definitions have been written, but IOS schema yet to be officially proposed
  • Windows XP SP2 will soon be major impact on content effort
  • OVAL is appearing as requirement in various contracts, RFPs, etc.

Raffael Marty: How many people are using OVAL? Downloads, interpreter use, etc?

Matthew Wojcik: Some stats are available, mostly web logs, which are polluted by web crawler hits. Since tracking began in April 2004, oval.mitre.org has averaged about 40,000 hits per month, discounting requests from the mitre.org domain.

The SQL-based interpreter is still getting more downloads than XML, but that may be due to crawlers. Email queries tend to focus on XML.

The Community Forum is up to approximate 125 members, new subscribers come periodically. The Data-Updates list has 44 subscribers, and the Announce list has 33.

Dave Waltermire of CIS mentioned that they're about to translate their Windows XP benchmark into OVAL / XCCDF. He estimates this will translate to around 200 new OVAL policy compliance definitions. CIS is very interested in the definition authoring tools MITRE is developing.

Wojcik gave an overview of the tool:

OVAL definitions are actually stored in mySql database behind the scenes at the moment. Tests are stored in database tables with IDs, etc. Relational structures are used to link tests with logical operators into full definitions, metadata is included, etc. Scripts generate XML, SQL, and pseudo-code from database.

The definition writing tool is comprised of PHP scripts which work against that database, accessed from a web browser through an Apache web server. It allows you to search the test library, edit tests, create new tests, copy-and-edit for derivative tests, build combination tests, make full definition and specify appropriate metadata. ID generation, modification and creation dates are handled.

The main benefits for writers: don't have to write XML syntax; enforces schema adherence; facilitates test library searching to avoid test redundancy.

The code is very much in development, has rough edges, and is not ready for distribution yet, but MITRE's intention is to develop *some* capability to assist other organizations in writing OVAL definitions. Redistribution difficulties: if accessible through the OVAL web site, serious authentication & security issues. If distributed, ID conflicts can arise, plus semantic redundancy (different organizations creating tests to accomplish the same thing). The current tool could probably be shared with close collaborators before long, but much manual sync work would be needed at this point.

Schema modifications

The System Characteristics and OVAL Results schemas need to allow for better host identification information (Raffael Marty pointed this out previously). Also, all schemas should have a place for what tool or organization generated the file (collection and analysis may be by different tools).

The SC and OR schemas are currently at INTERIM for the first version, would go to ACCEPTED soon, but MITRE may wish to add this information to the schemas before the first version is finalized. The general proposal is to add in primary hostname, and a more complete network interface section. Details to come to the Board list and Community Forum.

Wojcik: Comments?

Marty: That kind of additional system information / identification section would be very helpful.

David Waltermire: Any thoughts of extending the OR format to include detailed information on what exactly passed or failed for every test?

Woj: That's sort of in there already: there is a binary true or false for each test in the results file. Combining SC & OR files with the original definition file gives the complete picture: what was being tested for, what was found, and did that match?

Woj: We at MITRE have been realizing that OVAL will have to become more careful about changing schemas in the (near) future, because products and services will be compatible and relying on them. MITRE solicits the Board's help in guiding that process, so we don't make changes too rapidly.

OVAL Compatibility

A new web site section has been added since the last Board meeting in May 2004, more clearly defining compatibility. Included is a declaration section, where organizations can publicly state their intent to be OVAL compatible. ArcSight, Inc submitted the first declaration; more are in progress.

The compatibility section lays out categories of compatibility thought of so far, and how various products and services would fit into those categories. There are no hard requirements yet, e.g. how many categories you have to fit to be compliant.

Woj: My opinion is that eventually tools or services should be compatible in every category that makes sense for that product or service. Currently, any intent to be compatible would be enough to let you get started in the process.

Bob Martin: OVAL compatibility is inherently more complex than CVE compatibility; while CVE breaks down into 3 simple categories, OVAL has more categories and more ways things can fit in. It becomes a matrix. [Martin is the CVE Compatibility lead and is working on defining OVAL Compatibility as well.]

The current description of the OVAL Compatibility process is a beginning, much like the early CVE Compatibility process. Declarations are first, but eventually there will be a more detailed questionnaire structure, and then a validation process. OVAL Compatibility will evolve. A start was needed because of published requirements, and industry demand to be recognized as compatible.

Bill Wall: How will compatibility be tested? Take people's word, folks send MITRE tools for testing, or what?

Woj: Verification will be a component of the process eventually, but the exact form is tbd. Syntax and schema usage should be easy to verify; ability to interpret any valid definition is harder but feasible; semantic verification will be much more difficult. Need a whole test lab? MITRE likely doesn't have resources to do thorough validation for every potential platform or application covered by OVAL.

Martin: In developing the CVE process, MITRE worked hard to find the sweet spot of value of award vs. effort required from both MITRE and applicant. The work needs to be sustainable.

Woj: OVAL compliance must mean something valuable, but validation can't be enormous effort.

Dan Bezilla: Sounds like we're talking about two kinds of validation: syntactic and semantic. Syntax should be achievable, but is there a way to do semantic checking without killing ourselves?

Woj: Side note: two kinds of semantic checking: actual OVAL interpretation vs. equivalence.

Semantic checking clearly presents challenges. MITRE cannot expect to be able to always perform that validation; what about platforms we don't have? MITRE is not a test lab.

Martin: We had thought of using SC files as exemplar systems, to provide a known environment. But that would impose a requirement for reading SC files.

Bezilla: Seems to establish (at least) two levels of compatibility: syntactic is level one; semantic checking against SC files level 2; in-depth lab testing against real systems for semantics might be level 3.

Woj: Not 100% sure that's how I would see the levels break down, but compatibility levels could be appropriate. There's precedent in CVE compatibility levels.

Martin: Though those have to do with what stage of the process you've gone through.

Bezilla: I think we will definitely need levels of compatibility. Having declarations be level 1 (low barrier) will encourage people to get involved; higher levels would allow the government to have a requirement for level 4 compatibility to leverage the value of the process.

Marc Maiffret: Compatibility seems straightforward to eEye at this stage of our effort.

Wall: Will OVAL compatibility require CVE compatibility (or vice-versa)?

Woj: Very good question. I'd been assuming so. My only initial reservation is that "stacking" requirements might alienate some from pursuing OVAL compatibility (additional level of effort).

Kent Landfield: If OVAL compatible, should be CVE compatible.

Martin: If someone's going for the higher levels of OVAL compatibility, then going through the additional step of checking CVE usage shouldn't be difficult.

Marty: I disagree; people might be using CVE but not wanting to implement all the requirements for official CVE compatibility, e.g. search.

Martin: Also, not all OVAL definitions will include CVE entries (compliance definitions).

Woj: Not all tools would have to: data collection tools (SC compatible) wouldn't need CVEs.

Waltermire: CIS's content is all regarding compliance, so CVEs not used much, but there's a clear fit for OVAL Compatibility.

Woj: OVAL might actually lead to use of CVEs for some (VA) tools that aren't yet CVE compatible, since OVAL vulnerability definitions include CVE ids.

After the discussion, it was suggested that perhaps OVAL Compatibility should include a strong recommendation for CVE Compatibility where appropriate, but not a requirement. MITRE will continue its work to define and refine the OVAL Compatibility process, and invites Board comment at any time.

Back to top

Page Last Updated: February 07, 2008