Community Participation > Archives > OVAL Patch Definition Working Group: Teleconference - 1 November 2005

OVAL Patch Definition Working Group

Teleconference - 1 November 2005

Attendees

Chris Andrew, PatchLink Corp.
Barry Day, DesktopStandard Corp.
Tim Fessenden, BladeLogic, Inc.
Kent Landfield, Citadel Security Software
Eric Voskuil, DesktopStandard Corp.
Matthew Burton, MITRE Corp.
David Proulx, MITRE Corp.
Matthew Wojcik, MITRE Corp.

Purpose

The purpose for this meeting was to resume the discussion of OVAL Patch Definitions begun at OVAL Developer Days (http://oval.mitre.org/documents/docs-05/developer_days_minutes.html#s3.1). The format of the meeting was to ask a few high-level questions about patching in order to get a sense for the needs of the community, and to determine if the approach proposed at Developer Days will meet those needs.

Meeting Summary

Discussion was initiated with the following question - "What do we believe are the expectations of the community in having patch information encoded in OVAL?" Answers included:

  • To bring information associated with patches out into the open.
  • To encourage software and operating system vendors to start publishing patch information in a standard format.
  • To develop a standard that will facilitate exchange of patch information between tools.
  • To see OVAL expand beyond vulnerability definitions, and move more towards a general configuration management language.
  • That the approach taken by OVAL will add value to the methods currently in use today by remediation vendors.

With these issues in mind, the next question asked was, "What does it mean for an OVAL patch definition to return true? Is it fair to set the scope for the definition to be: "A definition that returns true means that the patch in question is technically applicable to the system against which the definition was executed"? The key terms in this statement are "technically applicable." While a system may have the necessary preconditions for installing a specific patch, there may be external factors (e.g., organization policy, software conflicts) that cause it not to be installed. Such factors fall outside the scope of the OVAL Patch Definition.

This question resulted in a number of follow-on questions, and how they should be handled within the definition. In addition to testing for whether a specific patch is applicable to a system:

  • Should the definition test for whether a patch is currently installed on a system?
  • Should the definition test for whether the patch is configured correctly?
  • How should the definition handle patch pre-conditions and conflicts?
  • Should the definition deal with multiple patch solutions - whether they be actual patches or workarounds - that in many cases are not all generated by the original software vendor?
  • What meta-data needs to be associated with the definition?

The outcome of this discussion was that these are the kinds of core questions that need to be identified and answered, before beginning the task of actually creating definitions. It was also decided that the strength of OVAL is detecting machine state, and that this should continue to be the case with patch definitions. While there is some amount of meta-data associated with a patch (e.g., Installation flags, reboot requirements, checksum), OVAL should focus on answering the technical applicability question, and try to minimize the amount of associated meta-data. There was further discussion about the ability of the Open Software Description (OSD) Format (http://www.w3.org/TR/NOTE-OSD) being able to support some of these meta-data needs, but it was decided that this isn't really a good fit.

The final question asked of those assembled was: "Does OVAL currently support the necessary tests to gather all of the information necessary for a patch definition, and if not, where does the language need to be extended?" The general consensus was that based upon a defined scope of detecting technical applicability of a patch, OVAL may not have all of the necessary tests at the moment, but it does have the necessary structure to fulfill this goal, and for those tests that do not exist or will not meet the needs of a patch definition, they can easily be added or modified. Example of the tests that may need to be added or modified include Microsoft Windows Installer (MSI) and Windows Management Instrumentation (WMI).

The meeting concluded with attendees agreeing upon the following next steps in the discussion:

  • Enumerate the questions associated with the technical applicability of patches (e.g. Preconditions, post conditions, conflicts) and the content of an OVAL Patch Definition (e.g. meta-data).
  • Enumerate the use cases for OVAL Patch Definitions.

The discussion for each of these topics will be conducted on the OVAL Developer's mailing list.

Back to top

Page Last Updated: January 18, 2011