OVAL - OVAL Board Minutes: Teleconference 2006-08-31

OVAL Board Minutes

2006-08-31

Attendees

David Waltermire - Center for Internet Security
William McVey - Cisco
Kent Landfield - Citadel
Carl Banzhof - Citadel
Darmin Ammala - Harris
Anton Chuvakin - LogLogic
Jay Graver - nCircle
Tim Keanini - nCircle
Chris Andrew - PatchLink
Scott Carpenter - SecureElements
Rob Hollis - ThreatGuard
Nils Puhlmann
Matthew Wojcik - MITRE
Jon Baker - MITRE
Drew Buttner - MITRE
Steve Boczenowski - MITRE
Dave Proulx - MITRE
Margie Zuk - MITRE

Agenda

Status Update
Expectations for OVAL Board representation
OVAL Intellectual Property agreement

Meeting Summary

OVAL Status Update

New Version: OVAL version 5.0 was finalized and accepted on June 16, 2006. All Repository content was converted to version 5, and the old format has been archived.

Developer Days conference: The second OVAL Developer Days were held July 11-12, 2006. The conference was very productive again this year. Minutes are available on the OVAL web site at http://oval.mitre.org/about/developer_days.html

Repository Submissions: MITRE is changing its review procedure for content submitted to the Repository. With the aim of facilitating community review, new content will be made available on the web site with 48 hours whenever possible. The DRAFT status review period will be used for more comprehensive proofreading of submissions. More details are available at http://making-security-measurable.1364806.n2.nabble.com/Suggestion-idea-for-community-submitted-content-tp21327p21327.html

NIST Checklist Program: MITRE has been working closely with NIST to support their integration of OVAL and XCCDF into the NIST Security Configuration Checklist program. A goal of the program is to automate FISMA compliance. NIST is holding a two-day event, the National Security Automation Conference & Workshop, September 18 & 19, focused on this program, its use of XCCDF, OVAL, and related standards, and how the program fits into the broader security landscape. Presenters include federal government officials, as well as MTIRE and other OVAL Board members.

Compatibility: MITRE continues internal discussions around the OVAL Compatibility program. We are working to anticipate types of products or services which may be brought forward for Compatibility, and more clearly define requirements for various capabilities. Correctness testing will also present a larger burden with increased use of OVAL, and we are exploring ways to meet that challenge.

RSA: MITRE has had a booth focusing on OVAL, CVE and related efforts at RSA for a number of years, as do many OVAL supporters. We're working on ways to more successfully spread the OVAL message at RSA 2007, including a multi-vendor demonstration of OVAL Compatible capabilities during the vendor exhibition. Organizations interested in participating should contact oval@mitre.org. MITRE is also aware of a few different talk and panel proposals submitted for the conference that focused on or included OVAL.

Primary Source Vendors: MITRE continues to engage with vendors of operating systems and applications to encourage the release of OVAL content with security advisories, patch notifications, configuration guidance, etc. A major milestone in OVAL's adoption came in June, when Red Hat began publishing OVAL patch definitions for all errata for Red Hat Enterprise Linux 3 and 4. As well as providing authoritative content for Red Hat security issues, this also serves as an important proof of concept to other vendors. The OVAL team can help vendors develop a process for producing OVAL content. NIST is also involved in outreach to urge vendors to publish secure configuration guidance for their products in XCCDF and OVAL in conjunction with the NIST checklist program.
Landfield suggested increased visibility of links to primary source vendor OVAL content on the OVAL website. MITRE agrees that's desirable, and will look into it. Other website feedback is welcome at oval@mitre.org.

Board Membership Changes: A number of new members of the Board were added just recently, mostly replacing departing representatives from various organizations. Timothy "TK" Keanini and Jay Graver from nCircle, and Scott Carpenter of Secure Elements are participating in their first Board meeting. Email with more details of the membership changes will be sent to the lists.

Web App: New features are being developed for the OVAL Repository section of the web site, in response to requests from Developer Days and internally. One planned feature is to provide statistics of contributions by individual and organization, to better acknowledge the efforts that go into building and improving the Repository.

Definition Interpreter: Development also continues on the Definition Interpreter. Additional probes (data collection functions) have been added to support more of the Windows schema. Support for OVAL v. 5 sets has been expanded. External variable support has been added. A cleanup of the Linux version of the Interpreter is planned, with an improved RPM for Red Hat systems, and a cleaner generic Linux source code distribution. Additional probes are also planned.

Wojcik reminded the Board that the Definition Interpreter is provided as a reference implementation, and is not optimized for efficiency, features, or ease of use. Developing the Interpreter also gives the OVAL team direct operational experience with the features of the OVAL language. The Interpreter is not meant to compete with any other implementations.

Hollis asked about the Interpreter's license--since the license is currently fairly non-restrictive (BSD license), the code can be incorporated in other offerings; is this what is intended? Wojcik explained that the license had been somewhat more restrictive originally (GPL), but Board members suggested the change, to encourage adoption of OVAL; when this was raised to the Board, there were no objections. As OVAL's adoption spreads, it may be appropriate to reconsider the license again. Also, the Interpreter itself is not officially OVAL Compatible, so any product or service incorporating the Interpreter must still add value to be considered for the Compatibility program.

Hollis asked about Compatibility for products that incorporate a library or other tool that provides OVAL capabilities: if the included library is OVAL Compatible, is the larger product? If the included library is not OVAL Compatible, can the larger product be OVAL Compatible?

Wojcik replied that in that scenario, the larger product is assessed for OVAL Compatibility. If the included library or tool is OVAL Compatible and is used correctly, the larger product should easily qualify for Compatible status. Even if the included library is not officially OVAL Compatible however, the larger product could still achieve Compatibility by demonstrating it meets the program requirements. An example would be an OVAL library developed by an organization which was not publicly distributed, but used in several products. Those products could all be put forward for Compatibility, even though the library would not be

Board Member Expectations

As the OVAL Board has grown and matured, MITRE has recognized the need to set expectations for Board members. The Board was originally tasked with OVAL schema development as one of its primary responsibilities, but the Developer list community (including but not limited to Board members) has largely taken over this role. There have been suggestions that the Board transition to a more strategic body, highlighting members' responsibilities to act as advocates of OVAL in the information security community.

Following discussion on this topic at the last Board meeting in May, MITRE has drafted a set of expectations:

Members should attend the quarterly teleconferences, notifying MITRE if they cannot participate in a scheduled call.

Members must be subscribed to the OVAL Discussion and Developer email lists as well as the Board list, and should make an effort to keep abreast of topics on those forums.

Members should act as advocates for OVAL in the community, seeking ways to promote the standard and educate people about OVAL.

Members should provide input to MITRE on OVAL's strategic direction and the growth of the project.

There has also been discussion of whether organizations should be limited to one OVAL Board representative. This would help limit the size of the Board, and provide a single point of contact for Board matters. A drawback to this approach is that very large organizations might naturally want more than one Board representative with different areas of expertise. Also, some organizations that currently are on the Board have a CTO-level representative who focuses more on strategic matters and has the ability to strongly advocate OVAL within their organization and to the community, and a more tactical person who is more frequently involved in day-to-day OVAL discussions. This has sometimes proved very effective in the past.

One option to dealing with multiple Board representatives would be to formalize various roles for Board members, perhaps an advocacy role and a technical role. CVE adopted a similar approach for its Editorial Board with some success.

There was basic consensus among call participants that multiple representatives can be useful, particularly if roles are better defined.

The idea was discussed of requiring organizations on the Board to work towards OVAL Compatibility in their products or services, as appropriate. Some were in favor, but others were opposed. If an organization is on the OVAL Board, it should be committed to the standard. However, a Board representative from a large organization may not be able to institute such a change, but could provide valuable expertise to the project and work over time for OVAL adoption by their organization. Also, adopting OVAL means different things for different types of organizations, and may be hard to measure. A compromise could be to say that Board members "should" work to incorporate OVAL as appropriate.

Regarding the email lists: Board members feel that traffic is not too heavy to keep up with. More clarity on what each lists is intended for would be helpful. MITRE will improve description of lists on the web site and in the welcome messages sent to each new subscriber. In general, the Developer list is for language feature requests and implementation issues, and the Discussion list for topics around content in the OVAL Repository or how to write OVAL definitions for a particular purpose.

OVAL Intellectual Property Agreement

With the growth in OVAL's adoption, MITRE has been asked to formalize the intellectual property terms for participation in the project and use of the standard. A draft agreement was sent to the lists for comment in October 2005, and received a lukewarm reception. Recently, the OVAL team has been meeting with MITRE's legal department again in another attempt to create an IP agreement. A high-level overview of our goals for such an agreement was sent to the Board list shortly before this teleconference.

MITRE holds a trademark on the name OVAL, and hence has control over what can legally be called "OVAL." MITRE, of course, is a not-for-profit organization chartered to act in the public interest. In line with the goals of the OVAL initiative, MITRE's charter, and the project's sponsor's direction, OVAL must remain an open specification, usable (and hopefully useful) in a variety of free and commercial products and services without undue encumbrance. It must not be co-opted by particular special interests.

With that in mind, the layman's overview of the goals for the IP agreement are:

1) The OVAL schema must be protected so that it is publicly available, and so that an outside interest cannot extend it and then claim it as his/her own. In other words, the language itself must remain an open specification.

2) Content in the MITRE OVAL Repository must remain available for public use. Content created by outside parties and submitted to MITRE for inclusion in the Repository is granted to MITRE.

3) MITRE claims no ownership of OVAL content generated by outside interests and not provided to MITRE for inclusion in the Repository. However, MITRE reserves the sole right to determine whether outside content is OVAL Compatible.

Regarding point 1, Keanini raised the question of extensions of the schema either for proprietary use, or because the official schema approval process would be too slow. Is there no way to extend the schema other than the formal channels? Wojcik replied that organizations are free to extend the schema, but cannot claim that any extension is OVAL.

Baker mentioned that a significant point of concern to the OVAL project is the idea of some outside party creating a schema for a platform not currently supported by the official standard, and then claiming ownership of that schema, to the exclusion of the open project. Since OVAL schemas track very closely with the native interfaces of a platform, rather than involving abstractions, two schemas developed independently for the same platform could look very similar. This is a major motivation for point 1.

Regarding point 2, McVey asked what license would apply to content in the Repository. Baker replied that the current "free to use" terms would likely remain, with the addition that MITRE's terms of use be carried along with any use of Repository content.

Regarding point 3, Hollis asked if MITRE would require outside collections of OVAL content to be registered as OVAL Compatible. Wojcik replied that it would not be required, but those collections could not be represented as officially OVAL Compatible (or otherwise use the OVAL mark) unless verified by MITRE. If asked, MITRE would indicate that it has no knowledge whether unvetted repositories are using OVAL correctly or would work with OVAL Compatible tools or services.

When a more formal legal draft of the IP agreement is available, it will be sent to the Board list for comment. MITRE will schedule a teleconference to discuss that draft.

Action Items

Provide more obvious links to primary-source vendor content on the web site

Provide a Compatibility use-case document, with examples for the various Compatibility types

Clarify the respective purposes of the Discussion and Developer email lists, on the web site and in list welcome messages, and consider changing the list names