32/64 bit updated proposal

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

32/64 bit updated proposal

Hansbury, Matt
All,

Once again I want to thank all the folks that are providing feedback as we try to narrow down the 32/64 bit redirection issue to a consensus solution.  The MITRE team has been reviewing all of the feedback over the past couple of weeks, and we now feel that it is appropriate to move forward with a solution based on that feedback.  Here is our updated proposal:

We will create a new behavior on the relevant tests (windows registry and file tests, as well as file tests in the independent Schema) with the following details:

Name:  windows_view

Description: 64 bit versions of Windows provide an alternate file system and registry views to 32bit applications. This behavior allows the OVAL Object to state which view should be examined. This behavior only applies to Windows, and is ignored in all other platforms.

Possible values:
        . 64_bit - Indicates that the 64-bit view on 64-bit Windows operating systems must be examined. On 32-bit Windows, using this behavior will result in a collected object with a flag of "does not exist".
        . 32_bit - Indicates that the 32-bit view on both 64-bit and 32-bit Windows operating systems must be examined.
        . all - Indicates that both the 32-bit and 64-bit views must be examined on 64-bit Windows operating systems. On 32-bit Windows operating systems, indicates that only the 32-bit view is examined.  In some cases this will result in collecting a given registry key once from the 32-bit view and once from the 64-bit view. These items must be differentiated by setting the windows_view item entity to 32_bit or 64_bit value respectively.

Default: all

By defaulting to the 'all' value, we believe that we will impact the least amount of content. Compliance content like USGCB and FDCC should not require any changes. Inventory related content like https://oval.mitre.org/repository/data/ViewDefinition?id=oval:org.mitre.oval:def:7533 which currently does not work will be fixed without any changes.

Patch and vulnerability content on windows will still need reviewing, but a quick search of the OVAL Repository shows that the check attribute on tests is rarely set to 'all'. This means that there is good chance that this content will also not need to be updated.   While some content could be impacted here and be made incorrect, we believe that no matter what solution and default is chosen, some percentage of the content will be affected.  Therefore, we are trying to pick a default that minimizes that.

We continue to value feedback on this issue, but in the interest of meeting the 5.10 timelines, we are going to begin implementing the above proposal, so that it can be included in the next Release Candidate. 

Thanks
Matt

====================================================
Matt Hansbury
G022 -  Information Assurance Industry Collaboration
The MITRE Corporation
[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: 32/64 bit updated proposal

Paul_Whitehurst
Why has the proposal changed so drastically from the last proposal?

Using your proposal, we invalidate all current content, as content authors do not expect to collect both the 32-bit node and the 64-bit node.

Reading through the previous email chain, I felt most people agreed with the original 'none (os-native) or 32-bit' proposal.

I think the following is the only viable solution…

Behavior name: os_redirection
Behavior settings: "none", "32_bit"
Documentation: 64 bit versions of Windows provide alternate file system and registry views to 32bit applications. This behavior allows the OVAL object to operate in that alternate view. This behavior only applies to 64bit versions of windows, and is ignored in all other instances. A setting of "none" means that the unredirected, native 64bit view of the file system and registry will be examined. A setting of "32_bit" means the redirected 32bit view will be examined.
Default: none

Paul


On Aug 23, 2011, at 8:10 AM, Hansbury, Matt wrote:

> All,
>
> Once again I want to thank all the folks that are providing feedback as we try to narrow down the 32/64 bit redirection issue to a consensus solution.  The MITRE team has been reviewing all of the feedback over the past couple of weeks, and we now feel that it is appropriate to move forward with a solution based on that feedback.  Here is our updated proposal:
>
> We will create a new behavior on the relevant tests (windows registry and file tests, as well as file tests in the independent Schema) with the following details:
>
> Name:  windows_view
>
> Description: 64 bit versions of Windows provide an alternate file system and registry views to 32bit applications. This behavior allows the OVAL Object to state which view should be examined. This behavior only applies to Windows, and is ignored in all other platforms.
>
> Possible values:
> . 64_bit - Indicates that the 64-bit view on 64-bit Windows operating systems must be examined. On 32-bit Windows, using this behavior will result in a collected object with a flag of "does not exist".
> . 32_bit - Indicates that the 32-bit view on both 64-bit and 32-bit Windows operating systems must be examined.
> . all - Indicates that both the 32-bit and 64-bit views must be examined on 64-bit Windows operating systems. On 32-bit Windows operating systems, indicates that only the 32-bit view is examined.  In some cases this will result in collecting a given registry key once from the 32-bit view and once from the 64-bit view. These items must be differentiated by setting the windows_view item entity to 32_bit or 64_bit value respectively.
>
> Default: all
>
> By defaulting to the 'all' value, we believe that we will impact the least amount of content. Compliance content like USGCB and FDCC should not require any changes. Inventory related content like https://oval.mitre.org/repository/data/ViewDefinition?id=oval:org.mitre.oval:def:7533 which currently does not work will be fixed without any changes.
>
> Patch and vulnerability content on windows will still need reviewing, but a quick search of the OVAL Repository shows that the check attribute on tests is rarely set to 'all'. This means that there is good chance that this content will also not need to be updated.   While some content could be impacted here and be made incorrect, we believe that no matter what solution and default is chosen, some percentage of the content will be affected.  Therefore, we are trying to pick a default that minimizes that.
>
> We continue to value feedback on this issue, but in the interest of meeting the 5.10 timelines, we are going to begin implementing the above proposal, so that it can be included in the next Release Candidate.  
>
> Thanks
> Matt
>
> ====================================================
> Matt Hansbury
> G022 -  Information Assurance Industry Collaboration
> The MITRE Corporation
> [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].

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: 32/64 bit updated proposal

KenSimone
In reply to this post by Hansbury, Matt
Wow. What happened? This proposal doesn't align at all with the last "Community call" message. In fact, the "All" notion is a concept that was unanimously rejected by the community, based on the premise that states are rarely reusable in that manner. Did I miss some conversation somewhere?
 
Thanks,
Ken

-----Original Message-----
From: Hansbury, Matt [mailto:[hidden email]]
Sent: Tuesday, August 23, 2011 8:10 AM
To: [hidden email]
Subject: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal

All,

Once again I want to thank all the folks that are providing feedback as we try to narrow down the 32/64 bit redirection issue to a consensus solution.  The MITRE team has been reviewing all of the feedback over the past couple of weeks, and we now feel that it is appropriate to move forward with a solution based on that feedback.  Here is our updated proposal:

We will create a new behavior on the relevant tests (windows registry and file tests, as well as file tests in the independent Schema) with the following details:

Name:  windows_view

Description: 64 bit versions of Windows provide an alternate file system and registry views to 32bit applications. This behavior allows the OVAL Object to state which view should be examined. This behavior only applies to Windows, and is ignored in all other platforms.

Possible values:
        . 64_bit - Indicates that the 64-bit view on 64-bit Windows operating systems must be examined. On 32-bit Windows, using this behavior will result in a collected object with a flag of "does not exist".
        . 32_bit - Indicates that the 32-bit view on both 64-bit and 32-bit Windows operating systems must be examined.
        . all - Indicates that both the 32-bit and 64-bit views must be examined on 64-bit Windows operating systems. On 32-bit Windows operating systems, indicates that only the 32-bit view is examined.  In some cases this will result in collecting a given registry key once from the 32-bit view and once from the 64-bit view. These items must be differentiated by setting the windows_view item entity to 32_bit or 64_bit value respectively.

Default: all

By defaulting to the 'all' value, we believe that we will impact the least amount of content. Compliance content like USGCB and FDCC should not require any changes. Inventory related content like https://oval.mitre.org/repository/data/ViewDefinition?id=oval:org.mitre.oval:def:7533 which currently does not work will be fixed without any changes.

Patch and vulnerability content on windows will still need reviewing, but a quick search of the OVAL Repository shows that the check attribute on tests is rarely set to 'all'. This means that there is good chance that this content will also not need to be updated.   While some content could be impacted here and be made incorrect, we believe that no matter what solution and default is chosen, some percentage of the content will be affected.  Therefore, we are trying to pick a default that minimizes that.

We continue to value feedback on this issue, but in the interest of meeting the 5.10 timelines, we are going to begin implementing the above proposal, so that it can be included in the next Release Candidate. 

Thanks
Matt

====================================================
Matt Hansbury
G022 -  Information Assurance Industry Collaboration The MITRE Corporation [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].

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: 32/64 bit updated proposal

Jon Baker
Administrator
In reply to this post by Paul_Whitehurst
Paul,

Can you help us understand what content is broken with this current proposal?

As Matt noted, we felt that this proposal actually minimized the impact to content. We survey the publicly available content in the OVAL Repository and NIST's USGCB and FDCC content. The NIST content did not seem to be impacted at all. Some content in the OVAL Repository is actually silently fixed by this proposal.

Thanks,

Jon

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


>-----Original Message-----
>From: [hidden email]
>[mailto:[hidden email]]
>Sent: Tuesday, August 23, 2011 11:19 AM
>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal
>
>Why has the proposal changed so drastically from the last proposal?
>
>Using your proposal, we invalidate all current content, as content authors do
>not expect to collect both the 32-bit node and the 64-bit node.
>
>Reading through the previous email chain, I felt most people agreed with the
>original 'none (os-native) or 32-bit' proposal.
>
>I think the following is the only viable solution...
>
>Behavior name: os_redirection
>Behavior settings: "none", "32_bit"
>Documentation: 64 bit versions of Windows provide alternate file system and
>registry views to 32bit applications. This behavior allows the OVAL object to
>operate in that alternate view. This behavior only applies to 64bit versions of
>windows, and is ignored in all other instances. A setting of "none" means that
>the unredirected, native 64bit view of the file system and registry will be
>examined. A setting of "32_bit" means the redirected 32bit view will be
>examined.
>Default: none
>
>Paul
>
>
>On Aug 23, 2011, at 8:10 AM, Hansbury, Matt wrote:
>
>> All,
>>
>> Once again I want to thank all the folks that are providing feedback as we try
>to narrow down the 32/64 bit redirection issue to a consensus solution.  The
>MITRE team has been reviewing all of the feedback over the past couple of
>weeks, and we now feel that it is appropriate to move forward with a solution
>based on that feedback.  Here is our updated proposal:
>>
>> We will create a new behavior on the relevant tests (windows registry and file
>tests, as well as file tests in the independent Schema) with the following details:
>>
>> Name:  windows_view
>>
>> Description: 64 bit versions of Windows provide an alternate file system and
>registry views to 32bit applications. This behavior allows the OVAL Object to
>state which view should be examined. This behavior only applies to Windows,
>and is ignored in all other platforms.
>>
>> Possible values:
>> . 64_bit - Indicates that the 64-bit view on 64-bit Windows operating
>systems must be examined. On 32-bit Windows, using this behavior will result
>in a collected object with a flag of "does not exist".
>> . 32_bit - Indicates that the 32-bit view on both 64-bit and 32-bit
>Windows operating systems must be examined.
>> . all - Indicates that both the 32-bit and 64-bit views must be examined
>on 64-bit Windows operating systems. On 32-bit Windows operating systems,
>indicates that only the 32-bit view is examined.  In some cases this will result in
>collecting a given registry key once from the 32-bit view and once from the 64-
>bit view. These items must be differentiated by setting the windows_view item
>entity to 32_bit or 64_bit value respectively.
>>
>> Default: all
>>
>> By defaulting to the 'all' value, we believe that we will impact the least
>amount of content. Compliance content like USGCB and FDCC should not
>require any changes. Inventory related content like
>https://oval.mitre.org/repository/data/ViewDefinition?id=oval:org.mitre.oval:
>def:7533 which currently does not work will be fixed without any changes.
>>
>> Patch and vulnerability content on windows will still need reviewing, but a
>quick search of the OVAL Repository shows that the check attribute on tests is
>rarely set to 'all'. This means that there is good chance that this content will also
>not need to be updated.   While some content could be impacted here and be
>made incorrect, we believe that no matter what solution and default is chosen,
>some percentage of the content will be affected.  Therefore, we are trying to
>pick a default that minimizes that.
>>
>> We continue to value feedback on this issue, but in the interest of meeting the
>5.10 timelines, we are going to begin implementing the above proposal, so that
>it can be included in the next Release Candidate.
>>
>> Thanks
>> Matt
>>
>> ====================================================
>> Matt Hansbury
>> G022 -  Information Assurance Industry Collaboration
>> The MITRE Corporation
>> [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 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].
Reply | Threaded
Open this post in threaded view
|

Re: 32/64 bit updated proposal

Hansbury, Matt
In reply to this post by Paul_Whitehurst
Paul,

The proposal has been changed, in many ways back to the original proposal following the Community Call, though this version contains some more explicit naming and better documentation.  The rational for this is as follows:

* During the initial long email exchange, it became clear that:
        a. There was significant confusion around the proposals
        b. There was a call for making thing very explicit for content authors

Given the above, we decided that introducing the '64_bit' value was important to achieve that level of detail and clarity.  Additionally, it was clear that limiting the effects of the behavior to only 64-bit systems was also introducing unnecessary confusion.  Therefore, we expanded the behavior to affect all platforms.  (This is intended to achieve clarity on the authoring side.  Obviously on the tool side, the behavior can still be largely ignored when examining a 32-bit system.)

* Another issue was attempting to limit the amount of broken content out there in the community.  From all of the content that we were able to review (the OVAL Repository content, USGCB, & FDCC content), it became very clear that the concept of 'all' would make the bulk of that content just work, which was as close to an ideal solution as possible.  

We understand that using this default (and even allowing this value) will create a significant amount of extra collected Items.  However, we generally would prefer to create extra bloat, than to break content.  Additionally, over time the bloat can be largely eliminated by revising the content.

Having explained our rational for the revised proposal, can you help us understand where it falls short in your eyes?  Does it break your existing content?  Or does it create issue for evaluation?  

Thanks
Matt

-----Original Message-----
From: [hidden email] [mailto:[hidden email]]
Sent: Tuesday, August 23, 2011 11:19 AM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal

Why has the proposal changed so drastically from the last proposal?

Using your proposal, we invalidate all current content, as content authors do not expect to collect both the 32-bit node and the 64-bit node.

Reading through the previous email chain, I felt most people agreed with the original 'none (os-native) or 32-bit' proposal.

I think the following is the only viable solution...

Behavior name: os_redirection
Behavior settings: "none", "32_bit"
Documentation: 64 bit versions of Windows provide alternate file system and registry views to 32bit applications. This behavior allows the OVAL object to operate in that alternate view. This behavior only applies to 64bit versions of windows, and is ignored in all other instances. A setting of "none" means that the unredirected, native 64bit view of the file system and registry will be examined. A setting of "32_bit" means the redirected 32bit view will be examined.
Default: none

Paul


On Aug 23, 2011, at 8:10 AM, Hansbury, Matt wrote:

> All,
>
> Once again I want to thank all the folks that are providing feedback as we try to narrow down the 32/64 bit redirection issue to a consensus solution.  The MITRE team has been reviewing all of the feedback over the past couple of weeks, and we now feel that it is appropriate to move forward with a solution based on that feedback.  Here is our updated proposal:
>
> We will create a new behavior on the relevant tests (windows registry and file tests, as well as file tests in the independent Schema) with the following details:
>
> Name:  windows_view
>
> Description: 64 bit versions of Windows provide an alternate file system and registry views to 32bit applications. This behavior allows the OVAL Object to state which view should be examined. This behavior only applies to Windows, and is ignored in all other platforms.
>
> Possible values:
> . 64_bit - Indicates that the 64-bit view on 64-bit Windows operating systems must be examined. On 32-bit Windows, using this behavior will result in a collected object with a flag of "does not exist".
> . 32_bit - Indicates that the 32-bit view on both 64-bit and 32-bit Windows operating systems must be examined.
> . all - Indicates that both the 32-bit and 64-bit views must be examined on 64-bit Windows operating systems. On 32-bit Windows operating systems, indicates that only the 32-bit view is examined.  In some cases this will result in collecting a given registry key once from the 32-bit view and once from the 64-bit view. These items must be differentiated by setting the windows_view item entity to 32_bit or 64_bit value respectively.
>
> Default: all
>
> By defaulting to the 'all' value, we believe that we will impact the least amount of content. Compliance content like USGCB and FDCC should not require any changes. Inventory related content like https://oval.mitre.org/repository/data/ViewDefinition?id=oval:org.mitre.oval:def:7533 which currently does not work will be fixed without any changes.
>
> Patch and vulnerability content on windows will still need reviewing, but a quick search of the OVAL Repository shows that the check attribute on tests is rarely set to 'all'. This means that there is good chance that this content will also not need to be updated.   While some content could be impacted here and be made incorrect, we believe that no matter what solution and default is chosen, some percentage of the content will be affected.  Therefore, we are trying to pick a default that minimizes that.
>
> We continue to value feedback on this issue, but in the interest of meeting the 5.10 timelines, we are going to begin implementing the above proposal, so that it can be included in the next Release Candidate.  
>
> Thanks
> Matt
>
> ====================================================
> Matt Hansbury
> G022 -  Information Assurance Industry Collaboration
> The MITRE Corporation
> [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].

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: 32/64 bit updated proposal

Paul_Whitehurst
You posted your proposal on 8/15.  After that email, there were 13 responses.  Of those 13, there are 4 unique responders.  Ken, Shane, Gunnar.. James, and Timothy.  Ken and james were for the proposal, Shane was against.  Timothy did not state an opinion and Gunnar agreed with Shane but was ambivalent to which approach to take.  Prior to your proposal, most people agreed with Ken's approach (which is your formal proposal).

As to the content issue.  We currently have broken content in the repository.  It is safe to assume content that was written to target 32 bit systems works on 32 bit system and content written to target 64 bit systems works on 64 bit system.  There for content which targets a 32 bit system, but runs on a 64 bit system is probably broken (although it is possible to write content that works on both 32 bit and 64 bit systems).  If you make the default behavior to collect both the 32 bit data and the 64 bit data for all checks, all content is broken as no content creators would expect that behavior prior to now.  Furthermore, it is not possible to fix existing content when executed on a 64 bit machine without breaking other content because we cannot know the intentions and expectations of the content author.


Seeing as content will be broken regardless of the approach, there was not significant push back for the proposal of August 15th, and, as Ken pointed out, there was a universal rejection to the 'default: all' proposal during the teleconference; I see no compelling reason to change the proposal.

Paul


On Aug 23, 2011, at 11:52 AM, Hansbury, Matt wrote:

> Paul,
>
> The proposal has been changed, in many ways back to the original proposal following the Community Call, though this version contains some more explicit naming and better documentation.  The rational for this is as follows:
>
> * During the initial long email exchange, it became clear that:
> a. There was significant confusion around the proposals
> b. There was a call for making thing very explicit for content authors
>
> Given the above, we decided that introducing the '64_bit' value was important to achieve that level of detail and clarity.  Additionally, it was clear that limiting the effects of the behavior to only 64-bit systems was also introducing unnecessary confusion.  Therefore, we expanded the behavior to affect all platforms.  (This is intended to achieve clarity on the authoring side.  Obviously on the tool side, the behavior can still be largely ignored when examining a 32-bit system.)
>
> * Another issue was attempting to limit the amount of broken content out there in the community.  From all of the content that we were able to review (the OVAL Repository content, USGCB, & FDCC content), it became very clear that the concept of 'all' would make the bulk of that content just work, which was as close to an ideal solution as possible.  
>
> We understand that using this default (and even allowing this value) will create a significant amount of extra collected Items.  However, we generally would prefer to create extra bloat, than to break content.  Additionally, over time the bloat can be largely eliminated by revising the content.
>
> Having explained our rational for the revised proposal, can you help us understand where it falls short in your eyes?  Does it break your existing content?  Or does it create issue for evaluation?  
>
> Thanks
> Matt
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]]
> Sent: Tuesday, August 23, 2011 11:19 AM
> To: oval-developer-list OVAL Developer List/Closed Public Discussion
> Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal
>
> Why has the proposal changed so drastically from the last proposal?
>
> Using your proposal, we invalidate all current content, as content authors do not expect to collect both the 32-bit node and the 64-bit node.
>
> Reading through the previous email chain, I felt most people agreed with the original 'none (os-native) or 32-bit' proposal.
>
> I think the following is the only viable solution...
>
> Behavior name: os_redirection
> Behavior settings: "none", "32_bit"
> Documentation: 64 bit versions of Windows provide alternate file system and registry views to 32bit applications. This behavior allows the OVAL object to operate in that alternate view. This behavior only applies to 64bit versions of windows, and is ignored in all other instances. A setting of "none" means that the unredirected, native 64bit view of the file system and registry will be examined. A setting of "32_bit" means the redirected 32bit view will be examined.
> Default: none
>
> Paul
>
>
> On Aug 23, 2011, at 8:10 AM, Hansbury, Matt wrote:
>
>> All,
>>
>> Once again I want to thank all the folks that are providing feedback as we try to narrow down the 32/64 bit redirection issue to a consensus solution.  The MITRE team has been reviewing all of the feedback over the past couple of weeks, and we now feel that it is appropriate to move forward with a solution based on that feedback.  Here is our updated proposal:
>>
>> We will create a new behavior on the relevant tests (windows registry and file tests, as well as file tests in the independent Schema) with the following details:
>>
>> Name:  windows_view
>>
>> Description: 64 bit versions of Windows provide an alternate file system and registry views to 32bit applications. This behavior allows the OVAL Object to state which view should be examined. This behavior only applies to Windows, and is ignored in all other platforms.
>>
>> Possible values:
>> . 64_bit - Indicates that the 64-bit view on 64-bit Windows operating systems must be examined. On 32-bit Windows, using this behavior will result in a collected object with a flag of "does not exist".
>> . 32_bit - Indicates that the 32-bit view on both 64-bit and 32-bit Windows operating systems must be examined.
>> . all - Indicates that both the 32-bit and 64-bit views must be examined on 64-bit Windows operating systems. On 32-bit Windows operating systems, indicates that only the 32-bit view is examined.  In some cases this will result in collecting a given registry key once from the 32-bit view and once from the 64-bit view. These items must be differentiated by setting the windows_view item entity to 32_bit or 64_bit value respectively.
>>
>> Default: all
>>
>> By defaulting to the 'all' value, we believe that we will impact the least amount of content. Compliance content like USGCB and FDCC should not require any changes. Inventory related content like https://oval.mitre.org/repository/data/ViewDefinition?id=oval:org.mitre.oval:def:7533 which currently does not work will be fixed without any changes.
>>
>> Patch and vulnerability content on windows will still need reviewing, but a quick search of the OVAL Repository shows that the check attribute on tests is rarely set to 'all'. This means that there is good chance that this content will also not need to be updated.   While some content could be impacted here and be made incorrect, we believe that no matter what solution and default is chosen, some percentage of the content will be affected.  Therefore, we are trying to pick a default that minimizes that.
>>
>> We continue to value feedback on this issue, but in the interest of meeting the 5.10 timelines, we are going to begin implementing the above proposal, so that it can be included in the next Release Candidate.  
>>
>> Thanks
>> Matt
>>
>> ====================================================
>> Matt Hansbury
>> G022 -  Information Assurance Industry Collaboration
>> The MITRE Corporation
>> [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].
>
> 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].

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: 32/64 bit updated proposal

Gunnar Engelbach
Actually, my preference was always to treat the flag as a "when"
conditional and not as a "how" instruction.

But all proposals are simple to implement so my primary objective are
those that Matt, et al, have stated:  simplification for content authors
and least problems with existing content.




On 8/23/2011 1:40 PM, [hidden email] wrote:

> You posted your proposal on 8/15.  After that email, there were 13 responses.  Of those 13, there are 4 unique responders.  Ken, Shane, Gunnar.. James, and Timothy.  Ken and james were for the proposal, Shane was against.  Timothy did not state an opinion and Gunnar agreed with Shane but was ambivalent to which approach to take.  Prior to your proposal, most people agreed with Ken's approach (which is your formal proposal).
>
> As to the content issue.  We currently have broken content in the repository.  It is safe to assume content that was written to target 32 bit systems works on 32 bit system and content written to target 64 bit systems works on 64 bit system.  There for content which targets a 32 bit system, but runs on a 64 bit system is probably broken (although it is possible to write content that works on both 32 bit and 64 bit systems).  If you make the default behavior to collect both the 32 bit data and the 64 bit data for all checks, all content is broken as no content creators would expect that behavior prior to now.  Furthermore, it is not possible to fix existing content when executed on a 64 bit machine without breaking other content because we cannot know the intentions and expectations of the content author.
>
>
> Seeing as content will be broken regardless of the approach, there was not significant push back for the proposal of August 15th, and, as Ken pointed out, there was a universal rejection to the 'default: all' proposal during the teleconference; I see no compelling reason to change the proposal.
>
> Paul
>
>
> On Aug 23, 2011, at 11:52 AM, Hansbury, Matt wrote:
>
>> Paul,
>>
>> The proposal has been changed, in many ways back to the original proposal following the Community Call, though this version contains some more explicit naming and better documentation.  The rational for this is as follows:
>>
>> * During the initial long email exchange, it became clear that:
>> a. There was significant confusion around the proposals
>> b. There was a call for making thing very explicit for content authors
>>
>> Given the above, we decided that introducing the '64_bit' value was important to achieve that level of detail and clarity.  Additionally, it was clear that limiting the effects of the behavior to only 64-bit systems was also introducing unnecessary confusion.  Therefore, we expanded the behavior to affect all platforms.  (This is intended to achieve clarity on the authoring side.  Obviously on the tool side, the behavior can still be largely ignored when examining a 32-bit system.)
>>
>> * Another issue was attempting to limit the amount of broken content out there in the community.  From all of the content that we were able to review (the OVAL Repository content, USGCB,&  FDCC content), it became very clear that the concept of 'all' would make the bulk of that content just work, which was as close to an ideal solution as possible.
>>
>> We understand that using this default (and even allowing this value) will create a significant amount of extra collected Items.  However, we generally would prefer to create extra bloat, than to break content.  Additionally, over time the bloat can be largely eliminated by revising the content.
>>
>> Having explained our rational for the revised proposal, can you help us understand where it falls short in your eyes?  Does it break your existing content?  Or does it create issue for evaluation?
>>
>> Thanks
>> Matt
>>
>> -----Original Message-----
>> From: [hidden email] [mailto:[hidden email]]
>> Sent: Tuesday, August 23, 2011 11:19 AM
>> To: oval-developer-list OVAL Developer List/Closed Public Discussion
>> Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal
>>
>> Why has the proposal changed so drastically from the last proposal?
>>
>> Using your proposal, we invalidate all current content, as content authors do not expect to collect both the 32-bit node and the 64-bit node.
>>
>> Reading through the previous email chain, I felt most people agreed with the original 'none (os-native) or 32-bit' proposal.
>>
>> I think the following is the only viable solution...
>>
>> Behavior name: os_redirection
>> Behavior settings: "none", "32_bit"
>> Documentation: 64 bit versions of Windows provide alternate file system and registry views to 32bit applications. This behavior allows the OVAL object to operate in that alternate view. This behavior only applies to 64bit versions of windows, and is ignored in all other instances. A setting of "none" means that the unredirected, native 64bit view of the file system and registry will be examined. A setting of "32_bit" means the redirected 32bit view will be examined.
>> Default: none
>>
>> Paul
>>
>>
>> On Aug 23, 2011, at 8:10 AM, Hansbury, Matt wrote:
>>
>>> All,
>>>
>>> Once again I want to thank all the folks that are providing feedback as we try to narrow down the 32/64 bit redirection issue to a consensus solution.  The MITRE team has been reviewing all of the feedback over the past couple of weeks, and we now feel that it is appropriate to move forward with a solution based on that feedback.  Here is our updated proposal:
>>>
>>> We will create a new behavior on the relevant tests (windows registry and file tests, as well as file tests in the independent Schema) with the following details:
>>>
>>> Name:  windows_view
>>>
>>> Description: 64 bit versions of Windows provide an alternate file system and registry views to 32bit applications. This behavior allows the OVAL Object to state which view should be examined. This behavior only applies to Windows, and is ignored in all other platforms.
>>>
>>> Possible values:
>>> . 64_bit - Indicates that the 64-bit view on 64-bit Windows operating systems must be examined. On 32-bit Windows, using this behavior will result in a collected object with a flag of "does not exist".
>>> . 32_bit - Indicates that the 32-bit view on both 64-bit and 32-bit Windows operating systems must be examined.
>>> . all - Indicates that both the 32-bit and 64-bit views must be examined on 64-bit Windows operating systems. On 32-bit Windows operating systems, indicates that only the 32-bit view is examined.  In some cases this will result in collecting a given registry key once from the 32-bit view and once from the 64-bit view. These items must be differentiated by setting the windows_view item entity to 32_bit or 64_bit value respectively.
>>>
>>> Default: all
>>>
>>> By defaulting to the 'all' value, we believe that we will impact the least amount of content. Compliance content like USGCB and FDCC should not require any changes. Inventory related content like https://oval.mitre.org/repository/data/ViewDefinition?id=oval:org.mitre.oval:def:7533 which currently does not work will be fixed without any changes.
>>>
>>> Patch and vulnerability content on windows will still need reviewing, but a quick search of the OVAL Repository shows that the check attribute on tests is rarely set to 'all'. This means that there is good chance that this content will also not need to be updated.   While some content could be impacted here and be made incorrect, we believe that no matter what solution and default is chosen, some percentage of the content will be affected.  Therefore, we are trying to pick a default that minimizes that.
>>>
>>> We continue to value feedback on this issue, but in the interest of meeting the 5.10 timelines, we are going to begin implementing the above proposal, so that it can be included in the next Release Candidate.
>>>
>>> Thanks
>>> Matt
>>>
>>> ====================================================
>>> Matt Hansbury
>>> G022 -  Information Assurance Industry Collaboration
>>> The MITRE Corporation
>>> [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].
>>
>> 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].
>
> 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: 32/64 bit updated proposal

KenSimone
In reply to this post by Hansbury, Matt
During the last conference call, we explored the "all" concept, and determined that values, hashes and versions more often than not differed between x86 and x64. The only scenario where "all" *might* work is in the case of permission checks.

Additionally, I suspect most existing content will either flat out fail in certain scenarios, or will be susceptible to false positives.

If every collected item has to match the state, then the definition will most likely fail in the case where the unexpected version is installed (i.e. when an x64 version exists, and the content was intended for x86), since versions and hashes differ across the targets.

If only one collected item has to match the state, then it's possible to create a false pass. I simply mock up the "view" I don't care about so that it will pass, and then I can put whatever I want in the other view. The test passes regardless.

Let's approach it this way... Can someone point me to some existing definitions that will work reliably with "all"?

Thanks,
Ken

-----Original Message-----
From: Hansbury, Matt [mailto:[hidden email]]
Sent: Tuesday, August 23, 2011 11:53 AM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal

Paul,

The proposal has been changed, in many ways back to the original proposal following the Community Call, though this version contains some more explicit naming and better documentation.  The rational for this is as follows:

* During the initial long email exchange, it became clear that:
        a. There was significant confusion around the proposals
        b. There was a call for making thing very explicit for content authors

Given the above, we decided that introducing the '64_bit' value was important to achieve that level of detail and clarity.  Additionally, it was clear that limiting the effects of the behavior to only 64-bit systems was also introducing unnecessary confusion.  Therefore, we expanded the behavior to affect all platforms.  (This is intended to achieve clarity on the authoring side.  Obviously on the tool side, the behavior can still be largely ignored when examining a 32-bit system.)

* Another issue was attempting to limit the amount of broken content out there in the community.  From all of the content that we were able to review (the OVAL Repository content, USGCB, & FDCC content), it became very clear that the concept of 'all' would make the bulk of that content just work, which was as close to an ideal solution as possible.  

We understand that using this default (and even allowing this value) will create a significant amount of extra collected Items.  However, we generally would prefer to create extra bloat, than to break content.  Additionally, over time the bloat can be largely eliminated by revising the content.

Having explained our rational for the revised proposal, can you help us understand where it falls short in your eyes?  Does it break your existing content?  Or does it create issue for evaluation?  

Thanks
Matt

-----Original Message-----
From: [hidden email] [mailto:[hidden email]]
Sent: Tuesday, August 23, 2011 11:19 AM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal

Why has the proposal changed so drastically from the last proposal?

Using your proposal, we invalidate all current content, as content authors do not expect to collect both the 32-bit node and the 64-bit node.

Reading through the previous email chain, I felt most people agreed with the original 'none (os-native) or 32-bit' proposal.

I think the following is the only viable solution...

Behavior name: os_redirection
Behavior settings: "none", "32_bit"
Documentation: 64 bit versions of Windows provide alternate file system and registry views to 32bit applications. This behavior allows the OVAL object to operate in that alternate view. This behavior only applies to 64bit versions of windows, and is ignored in all other instances. A setting of "none" means that the unredirected, native 64bit view of the file system and registry will be examined. A setting of "32_bit" means the redirected 32bit view will be examined.
Default: none

Paul


On Aug 23, 2011, at 8:10 AM, Hansbury, Matt wrote:

> All,
>
> Once again I want to thank all the folks that are providing feedback as we try to narrow down the 32/64 bit redirection issue to a consensus solution.  The MITRE team has been reviewing all of the feedback over the past couple of weeks, and we now feel that it is appropriate to move forward with a solution based on that feedback.  Here is our updated proposal:
>
> We will create a new behavior on the relevant tests (windows registry and file tests, as well as file tests in the independent Schema) with the following details:
>
> Name:  windows_view
>
> Description: 64 bit versions of Windows provide an alternate file system and registry views to 32bit applications. This behavior allows the OVAL Object to state which view should be examined. This behavior only applies to Windows, and is ignored in all other platforms.
>
> Possible values:
> . 64_bit - Indicates that the 64-bit view on 64-bit Windows operating systems must be examined. On 32-bit Windows, using this behavior will result in a collected object with a flag of "does not exist".
> . 32_bit - Indicates that the 32-bit view on both 64-bit and 32-bit Windows operating systems must be examined.
> . all - Indicates that both the 32-bit and 64-bit views must be examined on 64-bit Windows operating systems. On 32-bit Windows operating systems, indicates that only the 32-bit view is examined.  In some cases this will result in collecting a given registry key once from the 32-bit view and once from the 64-bit view. These items must be differentiated by setting the windows_view item entity to 32_bit or 64_bit value respectively.
>
> Default: all
>
> By defaulting to the 'all' value, we believe that we will impact the least amount of content. Compliance content like USGCB and FDCC should not require any changes. Inventory related content like https://oval.mitre.org/repository/data/ViewDefinition?id=oval:org.mitre.oval:def:7533 which currently does not work will be fixed without any changes.
>
> Patch and vulnerability content on windows will still need reviewing, but a quick search of the OVAL Repository shows that the check attribute on tests is rarely set to 'all'. This means that there is good chance that this content will also not need to be updated.   While some content could be impacted here and be made incorrect, we believe that no matter what solution and default is chosen, some percentage of the content will be affected.  Therefore, we are trying to pick a default that minimizes that.
>
> We continue to value feedback on this issue, but in the interest of meeting the 5.10 timelines, we are going to begin implementing the above proposal, so that it can be included in the next Release Candidate.  
>
> Thanks
> Matt
>
> ====================================================
> Matt Hansbury
> G022 -  Information Assurance Industry Collaboration The MITRE
> Corporation [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].

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

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: 32/64 bit updated proposal

Jon Baker
Administrator
>
>Let's approach it this way... Can someone point me to some existing definitions
>that will work reliably with "all"?
>

Won' t the FDCC content work? With a value of 'all' for the new behavior and a check attribute value of 'all', we are saying that both the 32 and 64 bit views must match the specified state (The FDCC content currently uses 'all' for its check attributes on tests.). On a 64 bit system I think that you would end up collecting the same registry key twice. If for some reason the values were different then you would fail, but that case should be concerning anyway.

Jon

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: 32/64 bit updated proposal

Gunnar Engelbach
On 8/23/2011 2:35 PM, Baker, Jon wrote:
>>
>> Let's approach it this way... Can someone point me to some existing definitions
>> that will work reliably with "all"?
>>
>
> Won' t the FDCC content work? With a value of 'all' for the new behavior and a check attribute value of 'all', we are saying that both the 32 and 64 bit views must match the specified state (The FDCC content currently uses 'all' for its check attributes on tests.). On a 64 bit system I think that you would end up collecting the same registry key twice. If for some reason the values were different then you would fail, but that case should be concerning anyway.

The example is valid point, but brings up a different issue in that
64-bit Windows OS checks are a special case.  On a 64-bit machine the
32-bit registry values are frequently different and from an OS
perspective the 32-bit values are not used, so a rule that fails when
the 64-bit value is correct and the 32-bit value is not would be a false
negative.

system32 vice syswow64 permissions and file versions are a different matter.


>
> Jon
>
> 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: 32/64 bit updated proposal

KenSimone
In reply to this post by Jon Baker
>> Won' t the FDCC content work? With a value of 'all' for the new behavior and a check attribute value of 'all', we are saying that both the 32 and 64 bit views
>> must match the specified state (The FDCC content currently uses 'all' for its check attributes on tests.). On a 64 bit system I think that you would end up
>> collecting the same registry key twice. If for some reason the values were different then you would fail, but that case should be concerning anyway.

I don't believe it will work, at least not with any consistency. File versions are frequently different between x64 and x86, and file hashes are always different. Differences in registry values are also fairly common.

Ken

-----Original Message-----
From: Baker, Jon [mailto:[hidden email]]
Sent: Tuesday, August 23, 2011 1:36 PM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal

>
>Let's approach it this way... Can someone point me to some existing
>definitions that will work reliably with "all"?
>

Won' t the FDCC content work? With a value of 'all' for the new behavior and a check attribute value of 'all', we are saying that both the 32 and 64 bit views must match the specified state (The FDCC content currently uses 'all' for its check attributes on tests.). On a 64 bit system I think that you would end up collecting the same registry key twice. If for some reason the values were different then you would fail, but that case should be concerning anyway.

Jon

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: 32/64 bit updated proposal

Jon Baker
Administrator
>>> Won' t the FDCC content work? With a value of 'all' for the new behavior
>and a check attribute value of 'all', we are saying that both the 32 and 64 bit
>views
>>> must match the specified state (The FDCC content currently uses 'all' for its
>check attributes on tests.). On a 64 bit system I think that you would end up
>>> collecting the same registry key twice. If for some reason the values were
>different then you would fail, but that case should be concerning anyway.
>
>I don't believe it will work, at least not with any consistency. File versions are
>frequently different between x64 and x86, and file hashes are always different.
>Differences in registry values are also fairly common.
>

Yes, checks for file versions will likely not work. This would impact the vulnerability and patch content in the OVAL Repository. It would not impact the USGCB or FDCC content streams, unless you are thinking of the patch content. The patch content for FDCC and USGCB will be impacted.

It looks like I should clarify a bit... When I stated that the USGCB and the FDCC content would not be impacted by this change I was referring to the compliance related content. The compliance definitions used in FDCC and USGCB are largely aimed at file permissions and registry settings, which should not be an issue.

Are you saying that this compliance related content will be broken too? If it is then we completely agree that this latest proposal is not acceptable.

Does that help clarify?

Jon

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: 32/64 bit updated proposal

Jon Baker
Administrator
In reply to this post by Paul_Whitehurst
Paul,

Are you talking about the content in your (meaning McAfee's) content repository?  Or the OVAL Repository?  My reading of your response is that you were talking about the OVAL Repository, and we are not clear on how a default of 'all' would break all of that content.  We were actually trying to convey the opposite in Matt's latest email.  

The team here believes that by including 'none' and including it as the default, we would essentially be choosing to leave the ambiguity that is already present in content.  ('none' here meaning, don't redirect at all, which would mean that the content would include no more intent than before.)  By choosing anything other than 'none', we would be at least moving clearly in a direction of clear intent.  Now, without question, we would also be breaking some content, and that needs to be addressed, though it does regardless of our solution.  I suppose the question is will it be harder to fix the content broken by defaulting to 'all', or checking and revising the intent of the content by choosing any other default?  (This is where some insight into other existing content would be helpful.)

Our assessment of the situation, as far as how this would affect the different types of content is as follows:

* compliance content - we believe that in large part this will just work, since in most cases compliance content assesses the OS, as opposed to applications. Is this an invalid assumption?
* inventory content - in many cases, we think that this content will be made to work correctly by defaulting to 'all', since in most cases, it is simply looking to see if an application is installed somewhere.
* vulnerability & patch content - in this case, we are pretty sure that we have a challenge (regardless of the default, in fact).  There seems to be a large number of cases where this content would need revision and would almost need to be entirely reviewed.

Hopefully that better explains our thinking here.  Please note that we are not trying to push a solution that does not work for folks.  We are happy to revise things to best suit the community needs.  Our latest proposal was achieved by focusing on the two major factors stated earlier (1. Focusing on making this as clear and explicit as possible for authors, and 2. Breaking the least amount of content.)  

So, are we way off here?  Does this achieve either of our goals?  (I believe we have in the case of making things clear for authors)   If not, how can we revise this to achieve them both?

Thanks

Jon

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


>-----Original Message-----
>From: [hidden email]
>[mailto:[hidden email]]
>Sent: Tuesday, August 23, 2011 1:41 PM
>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal
>
>You posted your proposal on 8/15.  After that email, there were 13 responses.
>Of those 13, there are 4 unique responders.  Ken, Shane, Gunnar.. James, and
>Timothy.  Ken and james were for the proposal, Shane was against.  Timothy
>did not state an opinion and Gunnar agreed with Shane but was ambivalent to
>which approach to take.  Prior to your proposal, most people agreed with Ken's
>approach (which is your formal proposal).
>
>As to the content issue.  We currently have broken content in the repository.  It
>is safe to assume content that was written to target 32 bit systems works on 32
>bit system and content written to target 64 bit systems works on 64 bit system.
>There for content which targets a 32 bit system, but runs on a 64 bit system is
>probably broken (although it is possible to write content that works on both 32
>bit and 64 bit systems).  If you make the default behavior to collect both the 32
>bit data and the 64 bit data for all checks, all content is broken as no content
>creators would expect that behavior prior to now.  Furthermore, it is not
>possible to fix existing content when executed on a 64 bit machine without
>breaking other content because we cannot know the intentions and
>expectations of the content author.
>
>
>Seeing as content will be broken regardless of the approach, there was not
>significant push back for the proposal of August 15th, and, as Ken pointed out,
>there was a universal rejection to the 'default: all' proposal during the
>teleconference; I see no compelling reason to change the proposal.
>
>Paul
>
>
>On Aug 23, 2011, at 11:52 AM, Hansbury, Matt wrote:
>
>> Paul,
>>
>> The proposal has been changed, in many ways back to the original proposal
>following the Community Call, though this version contains some more explicit
>naming and better documentation.  The rational for this is as follows:
>>
>> * During the initial long email exchange, it became clear that:
>> a. There was significant confusion around the proposals
>> b. There was a call for making thing very explicit for content authors
>>
>> Given the above, we decided that introducing the '64_bit' value was
>important to achieve that level of detail and clarity.  Additionally, it was clear
>that limiting the effects of the behavior to only 64-bit systems was also
>introducing unnecessary confusion.  Therefore, we expanded the behavior to
>affect all platforms.  (This is intended to achieve clarity on the authoring side.
>Obviously on the tool side, the behavior can still be largely ignored when
>examining a 32-bit system.)
>>
>> * Another issue was attempting to limit the amount of broken content out
>there in the community.  From all of the content that we were able to review
>(the OVAL Repository content, USGCB, & FDCC content), it became very clear
>that the concept of 'all' would make the bulk of that content just work, which
>was as close to an ideal solution as possible.
>>
>> We understand that using this default (and even allowing this value) will
>create a significant amount of extra collected Items.  However, we generally
>would prefer to create extra bloat, than to break content.  Additionally, over
>time the bloat can be largely eliminated by revising the content.
>>
>> Having explained our rational for the revised proposal, can you help us
>understand where it falls short in your eyes?  Does it break your existing
>content?  Or does it create issue for evaluation?
>>
>> Thanks
>> Matt
>>
>> -----Original Message-----
>> From: [hidden email]
>[mailto:[hidden email]]
>> Sent: Tuesday, August 23, 2011 11:19 AM
>> To: oval-developer-list OVAL Developer List/Closed Public Discussion
>> Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal
>>
>> Why has the proposal changed so drastically from the last proposal?
>>
>> Using your proposal, we invalidate all current content, as content authors do
>not expect to collect both the 32-bit node and the 64-bit node.
>>
>> Reading through the previous email chain, I felt most people agreed with the
>original 'none (os-native) or 32-bit' proposal.
>>
>> I think the following is the only viable solution...
>>
>> Behavior name: os_redirection
>> Behavior settings: "none", "32_bit"
>> Documentation: 64 bit versions of Windows provide alternate file system and
>registry views to 32bit applications. This behavior allows the OVAL object to
>operate in that alternate view. This behavior only applies to 64bit versions of
>windows, and is ignored in all other instances. A setting of "none" means that
>the unredirected, native 64bit view of the file system and registry will be
>examined. A setting of "32_bit" means the redirected 32bit view will be
>examined.
>> Default: none
>>
>> Paul
>>
>>
>> On Aug 23, 2011, at 8:10 AM, Hansbury, Matt wrote:
>>
>>> All,
>>>
>>> Once again I want to thank all the folks that are providing feedback as we
>try to narrow down the 32/64 bit redirection issue to a consensus solution.  The
>MITRE team has been reviewing all of the feedback over the past couple of
>weeks, and we now feel that it is appropriate to move forward with a solution
>based on that feedback.  Here is our updated proposal:
>>>
>>> We will create a new behavior on the relevant tests (windows registry and
>file tests, as well as file tests in the independent Schema) with the following
>details:
>>>
>>> Name:  windows_view
>>>
>>> Description: 64 bit versions of Windows provide an alternate file system and
>registry views to 32bit applications. This behavior allows the OVAL Object to
>state which view should be examined. This behavior only applies to Windows,
>and is ignored in all other platforms.
>>>
>>> Possible values:
>>> . 64_bit - Indicates that the 64-bit view on 64-bit Windows operating
>systems must be examined. On 32-bit Windows, using this behavior will result
>in a collected object with a flag of "does not exist".
>>> . 32_bit - Indicates that the 32-bit view on both 64-bit and 32-bit
>Windows operating systems must be examined.
>>> . all - Indicates that both the 32-bit and 64-bit views must be examined
>on 64-bit Windows operating systems. On 32-bit Windows operating systems,
>indicates that only the 32-bit view is examined.  In some cases this will result in
>collecting a given registry key once from the 32-bit view and once from the 64-
>bit view. These items must be differentiated by setting the windows_view item
>entity to 32_bit or 64_bit value respectively.
>>>
>>> Default: all
>>>
>>> By defaulting to the 'all' value, we believe that we will impact the least
>amount of content. Compliance content like USGCB and FDCC should not
>require any changes. Inventory related content like
>https://oval.mitre.org/repository/data/ViewDefinition?id=oval:org.mitre.oval:
>def:7533 which currently does not work will be fixed without any changes.
>>>
>>> Patch and vulnerability content on windows will still need reviewing, but a
>quick search of the OVAL Repository shows that the check attribute on tests is
>rarely set to 'all'. This means that there is good chance that this content will also
>not need to be updated.   While some content could be impacted here and be
>made incorrect, we believe that no matter what solution and default is chosen,
>some percentage of the content will be affected.  Therefore, we are trying to
>pick a default that minimizes that.
>
>>>
>>> We continue to value feedback on this issue, but in the interest of meeting
>the 5.10 timelines, we are going to begin implementing the above proposal, so
>that it can be included in the next Release Candidate.
>>>
>>> Thanks
>>> Matt
>>>
>>> ====================================================
>>> Matt Hansbury
>>> G022 -  Information Assurance Industry Collaboration
>>> The MITRE Corporation
>>> [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 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 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].
Reply | Threaded
Open this post in threaded view
|

Re: 32/64 bit updated proposal

KenSimone
I think the point is that no content is written with the intent that it target both x64 and x86 instances at the same time, and that's exactly what this proposal makes all content do. It may work in some scenarios, however there are many scenarios where it will break. Specifically:

I suspect all file-related content will break. Versions and hashes differ between x64 and x86 and the state cannot be shared.
I suspect many registry-related content will break, as values are not always mirrored between x64 and x86 and the state cannot be shared.
I have seen customer and internal content that populates variables with registry values. This will probably break when the variables suddenly become multi-valued.

My other concerns with the "all" setting are:

It's overly complex. Content authors must consider three states (x86, x64, and both) with one state object.
It's noisy. Any non-redirected registry path on x64 will always produce two items, correct?
There are many subtleties in OVAL that are ambiguous with this approach (i.e. If an item exists in one view, but not the other, does an item w/ a status of "does not exist" get created? Why or why not? How does "check_existence=all" behave?).

My impression is that the "all" concept is being proposed to salvage some existing content. I would argue that it actually puts all content at risk on x64 platforms. I believe that there are two types of content that exist in the wild. Content that assumes it will always see the 32bit world, and content that assumes it will always see the 64bit world on a 64bit system, and the 32bit world on a 32bit system. The default should be one of those. Not any sort of new concept.

 
Ken

-----Original Message-----
From: Baker, Jon [mailto:[hidden email]]
Sent: Tuesday, August 23, 2011 3:35 PM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal

Paul,

Are you talking about the content in your (meaning McAfee's) content repository?  Or the OVAL Repository?  My reading of your response is that you were talking about the OVAL Repository, and we are not clear on how a default of 'all' would break all of that content.  We were actually trying to convey the opposite in Matt's latest email.  

The team here believes that by including 'none' and including it as the default, we would essentially be choosing to leave the ambiguity that is already present in content.  ('none' here meaning, don't redirect at all, which would mean that the content would include no more intent than before.)  By choosing anything other than 'none', we would be at least moving clearly in a direction of clear intent.  Now, without question, we would also be breaking some content, and that needs to be addressed, though it does regardless of our solution.  I suppose the question is will it be harder to fix the content broken by defaulting to 'all', or checking and revising the intent of the content by choosing any other default?  (This is where some insight into other existing content would be helpful.)

Our assessment of the situation, as far as how this would affect the different types of content is as follows:

* compliance content - we believe that in large part this will just work, since in most cases compliance content assesses the OS, as opposed to applications. Is this an invalid assumption?
* inventory content - in many cases, we think that this content will be made to work correctly by defaulting to 'all', since in most cases, it is simply looking to see if an application is installed somewhere.
* vulnerability & patch content - in this case, we are pretty sure that we have a challenge (regardless of the default, in fact).  There seems to be a large number of cases where this content would need revision and would almost need to be entirely reviewed.

Hopefully that better explains our thinking here.  Please note that we are not trying to push a solution that does not work for folks.  We are happy to revise things to best suit the community needs.  Our latest proposal was achieved by focusing on the two major factors stated earlier (1. Focusing on making this as clear and explicit as possible for authors, and 2. Breaking the least amount of content.)  

So, are we way off here?  Does this achieve either of our goals?  (I believe we have in the case of making things clear for authors)   If not, how can we revise this to achieve them both?

Thanks

Jon

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


>-----Original Message-----
>From: [hidden email]
>[mailto:[hidden email]]
>Sent: Tuesday, August 23, 2011 1:41 PM
>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal
>
>You posted your proposal on 8/15.  After that email, there were 13 responses.
>Of those 13, there are 4 unique responders.  Ken, Shane, Gunnar..
>James, and Timothy.  Ken and james were for the proposal, Shane was
>against.  Timothy did not state an opinion and Gunnar agreed with Shane
>but was ambivalent to which approach to take.  Prior to your proposal,
>most people agreed with Ken's approach (which is your formal proposal).
>
>As to the content issue.  We currently have broken content in the
>repository.  It is safe to assume content that was written to target 32
>bit systems works on 32 bit system and content written to target 64 bit systems works on 64 bit system.
>There for content which targets a 32 bit system, but runs on a 64 bit
>system is probably broken (although it is possible to write content
>that works on both 32 bit and 64 bit systems).  If you make the default
>behavior to collect both the 32 bit data and the 64 bit data for all
>checks, all content is broken as no content creators would expect that
>behavior prior to now.  Furthermore, it is not possible to fix existing
>content when executed on a 64 bit machine without breaking other
>content because we cannot know the intentions and expectations of the content author.
>
>
>Seeing as content will be broken regardless of the approach, there was
>not significant push back for the proposal of August 15th, and, as Ken
>pointed out, there was a universal rejection to the 'default: all'
>proposal during the teleconference; I see no compelling reason to change the proposal.
>
>Paul
>
>
>On Aug 23, 2011, at 11:52 AM, Hansbury, Matt wrote:
>
>> Paul,
>>
>> The proposal has been changed, in many ways back to the original
>> proposal
>following the Community Call, though this version contains some more
>explicit naming and better documentation.  The rational for this is as follows:
>>
>> * During the initial long email exchange, it became clear that:
>> a. There was significant confusion around the proposals
>> b. There was a call for making thing very explicit for content
>> authors
>>
>> Given the above, we decided that introducing the '64_bit' value was
>important to achieve that level of detail and clarity.  Additionally,
>it was clear that limiting the effects of the behavior to only 64-bit
>systems was also introducing unnecessary confusion.  Therefore, we
>expanded the behavior to affect all platforms.  (This is intended to achieve clarity on the authoring side.
>Obviously on the tool side, the behavior can still be largely ignored
>when examining a 32-bit system.)
>>
>> * Another issue was attempting to limit the amount of broken content
>> out
>there in the community.  From all of the content that we were able to
>review (the OVAL Repository content, USGCB, & FDCC content), it became
>very clear that the concept of 'all' would make the bulk of that
>content just work, which was as close to an ideal solution as possible.
>>
>> We understand that using this default (and even allowing this value)
>> will
>create a significant amount of extra collected Items.  However, we
>generally would prefer to create extra bloat, than to break content.  
>Additionally, over time the bloat can be largely eliminated by revising the content.
>>
>> Having explained our rational for the revised proposal, can you help
>> us
>understand where it falls short in your eyes?  Does it break your
>existing content?  Or does it create issue for evaluation?
>>
>> Thanks
>> Matt
>>
>> -----Original Message-----
>> From: [hidden email]
>[mailto:[hidden email]]
>> Sent: Tuesday, August 23, 2011 11:19 AM
>> To: oval-developer-list OVAL Developer List/Closed Public Discussion
>> Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal
>>
>> Why has the proposal changed so drastically from the last proposal?
>>
>> Using your proposal, we invalidate all current content, as content
>> authors do
>not expect to collect both the 32-bit node and the 64-bit node.
>>
>> Reading through the previous email chain, I felt most people agreed
>> with the
>original 'none (os-native) or 32-bit' proposal.
>>
>> I think the following is the only viable solution...
>>
>> Behavior name: os_redirection
>> Behavior settings: "none", "32_bit"
>> Documentation: 64 bit versions of Windows provide alternate file
>> system and
>registry views to 32bit applications. This behavior allows the OVAL
>object to operate in that alternate view. This behavior only applies to
>64bit versions of windows, and is ignored in all other instances. A
>setting of "none" means that the unredirected, native 64bit view of the
>file system and registry will be examined. A setting of "32_bit" means
>the redirected 32bit view will be examined.
>> Default: none
>>
>> Paul
>>
>>
>> On Aug 23, 2011, at 8:10 AM, Hansbury, Matt wrote:
>>
>>> All,
>>>
>>> Once again I want to thank all the folks that are providing feedback
>>> as we
>try to narrow down the 32/64 bit redirection issue to a consensus
>solution.  The MITRE team has been reviewing all of the feedback over
>the past couple of weeks, and we now feel that it is appropriate to
>move forward with a solution based on that feedback.  Here is our updated proposal:
>>>
>>> We will create a new behavior on the relevant tests (windows
>>> registry and
>file tests, as well as file tests in the independent Schema) with the
>following
>details:
>>>
>>> Name:  windows_view
>>>
>>> Description: 64 bit versions of Windows provide an alternate file
>>> system and
>registry views to 32bit applications. This behavior allows the OVAL
>Object to state which view should be examined. This behavior only
>applies to Windows, and is ignored in all other platforms.
>>>
>>> Possible values:
>>> . 64_bit - Indicates that the 64-bit view on 64-bit Windows
>>> operating
>systems must be examined. On 32-bit Windows, using this behavior will
>result in a collected object with a flag of "does not exist".
>>> . 32_bit - Indicates that the 32-bit view on both 64-bit and 32-bit
>Windows operating systems must be examined.
>>> . all - Indicates that both the 32-bit and 64-bit views must be
>>> examined
>on 64-bit Windows operating systems. On 32-bit Windows operating
>systems, indicates that only the 32-bit view is examined.  In some
>cases this will result in collecting a given registry key once from the
>32-bit view and once from the 64- bit view. These items must be
>differentiated by setting the windows_view item entity to 32_bit or 64_bit value respectively.
>>>
>>> Default: all
>>>
>>> By defaulting to the 'all' value, we believe that we will impact the
>>> least
>amount of content. Compliance content like USGCB and FDCC should not
>require any changes. Inventory related content like
>https://oval.mitre.org/repository/data/ViewDefinition?id=oval:org.mitre.oval:
>def:7533 which currently does not work will be fixed without any changes.
>>>
>>> Patch and vulnerability content on windows will still need
>>> reviewing, but a
>quick search of the OVAL Repository shows that the check attribute on
>tests is rarely set to 'all'. This means that there is good chance that this content will also
>not need to be updated.   While some content could be impacted here and be
>made incorrect, we believe that no matter what solution and default is
>chosen, some percentage of the content will be affected.  Therefore, we
>are trying to pick a default that minimizes that.
>
>>>
>>> We continue to value feedback on this issue, but in the interest of
>>> meeting
>the 5.10 timelines, we are going to begin implementing the above
>proposal, so that it can be included in the next Release Candidate.
>>>
>>> Thanks
>>> Matt
>>>
>>> ====================================================
>>> Matt Hansbury
>>> G022 -  Information Assurance Industry Collaboration The MITRE
>>> Corporation [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 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 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].

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: 32/64 bit updated proposal

Jon Baker
Administrator
Ken and others, thanks for sticking with us through this discussion. I have detailed responses to your comments inline below.

We did not intend to surprise people with the proposal we posted yesterday. We were looking to find a compromise solution that gave us the clear and precise behaviors that were being requested and preserve as much content as possible. In further considering the proposal and listing to your feedback, it is clear that yesterday's proposal will not suffice.

We will revisit the second proposal (suggested by Ken) next.

Thanks,

Jon

>-----Original Message-----
>From: [hidden email] [mailto:[hidden email]]
>Sent: Tuesday, August 23, 2011 5:59 PM
>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal
>
>I think the point is that no content is written with the intent that it target both
>x64 and x86 instances at the same time, and that's exactly what this proposal
>makes all content do. It may work in some scenarios, however there are many
>scenarios where it will break. Specifically:
>

Take a look at the following definition:

https://oval.mitre.org/repository/data/ViewDefinition?id=oval:org.mitre.oval:def:7533

When we made the current proposal, we were considering the above definition, the USGCB/FDCC content, and the other content in the OVAL Repository.

The windows_view with a default of 'all' definitely makes the inventory definition above work.

Through this discussion, it is clear that some of our assumptions around the compliance content were invalid. I completely agree that none of the content was written to target both 32 and 64 bit views on a 64 bit system.

However, the USGCB content was written to work on both 32 and 64 bit windows operating systems. I realize that this is quite different than targeting both the 32 and 64 bit view on a 64 bit system.

>I suspect all file-related content will break. Versions and hashes differ between
>x64 and x86 and the state cannot be shared.

I agree that the file related content will be broken by this proposal. The previous proposal would have ensured that any of file-related content that was written for a 32 bit operating system would continue to work. We would need to review and fix the file related content on 64 bit windows systems.

Note that file permission checks would probably not be broken by this proposal.

>I suspect many registry-related content will break, as values are not always
>mirrored between x64 and x86 and the state cannot be shared.

I think this would be a mixed bag. Settings like "Interactive logon: Do not require CTRL+ALT+DEL" in the USGCB (show below) should be unaffected by our most recent proposal.

<registry_object xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5#windows" id="oval:gov.nist.usgcb.windowsseven:obj:51" version="1">
   <hive>HKEY_LOCAL_MACHINE</hive>
   <key>Software\Microsoft\Windows\CurrentVersion\Policies\System</key>
   <name>DisableCAD</name>
</registry_object>

Many of the settings in USGCB are just like the one above, where the key is mirrored to both 32 and 64 bit views. I think this content would all be unaffected by the current proposal.

I agree that this content was developed and tested to target either 32 bit or 64 bit operating systems but not both.

>I have seen customer and internal content that populates variables with registry
>values. This will probably break when the variables suddenly become multi-
>valued.
>

Agree, the current proposal becomes quite complex when variables are used. Not only would we need to consider the check and the check_existence attribute on tests, but we would need to look into the var_check attribute wherever a variable is used. I can see how this would be quite complex for content authors to interpret correctly.


>My other concerns with the "all" setting are:
>
>It's overly complex. Content authors must consider three states (x86, x64, and
>both) with one state object.

Agree, it adds a good deal of complexity. However, i think that moving forward content authors will need to be more aware of the platform(s) they are targeting regardless of the solution we choose. With the default to 'all' and the other choices being '32_bit' and '64_bit', content authors for settings like "Interactive logon: Do not require CTRL+ALT+DEL" would probably be best off simply writing two tests. Where one test targets 32_bit and one test targets 64_bit. With the previous proposal where the option were 'none' and 32_bit' the content author could choose 'none'. Obviously the later approach is far more simple.

>It's noisy. Any non-redirected registry path on x64 will always produce two
>items, correct?

Yes, that is correct. Non redirected registry keys and file paths would produce two items when in reality there is only one item. This would cause bloat of system characteristics files.

>There are many subtleties in OVAL that are ambiguous with this approach (i.e.
>If an item exists in one view, but not the other, does an item w/ a status of
>"does not exist" get created? Why or why not? How does
>"check_existence=all" behave?).
>

We have discussed this subtly a bit and have not come up with a solution that really makes us happy. If you create an item with a status of 'does not exist' any content that uses an existence_check of 'all_exist' will be broken. On the other hand, it feels a bit like a kludge to not create an item when it does not exist in one of the two views and the windows_view='all'.

We have not run into any other subtleties with this proposal, but agree that this is not an easy one to solve correctly.

>My impression is that the "all" concept is being proposed to salvage some
>existing content. I would argue that it actually puts all content at risk on x64
>platforms. I believe that there are two types of content that exist in the wild.
>Content that assumes it will always see the 32bit world, and content that
>assumes it will always see the 64bit world on a 64bit system, and the 32bit
>world on a 32bit system. The default should be one of those. Not any sort of
>new concept.

I think that these are fair assumptions. We felt that 'all' might be a be the happy medium that would preserve some of the content written to check 32 bit applications that may be installed on a 64 bit system.


>
>
>Ken
>
>-----Original Message-----
>From: Baker, Jon [mailto:[hidden email]]
>Sent: Tuesday, August 23, 2011 3:35 PM
>To: [hidden email]
>Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal
>
>Paul,
>
>Are you talking about the content in your (meaning McAfee's) content
>repository?  Or the OVAL Repository?  My reading of your response is that you
>were talking about the OVAL Repository, and we are not clear on how a default
>of 'all' would break all of that content.  We were actually trying to convey the
>opposite in Matt's latest email.
>
>The team here believes that by including 'none' and including it as the default,
>we would essentially be choosing to leave the ambiguity that is already present
>in content.  ('none' here meaning, don't redirect at all, which would mean that
>the content would include no more intent than before.)  By choosing anything
>other than 'none', we would be at least moving clearly in a direction of clear
>intent.  Now, without question, we would also be breaking some content, and
>that needs to be addressed, though it does regardless of our solution.  I suppose
>the question is will it be harder to fix the content broken by defaulting to 'all', or
>checking and revising the intent of the content by choosing any other default?
>(This is where some insight into other existing content would be helpful.)
>
>Our assessment of the situation, as far as how this would affect the different
>types of content is as follows:
>
>* compliance content - we believe that in large part this will just work, since in
>most cases compliance content assesses the OS, as opposed to applications. Is
>this an invalid assumption?
>* inventory content - in many cases, we think that this content will be made to
>work correctly by defaulting to 'all', since in most cases, it is simply looking to
>see if an application is installed somewhere.
>* vulnerability & patch content - in this case, we are pretty sure that we have a
>challenge (regardless of the default, in fact).  There seems to be a large number
>of cases where this content would need revision and would almost need to be
>entirely reviewed.
>
>Hopefully that better explains our thinking here.  Please note that we are not
>trying to push a solution that does not work for folks.  We are happy to revise
>things to best suit the community needs.  Our latest proposal was achieved by
>focusing on the two major factors stated earlier (1. Focusing on making this as
>clear and explicit as possible for authors, and 2. Breaking the least amount of
>content.)
>
>So, are we way off here?  Does this achieve either of our goals?  (I believe we
>have in the case of making things clear for authors)   If not, how can we revise
>this to achieve them both?
>
>Thanks
>
>Jon
>
>============================================
>Jonathan O. Baker
>G022 - IA Industry Collaboration
>The MITRE Corporation
>Email: [hidden email]
>
>
>>-----Original Message-----
>>From: [hidden email]
>>[mailto:[hidden email]]
>>Sent: Tuesday, August 23, 2011 1:41 PM
>>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>>Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal
>>
>>You posted your proposal on 8/15.  After that email, there were 13 responses.
>>Of those 13, there are 4 unique responders.  Ken, Shane, Gunnar..
>>James, and Timothy.  Ken and james were for the proposal, Shane was
>>against.  Timothy did not state an opinion and Gunnar agreed with Shane
>>but was ambivalent to which approach to take.  Prior to your proposal,
>>most people agreed with Ken's approach (which is your formal proposal).
>>
>>As to the content issue.  We currently have broken content in the
>>repository.  It is safe to assume content that was written to target 32
>>bit systems works on 32 bit system and content written to target 64 bit
>systems works on 64 bit system.
>>There for content which targets a 32 bit system, but runs on a 64 bit
>>system is probably broken (although it is possible to write content
>>that works on both 32 bit and 64 bit systems).  If you make the default
>>behavior to collect both the 32 bit data and the 64 bit data for all
>>checks, all content is broken as no content creators would expect that
>>behavior prior to now.  Furthermore, it is not possible to fix existing
>>content when executed on a 64 bit machine without breaking other
>>content because we cannot know the intentions and expectations of the
>content author.
>>
>>
>>Seeing as content will be broken regardless of the approach, there was
>>not significant push back for the proposal of August 15th, and, as Ken
>>pointed out, there was a universal rejection to the 'default: all'
>>proposal during the teleconference; I see no compelling reason to change the
>proposal.
>>
>>Paul
>>
>>
>>On Aug 23, 2011, at 11:52 AM, Hansbury, Matt wrote:
>>
>>> Paul,
>>>
>>> The proposal has been changed, in many ways back to the original
>>> proposal
>>following the Community Call, though this version contains some more
>>explicit naming and better documentation.  The rational for this is as follows:
>>>
>>> * During the initial long email exchange, it became clear that:
>>>     a. There was significant confusion around the proposals
>>>     b. There was a call for making thing very explicit for content
>>> authors
>>>
>>> Given the above, we decided that introducing the '64_bit' value was
>>important to achieve that level of detail and clarity.  Additionally,
>>it was clear that limiting the effects of the behavior to only 64-bit
>>systems was also introducing unnecessary confusion.  Therefore, we
>>expanded the behavior to affect all platforms.  (This is intended to achieve
>clarity on the authoring side.
>>Obviously on the tool side, the behavior can still be largely ignored
>>when examining a 32-bit system.)
>>>
>>> * Another issue was attempting to limit the amount of broken content
>>> out
>>there in the community.  From all of the content that we were able to
>>review (the OVAL Repository content, USGCB, & FDCC content), it became
>>very clear that the concept of 'all' would make the bulk of that
>>content just work, which was as close to an ideal solution as possible.
>>>
>>> We understand that using this default (and even allowing this value)
>>> will
>>create a significant amount of extra collected Items.  However, we
>>generally would prefer to create extra bloat, than to break content.
>>Additionally, over time the bloat can be largely eliminated by revising the
>content.
>>>
>>> Having explained our rational for the revised proposal, can you help
>>> us
>>understand where it falls short in your eyes?  Does it break your
>>existing content?  Or does it create issue for evaluation?
>>>
>>> Thanks
>>> Matt
>>>
>>> -----Original Message-----
>>> From: [hidden email]
>>[mailto:[hidden email]]
>>> Sent: Tuesday, August 23, 2011 11:19 AM
>>> To: oval-developer-list OVAL Developer List/Closed Public Discussion
>>> Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal
>>>
>>> Why has the proposal changed so drastically from the last proposal?
>>>
>>> Using your proposal, we invalidate all current content, as content
>>> authors do
>>not expect to collect both the 32-bit node and the 64-bit node.
>>>
>>> Reading through the previous email chain, I felt most people agreed
>>> with the
>>original 'none (os-native) or 32-bit' proposal.
>>>
>>> I think the following is the only viable solution...
>>>
>>> Behavior name: os_redirection
>>> Behavior settings: "none", "32_bit"
>>> Documentation: 64 bit versions of Windows provide alternate file
>>> system and
>>registry views to 32bit applications. This behavior allows the OVAL
>>object to operate in that alternate view. This behavior only applies to
>>64bit versions of windows, and is ignored in all other instances. A
>>setting of "none" means that the unredirected, native 64bit view of the
>>file system and registry will be examined. A setting of "32_bit" means
>>the redirected 32bit view will be examined.
>>> Default: none
>>>
>>> Paul
>>>
>>>
>>> On Aug 23, 2011, at 8:10 AM, Hansbury, Matt wrote:
>>>
>>>> All,
>>>>
>>>> Once again I want to thank all the folks that are providing feedback
>>>> as we
>>try to narrow down the 32/64 bit redirection issue to a consensus
>>solution.  The MITRE team has been reviewing all of the feedback over
>>the past couple of weeks, and we now feel that it is appropriate to
>>move forward with a solution based on that feedback.  Here is our updated
>proposal:
>>>>
>>>> We will create a new behavior on the relevant tests (windows
>>>> registry and
>>file tests, as well as file tests in the independent Schema) with the
>>following
>>details:
>>>>
>>>> Name:  windows_view
>>>>
>>>> Description: 64 bit versions of Windows provide an alternate file
>>>> system and
>>registry views to 32bit applications. This behavior allows the OVAL
>>Object to state which view should be examined. This behavior only
>>applies to Windows, and is ignored in all other platforms.
>>>>
>>>> Possible values:
>>>>    . 64_bit - Indicates that the 64-bit view on 64-bit Windows
>>>> operating
>>systems must be examined. On 32-bit Windows, using this behavior will
>>result in a collected object with a flag of "does not exist".
>>>>    . 32_bit - Indicates that the 32-bit view on both 64-bit and 32-bit
>>Windows operating systems must be examined.
>>>>    . all - Indicates that both the 32-bit and 64-bit views must be
>>>> examined
>>on 64-bit Windows operating systems. On 32-bit Windows operating
>>systems, indicates that only the 32-bit view is examined.  In some
>>cases this will result in collecting a given registry key once from the
>>32-bit view and once from the 64- bit view. These items must be
>>differentiated by setting the windows_view item entity to 32_bit or 64_bit
>value respectively.
>>>>
>>>> Default: all
>>>>
>>>> By defaulting to the 'all' value, we believe that we will impact the
>>>> least
>>amount of content. Compliance content like USGCB and FDCC should not
>>require any changes. Inventory related content like
>>https://oval.mitre.org/repository/data/ViewDefinition?id=oval:org.mitre.oval
>:
>>def:7533 which currently does not work will be fixed without any changes.
>>>>
>>>> Patch and vulnerability content on windows will still need
>>>> reviewing, but a
>>quick search of the OVAL Repository shows that the check attribute on
>>tests is rarely set to 'all'. This means that there is good chance that this content
>will also
>>not need to be updated.   While some content could be impacted here and be
>>made incorrect, we believe that no matter what solution and default is
>>chosen, some percentage of the content will be affected.  Therefore, we
>>are trying to pick a default that minimizes that.
>>
>>>>
>>>> We continue to value feedback on this issue, but in the interest of
>>>> meeting
>>the 5.10 timelines, we are going to begin implementing the above
>>proposal, so that it can be included in the next Release Candidate.
>>>>
>>>> Thanks
>>>> Matt
>>>>
>>>> ====================================================
>>>> Matt Hansbury
>>>> G022 -  Information Assurance Industry Collaboration The MITRE
>>>> Corporation [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 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 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].
>
>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].
Reply | Threaded
Open this post in threaded view
|

Re: 32/64 bit updated proposal

Hansbury, Matt
All,

From the feedback we received from the latest proposal, it certainly seems that we need to revise things.  It seems that the second proposal has received the most positive feedback, and so let's start again with that.  Here is what we'd like to do:


Create a behavior for Windows file and registry tests, and the Independent file tests:

Behavior name: windows_view

Behavior values:
        * 64_bit - Indicates that the 64-bit view should be examined.  Since this only affects 64-bit Windows, no redirection will occur.  Ignored on a 32-bit system.
        * 32_bit - Indicates that the 32-bit view should be examined.  Since this only affects 64-bit Windows, this value causes redirection to the 32-bit view.  Ignored on a 32-bit system.

Description: 64-bit versions of Windows provide alternate file system and registry views to 32-bit applications. This behavior allows the OVAL object to operate in that alternate view. This behavior only applies to 64-bit versions of Windows, and is ignored in all other platforms. A setting of "64_bit" means that the non-redirected, native 64-bit view of the file system and registry will be examined. A setting of "32_bit" means the redirected 32-bit view will be examined.  It is recommended that the corresponding 'windows_view' entity be set on OVAL Items collected by tests that use this behavior to distinguish between objects collected in the 32-bit or 64-bit views.

Default: 64_bit


Notes:

* This proposal is basically the same as the original second proposal.  The only real changes are the name of the behavior (folks seemed OK with 'windows_view' as the name), and the changing of the name of the non-redirected value from 'none' to '64-bit'.
* The biggest issue that we think came up with this proposal was that it wasn't entirely clear from an author's point of view.  This hope to help close that gap.  By using '32_bit' and '64_bit', it should be clear to the author which view is being targeted.  The only trick I see here from the author's view is that this only applies to 64-bit Windows, and the author needs to be aware of that.  Aside from that, our hope is that this will be a lot more clear for both author and tools.
* The change from 'none' to '64_bit' is only for the author's clarity.  No change is made to the meaning of the value, just its name.  For our purposes 'none' = '64_bit'.
* This solution suffers from the same issues regarding content that the others do.  Regardless of solution here, it seems to be agreed that large amounts of content *may* need revision.

Does this work?  Or do we need more clarification or revision?

Thanks
Matt

-----Original Message-----
From: Baker, Jon [mailto:[hidden email]]
Sent: Wednesday, August 24, 2011 7:14 AM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal

Ken and others, thanks for sticking with us through this discussion. I have detailed responses to your comments inline below.

We did not intend to surprise people with the proposal we posted yesterday. We were looking to find a compromise solution that gave us the clear and precise behaviors that were being requested and preserve as much content as possible. In further considering the proposal and listing to your feedback, it is clear that yesterday's proposal will not suffice.

We will revisit the second proposal (suggested by Ken) next.

Thanks,

Jon

>-----Original Message-----
>From: [hidden email] [mailto:[hidden email]]
>Sent: Tuesday, August 23, 2011 5:59 PM
>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal
>
>I think the point is that no content is written with the intent that it target both
>x64 and x86 instances at the same time, and that's exactly what this proposal
>makes all content do. It may work in some scenarios, however there are many
>scenarios where it will break. Specifically:
>

Take a look at the following definition:

https://oval.mitre.org/repository/data/ViewDefinition?id=oval:org.mitre.oval:def:7533

When we made the current proposal, we were considering the above definition, the USGCB/FDCC content, and the other content in the OVAL Repository.

The windows_view with a default of 'all' definitely makes the inventory definition above work.

Through this discussion, it is clear that some of our assumptions around the compliance content were invalid. I completely agree that none of the content was written to target both 32 and 64 bit views on a 64 bit system.

However, the USGCB content was written to work on both 32 and 64 bit windows operating systems. I realize that this is quite different than targeting both the 32 and 64 bit view on a 64 bit system.

>I suspect all file-related content will break. Versions and hashes differ between
>x64 and x86 and the state cannot be shared.

I agree that the file related content will be broken by this proposal. The previous proposal would have ensured that any of file-related content that was written for a 32 bit operating system would continue to work. We would need to review and fix the file related content on 64 bit windows systems.

Note that file permission checks would probably not be broken by this proposal.

>I suspect many registry-related content will break, as values are not always
>mirrored between x64 and x86 and the state cannot be shared.

I think this would be a mixed bag. Settings like "Interactive logon: Do not require CTRL+ALT+DEL" in the USGCB (show below) should be unaffected by our most recent proposal.

<registry_object xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5#windows" id="oval:gov.nist.usgcb.windowsseven:obj:51" version="1">
   <hive>HKEY_LOCAL_MACHINE</hive>
   <key>Software\Microsoft\Windows\CurrentVersion\Policies\System</key>
   <name>DisableCAD</name>
</registry_object>

Many of the settings in USGCB are just like the one above, where the key is mirrored to both 32 and 64 bit views. I think this content would all be unaffected by the current proposal.

I agree that this content was developed and tested to target either 32 bit or 64 bit operating systems but not both.

>I have seen customer and internal content that populates variables with registry
>values. This will probably break when the variables suddenly become multi-
>valued.
>

Agree, the current proposal becomes quite complex when variables are used. Not only would we need to consider the check and the check_existence attribute on tests, but we would need to look into the var_check attribute wherever a variable is used. I can see how this would be quite complex for content authors to interpret correctly.


>My other concerns with the "all" setting are:
>
>It's overly complex. Content authors must consider three states (x86, x64, and
>both) with one state object.

Agree, it adds a good deal of complexity. However, i think that moving forward content authors will need to be more aware of the platform(s) they are targeting regardless of the solution we choose. With the default to 'all' and the other choices being '32_bit' and '64_bit', content authors for settings like "Interactive logon: Do not require CTRL+ALT+DEL" would probably be best off simply writing two tests. Where one test targets 32_bit and one test targets 64_bit. With the previous proposal where the option were 'none' and 32_bit' the content author could choose 'none'. Obviously the later approach is far more simple.

>It's noisy. Any non-redirected registry path on x64 will always produce two
>items, correct?

Yes, that is correct. Non redirected registry keys and file paths would produce two items when in reality there is only one item. This would cause bloat of system characteristics files.

>There are many subtleties in OVAL that are ambiguous with this approach (i.e.
>If an item exists in one view, but not the other, does an item w/ a status of
>"does not exist" get created? Why or why not? How does
>"check_existence=all" behave?).
>

We have discussed this subtly a bit and have not come up with a solution that really makes us happy. If you create an item with a status of 'does not exist' any content that uses an existence_check of 'all_exist' will be broken. On the other hand, it feels a bit like a kludge to not create an item when it does not exist in one of the two views and the windows_view='all'.

We have not run into any other subtleties with this proposal, but agree that this is not an easy one to solve correctly.

>My impression is that the "all" concept is being proposed to salvage some
>existing content. I would argue that it actually puts all content at risk on x64
>platforms. I believe that there are two types of content that exist in the wild.
>Content that assumes it will always see the 32bit world, and content that
>assumes it will always see the 64bit world on a 64bit system, and the 32bit
>world on a 32bit system. The default should be one of those. Not any sort of
>new concept.

I think that these are fair assumptions. We felt that 'all' might be a be the happy medium that would preserve some of the content written to check 32 bit applications that may be installed on a 64 bit system.


>
>
>Ken
>
>-----Original Message-----
>From: Baker, Jon [mailto:[hidden email]]
>Sent: Tuesday, August 23, 2011 3:35 PM
>To: [hidden email]
>Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal
>
>Paul,
>
>Are you talking about the content in your (meaning McAfee's) content
>repository?  Or the OVAL Repository?  My reading of your response is that you
>were talking about the OVAL Repository, and we are not clear on how a default
>of 'all' would break all of that content.  We were actually trying to convey the
>opposite in Matt's latest email.
>
>The team here believes that by including 'none' and including it as the default,
>we would essentially be choosing to leave the ambiguity that is already present
>in content.  ('none' here meaning, don't redirect at all, which would mean that
>the content would include no more intent than before.)  By choosing anything
>other than 'none', we would be at least moving clearly in a direction of clear
>intent.  Now, without question, we would also be breaking some content, and
>that needs to be addressed, though it does regardless of our solution.  I suppose
>the question is will it be harder to fix the content broken by defaulting to 'all', or
>checking and revising the intent of the content by choosing any other default?
>(This is where some insight into other existing content would be helpful.)
>
>Our assessment of the situation, as far as how this would affect the different
>types of content is as follows:
>
>* compliance content - we believe that in large part this will just work, since in
>most cases compliance content assesses the OS, as opposed to applications. Is
>this an invalid assumption?
>* inventory content - in many cases, we think that this content will be made to
>work correctly by defaulting to 'all', since in most cases, it is simply looking to
>see if an application is installed somewhere.
>* vulnerability & patch content - in this case, we are pretty sure that we have a
>challenge (regardless of the default, in fact).  There seems to be a large number
>of cases where this content would need revision and would almost need to be
>entirely reviewed.
>
>Hopefully that better explains our thinking here.  Please note that we are not
>trying to push a solution that does not work for folks.  We are happy to revise
>things to best suit the community needs.  Our latest proposal was achieved by
>focusing on the two major factors stated earlier (1. Focusing on making this as
>clear and explicit as possible for authors, and 2. Breaking the least amount of
>content.)
>
>So, are we way off here?  Does this achieve either of our goals?  (I believe we
>have in the case of making things clear for authors)   If not, how can we revise
>this to achieve them both?
>
>Thanks
>
>Jon
>
>============================================
>Jonathan O. Baker
>G022 - IA Industry Collaboration
>The MITRE Corporation
>Email: [hidden email]
>
>
>>-----Original Message-----
>>From: [hidden email]
>>[mailto:[hidden email]]
>>Sent: Tuesday, August 23, 2011 1:41 PM
>>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>>Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal
>>
>>You posted your proposal on 8/15.  After that email, there were 13 responses.
>>Of those 13, there are 4 unique responders.  Ken, Shane, Gunnar..
>>James, and Timothy.  Ken and james were for the proposal, Shane was
>>against.  Timothy did not state an opinion and Gunnar agreed with Shane
>>but was ambivalent to which approach to take.  Prior to your proposal,
>>most people agreed with Ken's approach (which is your formal proposal).
>>
>>As to the content issue.  We currently have broken content in the
>>repository.  It is safe to assume content that was written to target 32
>>bit systems works on 32 bit system and content written to target 64 bit
>systems works on 64 bit system.
>>There for content which targets a 32 bit system, but runs on a 64 bit
>>system is probably broken (although it is possible to write content
>>that works on both 32 bit and 64 bit systems).  If you make the default
>>behavior to collect both the 32 bit data and the 64 bit data for all
>>checks, all content is broken as no content creators would expect that
>>behavior prior to now.  Furthermore, it is not possible to fix existing
>>content when executed on a 64 bit machine without breaking other
>>content because we cannot know the intentions and expectations of the
>content author.
>>
>>
>>Seeing as content will be broken regardless of the approach, there was
>>not significant push back for the proposal of August 15th, and, as Ken
>>pointed out, there was a universal rejection to the 'default: all'
>>proposal during the teleconference; I see no compelling reason to change the
>proposal.
>>
>>Paul
>>
>>
>>On Aug 23, 2011, at 11:52 AM, Hansbury, Matt wrote:
>>
>>> Paul,
>>>
>>> The proposal has been changed, in many ways back to the original
>>> proposal
>>following the Community Call, though this version contains some more
>>explicit naming and better documentation.  The rational for this is as follows:
>>>
>>> * During the initial long email exchange, it became clear that:
>>>     a. There was significant confusion around the proposals
>>>     b. There was a call for making thing very explicit for content
>>> authors
>>>
>>> Given the above, we decided that introducing the '64_bit' value was
>>important to achieve that level of detail and clarity.  Additionally,
>>it was clear that limiting the effects of the behavior to only 64-bit
>>systems was also introducing unnecessary confusion.  Therefore, we
>>expanded the behavior to affect all platforms.  (This is intended to achieve
>clarity on the authoring side.
>>Obviously on the tool side, the behavior can still be largely ignored
>>when examining a 32-bit system.)
>>>
>>> * Another issue was attempting to limit the amount of broken content
>>> out
>>there in the community.  From all of the content that we were able to
>>review (the OVAL Repository content, USGCB, & FDCC content), it became
>>very clear that the concept of 'all' would make the bulk of that
>>content just work, which was as close to an ideal solution as possible.
>>>
>>> We understand that using this default (and even allowing this value)
>>> will
>>create a significant amount of extra collected Items.  However, we
>>generally would prefer to create extra bloat, than to break content.
>>Additionally, over time the bloat can be largely eliminated by revising the
>content.
>>>
>>> Having explained our rational for the revised proposal, can you help
>>> us
>>understand where it falls short in your eyes?  Does it break your
>>existing content?  Or does it create issue for evaluation?
>>>
>>> Thanks
>>> Matt
>>>
>>> -----Original Message-----
>>> From: [hidden email]
>>[mailto:[hidden email]]
>>> Sent: Tuesday, August 23, 2011 11:19 AM
>>> To: oval-developer-list OVAL Developer List/Closed Public Discussion
>>> Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal
>>>
>>> Why has the proposal changed so drastically from the last proposal?
>>>
>>> Using your proposal, we invalidate all current content, as content
>>> authors do
>>not expect to collect both the 32-bit node and the 64-bit node.
>>>
>>> Reading through the previous email chain, I felt most people agreed
>>> with the
>>original 'none (os-native) or 32-bit' proposal.
>>>
>>> I think the following is the only viable solution...
>>>
>>> Behavior name: os_redirection
>>> Behavior settings: "none", "32_bit"
>>> Documentation: 64 bit versions of Windows provide alternate file
>>> system and
>>registry views to 32bit applications. This behavior allows the OVAL
>>object to operate in that alternate view. This behavior only applies to
>>64bit versions of windows, and is ignored in all other instances. A
>>setting of "none" means that the unredirected, native 64bit view of the
>>file system and registry will be examined. A setting of "32_bit" means
>>the redirected 32bit view will be examined.
>>> Default: none
>>>
>>> Paul
>>>
>>>
>>> On Aug 23, 2011, at 8:10 AM, Hansbury, Matt wrote:
>>>
>>>> All,
>>>>
>>>> Once again I want to thank all the folks that are providing feedback
>>>> as we
>>try to narrow down the 32/64 bit redirection issue to a consensus
>>solution.  The MITRE team has been reviewing all of the feedback over
>>the past couple of weeks, and we now feel that it is appropriate to
>>move forward with a solution based on that feedback.  Here is our updated
>proposal:
>>>>
>>>> We will create a new behavior on the relevant tests (windows
>>>> registry and
>>file tests, as well as file tests in the independent Schema) with the
>>following
>>details:
>>>>
>>>> Name:  windows_view
>>>>
>>>> Description: 64 bit versions of Windows provide an alternate file
>>>> system and
>>registry views to 32bit applications. This behavior allows the OVAL
>>Object to state which view should be examined. This behavior only
>>applies to Windows, and is ignored in all other platforms.
>>>>
>>>> Possible values:
>>>>    . 64_bit - Indicates that the 64-bit view on 64-bit Windows
>>>> operating
>>systems must be examined. On 32-bit Windows, using this behavior will
>>result in a collected object with a flag of "does not exist".
>>>>    . 32_bit - Indicates that the 32-bit view on both 64-bit and 32-bit
>>Windows operating systems must be examined.
>>>>    . all - Indicates that both the 32-bit and 64-bit views must be
>>>> examined
>>on 64-bit Windows operating systems. On 32-bit Windows operating
>>systems, indicates that only the 32-bit view is examined.  In some
>>cases this will result in collecting a given registry key once from the
>>32-bit view and once from the 64- bit view. These items must be
>>differentiated by setting the windows_view item entity to 32_bit or 64_bit
>value respectively.
>>>>
>>>> Default: all
>>>>
>>>> By defaulting to the 'all' value, we believe that we will impact the
>>>> least
>>amount of content. Compliance content like USGCB and FDCC should not
>>require any changes. Inventory related content like
>>https://oval.mitre.org/repository/data/ViewDefinition?id=oval:org.mitre.oval
>:
>>def:7533 which currently does not work will be fixed without any changes.
>>>>
>>>> Patch and vulnerability content on windows will still need
>>>> reviewing, but a
>>quick search of the OVAL Repository shows that the check attribute on
>>tests is rarely set to 'all'. This means that there is good chance that this content
>will also
>>not need to be updated.   While some content could be impacted here and be
>>made incorrect, we believe that no matter what solution and default is
>>chosen, some percentage of the content will be affected.  Therefore, we
>>are trying to pick a default that minimizes that.
>>
>>>>
>>>> We continue to value feedback on this issue, but in the interest of
>>>> meeting
>>the 5.10 timelines, we are going to begin implementing the above
>>proposal, so that it can be included in the next Release Candidate.
>>>>
>>>> Thanks
>>>> Matt
>>>>
>>>> ====================================================
>>>> Matt Hansbury
>>>> G022 -  Information Assurance Industry Collaboration The MITRE
>>>> Corporation [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 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 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].
>
>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].

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: 32/64 bit updated proposal

joval
Doesn't it seem a bit counter-intuitive that a windows_view set to 64-bit would show any results at all on a 32-bit system?

What if it were called "native" instead?  It's more clear (I think) than "none", and it describes the intended behavior better than "64_bit".

Finally, what about the items that the scanner creates?  I assume under this proposal that we will we be re-using the existing registry_item element?

jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More | Features | Download



On 8/24/2011 8:09 AM, Hansbury, Matt wrote:
All,

From the feedback we received from the latest proposal, it certainly seems that we need to revise things.  It seems that the second proposal has received the most positive feedback, and so let's start again with that.  Here is what we'd like to do:


Create a behavior for Windows file and registry tests, and the Independent file tests:

Behavior name: windows_view

Behavior values:
        * 64_bit - Indicates that the 64-bit view should be examined.  Since this only affects 64-bit Windows, no redirection will occur.  Ignored on a 32-bit system.
        * 32_bit - Indicates that the 32-bit view should be examined.  Since this only affects 64-bit Windows, this value causes redirection to the 32-bit view.  Ignored on a 32-bit system.

Description: 64-bit versions of Windows provide alternate file system and registry views to 32-bit applications. This behavior allows the OVAL object to operate in that alternate view. This behavior only applies to 64-bit versions of Windows, and is ignored in all other platforms. A setting of "64_bit" means that the non-redirected, native 64-bit view of the file system and registry will be examined. A setting of "32_bit" means the redirected 32-bit view will be examined.  It is recommended that the corresponding 'windows_view' entity be set on OVAL Items collected by tests that use this behavior to distinguish between objects collected in the 32-bit or 64-bit views.

Default: 64_bit


Notes:

* This proposal is basically the same as the original second proposal.  The only real changes are the name of the behavior (folks seemed OK with 'windows_view' as the name), and the changing of the name of the non-redirected value from 'none' to '64-bit'.
* The biggest issue that we think came up with this proposal was that it wasn't entirely clear from an author's point of view.  This hope to help close that gap.  By using '32_bit' and '64_bit', it should be clear to the author which view is being targeted.  The only trick I see here from the author's view is that this only applies to 64-bit Windows, and the author needs to be aware of that.  Aside from that, our hope is that this will be a lot more clear for both author and tools.
* The change from 'none' to '64_bit' is only for the author's clarity.  No change is made to the meaning of the value, just its name.  For our purposes 'none' = '64_bit'.
* This solution suffers from the same issues regarding content that the others do.  Regardless of solution here, it seems to be agreed that large amounts of content *may* need revision.

Does this work?  Or do we need more clarification or revision?

Thanks
Matt

-----Original Message-----
From: Baker, Jon [[hidden email]]
Sent: Wednesday, August 24, 2011 7:14 AM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal

Ken and others, thanks for sticking with us through this discussion. I have detailed responses to your comments inline below.

We did not intend to surprise people with the proposal we posted yesterday. We were looking to find a compromise solution that gave us the clear and precise behaviors that were being requested and preserve as much content as possible. In further considering the proposal and listing to your feedback, it is clear that yesterday's proposal will not suffice.

We will revisit the second proposal (suggested by Ken) next.

Thanks,

Jon

-----Original Message-----
From: [hidden email] [[hidden email]]
Sent: Tuesday, August 23, 2011 5:59 PM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal

I think the point is that no content is written with the intent that it target both
x64 and x86 instances at the same time, and that's exactly what this proposal
makes all content do. It may work in some scenarios, however there are many
scenarios where it will break. Specifically:

Take a look at the following definition:

https://oval.mitre.org/repository/data/ViewDefinition?id=oval:org.mitre.oval:def:7533

When we made the current proposal, we were considering the above definition, the USGCB/FDCC content, and the other content in the OVAL Repository.

The windows_view with a default of 'all' definitely makes the inventory definition above work.

Through this discussion, it is clear that some of our assumptions around the compliance content were invalid. I completely agree that none of the content was written to target both 32 and 64 bit views on a 64 bit system.

However, the USGCB content was written to work on both 32 and 64 bit windows operating systems. I realize that this is quite different than targeting both the 32 and 64 bit view on a 64 bit system.

I suspect all file-related content will break. Versions and hashes differ between
x64 and x86 and the state cannot be shared.
I agree that the file related content will be broken by this proposal. The previous proposal would have ensured that any of file-related content that was written for a 32 bit operating system would continue to work. We would need to review and fix the file related content on 64 bit windows systems.

Note that file permission checks would probably not be broken by this proposal.

I suspect many registry-related content will break, as values are not always
mirrored between x64 and x86 and the state cannot be shared.
I think this would be a mixed bag. Settings like "Interactive logon: Do not require CTRL+ALT+DEL" in the USGCB (show below) should be unaffected by our most recent proposal.

<registry_object xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5#windows" id="oval:gov.nist.usgcb.windowsseven:obj:51" version="1">
   <hive>HKEY_LOCAL_MACHINE</hive>
   <key>Software\Microsoft\Windows\CurrentVersion\Policies\System</key>
   <name>DisableCAD</name>
</registry_object>

Many of the settings in USGCB are just like the one above, where the key is mirrored to both 32 and 64 bit views. I think this content would all be unaffected by the current proposal.

I agree that this content was developed and tested to target either 32 bit or 64 bit operating systems but not both.

I have seen customer and internal content that populates variables with registry
values. This will probably break when the variables suddenly become multi-
valued.

Agree, the current proposal becomes quite complex when variables are used. Not only would we need to consider the check and the check_existence attribute on tests, but we would need to look into the var_check attribute wherever a variable is used. I can see how this would be quite complex for content authors to interpret correctly.


My other concerns with the "all" setting are:

It's overly complex. Content authors must consider three states (x86, x64, and
both) with one state object.
Agree, it adds a good deal of complexity. However, i think that moving forward content authors will need to be more aware of the platform(s) they are targeting regardless of the solution we choose. With the default to 'all' and the other choices being '32_bit' and '64_bit', content authors for settings like "Interactive logon: Do not require CTRL+ALT+DEL" would probably be best off simply writing two tests. Where one test targets 32_bit and one test targets 64_bit. With the previous proposal where the option were 'none' and 32_bit' the content author could choose 'none'. Obviously the later approach is far more simple.

It's noisy. Any non-redirected registry path on x64 will always produce two
items, correct?
Yes, that is correct. Non redirected registry keys and file paths would produce two items when in reality there is only one item. This would cause bloat of system characteristics files.

There are many subtleties in OVAL that are ambiguous with this approach (i.e.
If an item exists in one view, but not the other, does an item w/ a status of
"does not exist" get created? Why or why not? How does
"check_existence=all" behave?).

We have discussed this subtly a bit and have not come up with a solution that really makes us happy. If you create an item with a status of 'does not exist' any content that uses an existence_check of 'all_exist' will be broken. On the other hand, it feels a bit like a kludge to not create an item when it does not exist in one of the two views and the windows_view='all'.

We have not run into any other subtleties with this proposal, but agree that this is not an easy one to solve correctly.

My impression is that the "all" concept is being proposed to salvage some
existing content. I would argue that it actually puts all content at risk on x64
platforms. I believe that there are two types of content that exist in the wild.
Content that assumes it will always see the 32bit world, and content that
assumes it will always see the 64bit world on a 64bit system, and the 32bit
world on a 32bit system. The default should be one of those. Not any sort of
new concept.
I think that these are fair assumptions. We felt that 'all' might be a be the happy medium that would preserve some of the content written to check 32 bit applications that may be installed on a 64 bit system.



Ken

-----Original Message-----
From: Baker, Jon [[hidden email]]
Sent: Tuesday, August 23, 2011 3:35 PM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal

Paul,

Are you talking about the content in your (meaning McAfee's) content
repository?  Or the OVAL Repository?  My reading of your response is that you
were talking about the OVAL Repository, and we are not clear on how a default
of 'all' would break all of that content.  We were actually trying to convey the
opposite in Matt's latest email.

The team here believes that by including 'none' and including it as the default,
we would essentially be choosing to leave the ambiguity that is already present
in content.  ('none' here meaning, don't redirect at all, which would mean that
the content would include no more intent than before.)  By choosing anything
other than 'none', we would be at least moving clearly in a direction of clear
intent.  Now, without question, we would also be breaking some content, and
that needs to be addressed, though it does regardless of our solution.  I suppose
the question is will it be harder to fix the content broken by defaulting to 'all', or
checking and revising the intent of the content by choosing any other default?
(This is where some insight into other existing content would be helpful.)

Our assessment of the situation, as far as how this would affect the different
types of content is as follows:

* compliance content - we believe that in large part this will just work, since in
most cases compliance content assesses the OS, as opposed to applications. Is
this an invalid assumption?
* inventory content - in many cases, we think that this content will be made to
work correctly by defaulting to 'all', since in most cases, it is simply looking to
see if an application is installed somewhere.
* vulnerability & patch content - in this case, we are pretty sure that we have a
challenge (regardless of the default, in fact).  There seems to be a large number
of cases where this content would need revision and would almost need to be
entirely reviewed.

Hopefully that better explains our thinking here.  Please note that we are not
trying to push a solution that does not work for folks.  We are happy to revise
things to best suit the community needs.  Our latest proposal was achieved by
focusing on the two major factors stated earlier (1. Focusing on making this as
clear and explicit as possible for authors, and 2. Breaking the least amount of
content.)

So, are we way off here?  Does this achieve either of our goals?  (I believe we
have in the case of making things clear for authors)   If not, how can we revise
this to achieve them both?

Thanks

Jon

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


-----Original Message-----
From: [hidden email]
[[hidden email]]
Sent: Tuesday, August 23, 2011 1:41 PM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal

You posted your proposal on 8/15.  After that email, there were 13 responses.
Of those 13, there are 4 unique responders.  Ken, Shane, Gunnar..
James, and Timothy.  Ken and james were for the proposal, Shane was
against.  Timothy did not state an opinion and Gunnar agreed with Shane
but was ambivalent to which approach to take.  Prior to your proposal,
most people agreed with Ken's approach (which is your formal proposal).

As to the content issue.  We currently have broken content in the
repository.  It is safe to assume content that was written to target 32
bit systems works on 32 bit system and content written to target 64 bit
systems works on 64 bit system.
There for content which targets a 32 bit system, but runs on a 64 bit
system is probably broken (although it is possible to write content
that works on both 32 bit and 64 bit systems).  If you make the default
behavior to collect both the 32 bit data and the 64 bit data for all
checks, all content is broken as no content creators would expect that
behavior prior to now.  Furthermore, it is not possible to fix existing
content when executed on a 64 bit machine without breaking other
content because we cannot know the intentions and expectations of the
content author.

Seeing as content will be broken regardless of the approach, there was
not significant push back for the proposal of August 15th, and, as Ken
pointed out, there was a universal rejection to the 'default: all'
proposal during the teleconference; I see no compelling reason to change the
proposal.
Paul


On Aug 23, 2011, at 11:52 AM, Hansbury, Matt wrote:

Paul,

The proposal has been changed, in many ways back to the original
proposal
following the Community Call, though this version contains some more
explicit naming and better documentation.  The rational for this is as follows:
* During the initial long email exchange, it became clear that:
    a. There was significant confusion around the proposals
    b. There was a call for making thing very explicit for content
authors

Given the above, we decided that introducing the '64_bit' value was
important to achieve that level of detail and clarity.  Additionally,
it was clear that limiting the effects of the behavior to only 64-bit
systems was also introducing unnecessary confusion.  Therefore, we
expanded the behavior to affect all platforms.  (This is intended to achieve
clarity on the authoring side.
Obviously on the tool side, the behavior can still be largely ignored
when examining a 32-bit system.)
* Another issue was attempting to limit the amount of broken content
out
there in the community.  From all of the content that we were able to
review (the OVAL Repository content, USGCB, & FDCC content), it became
very clear that the concept of 'all' would make the bulk of that
content just work, which was as close to an ideal solution as possible.
We understand that using this default (and even allowing this value)
will
create a significant amount of extra collected Items.  However, we
generally would prefer to create extra bloat, than to break content.
Additionally, over time the bloat can be largely eliminated by revising the
content.
Having explained our rational for the revised proposal, can you help
us
understand where it falls short in your eyes?  Does it break your
existing content?  Or does it create issue for evaluation?
Thanks
Matt

-----Original Message-----
From: [hidden email]
[[hidden email]]
Sent: Tuesday, August 23, 2011 11:19 AM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal

Why has the proposal changed so drastically from the last proposal?

Using your proposal, we invalidate all current content, as content
authors do
not expect to collect both the 32-bit node and the 64-bit node.
Reading through the previous email chain, I felt most people agreed
with the
original 'none (os-native) or 32-bit' proposal.
I think the following is the only viable solution...

Behavior name: os_redirection
Behavior settings: "none", "32_bit"
Documentation: 64 bit versions of Windows provide alternate file
system and
registry views to 32bit applications. This behavior allows the OVAL
object to operate in that alternate view. This behavior only applies to
64bit versions of windows, and is ignored in all other instances. A
setting of "none" means that the unredirected, native 64bit view of the
file system and registry will be examined. A setting of "32_bit" means
the redirected 32bit view will be examined.
Default: none

Paul


On Aug 23, 2011, at 8:10 AM, Hansbury, Matt wrote:

All,

Once again I want to thank all the folks that are providing feedback
as we
try to narrow down the 32/64 bit redirection issue to a consensus
solution.  The MITRE team has been reviewing all of the feedback over
the past couple of weeks, and we now feel that it is appropriate to
move forward with a solution based on that feedback.  Here is our updated
proposal:
We will create a new behavior on the relevant tests (windows
registry and
file tests, as well as file tests in the independent Schema) with the
following
details:
Name:  windows_view

Description: 64 bit versions of Windows provide an alternate file
system and
registry views to 32bit applications. This behavior allows the OVAL
Object to state which view should be examined. This behavior only
applies to Windows, and is ignored in all other platforms.
Possible values:
   . 64_bit - Indicates that the 64-bit view on 64-bit Windows
operating
systems must be examined. On 32-bit Windows, using this behavior will
result in a collected object with a flag of "does not exist".
   . 32_bit - Indicates that the 32-bit view on both 64-bit and 32-bit
Windows operating systems must be examined.
   . all - Indicates that both the 32-bit and 64-bit views must be
examined
on 64-bit Windows operating systems. On 32-bit Windows operating
systems, indicates that only the 32-bit view is examined.  In some
cases this will result in collecting a given registry key once from the
32-bit view and once from the 64- bit view. These items must be
differentiated by setting the windows_view item entity to 32_bit or 64_bit
value respectively.
Default: all

By defaulting to the 'all' value, we believe that we will impact the
least
amount of content. Compliance content like USGCB and FDCC should not
require any changes. Inventory related content like
https://oval.mitre.org/repository/data/ViewDefinition?id=oval:org.mitre.oval
:
def:7533 which currently does not work will be fixed without any changes.
Patch and vulnerability content on windows will still need
reviewing, but a
quick search of the OVAL Repository shows that the check attribute on
tests is rarely set to 'all'. This means that there is good chance that this content
will also
not need to be updated.   While some content could be impacted here and be
made incorrect, we believe that no matter what solution and default is
chosen, some percentage of the content will be affected.  Therefore, we
are trying to pick a default that minimizes that.

We continue to value feedback on this issue, but in the interest of
meeting
the 5.10 timelines, we are going to begin implementing the above
proposal, so that it can be included in the next Release Candidate.
Thanks
Matt

====================================================
Matt Hansbury
G022 -  Information Assurance Industry Collaboration The MITRE
Corporation [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 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 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].

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

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

jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More | Features | Download

Reply | Threaded
Open this post in threaded view
|

Re: 32/64 bit updated proposal

Danny Haynes
Administrator

Hi David,

 

>Doesn't it seem a bit counter-intuitive that a windows_view set to 64-bit would show any results at all on a 32-bit system?

 

This behavior will only apply to 64-bit Windows operating systems.  Are you thinking that it is counter-intuitive because the behavior may still be there, but, it will just being ignored when run on a 32-bit Windows system?

>What if it were called "native" instead?  It's more clear (I think) than "none", and it describes the intended behavior better than "64_bit".

I agree that “native” is probably more descriptive than “none”, however, if the behavior is only going to apply to 64-bit Windows operating systems, does it really seem that useful since “native” is always “64_bit”?  To me, “native” seemed more applicable when we were considering the behavior to apply to both 32-bit and 64-bit Windows operating systems.


>Finally, what about the items that the scanner creates?  I assume under this proposal that we will we be re-using the existing registry_item element?

 

Yes, we will be re-using the existing items.  The only change that will be made to these items is that they will now have a windows_view entity which should be populated with the view that the item was collected from.  This will allow us to distinguish between two identical items that were collected from different views.

 

Thanks,

Danny

 

From: David Solin [mailto:[hidden email]]
Sent: Wednesday, August 24, 2011 9:30 AM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal

 

Doesn't it seem a bit counter-intuitive that a windows_view set to 64-bit would show any results at all on a 32-bit system?

What if it were called "native" instead?  It's more clear (I think) than "none", and it describes the intended behavior better than "64_bit".

Finally, what about the items that the scanner creates?  I assume under this proposal that we will we be re-using the existing registry_item element?

jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More | Features | Download



On 8/24/2011 8:09 AM, Hansbury, Matt wrote:

All,
 
From the feedback we received from the latest proposal, it certainly seems that we need to revise things.  It seems that the second proposal has received the most positive feedback, and so let's start again with that.  Here is what we'd like to do:
 
 
Create a behavior for Windows file and registry tests, and the Independent file tests:
 
Behavior name: windows_view
 
Behavior values:
        * 64_bit - Indicates that the 64-bit view should be examined.  Since this only affects 64-bit Windows, no redirection will occur.  Ignored on a 32-bit system.
        * 32_bit - Indicates that the 32-bit view should be examined.  Since this only affects 64-bit Windows, this value causes redirection to the 32-bit view.  Ignored on a 32-bit system.
 
Description: 64-bit versions of Windows provide alternate file system and registry views to 32-bit applications. This behavior allows the OVAL object to operate in that alternate view. This behavior only applies to 64-bit versions of Windows, and is ignored in all other platforms. A setting of "64_bit" means that the non-redirected, native 64-bit view of the file system and registry will be examined. A setting of "32_bit" means the redirected 32-bit view will be examined.  It is recommended that the corresponding 'windows_view' entity be set on OVAL Items collected by tests that use this behavior to distinguish between objects collected in the 32-bit or 64-bit views.
 
Default: 64_bit
 
 
Notes:
 
* This proposal is basically the same as the original second proposal.  The only real changes are the name of the behavior (folks seemed OK with 'windows_view' as the name), and the changing of the name of the non-redirected value from 'none' to '64-bit'.
* The biggest issue that we think came up with this proposal was that it wasn't entirely clear from an author's point of view.  This hope to help close that gap.  By using '32_bit' and '64_bit', it should be clear to the author which view is being targeted.  The only trick I see here from the author's view is that this only applies to 64-bit Windows, and the author needs to be aware of that.  Aside from that, our hope is that this will be a lot more clear for both author and tools.
* The change from 'none' to '64_bit' is only for the author's clarity.  No change is made to the meaning of the value, just its name.  For our purposes 'none' = '64_bit'.
* This solution suffers from the same issues regarding content that the others do.  Regardless of solution here, it seems to be agreed that large amounts of content *may* need revision.
 
Does this work?  Or do we need more clarification or revision?
 
Thanks
Matt
 
-----Original Message-----
From: Baker, Jon [[hidden email]]
Sent: Wednesday, August 24, 2011 7:14 AM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal
 
Ken and others, thanks for sticking with us through this discussion. I have detailed responses to your comments inline below.
 
We did not intend to surprise people with the proposal we posted yesterday. We were looking to find a compromise solution that gave us the clear and precise behaviors that were being requested and preserve as much content as possible. In further considering the proposal and listing to your feedback, it is clear that yesterday's proposal will not suffice.
 
We will revisit the second proposal (suggested by Ken) next.
 
Thanks,
 
Jon
 
-----Original Message-----
From: [hidden email] [[hidden email]]
Sent: Tuesday, August 23, 2011 5:59 PM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal
 
I think the point is that no content is written with the intent that it target both
x64 and x86 instances at the same time, and that's exactly what this proposal
makes all content do. It may work in some scenarios, however there are many
scenarios where it will break. Specifically:
 
 
Take a look at the following definition:
 
https://oval.mitre.org/repository/data/ViewDefinition?id=oval:org.mitre.oval:def:7533
 
When we made the current proposal, we were considering the above definition, the USGCB/FDCC content, and the other content in the OVAL Repository.
 
The windows_view with a default of 'all' definitely makes the inventory definition above work.
 
Through this discussion, it is clear that some of our assumptions around the compliance content were invalid. I completely agree that none of the content was written to target both 32 and 64 bit views on a 64 bit system.
 
However, the USGCB content was written to work on both 32 and 64 bit windows operating systems. I realize that this is quite different than targeting both the 32 and 64 bit view on a 64 bit system.
 
I suspect all file-related content will break. Versions and hashes differ between
x64 and x86 and the state cannot be shared.
 
I agree that the file related content will be broken by this proposal. The previous proposal would have ensured that any of file-related content that was written for a 32 bit operating system would continue to work. We would need to review and fix the file related content on 64 bit windows systems.
 
Note that file permission checks would probably not be broken by this proposal.
 
I suspect many registry-related content will break, as values are not always
mirrored between x64 and x86 and the state cannot be shared.
 
I think this would be a mixed bag. Settings like "Interactive logon: Do not require CTRL+ALT+DEL" in the USGCB (show below) should be unaffected by our most recent proposal.
 
<registry_object xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5#windows" id="oval:gov.nist.usgcb.windowsseven:obj:51" version="1">
   <hive>HKEY_LOCAL_MACHINE</hive>
   <key>Software\Microsoft\Windows\CurrentVersion\Policies\System</key>
   <name>DisableCAD</name>
</registry_object>
 
Many of the settings in USGCB are just like the one above, where the key is mirrored to both 32 and 64 bit views. I think this content would all be unaffected by the current proposal.
 
I agree that this content was developed and tested to target either 32 bit or 64 bit operating systems but not both.
 
I have seen customer and internal content that populates variables with registry
values. This will probably break when the variables suddenly become multi-
valued.
 
 
Agree, the current proposal becomes quite complex when variables are used. Not only would we need to consider the check and the check_existence attribute on tests, but we would need to look into the var_check attribute wherever a variable is used. I can see how this would be quite complex for content authors to interpret correctly.
 
 
My other concerns with the "all" setting are:
 
It's overly complex. Content authors must consider three states (x86, x64, and
both) with one state object.
 
Agree, it adds a good deal of complexity. However, i think that moving forward content authors will need to be more aware of the platform(s) they are targeting regardless of the solution we choose. With the default to 'all' and the other choices being '32_bit' and '64_bit', content authors for settings like "Interactive logon: Do not require CTRL+ALT+DEL" would probably be best off simply writing two tests. Where one test targets 32_bit and one test targets 64_bit. With the previous proposal where the option were 'none' and 32_bit' the content author could choose 'none'. Obviously the later approach is far more simple.
 
It's noisy. Any non-redirected registry path on x64 will always produce two
items, correct?
 
Yes, that is correct. Non redirected registry keys and file paths would produce two items when in reality there is only one item. This would cause bloat of system characteristics files.
 
There are many subtleties in OVAL that are ambiguous with this approach (i.e.
If an item exists in one view, but not the other, does an item w/ a status of
"does not exist" get created? Why or why not? How does
"check_existence=all" behave?).
 
 
We have discussed this subtly a bit and have not come up with a solution that really makes us happy. If you create an item with a status of 'does not exist' any content that uses an existence_check of 'all_exist' will be broken. On the other hand, it feels a bit like a kludge to not create an item when it does not exist in one of the two views and the windows_view='all'.
 
We have not run into any other subtleties with this proposal, but agree that this is not an easy one to solve correctly.
 
My impression is that the "all" concept is being proposed to salvage some
existing content. I would argue that it actually puts all content at risk on x64
platforms. I believe that there are two types of content that exist in the wild.
Content that assumes it will always see the 32bit world, and content that
assumes it will always see the 64bit world on a 64bit system, and the 32bit
world on a 32bit system. The default should be one of those. Not any sort of
new concept.
 
I think that these are fair assumptions. We felt that 'all' might be a be the happy medium that would preserve some of the content written to check 32 bit applications that may be installed on a 64 bit system.
 
 
 
 
Ken
 
-----Original Message-----
From: Baker, Jon [[hidden email]]
Sent: Tuesday, August 23, 2011 3:35 PM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal
 
Paul,
 
Are you talking about the content in your (meaning McAfee's) content
repository?  Or the OVAL Repository?  My reading of your response is that you
were talking about the OVAL Repository, and we are not clear on how a default
of 'all' would break all of that content.  We were actually trying to convey the
opposite in Matt's latest email.
 
The team here believes that by including 'none' and including it as the default,
we would essentially be choosing to leave the ambiguity that is already present
in content.  ('none' here meaning, don't redirect at all, which would mean that
the content would include no more intent than before.)  By choosing anything
other than 'none', we would be at least moving clearly in a direction of clear
intent.  Now, without question, we would also be breaking some content, and
that needs to be addressed, though it does regardless of our solution.  I suppose
the question is will it be harder to fix the content broken by defaulting to 'all', or
checking and revising the intent of the content by choosing any other default?
(This is where some insight into other existing content would be helpful.)
 
Our assessment of the situation, as far as how this would affect the different
types of content is as follows:
 
* compliance content - we believe that in large part this will just work, since in
most cases compliance content assesses the OS, as opposed to applications. Is
this an invalid assumption?
* inventory content - in many cases, we think that this content will be made to
work correctly by defaulting to 'all', since in most cases, it is simply looking to
see if an application is installed somewhere.
* vulnerability & patch content - in this case, we are pretty sure that we have a
challenge (regardless of the default, in fact).  There seems to be a large number
of cases where this content would need revision and would almost need to be
entirely reviewed.
 
Hopefully that better explains our thinking here.  Please note that we are not
trying to push a solution that does not work for folks.  We are happy to revise
things to best suit the community needs.  Our latest proposal was achieved by
focusing on the two major factors stated earlier (1. Focusing on making this as
clear and explicit as possible for authors, and 2. Breaking the least amount of
content.)
 
So, are we way off here?  Does this achieve either of our goals?  (I believe we
have in the case of making things clear for authors)   If not, how can we revise
this to achieve them both?
 
Thanks
 
Jon
 
============================================
Jonathan O. Baker
G022 - IA Industry Collaboration
The MITRE Corporation
Email: [hidden email]
 
 
-----Original Message-----
From: [hidden email]
[[hidden email]]
Sent: Tuesday, August 23, 2011 1:41 PM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal
 
You posted your proposal on 8/15.  After that email, there were 13 responses.
Of those 13, there are 4 unique responders.  Ken, Shane, Gunnar..
James, and Timothy.  Ken and james were for the proposal, Shane was
against.  Timothy did not state an opinion and Gunnar agreed with Shane
but was ambivalent to which approach to take.  Prior to your proposal,
most people agreed with Ken's approach (which is your formal proposal).
 
As to the content issue.  We currently have broken content in the
repository.  It is safe to assume content that was written to target 32
bit systems works on 32 bit system and content written to target 64 bit
systems works on 64 bit system.
There for content which targets a 32 bit system, but runs on a 64 bit
system is probably broken (although it is possible to write content
that works on both 32 bit and 64 bit systems).  If you make the default
behavior to collect both the 32 bit data and the 64 bit data for all
checks, all content is broken as no content creators would expect that
behavior prior to now.  Furthermore, it is not possible to fix existing
content when executed on a 64 bit machine without breaking other
content because we cannot know the intentions and expectations of the
content author.
 
 
Seeing as content will be broken regardless of the approach, there was
not significant push back for the proposal of August 15th, and, as Ken
pointed out, there was a universal rejection to the 'default: all'
proposal during the teleconference; I see no compelling reason to change the
proposal.
 
Paul
 
 
On Aug 23, 2011, at 11:52 AM, Hansbury, Matt wrote:
 
Paul,
 
The proposal has been changed, in many ways back to the original
proposal
following the Community Call, though this version contains some more
explicit naming and better documentation.  The rational for this is as follows:
 
* During the initial long email exchange, it became clear that:
    a. There was significant confusion around the proposals
    b. There was a call for making thing very explicit for content
authors
 
Given the above, we decided that introducing the '64_bit' value was
important to achieve that level of detail and clarity.  Additionally,
it was clear that limiting the effects of the behavior to only 64-bit
systems was also introducing unnecessary confusion.  Therefore, we
expanded the behavior to affect all platforms.  (This is intended to achieve
clarity on the authoring side.
Obviously on the tool side, the behavior can still be largely ignored
when examining a 32-bit system.)
 
* Another issue was attempting to limit the amount of broken content
out
there in the community.  From all of the content that we were able to
review (the OVAL Repository content, USGCB, & FDCC content), it became
very clear that the concept of 'all' would make the bulk of that
content just work, which was as close to an ideal solution as possible.
 
We understand that using this default (and even allowing this value)
will
create a significant amount of extra collected Items.  However, we
generally would prefer to create extra bloat, than to break content.
Additionally, over time the bloat can be largely eliminated by revising the
content.
 
Having explained our rational for the revised proposal, can you help
us
understand where it falls short in your eyes?  Does it break your
existing content?  Or does it create issue for evaluation?
 
Thanks
Matt
 
-----Original Message-----
From: [hidden email]
[[hidden email]]
Sent: Tuesday, August 23, 2011 11:19 AM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal
 
Why has the proposal changed so drastically from the last proposal?
 
Using your proposal, we invalidate all current content, as content
authors do
not expect to collect both the 32-bit node and the 64-bit node.
 
Reading through the previous email chain, I felt most people agreed
with the
original 'none (os-native) or 32-bit' proposal.
 
I think the following is the only viable solution...
 
Behavior name: os_redirection
Behavior settings: "none", "32_bit"
Documentation: 64 bit versions of Windows provide alternate file
system and
registry views to 32bit applications. This behavior allows the OVAL
object to operate in that alternate view. This behavior only applies to
64bit versions of windows, and is ignored in all other instances. A
setting of "none" means that the unredirected, native 64bit view of the
file system and registry will be examined. A setting of "32_bit" means
the redirected 32bit view will be examined.
Default: none
 
Paul
 
 
On Aug 23, 2011, at 8:10 AM, Hansbury, Matt wrote:
 
All,
 
Once again I want to thank all the folks that are providing feedback
as we
try to narrow down the 32/64 bit redirection issue to a consensus
solution.  The MITRE team has been reviewing all of the feedback over
the past couple of weeks, and we now feel that it is appropriate to
move forward with a solution based on that feedback.  Here is our updated
proposal:
 
We will create a new behavior on the relevant tests (windows
registry and
file tests, as well as file tests in the independent Schema) with the
following
details:
 
Name:  windows_view
 
Description: 64 bit versions of Windows provide an alternate file
system and
registry views to 32bit applications. This behavior allows the OVAL
Object to state which view should be examined. This behavior only
applies to Windows, and is ignored in all other platforms.
 
Possible values:
   . 64_bit - Indicates that the 64-bit view on 64-bit Windows
operating
systems must be examined. On 32-bit Windows, using this behavior will
result in a collected object with a flag of "does not exist".
   . 32_bit - Indicates that the 32-bit view on both 64-bit and 32-bit
Windows operating systems must be examined.
   . all - Indicates that both the 32-bit and 64-bit views must be
examined
on 64-bit Windows operating systems. On 32-bit Windows operating
systems, indicates that only the 32-bit view is examined.  In some
cases this will result in collecting a given registry key once from the
32-bit view and once from the 64- bit view. These items must be
differentiated by setting the windows_view item entity to 32_bit or 64_bit
value respectively.
 
Default: all
 
By defaulting to the 'all' value, we believe that we will impact the
least
amount of content. Compliance content like USGCB and FDCC should not
require any changes. Inventory related content like
https://oval.mitre.org/repository/data/ViewDefinition?id=oval:org.mitre.oval
:
def:7533 which currently does not work will be fixed without any changes.
 
Patch and vulnerability content on windows will still need
reviewing, but a
quick search of the OVAL Repository shows that the check attribute on
tests is rarely set to 'all'. This means that there is good chance that this content
will also
not need to be updated.   While some content could be impacted here and be
made incorrect, we believe that no matter what solution and default is
chosen, some percentage of the content will be affected.  Therefore, we
are trying to pick a default that minimizes that.
 
 
We continue to value feedback on this issue, but in the interest of
meeting
the 5.10 timelines, we are going to begin implementing the above
proposal, so that it can be included in the next Release Candidate.
 
Thanks
Matt
 
====================================================
Matt Hansbury
G022 -  Information Assurance Industry Collaboration The MITRE
Corporation [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 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 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].
 
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].
 
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].

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

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: 32/64 bit updated proposal

Waltermire, David A.
In reply to this post by Jon Baker
T

----- Original Message -----
From: Baker, Jon <[hidden email]>
To: [hidden email] <[hidden email]>
Sent: Wed Aug 24 07:13:38 2011
Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal

Ken and others, thanks for sticking with us through this discussion. I have detailed responses to your comments inline below.

We did not intend to surprise people with the proposal we posted yesterday. We were looking to find a compromise solution that gave us the clear and precise behaviors that were being requested and preserve as much content as possible. In further considering the proposal and listing to your feedback, it is clear that yesterday's proposal will not suffice.

We will revisit the second proposal (suggested by Ken) next.

Thanks,

Jon

>-----Original Message-----
>From: [hidden email] [mailto:[hidden email]]
>Sent: Tuesday, August 23, 2011 5:59 PM
>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal
>
>I think the point is that no content is written with the intent that it target both
>x64 and x86 instances at the same time, and that's exactly what this proposal
>makes all content do. It may work in some scenarios, however there are many
>scenarios where it will break. Specifically:
>

Take a look at the following definition:

https://oval.mitre.org/repository/data/ViewDefinition?id=oval:org.mitre.oval:def:7533

When we made the current proposal, we were considering the above definition, the USGCB/FDCC content, and the other content in the OVAL Repository.

The windows_view with a default of 'all' definitely makes the inventory definition above work.

Through this discussion, it is clear that some of our assumptions around the compliance content were invalid. I completely agree that none of the content was written to target both 32 and 64 bit views on a 64 bit system.

However, the USGCB content was written to work on both 32 and 64 bit windows operating systems. I realize that this is quite different than targeting both the 32 and 64 bit view on a 64 bit system.

>I suspect all file-related content will break. Versions and hashes differ between
>x64 and x86 and the state cannot be shared.

I agree that the file related content will be broken by this proposal. The previous proposal would have ensured that any of file-related content that was written for a 32 bit operating system would continue to work. We would need to review and fix the file related content on 64 bit windows systems.

Note that file permission checks would probably not be broken by this proposal.

>I suspect many registry-related content will break, as values are not always
>mirrored between x64 and x86 and the state cannot be shared.

I think this would be a mixed bag. Settings like "Interactive logon: Do not require CTRL+ALT+DEL" in the USGCB (show below) should be unaffected by our most recent proposal.

<registry_object xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5#windows" id="oval:gov.nist.usgcb.windowsseven:obj:51" version="1">
   <hive>HKEY_LOCAL_MACHINE</hive>
   <key>Software\Microsoft\Windows\CurrentVersion\Policies\System</key>
   <name>DisableCAD</name>
</registry_object>

Many of the settings in USGCB are just like the one above, where the key is mirrored to both 32 and 64 bit views. I think this content would all be unaffected by the current proposal.

I agree that this content was developed and tested to target either 32 bit or 64 bit operating systems but not both.

>I have seen customer and internal content that populates variables with registry
>values. This will probably break when the variables suddenly become multi-
>valued.
>

Agree, the current proposal becomes quite complex when variables are used. Not only would we need to consider the check and the check_existence attribute on tests, but we would need to look into the var_check attribute wherever a variable is used. I can see how this would be quite complex for content authors to interpret correctly.


>My other concerns with the "all" setting are:
>
>It's overly complex. Content authors must consider three states (x86, x64, and
>both) with one state object.

Agree, it adds a good deal of complexity. However, i think that moving forward content authors will need to be more aware of the platform(s) they are targeting regardless of the solution we choose. With the default to 'all' and the other choices being '32_bit' and '64_bit', content authors for settings like "Interactive logon: Do not require CTRL+ALT+DEL" would probably be best off simply writing two tests. Where one test targets 32_bit and one test targets 64_bit. With the previous proposal where the option were 'none' and 32_bit' the content author could choose 'none'. Obviously the later approach is far more simple.

>It's noisy. Any non-redirected registry path on x64 will always produce two
>items, correct?

Yes, that is correct. Non redirected registry keys and file paths would produce two items when in reality there is only one item. This would cause bloat of system characteristics files.

>There are many subtleties in OVAL that are ambiguous with this approach (i.e.
>If an item exists in one view, but not the other, does an item w/ a status of
>"does not exist" get created? Why or why not? How does
>"check_existence=all" behave?).
>

We have discussed this subtly a bit and have not come up with a solution that really makes us happy. If you create an item with a status of 'does not exist' any content that uses an existence_check of 'all_exist' will be broken. On the other hand, it feels a bit like a kludge to not create an item when it does not exist in one of the two views and the windows_view='all'.

We have not run into any other subtleties with this proposal, but agree that this is not an easy one to solve correctly.

>My impression is that the "all" concept is being proposed to salvage some
>existing content. I would argue that it actually puts all content at risk on x64
>platforms. I believe that there are two types of content that exist in the wild.
>Content that assumes it will always see the 32bit world, and content that
>assumes it will always see the 64bit world on a 64bit system, and the 32bit
>world on a 32bit system. The default should be one of those. Not any sort of
>new concept.

I think that these are fair assumptions. We felt that 'all' might be a be the happy medium that would preserve some of the content written to check 32 bit applications that may be installed on a 64 bit system.


>
>
>Ken
>
>-----Original Message-----
>From: Baker, Jon [mailto:[hidden email]]
>Sent: Tuesday, August 23, 2011 3:35 PM
>To: [hidden email]
>Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal
>
>Paul,
>
>Are you talking about the content in your (meaning McAfee's) content
>repository?  Or the OVAL Repository?  My reading of your response is that you
>were talking about the OVAL Repository, and we are not clear on how a default
>of 'all' would break all of that content.  We were actually trying to convey the
>opposite in Matt's latest email.
>
>The team here believes that by including 'none' and including it as the default,
>we would essentially be choosing to leave the ambiguity that is already present
>in content.  ('none' here meaning, don't redirect at all, which would mean that
>the content would include no more intent than before.)  By choosing anything
>other than 'none', we would be at least moving clearly in a direction of clear
>intent.  Now, without question, we would also be breaking some content, and
>that needs to be addressed, though it does regardless of our solution.  I suppose
>the question is will it be harder to fix the content broken by defaulting to 'all', or
>checking and revising the intent of the content by choosing any other default?
>(This is where some insight into other existing content would be helpful.)
>
>Our assessment of the situation, as far as how this would affect the different
>types of content is as follows:
>
>* compliance content - we believe that in large part this will just work, since in
>most cases compliance content assesses the OS, as opposed to applications. Is
>this an invalid assumption?
>* inventory content - in many cases, we think that this content will be made to
>work correctly by defaulting to 'all', since in most cases, it is simply looking to
>see if an application is installed somewhere.
>* vulnerability & patch content - in this case, we are pretty sure that we have a
>challenge (regardless of the default, in fact).  There seems to be a large number
>of cases where this content would need revision and would almost need to be
>entirely reviewed.
>
>Hopefully that better explains our thinking here.  Please note that we are not
>trying to push a solution that does not work for folks.  We are happy to revise
>things to best suit the community needs.  Our latest proposal was achieved by
>focusing on the two major factors stated earlier (1. Focusing on making this as
>clear and explicit as possible for authors, and 2. Breaking the least amount of
>content.)
>
>So, are we way off here?  Does this achieve either of our goals?  (I believe we
>have in the case of making things clear for authors)   If not, how can we revise
>this to achieve them both?
>
>Thanks
>
>Jon
>
>============================================
>Jonathan O. Baker
>G022 - IA Industry Collaboration
>The MITRE Corporation
>Email: [hidden email]
>
>
>>-----Original Message-----
>>From: [hidden email]
>>[mailto:[hidden email]]
>>Sent: Tuesday, August 23, 2011 1:41 PM
>>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>>Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal
>>
>>You posted your proposal on 8/15.  After that email, there were 13 responses.
>>Of those 13, there are 4 unique responders.  Ken, Shane, Gunnar..
>>James, and Timothy.  Ken and james were for the proposal, Shane was
>>against.  Timothy did not state an opinion and Gunnar agreed with Shane
>>but was ambivalent to which approach to take.  Prior to your proposal,
>>most people agreed with Ken's approach (which is your formal proposal).
>>
>>As to the content issue.  We currently have broken content in the
>>repository.  It is safe to assume content that was written to target 32
>>bit systems works on 32 bit system and content written to target 64 bit
>systems works on 64 bit system.
>>There for content which targets a 32 bit system, but runs on a 64 bit
>>system is probably broken (although it is possible to write content
>>that works on both 32 bit and 64 bit systems).  If you make the default
>>behavior to collect both the 32 bit data and the 64 bit data for all
>>checks, all content is broken as no content creators would expect that
>>behavior prior to now.  Furthermore, it is not possible to fix existing
>>content when executed on a 64 bit machine without breaking other
>>content because we cannot know the intentions and expectations of the
>content author.
>>
>>
>>Seeing as content will be broken regardless of the approach, there was
>>not significant push back for the proposal of August 15th, and, as Ken
>>pointed out, there was a universal rejection to the 'default: all'
>>proposal during the teleconference; I see no compelling reason to change the
>proposal.
>>
>>Paul
>>
>>
>>On Aug 23, 2011, at 11:52 AM, Hansbury, Matt wrote:
>>
>>> Paul,
>>>
>>> The proposal has been changed, in many ways back to the original
>>> proposal
>>following the Community Call, though this version contains some more
>>explicit naming and better documentation.  The rational for this is as follows:
>>>
>>> * During the initial long email exchange, it became clear that:
>>>     a. There was significant confusion around the proposals
>>>     b. There was a call for making thing very explicit for content
>>> authors
>>>
>>> Given the above, we decided that introducing the '64_bit' value was
>>important to achieve that level of detail and clarity.  Additionally,
>>it was clear that limiting the effects of the behavior to only 64-bit
>>systems was also introducing unnecessary confusion.  Therefore, we
>>expanded the behavior to affect all platforms.  (This is intended to achieve
>clarity on the authoring side.
>>Obviously on the tool side, the behavior can still be largely ignored
>>when examining a 32-bit system.)
>>>
>>> * Another issue was attempting to limit the amount of broken content
>>> out
>>there in the community.  From all of the content that we were able to
>>review (the OVAL Repository content, USGCB, & FDCC content), it became
>>very clear that the concept of 'all' would make the bulk of that
>>content just work, which was as close to an ideal solution as possible.
>>>
>>> We understand that using this default (and even allowing this value)
>>> will
>>create a significant amount of extra collected Items.  However, we
>>generally would prefer to create extra bloat, than to break content.
>>Additionally, over time the bloat can be largely eliminated by revising the
>content.
>>>
>>> Having explained our rational for the revised proposal, can you help
>>> us
>>understand where it falls short in your eyes?  Does it break your
>>existing content?  Or does it create issue for evaluation?
>>>
>>> Thanks
>>> Matt
>>>
>>> -----Original Message-----
>>> From: [hidden email]
>>[mailto:[hidden email]]
>>> Sent: Tuesday, August 23, 2011 11:19 AM
>>> To: oval-developer-list OVAL Developer List/Closed Public Discussion
>>> Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal
>>>
>>> Why has the proposal changed so drastically from the last proposal?
>>>
>>> Using your proposal, we invalidate all current content, as content
>>> authors do
>>not expect to collect both the 32-bit node and the 64-bit node.
>>>
>>> Reading through the previous email chain, I felt most people agreed
>>> with the
>>original 'none (os-native) or 32-bit' proposal.
>>>
>>> I think the following is the only viable solution...
>>>
>>> Behavior name: os_redirection
>>> Behavior settings: "none", "32_bit"
>>> Documentation: 64 bit versions of Windows provide alternate file
>>> system and
>>registry views to 32bit applications. This behavior allows the OVAL
>>object to operate in that alternate view. This behavior only applies to
>>64bit versions of windows, and is ignored in all other instances. A
>>setting of "none" means that the unredirected, native 64bit view of the
>>file system and registry will be examined. A setting of "32_bit" means
>>the redirected 32bit view will be examined.
>>> Default: none
>>>
>>> Paul
>>>
>>>
>>> On Aug 23, 2011, at 8:10 AM, Hansbury, Matt wrote:
>>>
>>>> All,
>>>>
>>>> Once again I want to thank all the folks that are providing feedback
>>>> as we
>>try to narrow down the 32/64 bit redirection issue to a consensus
>>solution.  The MITRE team has been reviewing all of the feedback over
>>the past couple of weeks, and we now feel that it is appropriate to
>>move forward with a solution based on that feedback.  Here is our updated
>proposal:
>>>>
>>>> We will create a new behavior on the relevant tests (windows
>>>> registry and
>>file tests, as well as file tests in the independent Schema) with the
>>following
>>details:
>>>>
>>>> Name:  windows_view
>>>>
>>>> Description: 64 bit versions of Windows provide an alternate file
>>>> system and
>>registry views to 32bit applications. This behavior allows the OVAL
>>Object to state which view should be examined. This behavior only
>>applies to Windows, and is ignored in all other platforms.
>>>>
>>>> Possible values:
>>>>    . 64_bit - Indicates that the 64-bit view on 64-bit Windows
>>>> operating
>>systems must be examined. On 32-bit Windows, using this behavior will
>>result in a collected object with a flag of "does not exist".
>>>>    . 32_bit - Indicates that the 32-bit view on both 64-bit and 32-bit
>>Windows operating systems must be examined.
>>>>    . all - Indicates that both the 32-bit and 64-bit views must be
>>>> examined
>>on 64-bit Windows operating systems. On 32-bit Windows operating
>>systems, indicates that only the 32-bit view is examined.  In some
>>cases this will result in collecting a given registry key once from the
>>32-bit view and once from the 64- bit view. These items must be
>>differentiated by setting the windows_view item entity to 32_bit or 64_bit
>value respectively.
>>>>
>>>> Default: all
>>>>
>>>> By defaulting to the 'all' value, we believe that we will impact the
>>>> least
>>amount of content. Compliance content like USGCB and FDCC should not
>>require any changes. Inventory related content like
>>https://oval.mitre.org/repository/data/ViewDefinition?id=oval:org.mitre.oval
>:
>>def:7533 which currently does not work will be fixed without any changes.
>>>>
>>>> Patch and vulnerability content on windows will still need
>>>> reviewing, but a
>>quick search of the OVAL Repository shows that the check attribute on
>>tests is rarely set to 'all'. This means that there is good chance that this content
>will also
>>not need to be updated.   While some content could be impacted here and be
>>made incorrect, we believe that no matter what solution and default is
>>chosen, some percentage of the content will be affected.  Therefore, we
>>are trying to pick a default that minimizes that.
>>
>>>>
>>>> We continue to value feedback on this issue, but in the interest of
>>>> meeting
>>the 5.10 timelines, we are going to begin implementing the above
>>proposal, so that it can be included in the next Release Candidate.
>>>>
>>>> Thanks
>>>> Matt
>>>>
>>>> ====================================================
>>>> Matt Hansbury
>>>> G022 -  Information Assurance Industry Collaboration The MITRE
>>>> Corporation [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 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 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].
>
>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].

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