Additions to win-def:wuaupdatesearcher

[Timothy Harrison]

Folks,

After testing the win-def:wuaupdatesearcher_test there are a few additions which I would like to put up for consideration.

Currently, the update_id child element of win-def:wuaupdatesearcher_state uses the updates UUID.  This ID  appears to be available within Windows WMI and is not published anywhere as far as I able to find.

If the option(s) existed to retrieve the values of the KBArticleIDs and/or SecurityBulletinIDs properties it may be easier to test for and identify the installed updates.  Additionally there is a SupersededUpdateIDs perperty which may could potentially be used to prevent fails when updates are superseded.  It may be worthe noting that these are all properties of the same IUpdate interface from which the OVAL Interpreter currently obtains the UUID.

Based on this I would like to suggest that a behavior be added to the win-def:wuaupdatesearcher_object to trigger the inclusion of SupersededUpdateIDs and child elements be added the win-def:wuaupdatesearcher_state for the KBARticleID and/or SecurityBulletinID.

One final item, the IUpdatSearcher interface used by OVALDI to perform searches specified by the win-def:wuaupdatesearcher_object has properties to specify whether to search online or offline as well as to whether to search a Windows Update site or some other site as defined by the ServiceID property.  I am not entirely familiar with how these work, but they may be of beneift for certain environments where a non-Windows Update server is preferred or the system has no online connection.  This may or may not be something we need to add support for in OVAL, but I wanted to put it out there for others weigh-in on.

Respectfully,
Tim Harrison
SCAP Content Development
National Institute of Standards and Technology
[phone]
[hidden email]
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].

[bakerj]

Tim,

Thanks for bringing these issues up. How about this for a new behavior?

<xsd:complexType name="WuaUpdateSearcherBehaviors">
  <xsd:annotation>
    <xsd:documentation>The WuaUpdateSearcherBehaviors complex type defines a number of behaviors that allow a more detailed definition of the wuaupdatesearcher_object being specified.  Note that using these behaviors may result in some unique results.  For example, a double negative type condition might be created where an object entity says include everything except a specific item, but a behavior is used that might then add that item back in.</xsd:documentation>
  </xsd:annotation>
  <xsd:attribute name="include_superseded_updates" use="optional"  type="xsd:boolean" default="true">
    <xsd:annotation>
      <xsd:documentation>
        'include_superseded_updates' is a boolean flag that when set to true indicates that the search results should include updates that are superseded by other updates in the search results. When set to 'false' superseded updates should be excluded from the set of matching update items. The default value is 'true'.
      </xsd:documentation>
    </xsd:annotation>
   </xsd:attribute>
</xsd:complexType>

This is a simple straight forward addition that as defined above has a default behavior that aligns with current 5.5 implementation of the object.

I looked into your suggestion of adding KBArticleID and SecurityBulletinID. I can see the value of these items, but this probably should be a separate test. These entities are both attributes of a single update and this test lists update ids and nothing more. When this test was added the working assumption was that a query would be used to search for updates that have not yet been installed for the host. Then if any updates were found that were not installed the system was to be considered out of compliance with the organization's patch policy. I believe that update_id was picked since it is the unique id of the update.


Jon

============================================
Jonathan O. Baker
G022 - IA Industry Collaboration
The MITRE Corporation
Email: [hidden email]

>-----Original Message-----
>From: Harrison, Tim [mailto:[hidden email]]
>Sent: Thursday, August 13, 2009 3:04 PM
>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>Subject: [OVAL-DEVELOPER-LIST] Additions to win-def:wuaupdatesearcher
>
>Folks,
>
>After testing the win-def:wuaupdatesearcher_test there are a few
>additions which I would like to put up for consideration.
>
>Currently, the update_id child element of win-
>def:wuaupdatesearcher_state uses the updates UUID.  This ID  appears to
>be available within Windows WMI and is not published anywhere as far as
>I able to find.
>
>If the option(s) existed to retrieve the values of the KBArticleIDs
>and/or SecurityBulletinIDs properties it may be easier to test for and
>identify the installed updates.  Additionally there is a
>SupersededUpdateIDs perperty which may could potentially be used to
>prevent fails when updates are superseded.  It may be worthe noting that
>these are all properties of the same IUpdate interface from which the
>OVAL Interpreter currently obtains the UUID.
>
>Based on this I would like to suggest that a behavior be added to the
>win-def:wuaupdatesearcher_object to trigger the inclusion of
>SupersededUpdateIDs and child elements be added the win-
>def:wuaupdatesearcher_state for the KBARticleID and/or
>SecurityBulletinID.
>
>One final item, the IUpdatSearcher interface used by OVALDI to perform
>searches specified by the win-def:wuaupdatesearcher_object has
>properties to specify whether to search online or offline as well as to
>whether to search a Windows Update site or some other site as defined by
>the ServiceID property.  I am not entirely familiar with how these work,
>but they may be of beneift for certain environments where a non-Windows
>Update server is preferred or the system has no online connection.  This
>may or may not be something we need to add support for in OVAL, but I
>wanted to put it out there for others weigh-in on.
>
>Respectfully,
>Tim Harrison
>SCAP Content Development
>National Institute of Standards and Technology
>[phone]
>[hidden email]
>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 OVAL-
>[hidden email].

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].

[James Hugard]

On Aug 13, 2009, Tim Harrison wrote:

> One final item, the IUpdatSearcher interface used by OVALDI to perform
> searches specified by the win-def:wuaupdatesearcher_object has
> properties to specify whether to search online or offline as well as to
> whether to search a Windows Update site or some other site as defined
> by the ServiceID property.  I am not entirely familiar with how these
> work, but they may be of beneift for certain environments where a non-
> Windows Update server is preferred or the system has no online
> connection.  This may or may not be something we need to add support
> for in OVAL, but I wanted to put it out there for others weigh-in on.

Generally, the update server to use on any given network would be specified by a domain policy which either points to an internal SUS server, or to the Microsoft SUS server.  In either case, querying for updates that are not approved (i.e., by overriding the domain policy's SUS setting) may produce invalid results from the customer's perspective.


"Perfection is reached not when there is nothing left to add, but when nothing more can be taken away."  -- Antoine de Saint-Exupery

James Hugard
Foundstone Architect
[hidden email]
[phone] (cell)

McAfee, Inc.
27201 Puerta Real, Suite 400
Mission Viejo, CA 92691
[phone] (direct)

Note: This email may contain confidential and privileged information for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient please contact the sender and delete all copies of this message.
 

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].

[Timothy Harrison]

James,

Thanks for clearing that up. I had a hunch that would be the case, but didn't have the chance to fully research it.  Unless someone can offer a differing perspective I am inclined to say this is not something that needs to be supported in OVAL.

Thanks,
Tim Harrison
SCAP Content Development
National Institute of Standards and Technology
[phone]
[hidden email]
________________________________________
From: [hidden email] [[hidden email]]
Sent: Friday, August 28, 2009 2:17 PM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] Additions to win-def:wuaupdatesearcher

On Aug 13, 2009, Tim Harrison wrote:

> One final item, the IUpdatSearcher interface used by OVALDI to perform
> searches specified by the win-def:wuaupdatesearcher_object has
> properties to specify whether to search online or offline as well as to
> whether to search a Windows Update site or some other site as defined
> by the ServiceID property.  I am not entirely familiar with how these
> work, but they may be of beneift for certain environments where a non-
> Windows Update server is preferred or the system has no online
> connection.  This may or may not be something we need to add support
> for in OVAL, but I wanted to put it out there for others weigh-in on.

Generally, the update server to use on any given network would be specified by a domain policy which either points to an internal SUS server, or to the Microsoft SUS server.  In either case, querying for updates that are not approved (i.e., by overriding the domain policy's SUS setting) may produce invalid results from the customer's perspective.


"Perfection is reached not when there is nothing left to add, but when nothing more can be taken away."  -- Antoine de Saint-Exupery

James Hugard
Foundstone Architect
[hidden email]
[phone] (cell)

McAfee, Inc.
27201 Puerta Real, Suite 400
Mission Viejo, CA 92691
[phone] (direct)

Note: This email may contain confidential and privileged information for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient please contact the sender and delete all copies of this message.


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].
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].