ESX updated patch test for Version 5.6

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

ESX updated patch test for Version 5.6

Andrew Buttner
Administrator
Pai,

Thanks you very much for the updated patch test schema.  I have a question about it before adding this into the OVAL Version 5.6 draft.

First, it looks like there is a bug in the current patch test where the <patch_number> entity is defined with a string datatype in the object, but is an int datatype in the stat and in the System Characteristic item.  So we really need to deprecate the existing test and create a new one.

The question I have is if a single patch test with a <patch_name> entity with datatype string could be used to satisfy both older ESX versions and the newer 3.0.3 and 3.5 versions?  For older versions of the ESX, the bundle id, classification, support level (remember that all state entities are optional) would be empty when a tool tries to collect information.  For newer versions this information would be collected as appropriate.

Or should we really have two different patch tests, one for the old way and one for the new way?

Thanks
Drew




>-----Original Message-----
>From: Peng, Pai [mailto:[hidden email]]
>Sent: Friday, May 01, 2009 2:51 PM
>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>Subject: Re: [OVAL-DEVELOPER-LIST] Version 5.6 Release Timeline
>
>Hi Jon,
>
>For version 5.6, we'd like to submit a new patch35_test for VMware ESX
>schema. In ESX 3.0.3 and 3.5, the patch number is not an integer
>anymore. It follows the convention of {ProductName}{VersionNumber}-
>{BundleID}-{Classification}{SupportLevel}. The new test covers this
>change.
>
>Thanks,
>Pai

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].
Reply | Threaded
Open this post in threaded view
|

Re: ESX updated patch test for Version 5.6

Peng, Pai
Drew,

I think we could use patch_name for both old version and new version patches and deprecate the existing test. The reason I created a new test is to keep the existing OVAL definitions intact. If we decide to keep only one test, we can revise existing patch_test and put the entire string "ESX-xxxxx" as the patch_name.

After reading patch management doc at http://www.vmware.com/pdf/esx3_esxupdate.pdf, the patch_number in the existing test is actually the knowledge base article identification number. So optionally we could create a new state entity called knowledge base ID, so that a tool can collect patch information and return either knowledge base ID or a collection of bundle id, classification, and support level. Note that all those state entities are not very important for vulnerability assessment purpose, at least for now. I included them in the schema just in case they may be useful in the future.

Thanks,
Pai


-----Original Message-----
From: Buttner, Drew [mailto:[hidden email]]
Sent: Tuesday, May 12, 2009 2:26 PM
To: [hidden email]
Subject: [OVAL-DEVELOPER-LIST] ESX updated patch test for Version 5.6

Pai,

Thanks you very much for the updated patch test schema.  I have a question about it before adding this into the OVAL Version 5.6 draft.

First, it looks like there is a bug in the current patch test where the <patch_number> entity is defined with a string datatype in the object, but is an int datatype in the stat and in the System Characteristic item.  So we really need to deprecate the existing test and create a new one.

The question I have is if a single patch test with a <patch_name> entity with datatype string could be used to satisfy both older ESX versions and the newer 3.0.3 and 3.5 versions?  For older versions of the ESX, the bundle id, classification, support level (remember that all state entities are optional) would be empty when a tool tries to collect information.  For newer versions this information would be collected as appropriate.

Or should we really have two different patch tests, one for the old way and one for the new way?

Thanks
Drew




>-----Original Message-----
>From: Peng, Pai [mailto:[hidden email]]
>Sent: Friday, May 01, 2009 2:51 PM
>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>Subject: Re: [OVAL-DEVELOPER-LIST] Version 5.6 Release Timeline
>
>Hi Jon,
>
>For version 5.6, we'd like to submit a new patch35_test for VMware ESX
>schema. In ESX 3.0.3 and 3.5, the patch number is not an integer
>anymore. It follows the convention of {ProductName}{VersionNumber}-
>{BundleID}-{Classification}{SupportLevel}. The new test covers this
>change.
>
>Thanks,
>Pai

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].
Reply | Threaded
Open this post in threaded view
|

Re: ESX updated patch test for Version 5.6

Andrew Buttner
Administrator
Does the proposed test in the draft of version 5.3 work?  (Note that original test would be deprecated)  Should it be tweaked at all?

http://oval.mitre.org/language/download/schema/version5.6/ovaldefinition/documentation/esx-definitions-schema.html

>After reading patch management doc at
>http://www.vmware.com/pdf/esx3_esxupdate.pdf, the patch_number in the
>existing test is actually the knowledge base article identification
>number. So optionally we could create a new state entity called
>knowledge base ID, so that a tool can collect patch information and
>return either knowledge base ID or a collection of bundle id,
>classification, and support level.

I was thinking that the existing patch_number is really the patch_name in the new test.  Can you see it this way?  Or would it be better to add a knowledge base ID?  If we added this, what would the patch name be for the older patches?

Thanks
Drew

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].
Reply | Threaded
Open this post in threaded view
|

Re: ESX updated patch test for Version 5.6

Peng, Pai
I think patch_name should be the entire string, such as "ESX350-200808218-UG" for newer versions or "ESX-2257739" for older versions (not just "2257739" as used previously in patch_number). In this case, an optional knowledge base ID could be created to return just "2257739" for older versions. That's what I meant. Does that make sense?

Pai

-----Original Message-----
From: Buttner, Drew [mailto:[hidden email]]
Sent: Tuesday, May 19, 2009 6:42 AM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] ESX updated patch test for Version 5.6

Does the proposed test in the draft of version 5.3 work?  (Note that original test would be deprecated)  Should it be tweaked at all?

http://oval.mitre.org/language/download/schema/version5.6/ovaldefinition/documentation/esx-definitions-schema.html

>After reading patch management doc at
>http://www.vmware.com/pdf/esx3_esxupdate.pdf, the patch_number in the
>existing test is actually the knowledge base article identification
>number. So optionally we could create a new state entity called
>knowledge base ID, so that a tool can collect patch information and
>return either knowledge base ID or a collection of bundle id,
>classification, and support level.

I was thinking that the existing patch_number is really the patch_name in the new test.  Can you see it this way?  Or would it be better to add a knowledge base ID?  If we added this, what would the patch name be for the older patches?

Thanks
Drew

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].
Reply | Threaded
Open this post in threaded view
|

Re: ESX updated patch test for Version 5.6

Andrew Buttner
Administrator
Pai,

Sorry for losing track of this discussion.  As we were reviewing the tracker items for Version 5.6, we noticed that I had not closed this out.  I'd like to do so now.

In quick review, we were talking about the new patch56_test for the ESX component schema.

Reading your last response, I now understand what you were suggesting regarding adding a kb_id entity to the state.  This would apply to ESX versions 3.0.2 and earlier that used the older patch naming convention.  Like the other entities, it would be optional and therefore not used by version 3.0.3 and later.

I agree with your suggestion and have added a <knowledge_base_id> entity to the proposed test.  This will be available in the next draft of Version 5.6.

Thanks
Drew

 

>-----Original Message-----
>From: Peng, Pai [mailto:[hidden email]]
>Sent: Tuesday, May 19, 2009 10:45 AM
>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>Subject: Re: [OVAL-DEVELOPER-LIST] ESX updated patch test for Version
>5.6
>
>I think patch_name should be the entire string, such as "ESX350-
>200808218-UG" for newer versions or "ESX-2257739" for older versions
>(not just "2257739" as used previously in patch_number). In this case,
>an optional knowledge base ID could be created to return just "2257739"
>for older versions. That's what I meant. Does that make sense?
>
>Pai
>
>-----Original Message-----
>From: Buttner, Drew [mailto:[hidden email]]
>Sent: Tuesday, May 19, 2009 6:42 AM
>To: [hidden email]
>Subject: Re: [OVAL-DEVELOPER-LIST] ESX updated patch test for Version
>5.6
>
>Does the proposed test in the draft of version 5.3 work?  (Note that
>original test would be deprecated)  Should it be tweaked at all?
>
>http://oval.mitre.org/language/download/schema/version5.6/ovaldefinition
>/documentation/esx-definitions-schema.html
>
>>After reading patch management doc at
>>http://www.vmware.com/pdf/esx3_esxupdate.pdf, the patch_number in the
>>existing test is actually the knowledge base article identification
>>number. So optionally we could create a new state entity called
>>knowledge base ID, so that a tool can collect patch information and
>>return either knowledge base ID or a collection of bundle id,
>>classification, and support level.
>
>I was thinking that the existing patch_number is really the patch_name
>in the new test.  Can you see it this way?  Or would it be better to add
>a knowledge base ID?  If we added this, what would the patch name be for
>the older patches?
>
>Thanks
>Drew
>
>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 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].