Fwd: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal

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

Fwd: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal

joval
Comments below...

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



On 8/24/2011 9:57 AM, Haynes, Dan wrote:

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?


Not only is it ignored on 32-bit, but the scanner is actually supposed to generate results, right?  I mean, the behavior says "64_bit", so you'd think intuitively that on a 32-bit machine it just shouldn't generate any results at all.

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



If you're generating results, then my opinion is that it can be said to "apply".  The name of the behavior should describe the expected results.

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


I'm just saying that there is already a way to distinguish, which is by looking at the objects with which they're associated.  In fact, it's entirely possible that two objects with different behaviors could both point to the same item, even though there are two different registry values that happen by coincidence to be equal to one-another, and the generated results would be valid and correct.

 

Thanks,

Danny

 

From: David Solin [[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].
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,

 

>Not only is it ignored on 32-bit, but the scanner is actually supposed to generate results, right?  I mean, the behavior says "64_bit", so you'd think intuitively that on a 32-bit machine it just >shouldn't generate any results at all.

> 

>If you're generating results, then my opinion is that it can be said to "apply".  The name of the behavior should describe the expected results.

 

Yes, the scanner would be expected to generate results.  I would agree that this it is somewhat counter-intuitive if you were to just look at the content without the full context of how the behavior is meant to work.  That is, if you consider that same content in the context of the behavior only applying to 64-bit Windows operating systems it doesn’t seem so confusing (at least to me) as the documentation states that the behavior must be ignored as if it wasn’t even there (implicitly or explicitly).  I understand this is not the most elegant solution, but, we have similar restrictions on the use of behaviors today in the OVAL Language so I wouldn’t think that this is that far off.  For example, the ‘recurse’ behavior in the ind-def:FileBehaviors states:

“'recurse' defines...Also note that this behavior does not apply to Windows systems since they do not support symbolic links. On Windows systems the 'recurse' behavior is always equivalent to directories.”

Here it is not only saying the behavior value doesn’t apply, but, that it must be interpreted as something else.

 

If you were to use “native” instead of “64_bit”, I would anticipate that would mean that this behavior would now apply to 32-bit Windows operating systems along with 64-bit Windows operating systems?  Do you think there would be any confusion between which value a content author should use since “native” and “32_bit” are the same thing in the context of a 32-bit Windows operating system?

 

>I'm just saying that there is already a way to distinguish, which is by looking at the objects with which they're associated.  In fact, it's entirely possible that two objects with different behaviors >could both point to the same item, even though there are two different registry values that happen by coincidence to be equal to one-another, and the generated results would be valid and >correct.

 

While in some cases you can look at the object to distinguish between where an item came from, it will not always work as the collected_object section is optional.  For example, consider the system characteristics producer adoption capability.  It is completely valid for items to be collected using some proprietary process, without the use of objects, as long as it conforms to the oval-system-characteristics-schema.  In this situation, you would not have a collected_objects section in the system characteristics and would not be able to make that distinction.  I think that the windows_view item entity will be need to make that distinction between those items.

Thanks,

Danny

 

From: David Solin [mailto:[hidden email]] On Behalf Of David Solin
Sent: Wednesday, August 24, 2011 1:16 PM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Cc: Haynes, Dan
Subject: Fwd: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal

 

Comments below...

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



On 8/24/2011 9:57 AM, Haynes, Dan wrote:

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?



Not only is it ignored on 32-bit, but the scanner is actually supposed to generate results, right?  I mean, the behavior says "64_bit", so you'd think intuitively that on a 32-bit machine it just shouldn't generate any results at all.


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

 


If you're generating results, then my opinion is that it can be said to "apply".  The name of the behavior should describe the expected results.


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


I'm just saying that there is already a way to distinguish, which is by looking at the objects with which they're associated.  In fact, it's entirely possible that two objects with different behaviors could both point to the same item, even though there are two different registry values that happen by coincidence to be equal to one-another, and the generated results would be valid and correct.


 

Thanks,

Danny

 

From: David Solin [[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].

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

joval
Ah, you're talking about the Independent schema FileBehaviors.  Unix FileBehaviors deprecates the recurse attribute, and Windows FileBehaviors doesn't have one...

Indeed there are instances where the generality required in the independent schema has ultimately failed to exist, but it is still a practice we should strive to avoid.  Along those lines, then, we really need only one behavior -- which is "32-bit".  It is intuitively meaningful on both 32-bit and 64-bit machines -- it signifies some path for a 32-bit object.  In fact the text "Ignored on a 32-bit system" is itself confusing -- does it mean to ignore the behavior, or to ignore the object on which the behavior is defined -- meaning that no items should be created?

As for modifying the items themselves, it seems to me that if some proprietary means of associating items is being used to bypass the optional object references (e.g., attributes from another namespace), then that is hardly a problem that the specification itself needs to address.  Since the specification already provides a means of determining the object origins of items, it is not really necessary (as a function of the specification) to duplicate the object's behavior information in the item itself.

Anyway, if the rest of the community is really pleased with the proposal, I'll fall in line.

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


On 8/24/2011 2:03 PM, Haynes, Dan wrote:

Hi David,

 

>Not only is it ignored on 32-bit, but the scanner is actually supposed to generate results, right?  I mean, the behavior says "64_bit", so you'd think intuitively that on a 32-bit machine it just >shouldn't generate any results at all.

> 

>If you're generating results, then my opinion is that it can be said to "apply".  The name of the behavior should describe the expected results.

 

Yes, the scanner would be expected to generate results.  I would agree that this it is somewhat counter-intuitive if you were to just look at the content without the full context of how the behavior is meant to work.  That is, if you consider that same content in the context of the behavior only applying to 64-bit Windows operating systems it doesn’t seem so confusing (at least to me) as the documentation states that the behavior must be ignored as if it wasn’t even there (implicitly or explicitly).  I understand this is not the most elegant solution, but, we have similar restrictions on the use of behaviors today in the OVAL Language so I wouldn’t think that this is that far off.  For example, the ‘recurse’ behavior in the ind-def:FileBehaviors states:

“'recurse' defines...Also note that this behavior does not apply to Windows systems since they do not support symbolic links. On Windows systems the 'recurse' behavior is always equivalent to directories.”

Here it is not only saying the behavior value doesn’t apply, but, that it must be interpreted as something else.

 

If you were to use “native” instead of “64_bit”, I would anticipate that would mean that this behavior would now apply to 32-bit Windows operating systems along with 64-bit Windows operating systems?  Do you think there would be any confusion between which value a content author should use since “native” and “32_bit” are the same thing in the context of a 32-bit Windows operating system?

 

>I'm just saying that there is already a way to distinguish, which is by looking at the objects with which they're associated.  In fact, it's entirely possible that two objects with different behaviors >could both point to the same item, even though there are two different registry values that happen by coincidence to be equal to one-another, and the generated results would be valid and >correct.

 

While in some cases you can look at the object to distinguish between where an item came from, it will not always work as the collected_object section is optional.  For example, consider the system characteristics producer adoption capability.  It is completely valid for items to be collected using some proprietary process, without the use of objects, as long as it conforms to the oval-system-characteristics-schema.  In this situation, you would not have a collected_objects section in the system characteristics and would not be able to make that distinction.  I think that the windows_view item entity will be need to make that distinction between those items.

Thanks,

Danny

 

From: David Solin [[hidden email]] On Behalf Of David Solin
Sent: Wednesday, August 24, 2011 1:16 PM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Cc: Haynes, Dan
Subject: Fwd: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal

 

Comments below...

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



On 8/24/2011 9:57 AM, Haynes, Dan wrote:

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?



Not only is it ignored on 32-bit, but the scanner is actually supposed to generate results, right?  I mean, the behavior says "64_bit", so you'd think intuitively that on a 32-bit machine it just shouldn't generate any results at all.


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

 


If you're generating results, then my opinion is that it can be said to "apply".  The name of the behavior should describe the expected results.


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


I'm just saying that there is already a way to distinguish, which is by looking at the objects with which they're associated.  In fact, it's entirely possible that two objects with different behaviors could both point to the same item, even though there are two different registry values that happen by coincidence to be equal to one-another, and the generated results would be valid and correct.


 

Thanks,

Danny

 

From: David Solin [[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].

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,

 

>Indeed there are instances where the generality required in the independent schema has ultimately failed to exist, but it is still a practice we should strive to avoid. 

 

I agree.

 

>Along those lines, then, we really need only one behavior -- which is "32-bit".  It is intuitively meaningful on both 32-bit and 64-bit machines -- it signifies some path for a 32-bit object. 

 

That is an interesting proposal, were you thinking something like 32_bit_view=”true/false” and if false simply check the native view?  My only concern with that it would be somewhat redundant on a 32-bit system.

 

>In fact the text "Ignored on a 32-bit system" is itself confusing -- does it mean to ignore the behavior, or to ignore the object on which the behavior is defined -- meaning that no items should be >created?

I would expect that “ignored on a 32-bit system” would mean that the behavior itself would be ignored and the object would go about its item collection as if the behavior did not exist for that object.  If you ignored the object on which the behavior was defined, you would be breaking all of the content on 32-bit systems since the behavior would be there by default.


>As for modifying the items themselves, it seems to me that if some proprietary means of associating items is being used to bypass the optional object references (e.g., attributes from another >namespace), then that is hardly a problem that the specification itself needs to address.  Since the specification already provides a means of determining the object origins of items, it is not >really necessary (as a function of the specification) to duplicate the object's behavior information in the item itself.

 

I wouldn’t say the proprietary means is a way of bypassing the optional object references, but rather, just another way of doing things.  One thing that I forgot to mention is that another way to implement a system characteristics producer is to in fact use OVAL objects in which you could get that mapping.  To go into the system characteristics producer scenario some more, an organization may have agents on a system that simply collect certain information of interest whether it be registry keys, file hashes, etc. and then send that information of to another system for evaluation against some OVAL definitions.  If a collected_objects section is not available, in this system-characteristics file, the tool performing the evaluation must consider all items in the OVAL system-characteristics (that are of the same type – i.e. registry_object would consider all registry_items) and compare them to the objects specified in the OVAL definitions to see if they match and should be used in the evaluation of the test (there is more on this in Section 5.3.2.4.1 of the spec).  Now if you had an OVAL object that used the windows_view behavior, it would not be able to determine if that item actually matched the object or if it did not exist for that object.  You would need the windows_view entity to make that determination.  As a result, I think we want to support this use case.

 

Thanks,

Danny

 

From: David Solin [mailto:[hidden email]] On Behalf Of David Solin
Sent: Wednesday, August 24, 2011 4:00 PM
To: Haynes, Dan
Cc: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal

 

Ah, you're talking about the Independent schema FileBehaviors.  Unix FileBehaviors deprecates the recurse attribute, and Windows FileBehaviors doesn't have one...

Indeed there are instances where the generality required in the independent schema has ultimately failed to exist, but it is still a practice we should strive to avoid.  Along those lines, then, we really need only one behavior -- which is "32-bit".  It is intuitively meaningful on both 32-bit and 64-bit machines -- it signifies some path for a 32-bit object.  In fact the text "Ignored on a 32-bit system" is itself confusing -- does it mean to ignore the behavior, or to ignore the object on which the behavior is defined -- meaning that no items should be created?

As for modifying the items themselves, it seems to me that if some proprietary means of associating items is being used to bypass the optional object references (e.g., attributes from another namespace), then that is hardly a problem that the specification itself needs to address.  Since the specification already provides a means of determining the object origins of items, it is not really necessary (as a function of the specification) to duplicate the object's behavior information in the item itself.

Anyway, if the rest of the community is really pleased with the proposal, I'll fall in line.

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


On 8/24/2011 2:03 PM, Haynes, Dan wrote:

Hi David,

 

>Not only is it ignored on 32-bit, but the scanner is actually supposed to generate results, right?  I mean, the behavior says "64_bit", so you'd think intuitively that on a 32-bit machine it just >shouldn't generate any results at all.

>If you're generating results, then my opinion is that it can be said to "apply".  The name of the behavior should describe the expected results.

 

Yes, the scanner would be expected to generate results.  I would agree that this it is somewhat counter-intuitive if you were to just look at the content without the full context of how the behavior is meant to work.  That is, if you consider that same content in the context of the behavior only applying to 64-bit Windows operating systems it doesn’t seem so confusing (at least to me) as the documentation states that the behavior must be ignored as if it wasn’t even there (implicitly or explicitly).  I understand this is not the most elegant solution, but, we have similar restrictions on the use of behaviors today in the OVAL Language so I wouldn’t think that this is that far off.  For example, the ‘recurse’ behavior in the ind-def:FileBehaviors states:

“'recurse' defines...Also note that this behavior does not apply to Windows systems since they do not support symbolic links. On Windows systems the 'recurse' behavior is always equivalent to directories.”


Here it is not only saying the behavior value doesn’t apply, but, that it must be interpreted as something else.

 

If you were to use “native” instead of “64_bit”, I would anticipate that would mean that this behavior would now apply to 32-bit Windows operating systems along with 64-bit Windows operating systems?  Do you think there would be any confusion between which value a content author should use since “native” and “32_bit” are the same thing in the context of a 32-bit Windows operating system?

 

>I'm just saying that there is already a way to distinguish, which is by looking at the objects with which they're associated.  In fact, it's entirely possible that two objects with different behaviors >could both point to the same item, even though there are two different registry values that happen by coincidence to be equal to one-another, and the generated results would be valid and >correct.

 

While in some cases you can look at the object to distinguish between where an item came from, it will not always work as the collected_object section is optional.  For example, consider the system characteristics producer adoption capability.  It is completely valid for items to be collected using some proprietary process, without the use of objects, as long as it conforms to the oval-system-characteristics-schema.  In this situation, you would not have a collected_objects section in the system characteristics and would not be able to make that distinction.  I think that the windows_view item entity will be need to make that distinction between those items.


Thanks,

Danny

 

From: David Solin [[hidden email]] On Behalf Of David Solin
Sent: Wednesday, August 24, 2011 1:16 PM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Cc: Haynes, Dan
Subject: Fwd: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal

 

Comments below...

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



On 8/24/2011 9:57 AM, Haynes, Dan wrote:

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?




Not only is it ignored on 32-bit, but the scanner is actually supposed to generate results, right?  I mean, the behavior says "64_bit", so you'd think intuitively that on a 32-bit machine it just shouldn't generate any results at all.



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

 


If you're generating results, then my opinion is that it can be said to "apply".  The name of the behavior should describe the expected results.



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


I'm just saying that there is already a way to distinguish, which is by looking at the objects with which they're associated.  In fact, it's entirely possible that two objects with different behaviors could both point to the same item, even though there are two different registry values that happen by coincidence to be equal to one-another, and the generated results would be valid and correct.



 

Thanks,

Danny

 

From: David Solin [[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].

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

joval
Inline...

On 8/24/2011 4:09 PM, Haynes, Dan wrote:

Hi David,

 

>Indeed there are instances where the generality required in the independent schema has ultimately failed to exist, but it is still a practice we should strive to avoid. 

 

I agree.

 

>Along those lines, then, we really need only one behavior -- which is "32-bit".  It is intuitively meaningful on both 32-bit and 64-bit machines -- it signifies some path for a 32-bit object. 

 

That is an interesting proposal, were you thinking something like 32_bit_view=”true/false” and if false simply check the native view?  My only concern with that it would be somewhat redundant on a 32-bit system.

Right, that's the idea exactly.  I don't see it as any more redundant than, say ignoring the 32-bit or 64-bit flag on a 32-bit system.

 

>In fact the text "Ignored on a 32-bit system" is itself confusing -- does it mean to ignore the behavior, or to ignore the object on which the behavior is defined -- meaning that no items should be >created?

I would expect that “ignored on a 32-bit system” would mean that the behavior itself would be ignored and the object would go about its item collection as if the behavior did not exist for that object.  If you ignored the object on which the behavior was defined, you would be breaking all of the content on 32-bit systems since the behavior would be there by default.


You and I know what it means, but a reasonable person reading the statement for the first time might be confused.

>As for modifying the items themselves, it seems to me that if some proprietary means of associating items is being used to bypass the optional object references (e.g., attributes from another >namespace), then that is hardly a problem that the specification itself needs to address.  Since the specification already provides a means of determining the object origins of items, it is not >really necessary (as a function of the specification) to duplicate the object's behavior information in the item itself.

 

I wouldn’t say the proprietary means is a way of bypassing the optional object references, but rather, just another way of doing things.  One thing that I forgot to mention is that another way to implement a system characteristics producer is to in fact use OVAL objects in which you could get that mapping.  To go into the system characteristics producer scenario some more, an organization may have agents on a system that simply collect certain information of interest whether it be registry keys, file hashes, etc. and then send that information of to another system for evaluation against some OVAL definitions.  If a collected_objects section is not available, in this system-characteristics file, the tool performing the evaluation must consider all items in the OVAL system-characteristics (that are of the same type – i.e. registry_object would consider all registry_items) and compare them to the objects specified in the OVAL definitions to see if they match and should be used in the evaluation of the test (there is more on this in Section 5.3.2.4.1 of the spec).  Now if you had an OVAL object that used the windows_view behavior, it would not be able to determine if that item actually matched the object or if it did not exist for that object.  You would need the windows_view entity to make that determination.  As a result, I think we want to support this use case.

I certainly hadn't considered that!  You've convinced me!

 

Thanks,

Danny

 

From: David Solin [[hidden email]] On Behalf Of David Solin
Sent: Wednesday, August 24, 2011 4:00 PM
To: Haynes, Dan
Cc: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal

 

Ah, you're talking about the Independent schema FileBehaviors.  Unix FileBehaviors deprecates the recurse attribute, and Windows FileBehaviors doesn't have one...

Indeed there are instances where the generality required in the independent schema has ultimately failed to exist, but it is still a practice we should strive to avoid.  Along those lines, then, we really need only one behavior -- which is "32-bit".  It is intuitively meaningful on both 32-bit and 64-bit machines -- it signifies some path for a 32-bit object.  In fact the text "Ignored on a 32-bit system" is itself confusing -- does it mean to ignore the behavior, or to ignore the object on which the behavior is defined -- meaning that no items should be created?

As for modifying the items themselves, it seems to me that if some proprietary means of associating items is being used to bypass the optional object references (e.g., attributes from another namespace), then that is hardly a problem that the specification itself needs to address.  Since the specification already provides a means of determining the object origins of items, it is not really necessary (as a function of the specification) to duplicate the object's behavior information in the item itself.

Anyway, if the rest of the community is really pleased with the proposal, I'll fall in line.

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


On 8/24/2011 2:03 PM, Haynes, Dan wrote:

Hi David,

 

>Not only is it ignored on 32-bit, but the scanner is actually supposed to generate results, right?  I mean, the behavior says "64_bit", so you'd think intuitively that on a 32-bit machine it just >shouldn't generate any results at all.

>If you're generating results, then my opinion is that it can be said to "apply".  The name of the behavior should describe the expected results.

 

Yes, the scanner would be expected to generate results.  I would agree that this it is somewhat counter-intuitive if you were to just look at the content without the full context of how the behavior is meant to work.  That is, if you consider that same content in the context of the behavior only applying to 64-bit Windows operating systems it doesn’t seem so confusing (at least to me) as the documentation states that the behavior must be ignored as if it wasn’t even there (implicitly or explicitly).  I understand this is not the most elegant solution, but, we have similar restrictions on the use of behaviors today in the OVAL Language so I wouldn’t think that this is that far off.  For example, the ‘recurse’ behavior in the ind-def:FileBehaviors states:

“'recurse' defines...Also note that this behavior does not apply to Windows systems since they do not support symbolic links. On Windows systems the 'recurse' behavior is always equivalent to directories.”


Here it is not only saying the behavior value doesn’t apply, but, that it must be interpreted as something else.

 

If you were to use “native” instead of “64_bit”, I would anticipate that would mean that this behavior would now apply to 32-bit Windows operating systems along with 64-bit Windows operating systems?  Do you think there would be any confusion between which value a content author should use since “native” and “32_bit” are the same thing in the context of a 32-bit Windows operating system?

 

>I'm just saying that there is already a way to distinguish, which is by looking at the objects with which they're associated.  In fact, it's entirely possible that two objects with different behaviors >could both point to the same item, even though there are two different registry values that happen by coincidence to be equal to one-another, and the generated results would be valid and >correct.

 

While in some cases you can look at the object to distinguish between where an item came from, it will not always work as the collected_object section is optional.  For example, consider the system characteristics producer adoption capability.  It is completely valid for items to be collected using some proprietary process, without the use of objects, as long as it conforms to the oval-system-characteristics-schema.  In this situation, you would not have a collected_objects section in the system characteristics and would not be able to make that distinction.  I think that the windows_view item entity will be need to make that distinction between those items.


Thanks,

Danny

 

From: David Solin [[hidden email]] On Behalf Of David Solin
Sent: Wednesday, August 24, 2011 1:16 PM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Cc: Haynes, Dan
Subject: Fwd: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal

 

Comments below...

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



On 8/24/2011 9:57 AM, Haynes, Dan wrote:

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?




Not only is it ignored on 32-bit, but the scanner is actually supposed to generate results, right?  I mean, the behavior says "64_bit", so you'd think intuitively that on a 32-bit machine it just shouldn't generate any results at all.



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

 


If you're generating results, then my opinion is that it can be said to "apply".  The name of the behavior should describe the expected results.



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


I'm just saying that there is already a way to distinguish, which is by looking at the objects with which they're associated.  In fact, it's entirely possible that two objects with different behaviors could both point to the same item, even though there are two different registry values that happen by coincidence to be equal to one-another, and the generated results would be valid and correct.



 

Thanks,

Danny

 

From: David Solin [[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].

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

Were you thinking for a default value ‘true’?  If you had a default value of ‘false’, what would be expected to happen there? 

 

You raise a good point about the confusion around what it means to ignore the behavior.  We will need to add some more documentation explaining what “ignore the behavior” means to further clarify how it should work.

 

Thanks,

Danny

 

From: David Solin [mailto:[hidden email]] On Behalf Of David Solin
Sent: Thursday, August 25, 2011 8:11 AM
To: Haynes, Dan
Cc: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal

 

Inline...

On 8/24/2011 4:09 PM, Haynes, Dan wrote:

Hi David,

 

>Indeed there are instances where the generality required in the independent schema has ultimately failed to exist, but it is still a practice we should strive to avoid. 

 

I agree.

 

>Along those lines, then, we really need only one behavior -- which is "32-bit".  It is intuitively meaningful on both 32-bit and 64-bit machines -- it signifies some path for a 32-bit object. 

 

That is an interesting proposal, were you thinking something like 32_bit_view=”true/false” and if false simply check the native view?  My only concern with that it would be somewhat redundant on a 32-bit system.

Right, that's the idea exactly.  I don't see it as any more redundant than, say ignoring the 32-bit or 64-bit flag on a 32-bit system.


 

>In fact the text "Ignored on a 32-bit system" is itself confusing -- does it mean to ignore the behavior, or to ignore the object on which the behavior is defined -- meaning that no items should be >created?


I would expect that “ignored on a 32-bit system” would mean that the behavior itself would be ignored and the object would go about its item collection as if the behavior did not exist for that object.  If you ignored the object on which the behavior was defined, you would be breaking all of the content on 32-bit systems since the behavior would be there by default.

 

You and I know what it means, but a reasonable person reading the statement for the first time might be confused.


>As for modifying the items themselves, it seems to me that if some proprietary means of associating items is being used to bypass the optional object references (e.g., attributes from another >namespace), then that is hardly a problem that the specification itself needs to address.  Since the specification already provides a means of determining the object origins of items, it is not >really necessary (as a function of the specification) to duplicate the object's behavior information in the item itself.

 

I wouldn’t say the proprietary means is a way of bypassing the optional object references, but rather, just another way of doing things.  One thing that I forgot to mention is that another way to implement a system characteristics producer is to in fact use OVAL objects in which you could get that mapping.  To go into the system characteristics producer scenario some more, an organization may have agents on a system that simply collect certain information of interest whether it be registry keys, file hashes, etc. and then send that information of to another system for evaluation against some OVAL definitions.  If a collected_objects section is not available, in this system-characteristics file, the tool performing the evaluation must consider all items in the OVAL system-characteristics (that are of the same type – i.e. registry_object would consider all registry_items) and compare them to the objects specified in the OVAL definitions to see if they match and should be used in the evaluation of the test (there is more on this in Section 5.3.2.4.1 of the spec).  Now if you had an OVAL object that used the windows_view behavior, it would not be able to determine if that item actually matched the object or if it did not exist for that object.  You would need the windows_view entity to make that determination.  As a result, I think we want to support this use case.

I certainly hadn't considered that!  You've convinced me!


 

Thanks,

Danny

 

From: David Solin [[hidden email]] On Behalf Of David Solin
Sent: Wednesday, August 24, 2011 4:00 PM
To: Haynes, Dan
Cc: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal

 

Ah, you're talking about the Independent schema FileBehaviors.  Unix FileBehaviors deprecates the recurse attribute, and Windows FileBehaviors doesn't have one...

Indeed there are instances where the generality required in the independent schema has ultimately failed to exist, but it is still a practice we should strive to avoid.  Along those lines, then, we really need only one behavior -- which is "32-bit".  It is intuitively meaningful on both 32-bit and 64-bit machines -- it signifies some path for a 32-bit object.  In fact the text "Ignored on a 32-bit system" is itself confusing -- does it mean to ignore the behavior, or to ignore the object on which the behavior is defined -- meaning that no items should be created?

As for modifying the items themselves, it seems to me that if some proprietary means of associating items is being used to bypass the optional object references (e.g., attributes from another namespace), then that is hardly a problem that the specification itself needs to address.  Since the specification already provides a means of determining the object origins of items, it is not really necessary (as a function of the specification) to duplicate the object's behavior information in the item itself.

Anyway, if the rest of the community is really pleased with the proposal, I'll fall in line.

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


On 8/24/2011 2:03 PM, Haynes, Dan wrote:

Hi David,

 

>Not only is it ignored on 32-bit, but the scanner is actually supposed to generate results, right?  I mean, the behavior says "64_bit", so you'd think intuitively that on a 32-bit machine it just >shouldn't generate any results at all.

>If you're generating results, then my opinion is that it can be said to "apply".  The name of the behavior should describe the expected results.

 

Yes, the scanner would be expected to generate results.  I would agree that this it is somewhat counter-intuitive if you were to just look at the content without the full context of how the behavior is meant to work.  That is, if you consider that same content in the context of the behavior only applying to 64-bit Windows operating systems it doesn’t seem so confusing (at least to me) as the documentation states that the behavior must be ignored as if it wasn’t even there (implicitly or explicitly).  I understand this is not the most elegant solution, but, we have similar restrictions on the use of behaviors today in the OVAL Language so I wouldn’t think that this is that far off.  For example, the ‘recurse’ behavior in the ind-def:FileBehaviors states:

“'recurse' defines...Also note that this behavior does not apply to Windows systems since they do not support symbolic links. On Windows systems the 'recurse' behavior is always equivalent to directories.”



Here it is not only saying the behavior value doesn’t apply, but, that it must be interpreted as something else.

 

If you were to use “native” instead of “64_bit”, I would anticipate that would mean that this behavior would now apply to 32-bit Windows operating systems along with 64-bit Windows operating systems?  Do you think there would be any confusion between which value a content author should use since “native” and “32_bit” are the same thing in the context of a 32-bit Windows operating system?

 

>I'm just saying that there is already a way to distinguish, which is by looking at the objects with which they're associated.  In fact, it's entirely possible that two objects with different behaviors >could both point to the same item, even though there are two different registry values that happen by coincidence to be equal to one-another, and the generated results would be valid and >correct.

 

While in some cases you can look at the object to distinguish between where an item came from, it will not always work as the collected_object section is optional.  For example, consider the system characteristics producer adoption capability.  It is completely valid for items to be collected using some proprietary process, without the use of objects, as long as it conforms to the oval-system-characteristics-schema.  In this situation, you would not have a collected_objects section in the system characteristics and would not be able to make that distinction.  I think that the windows_view item entity will be need to make that distinction between those items.



Thanks,

Danny

 

From: David Solin [[hidden email]] On Behalf Of David Solin
Sent: Wednesday, August 24, 2011 1:16 PM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Cc: Haynes, Dan
Subject: Fwd: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal

 

Comments below...

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



On 8/24/2011 9:57 AM, Haynes, Dan wrote:

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?





Not only is it ignored on 32-bit, but the scanner is actually supposed to generate results, right?  I mean, the behavior says "64_bit", so you'd think intuitively that on a 32-bit machine it just shouldn't generate any results at all.




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

 


If you're generating results, then my opinion is that it can be said to "apply".  The name of the behavior should describe the expected results.




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


I'm just saying that there is already a way to distinguish, which is by looking at the objects with which they're associated.  In fact, it's entirely possible that two objects with different behaviors could both point to the same item, even though there are two different registry values that happen by coincidence to be equal to one-another, and the generated results would be valid and correct.




 

Thanks,

Danny

 

From: David Solin [[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].

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

KenSimone

If we go this route, I propose it look something like this:

 

Behavior name: 32_bit_view

Description: This behavior affects which file system or registry view is examined on 64bit versions of Windows. This behavior has no effect on other operating systems.

Values: A setting of ‘true’ directs the probe to examine the 32bit view. A setting of ‘false’ directs the probe to examine the native, 64bit view.

Default: ‘false’

 

I think you have to keep the concept of “ignored everywhere except on 64bit windows” – because what does a setting of ‘false’ mean when on a 32bit version of Windows?

 

Ken

 

From: Haynes, Dan [mailto:[hidden email]]
Sent: Thursday, August 25, 2011 9:21 AM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal

 

Were you thinking for a default value ‘true’?  If you had a default value of ‘false’, what would be expected to happen there? 

 

You raise a good point about the confusion around what it means to ignore the behavior.  We will need to add some more documentation explaining what “ignore the behavior” means to further clarify how it should work.

 

Thanks,

Danny

 

From: David Solin [mailto:[hidden email]] On Behalf Of David Solin
Sent: Thursday, August 25, 2011 8:11 AM
To: Haynes, Dan
Cc: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal

 

Inline...

On 8/24/2011 4:09 PM, Haynes, Dan wrote:

Hi David,

 

>Indeed there are instances where the generality required in the independent schema has ultimately failed to exist, but it is still a practice we should strive to avoid. 

 

I agree.

 

>Along those lines, then, we really need only one behavior -- which is "32-bit".  It is intuitively meaningful on both 32-bit and 64-bit machines -- it signifies some path for a 32-bit object. 

 

That is an interesting proposal, were you thinking something like 32_bit_view=”true/false” and if false simply check the native view?  My only concern with that it would be somewhat redundant on a 32-bit system.

Right, that's the idea exactly.  I don't see it as any more redundant than, say ignoring the 32-bit or 64-bit flag on a 32-bit system.

 

>In fact the text "Ignored on a 32-bit system" is itself confusing -- does it mean to ignore the behavior, or to ignore the object on which the behavior is defined -- meaning that no items should be >created?

I would expect that “ignored on a 32-bit system” would mean that the behavior itself would be ignored and the object would go about its item collection as if the behavior did not exist for that object.  If you ignored the object on which the behavior was defined, you would be breaking all of the content on 32-bit systems since the behavior would be there by default.

 

You and I know what it means, but a reasonable person reading the statement for the first time might be confused.

>As for modifying the items themselves, it seems to me that if some proprietary means of associating items is being used to bypass the optional object references (e.g., attributes from another >namespace), then that is hardly a problem that the specification itself needs to address.  Since the specification already provides a means of determining the object origins of items, it is not >really necessary (as a function of the specification) to duplicate the object's behavior information in the item itself.

 

I wouldn’t say the proprietary means is a way of bypassing the optional object references, but rather, just another way of doing things.  One thing that I forgot to mention is that another way to implement a system characteristics producer is to in fact use OVAL objects in which you could get that mapping.  To go into the system characteristics producer scenario some more, an organization may have agents on a system that simply collect certain information of interest whether it be registry keys, file hashes, etc. and then send that information of to another system for evaluation against some OVAL definitions.  If a collected_objects section is not available, in this system-characteristics file, the tool performing the evaluation must consider all items in the OVAL system-characteristics (that are of the same type – i.e. registry_object would consider all registry_items) and compare them to the objects specified in the OVAL definitions to see if they match and should be used in the evaluation of the test (there is more on this in Section 5.3.2.4.1 of the spec).  Now if you had an OVAL object that used the windows_view behavior, it would not be able to determine if that item actually matched the object or if it did not exist for that object.  You would need the windows_view entity to make that determination.  As a result, I think we want to support this use case.

I certainly hadn't considered that!  You've convinced me!

 

Thanks,

Danny

 

From: David Solin [[hidden email]] On Behalf Of David Solin
Sent: Wednesday, August 24, 2011 4:00 PM
To: Haynes, Dan
Cc: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal

 

Ah, you're talking about the Independent schema FileBehaviors.  Unix FileBehaviors deprecates the recurse attribute, and Windows FileBehaviors doesn't have one...

Indeed there are instances where the generality required in the independent schema has ultimately failed to exist, but it is still a practice we should strive to avoid.  Along those lines, then, we really need only one behavior -- which is "32-bit".  It is intuitively meaningful on both 32-bit and 64-bit machines -- it signifies some path for a 32-bit object.  In fact the text "Ignored on a 32-bit system" is itself confusing -- does it mean to ignore the behavior, or to ignore the object on which the behavior is defined -- meaning that no items should be created?

As for modifying the items themselves, it seems to me that if some proprietary means of associating items is being used to bypass the optional object references (e.g., attributes from another namespace), then that is hardly a problem that the specification itself needs to address.  Since the specification already provides a means of determining the object origins of items, it is not really necessary (as a function of the specification) to duplicate the object's behavior information in the item itself.

Anyway, if the rest of the community is really pleased with the proposal, I'll fall in line.

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


On 8/24/2011 2:03 PM, Haynes, Dan wrote:

Hi David,

 

>Not only is it ignored on 32-bit, but the scanner is actually supposed to generate results, right?  I mean, the behavior says "64_bit", so you'd think intuitively that on a 32-bit machine it just >shouldn't generate any results at all.

>If you're generating results, then my opinion is that it can be said to "apply".  The name of the behavior should describe the expected results.

 

Yes, the scanner would be expected to generate results.  I would agree that this it is somewhat counter-intuitive if you were to just look at the content without the full context of how the behavior is meant to work.  That is, if you consider that same content in the context of the behavior only applying to 64-bit Windows operating systems it doesn’t seem so confusing (at least to me) as the documentation states that the behavior must be ignored as if it wasn’t even there (implicitly or explicitly).  I understand this is not the most elegant solution, but, we have similar restrictions on the use of behaviors today in the OVAL Language so I wouldn’t think that this is that far off.  For example, the ‘recurse’ behavior in the ind-def:FileBehaviors states:

“'recurse' defines...Also note that this behavior does not apply to Windows systems since they do not support symbolic links. On Windows systems the 'recurse' behavior is always equivalent to directories.”


Here it is not only saying the behavior value doesn’t apply, but, that it must be interpreted as something else.

 

If you were to use “native” instead of “64_bit”, I would anticipate that would mean that this behavior would now apply to 32-bit Windows operating systems along with 64-bit Windows operating systems?  Do you think there would be any confusion between which value a content author should use since “native” and “32_bit” are the same thing in the context of a 32-bit Windows operating system?

 

>I'm just saying that there is already a way to distinguish, which is by looking at the objects with which they're associated.  In fact, it's entirely possible that two objects with different behaviors >could both point to the same item, even though there are two different registry values that happen by coincidence to be equal to one-another, and the generated results would be valid and >correct.

 

While in some cases you can look at the object to distinguish between where an item came from, it will not always work as the collected_object section is optional.  For example, consider the system characteristics producer adoption capability.  It is completely valid for items to be collected using some proprietary process, without the use of objects, as long as it conforms to the oval-system-characteristics-schema.  In this situation, you would not have a collected_objects section in the system characteristics and would not be able to make that distinction.  I think that the windows_view item entity will be need to make that distinction between those items.


Thanks,

Danny

 

From: David Solin [[hidden email]] On Behalf Of David Solin
Sent: Wednesday, August 24, 2011 1:16 PM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Cc: Haynes, Dan
Subject: Fwd: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal

 

Comments below...

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



On 8/24/2011 9:57 AM, Haynes, Dan wrote:

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?




Not only is it ignored on 32-bit, but the scanner is actually supposed to generate results, right?  I mean, the behavior says "64_bit", so you'd think intuitively that on a 32-bit machine it just shouldn't generate any results at all.



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

 


If you're generating results, then my opinion is that it can be said to "apply".  The name of the behavior should describe the expected results.



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


I'm just saying that there is already a way to distinguish, which is by looking at the objects with which they're associated.  In fact, it's entirely possible that two objects with different behaviors could both point to the same item, even though there are two different registry values that happen by coincidence to be equal to one-another, and the generated results would be valid and correct.



 

Thanks,

Danny

 

From: David Solin [[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].

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

Hansbury, Matt
Ken/David,

I agree that this solution would work as well.  I would point out, however, that with a name like 32_bit_view and using a boolean value, we do lose the option of easily extending this should the occasion ever arise.

Are we OK with that?

Alternatively, David, would last approach I posted be acceptable with a bit more clarification in the documentation regarding what it means to ignore the behavior?  (To be specific, I'm referring to the 'windows_view' behavior with the values of 32_bit & 64_bit only.)

Are there others out there with thoughts on this?  Either for or against?

Thanks
Matt

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

If we go this route, I propose it look something like this:



Behavior name: 32_bit_view

Description: This behavior affects which file system or registry view is examined on 64bit versions of Windows. This behavior has no effect on other operating systems.

Values: A setting of 'true' directs the probe to examine the 32bit view. A setting of 'false' directs the probe to examine the native, 64bit view.

Default: 'false'



I think you have to keep the concept of "ignored everywhere except on 64bit windows" - because what does a setting of 'false' mean when on a 32bit version of Windows?



Ken



From: Haynes, Dan [mailto:[hidden email]]
Sent: Thursday, August 25, 2011 9:21 AM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal



Were you thinking for a default value 'true'?  If you had a default value of 'false', what would be expected to happen there?



You raise a good point about the confusion around what it means to ignore the behavior.  We will need to add some more documentation explaining what "ignore the behavior" means to further clarify how it should work.



Thanks,

Danny



From: David Solin [mailto:[hidden email]] On Behalf Of David Solin
Sent: Thursday, August 25, 2011 8:11 AM
To: Haynes, Dan
Cc: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal



Inline...

On 8/24/2011 4:09 PM, Haynes, Dan wrote:

Hi David,



>Indeed there are instances where the generality required in the independent schema has ultimately failed to exist, but it is still a practice we should strive to avoid.



I agree.



>Along those lines, then, we really need only one behavior -- which is "32-bit".  It is intuitively meaningful on both 32-bit and 64-bit machines -- it signifies some path for a 32-bit object.



That is an interesting proposal, were you thinking something like 32_bit_view="true/false" and if false simply check the native view?  My only concern with that it would be somewhat redundant on a 32-bit system.

Right, that's the idea exactly.  I don't see it as any more redundant than, say ignoring the 32-bit or 64-bit flag on a 32-bit system.





>In fact the text "Ignored on a 32-bit system" is itself confusing -- does it mean to ignore the behavior, or to ignore the object on which the behavior is defined -- meaning that no items should be >created?



I would expect that "ignored on a 32-bit system" would mean that the behavior itself would be ignored and the object would go about its item collection as if the behavior did not exist for that object.  If you ignored the object on which the behavior was defined, you would be breaking all of the content on 32-bit systems since the behavior would be there by default.



You and I know what it means, but a reasonable person reading the statement for the first time might be confused.



>As for modifying the items themselves, it seems to me that if some proprietary means of associating items is being used to bypass the optional object references (e.g., attributes from another >namespace), then that is hardly a problem that the specification itself needs to address.  Since the specification already provides a means of determining the object origins of items, it is not >really necessary (as a function of the specification) to duplicate the object's behavior information in the item itself.



I wouldn't say the proprietary means is a way of bypassing the optional object references, but rather, just another way of doing things.  One thing that I forgot to mention is that another way to implement a system characteristics producer is to in fact use OVAL objects in which you could get that mapping.  To go into the system characteristics producer scenario some more, an organization may have agents on a system that simply collect certain information of interest whether it be registry keys, file hashes, etc. and then send that information of to another system for evaluation against some OVAL definitions.  If a collected_objects section is not available, in this system-characteristics file, the tool performing the evaluation must consider all items in the OVAL system-characteristics (that are of the same type - i.e. registry_object would consider all registry_items) and compare them to the objects specified in the OVAL definitions to see if they match and should be used in the evaluation of the test (there is more on this in Section 5.3.2.4.1 of the spec).  Now if you had an OVAL object that used the windows_view behavior, it would not be able to determine if that item actually matched the object or if it did not exist for that object.  You would need the windows_view entity to make that determination.  As a result, I think we want to support this use case.

I certainly hadn't considered that!  You've convinced me!





Thanks,

Danny



From: David Solin [mailto:[hidden email]] On Behalf Of David Solin
Sent: Wednesday, August 24, 2011 4:00 PM
To: Haynes, Dan
Cc: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal



Ah, you're talking about the Independent schema FileBehaviors.  Unix FileBehaviors deprecates the recurse attribute, and Windows FileBehaviors doesn't have one...

Indeed there are instances where the generality required in the independent schema has ultimately failed to exist, but it is still a practice we should strive to avoid.  Along those lines, then, we really need only one behavior -- which is "32-bit".  It is intuitively meaningful on both 32-bit and 64-bit machines -- it signifies some path for a 32-bit object.  In fact the text "Ignored on a 32-bit system" is itself confusing -- does it mean to ignore the behavior, or to ignore the object on which the behavior is defined -- meaning that no items should be created?

As for modifying the items themselves, it seems to me that if some proprietary means of associating items is being used to bypass the optional object references (e.g., attributes from another namespace), then that is hardly a problem that the specification itself needs to address.  Since the specification already provides a means of determining the object origins of items, it is not really necessary (as a function of the specification) to duplicate the object's behavior information in the item itself.

Anyway, if the rest of the community is really pleased with the proposal, I'll fall in line.

jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More <http://www.joval.org>  | Features <http://www.joval.org/features/>  | Download <http://www.joval.org/download/>


On 8/24/2011 2:03 PM, Haynes, Dan wrote:

Hi David,



>Not only is it ignored on 32-bit, but the scanner is actually supposed to generate results, right?  I mean, the behavior says "64_bit", so you'd think intuitively that on a 32-bit machine it just >shouldn't generate any results at all.

>

>If you're generating results, then my opinion is that it can be said to "apply".  The name of the behavior should describe the expected results.



Yes, the scanner would be expected to generate results.  I would agree that this it is somewhat counter-intuitive if you were to just look at the content without the full context of how the behavior is meant to work.  That is, if you consider that same content in the context of the behavior only applying to 64-bit Windows operating systems it doesn't seem so confusing (at least to me) as the documentation states that the behavior must be ignored as if it wasn't even there (implicitly or explicitly).  I understand this is not the most elegant solution, but, we have similar restrictions on the use of behaviors today in the OVAL Language so I wouldn't think that this is that far off.  For example, the 'recurse' behavior in the ind-def:FileBehaviors states:

"'recurse' defines...Also note that this behavior does not apply to Windows systems since they do not support symbolic links. On Windows systems the 'recurse' behavior is always equivalent to directories."




Here it is not only saying the behavior value doesn't apply, but, that it must be interpreted as something else.



If you were to use "native" instead of "64_bit", I would anticipate that would mean that this behavior would now apply to 32-bit Windows operating systems along with 64-bit Windows operating systems?  Do you think there would be any confusion between which value a content author should use since "native" and "32_bit" are the same thing in the context of a 32-bit Windows operating system?



>I'm just saying that there is already a way to distinguish, which is by looking at the objects with which they're associated.  In fact, it's entirely possible that two objects with different behaviors >could both point to the same item, even though there are two different registry values that happen by coincidence to be equal to one-another, and the generated results would be valid and >correct.



While in some cases you can look at the object to distinguish between where an item came from, it will not always work as the collected_object section is optional.  For example, consider the system characteristics producer adoption capability.  It is completely valid for items to be collected using some proprietary process, without the use of objects, as long as it conforms to the oval-system-characteristics-schema.  In this situation, you would not have a collected_objects section in the system characteristics and would not be able to make that distinction.  I think that the windows_view item entity will be need to make that distinction between those items.




Thanks,

Danny



From: David Solin [mailto:[hidden email]] On Behalf Of David Solin
Sent: Wednesday, August 24, 2011 1:16 PM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Cc: Haynes, Dan
Subject: Fwd: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal



Comments below...

jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More <http://www.joval.org>  | Features <http://www.joval.org/features/>  | Download <http://www.joval.org/download/>



On 8/24/2011 9:57 AM, Haynes, Dan wrote:

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?






Not only is it ignored on 32-bit, but the scanner is actually supposed to generate results, right?  I mean, the behavior says "64_bit", so you'd think intuitively that on a 32-bit machine it just shouldn't generate any results at all.





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




If you're generating results, then my opinion is that it can be said to "apply".  The name of the behavior should describe the expected results.





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


I'm just saying that there is already a way to distinguish, which is by looking at the objects with which they're associated.  In fact, it's entirely possible that two objects with different behaviors could both point to the same item, even though there are two different registry values that happen by coincidence to be equal to one-another, and the generated results would be valid and correct.







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 <http://www.joval.org>  | Features <http://www.joval.org/features/>  | Download <http://www.joval.org/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 [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" <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].

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

Gunnar Engelbach
In reply to this post by Danny Haynes
On 8/25/2011 10:21 AM, Haynes, Dan wrote:
> Were you thinking for a default value ‘true’? If you had a default value
> of ‘false’, what would be expected to happen there?
>
> You raise a good point about the confusion around what it means to
> ignore the behavior. We will need to add some more documentation
> explaining what “ignore the behavior” means to further clarify how it
> should work.

Rather than think of it as a flag that explicitly requests redirection,
I think it's easier to think of it as a flag that indicates when the
behavior applies.  That seems to more closely follow what is reported in
security bulletins.  The interpreters can take care of the business of
doing redirection, if necessary, to fulfill it.

In other words, the presence of the 64-bit flag means that it should
apply only when the 64-bit subsystem is being targeted and ignored
otherwise.  Likewise for the 32-bit flag.

The question is, keeping in mind the collections of existing content,
what should the default value be?

If it is taken to be "native" would indicate the currently targeted
subsystem which would only be evaluated once on any system while "any"
would imply multiple collections on a 64-bit system.

The former allows each subsystem to be targeted and reported on
separately, the latter reports once on the system as a whole.

Personally, I prefer the former for two reasons:

1) For OS-level checks, such as performed for XCCDF, only the 64-bit
view matters.  Reporting a FAIL because a 32-bit registry value is
non-compliant while the 64-bit value is would be a false negative.

2) (Contrived example) If I have both a 32-bit and 64-bit version of
Flash installed where the 64-bit version is patched but the 32-bit is
not, I want to know that.  Otherwise my remediation may well be incorrect.



>
> Thanks,
>
> Danny
>
> *From:*David Solin [mailto:[hidden email]] *On Behalf Of *David Solin
> *Sent:* Thursday, August 25, 2011 8:11 AM
> *To:* Haynes, Dan
> *Cc:* oval-developer-list OVAL Developer List/Closed Public Discussion
> *Subject:* Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal
>
> Inline...
>
> On 8/24/2011 4:09 PM, Haynes, Dan wrote:
>
> Hi David,
>
>>Indeed there are instances where the generality required in the
> independent schema has ultimately failed to exist, but it is still a
> practice we should strive to avoid.
>
> I agree.
>
>>Along those lines, then, we really need only one behavior -- which is
> "32-bit". It is intuitively meaningful on both 32-bit and 64-bit
> machines -- it signifies some path for a 32-bit object.
>
> That is an interesting proposal, were you thinking something like
> 32_bit_view=”true/false” and if false simply check the native view? My
> only concern with that it would be somewhat redundant on a 32-bit system.
>
> Right, that's the idea exactly. I don't see it as any more redundant
> than, say ignoring the 32-bit or 64-bit flag on a 32-bit system.
>
>
>>In fact the text "Ignored on a 32-bit system" is itself confusing --
> does it mean to ignore the behavior, or to ignore the object on which
> the behavior is defined -- meaning that no items should be >created?
>
>
> I would expect that “ignored on a 32-bit system” would mean that the
> behavior itself would be ignored and the object would go about its item
> collection as if the behavior did not exist for that object. If you
> ignored the object on which the behavior was defined, you would be
> breaking all of the content on 32-bit systems since the behavior would
> be there by default.
>
> You and I know what it means, but a reasonable person reading the
> statement for the first time might be confused.
>
>
>>As for modifying the items themselves, it seems to me that if some
> proprietary means of associating items is being used to bypass the
> optional object references (e.g., attributes from another >namespace),
> then that is hardly a problem that the specification itself needs to
> address. Since the specification already provides a means of determining
> the object origins of items, it is not >really necessary (as a function
> of the specification) to duplicate the object's behavior information in
> the item itself.
>
> I wouldn’t say the proprietary means is a way of bypassing the optional
> object references, but rather, just another way of doing things. One
> thing that I forgot to mention is that another way to implement a system
> characteristics producer is to in fact use OVAL objects in which you
> could get that mapping. To go into the system characteristics producer
> scenario some more, an organization may have agents on a system that
> simply collect certain information of interest whether it be registry
> keys, file hashes, etc. and then send that information of to another
> system for evaluation against some OVAL definitions. If a
> collected_objects section is not available, in this
> system-characteristics file, the tool performing the evaluation must
> consider all items in the OVAL system-characteristics (that are of the
> same type – i.e. registry_object would consider all registry_items) and
> compare them to the objects specified in the OVAL definitions to see if
> they match and should be used in the evaluation of the test (there is
> more on this in Section 5.3.2.4.1 of the spec). Now if you had an OVAL
> object that used the windows_view behavior, it would not be able to
> determine if that item actually matched the object or if it did not
> exist for that object. You would need the windows_view entity to make
> that determination. As a result, I think we want to support this use case.
>
> I certainly hadn't considered that! You've convinced me!
>
>
> Thanks,
>
> Danny
>
> *From:*David Solin [mailto:[hidden email]] *On Behalf Of *David Solin
> *Sent:* Wednesday, August 24, 2011 4:00 PM
> *To:* Haynes, Dan
> *Cc:* oval-developer-list OVAL Developer List/Closed Public Discussion
> *Subject:* Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal
>
> Ah, you're talking about the Independent schema FileBehaviors. Unix
> FileBehaviors deprecates the recurse attribute, and Windows
> FileBehaviors doesn't have one...
>
> Indeed there are instances where the generality required in the
> independent schema has ultimately failed to exist, but it is still a
> practice we should strive to avoid. Along those lines, then, we really
> need only one behavior -- which is "32-bit". It is intuitively
> meaningful on both 32-bit and 64-bit machines -- it signifies some path
> for a 32-bit object. In fact the text "Ignored on a 32-bit system" is
> itself confusing -- does it mean to ignore the behavior, or to ignore
> the object on which the behavior is defined -- meaning that no items
> should be created?
>
> As for modifying the items themselves, it seems to me that if some
> proprietary means of associating items is being used to bypass the
> optional object references (e.g., attributes from another namespace),
> then that is hardly a problem that the specification itself needs to
> address. Since the specification already provides a means of determining
> the object origins of items, it is not really necessary (as a function
> of the specification) to duplicate the object's behavior information in
> the item itself.
>
> Anyway, if the rest of the community is really pleased with the
> proposal, I'll fall in line.
>
> jOVAL.org: OVAL implemented in Java.
> /Scan any machine from any machine. For free!/
> Learn More <http://www.joval.org> | Features
> <http://www.joval.org/features/> | Download
> <http://www.joval.org/download/>
>
>
> On 8/24/2011 2:03 PM, Haynes, Dan wrote:
>
> Hi David,
>
>>Not only is it ignored on 32-bit, but the scanner is actually supposed
> to generate results, right? I mean, the behavior says "64_bit", so you'd
> think intuitively that on a 32-bit machine it just >shouldn't generate
> any results at all.
>
>>
>
>>If you're generating results, then my opinion is that it can be said to
> "apply". The name of the behavior should describe the expected results.
>
> Yes, the scanner would be expected to generate results. I would agree
> that this it is somewhat counter-intuitive if you were to just look at
> the content without the full context of how the behavior is meant to
> work. That is, if you consider that same content in the context of the
> behavior only applying to 64-bit Windows operating systems it doesn’t
> seem so confusing (at least to me) as the documentation states that the
> behavior must be ignored as if it wasn’t even there (implicitly or
> explicitly). I understand this is not the most elegant solution, but, we
> have similar restrictions on the use of behaviors today in the OVAL
> Language so I wouldn’t think that this is that far off. For example, the
> ‘recurse’ behavior in the ind-def:FileBehaviors states:
>
> “'recurse' defines...Also note that this behavior does not apply to
> Windows systems since they do not support symbolic links. On Windows
> systems the 'recurse' behavior is always equivalent to directories.”
>
>
>
> Here it is not only saying the behavior value doesn’t apply, but, that
> it must be interpreted as something else.
>
> If you were to use “native” instead of “64_bit”, I would anticipate that
> would mean that this behavior would now apply to 32-bit Windows
> operating systems along with 64-bit Windows operating systems? Do you
> think there would be any confusion between which value a content author
> should use since “native” and “32_bit” are the same thing in the context
> of a 32-bit Windows operating system?
>
>>I'm just saying that there is already a way to distinguish, which is by
> looking at the objects with which they're associated. In fact, it's
> entirely possible that two objects with different behaviors >could both
> point to the same item, even though there are two different registry
> values that happen by coincidence to be equal to one-another, and the
> generated results would be valid and >correct.
>
> While in some cases you can look at the object to distinguish between
> where an item came from, it will not always work as the collected_object
> section is optional. For example, consider the system characteristics
> producer adoption capability. It is completely valid for items to be
> collected using some proprietary process, without the use of objects, as
> long as it conforms to the oval-system-characteristics-schema. In this
> situation, you would not have a collected_objects section in the system
> characteristics and would not be able to make that distinction. I think
> that the windows_view item entity will be need to make that distinction
> between those items.
>
>
>
> Thanks,
>
> Danny
>
> *From:*David Solin [mailto:[hidden email]] *On Behalf Of *David Solin
> *Sent:* Wednesday, August 24, 2011 1:16 PM
> *To:* oval-developer-list OVAL Developer List/Closed Public Discussion
> *Cc:* Haynes, Dan
> *Subject:* Fwd: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal
>
> Comments below...
>
> jOVAL.org: OVAL implemented in Java.
> /Scan any machine from any machine. For free!/
> Learn More <http://www.joval.org> | Features
> <http://www.joval.org/features/> | Download
> <http://www.joval.org/download/>
>
>
>
> On 8/24/2011 9:57 AM, Haynes, Dan wrote:
>
> 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?
>
>
>
>
>
> Not only is it ignored on 32-bit, but the scanner is actually supposed
> to generate results, right? I mean, the behavior says "64_bit", so you'd
> think intuitively that on a 32-bit machine it just shouldn't generate
> any results at all.
>
>
>
>
>>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.
>
>
> If you're generating results, then my opinion is that it can be said to
> "apply". The name of the behavior should describe the expected results.
>
>
>
>
>>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.
>
>
> I'm just saying that there is already a way to distinguish, which is by
> looking at the objects with which they're associated. In fact, it's
> entirely possible that two objects with different behaviors could both
> point to the same item, even though there are two different registry
> values that happen by coincidence to be equal to one-another, and the
> generated results would be valid and correct.
>
>
>
>
> 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 <http://www.joval.org> | Features
> <http://www.joval.org/features/> | Download
> <http://www.joval.org/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 [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]>  [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]  <mailto:[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]  <mailto:[hidden email]>
>
>
>
>
>
>         -----Original Message-----
>
>         From:[hidden email]  <mailto:[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]>
>
>         [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
>
>                 [hidden email]  <mailto:[hidden email]>
>
>
>
>                 To unsubscribe, send an email message [hidden email]  <mailto:[hidden email]>
>
>                 with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message.    If you
>
>                 have difficulties, write to OVAL-
>
>         [hidden email]  <mailto:[hidden email]>.
>
>
>
>             To unsubscribe, send an email message [hidden email]  <mailto:[hidden email]>
>
>             with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message.    If you
>
>             have difficulties, write to OVAL-
>
>         [hidden email]  <mailto:[hidden email]>.
>
>
>
>             To unsubscribe, send an email message [hidden email]  <mailto:[hidden email]>
>
>             with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message.    If you
>
>             have difficulties, write to OVAL-
>
>         [hidden email]  <mailto:[hidden email]>.
>
>
>
>         To unsubscribe, send an email message [hidden email]  <mailto:[hidden email]>  with
>
>         SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message.    If you have
>
>         difficulties, write to [hidden email]  <mailto:[hidden email]>.
>
>
>
>     To unsubscribe, send an email message [hidden email]  <mailto:[hidden email]>  with
>
>     SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message.    If you have
>
>     difficulties, write [hidden email]  <mailto:[hidden email]>.
>
>
>
>     To unsubscribe, send an email message [hidden email]  <mailto:[hidden email]>  with
>
>     SIGNOFF OVAL-DEVELOPER-LIST
>
>     in the BODY of the message.    If you have difficulties, write to OVAL-
>
>     [hidden email]  <mailto:[hidden email]>.
>
>
>
> To unsubscribe, send an email message [hidden email]  <mailto:[hidden email]>  with
>
> SIGNOFF OVAL-DEVELOPER-LIST
>
> in the BODY of the message.    If you have difficulties, write [hidden email]  <mailto:[hidden email]>.
>
>
>
> To unsubscribe, send an email message [hidden email]  <mailto:[hidden email]>  with
>
> SIGNOFF OVAL-DEVELOPER-LIST
>
> in the BODY of the message.    If you have difficulties, write [hidden email]  <mailto:[hidden email]>.
>
> To unsubscribe, send an email message to [hidden email]
> <mailto:[hidden email]> with SIGNOFF OVAL-DEVELOPER-LIST in
> the BODY of the message. If you have difficulties, write to
> [hidden email]
> <mailto:[hidden email]>.
>
> To unsubscribe, send an email message to [hidden email]
> <mailto:[hidden email]> with SIGNOFF OVAL-DEVELOPER-LIST in
> the BODY of the message. If you have difficulties, write to
> [hidden email]
> <mailto:[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
>> I would point out, however, that with a name like 32_bit_view and using a boolean value,
>> we do lose the option of easily extending this should the occasion ever arise.

I'm OK with that. I had considered this approach a while ago, but never suggested it because the community seemed to want generic terms.

>> Alternatively, David, would last approach I posted be acceptable with a bit more clarification
>> in the documentation regarding what it means to ignore the behavior?  (To be specific, I'm referring to the
>> 'windows_view' behavior with the values of 32_bit & 64_bit only.)

Honestly, I do like the 'windows_view' name slightly better, but I'm not going to put up a fight against the other approach. Any approach that has two values, and the default is that no redirection occurs is fine with me.

Ken

-----Original Message-----
From: Hansbury, Matt [mailto:[hidden email]]
Sent: Thursday, August 25, 2011 9:54 AM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal

Ken/David,

I agree that this solution would work as well.  I would point out, however, that with a name like 32_bit_view and using a boolean value, we do lose the option of easily extending this should the occasion ever arise.

Are we OK with that?

Alternatively, David, would last approach I posted be acceptable with a bit more clarification in the documentation regarding what it means to ignore the behavior?  (To be specific, I'm referring to the 'windows_view' behavior with the values of 32_bit & 64_bit only.)

Are there others out there with thoughts on this?  Either for or against?

Thanks
Matt

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

If we go this route, I propose it look something like this:



Behavior name: 32_bit_view

Description: This behavior affects which file system or registry view is examined on 64bit versions of Windows. This behavior has no effect on other operating systems.

Values: A setting of 'true' directs the probe to examine the 32bit view. A setting of 'false' directs the probe to examine the native, 64bit view.

Default: 'false'



I think you have to keep the concept of "ignored everywhere except on 64bit windows" - because what does a setting of 'false' mean when on a 32bit version of Windows?



Ken



From: Haynes, Dan [mailto:[hidden email]]
Sent: Thursday, August 25, 2011 9:21 AM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal



Were you thinking for a default value 'true'?  If you had a default value of 'false', what would be expected to happen there?



You raise a good point about the confusion around what it means to ignore the behavior.  We will need to add some more documentation explaining what "ignore the behavior" means to further clarify how it should work.



Thanks,

Danny



From: David Solin [mailto:[hidden email]] On Behalf Of David Solin
Sent: Thursday, August 25, 2011 8:11 AM
To: Haynes, Dan
Cc: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal



Inline...

On 8/24/2011 4:09 PM, Haynes, Dan wrote:

Hi David,



>Indeed there are instances where the generality required in the independent schema has ultimately failed to exist, but it is still a practice we should strive to avoid.



I agree.



>Along those lines, then, we really need only one behavior -- which is "32-bit".  It is intuitively meaningful on both 32-bit and 64-bit machines -- it signifies some path for a 32-bit object.



That is an interesting proposal, were you thinking something like 32_bit_view="true/false" and if false simply check the native view?  My only concern with that it would be somewhat redundant on a 32-bit system.

Right, that's the idea exactly.  I don't see it as any more redundant than, say ignoring the 32-bit or 64-bit flag on a 32-bit system.





>In fact the text "Ignored on a 32-bit system" is itself confusing -- does it mean to ignore the behavior, or to ignore the object on which the behavior is defined -- meaning that no items should be >created?



I would expect that "ignored on a 32-bit system" would mean that the behavior itself would be ignored and the object would go about its item collection as if the behavior did not exist for that object.  If you ignored the object on which the behavior was defined, you would be breaking all of the content on 32-bit systems since the behavior would be there by default.



You and I know what it means, but a reasonable person reading the statement for the first time might be confused.



>As for modifying the items themselves, it seems to me that if some proprietary means of associating items is being used to bypass the optional object references (e.g., attributes from another >namespace), then that is hardly a problem that the specification itself needs to address.  Since the specification already provides a means of determining the object origins of items, it is not >really necessary (as a function of the specification) to duplicate the object's behavior information in the item itself.



I wouldn't say the proprietary means is a way of bypassing the optional object references, but rather, just another way of doing things.  One thing that I forgot to mention is that another way to implement a system characteristics producer is to in fact use OVAL objects in which you could get that mapping.  To go into the system characteristics producer scenario some more, an organization may have agents on a system that simply collect certain information of interest whether it be registry keys, file hashes, etc. and then send that information of to another system for evaluation against some OVAL definitions.  If a collected_objects section is not available, in this system-characteristics file, the tool performing the evaluation must consider all items in the OVAL system-characteristics (that are of the same type - i.e. registry_object would consider all registry_items) and compare them to the objects specified in the OVAL definitions to see if they match and should be used in the evaluation of the test (there is more on this in Section 5.3.2.4.1 of the spec).  Now if you had an OVAL object that used the windows_view behavior, it would not be able to determine if that item actually matched the object or if it did not exist for that object.  You would need the windows_view entity to make that determination.  As a result, I think we want to support this use case.

I certainly hadn't considered that!  You've convinced me!





Thanks,

Danny



From: David Solin [mailto:[hidden email]] On Behalf Of David Solin
Sent: Wednesday, August 24, 2011 4:00 PM
To: Haynes, Dan
Cc: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal



Ah, you're talking about the Independent schema FileBehaviors.  Unix FileBehaviors deprecates the recurse attribute, and Windows FileBehaviors doesn't have one...

Indeed there are instances where the generality required in the independent schema has ultimately failed to exist, but it is still a practice we should strive to avoid.  Along those lines, then, we really need only one behavior -- which is "32-bit".  It is intuitively meaningful on both 32-bit and 64-bit machines -- it signifies some path for a 32-bit object.  In fact the text "Ignored on a 32-bit system" is itself confusing -- does it mean to ignore the behavior, or to ignore the object on which the behavior is defined -- meaning that no items should be created?

As for modifying the items themselves, it seems to me that if some proprietary means of associating items is being used to bypass the optional object references (e.g., attributes from another namespace), then that is hardly a problem that the specification itself needs to address.  Since the specification already provides a means of determining the object origins of items, it is not really necessary (as a function of the specification) to duplicate the object's behavior information in the item itself.

Anyway, if the rest of the community is really pleased with the proposal, I'll fall in line.

jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More <http://www.joval.org>  | Features <http://www.joval.org/features/>  | Download <http://www.joval.org/download/>


On 8/24/2011 2:03 PM, Haynes, Dan wrote:

Hi David,



>Not only is it ignored on 32-bit, but the scanner is actually supposed to generate results, right?  I mean, the behavior says "64_bit", so you'd think intuitively that on a 32-bit machine it just >shouldn't generate any results at all.

>

>If you're generating results, then my opinion is that it can be said to "apply".  The name of the behavior should describe the expected results.



Yes, the scanner would be expected to generate results.  I would agree that this it is somewhat counter-intuitive if you were to just look at the content without the full context of how the behavior is meant to work.  That is, if you consider that same content in the context of the behavior only applying to 64-bit Windows operating systems it doesn't seem so confusing (at least to me) as the documentation states that the behavior must be ignored as if it wasn't even there (implicitly or explicitly).  I understand this is not the most elegant solution, but, we have similar restrictions on the use of behaviors today in the OVAL Language so I wouldn't think that this is that far off.  For example, the 'recurse' behavior in the ind-def:FileBehaviors states:

"'recurse' defines...Also note that this behavior does not apply to Windows systems since they do not support symbolic links. On Windows systems the 'recurse' behavior is always equivalent to directories."




Here it is not only saying the behavior value doesn't apply, but, that it must be interpreted as something else.



If you were to use "native" instead of "64_bit", I would anticipate that would mean that this behavior would now apply to 32-bit Windows operating systems along with 64-bit Windows operating systems?  Do you think there would be any confusion between which value a content author should use since "native" and "32_bit" are the same thing in the context of a 32-bit Windows operating system?



>I'm just saying that there is already a way to distinguish, which is by looking at the objects with which they're associated.  In fact, it's entirely possible that two objects with different behaviors >could both point to the same item, even though there are two different registry values that happen by coincidence to be equal to one-another, and the generated results would be valid and >correct.



While in some cases you can look at the object to distinguish between where an item came from, it will not always work as the collected_object section is optional.  For example, consider the system characteristics producer adoption capability.  It is completely valid for items to be collected using some proprietary process, without the use of objects, as long as it conforms to the oval-system-characteristics-schema.  In this situation, you would not have a collected_objects section in the system characteristics and would not be able to make that distinction.  I think that the windows_view item entity will be need to make that distinction between those items.




Thanks,

Danny



From: David Solin [mailto:[hidden email]] On Behalf Of David Solin
Sent: Wednesday, August 24, 2011 1:16 PM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Cc: Haynes, Dan
Subject: Fwd: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal



Comments below...

jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More <http://www.joval.org>  | Features <http://www.joval.org/features/>  | Download <http://www.joval.org/download/>



On 8/24/2011 9:57 AM, Haynes, Dan wrote:

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?






Not only is it ignored on 32-bit, but the scanner is actually supposed to generate results, right?  I mean, the behavior says "64_bit", so you'd think intuitively that on a 32-bit machine it just shouldn't generate any results at all.





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




If you're generating results, then my opinion is that it can be said to "apply".  The name of the behavior should describe the expected results.





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


I'm just saying that there is already a way to distinguish, which is by looking at the objects with which they're associated.  In fact, it's entirely possible that two objects with different behaviors could both point to the same item, even though there are two different registry values that happen by coincidence to be equal to one-another, and the generated results would be valid and correct.







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 <http://www.joval.org>  | Features <http://www.joval.org/features/>  | Download <http://www.joval.org/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 [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" <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].

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

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
Actually I liked Ken's suggestion too.  The idea is that the default behavior should be to look at the Registry or Filesystem as a native application would.  "view=32-bit" would in actuality only apply to 64-bit systems, however even though the behavior would technically be ignored on a 32-bit Windows machine, one could indeed expect (and be correct) that the indicated path would be inspected on a 32-bit Windows machine as well.

Setting the flag I propose lets the content developer say, simply, "This test is for a 32-bit application".  It would be valid for testing that 32-bit application on both 32- and 64-bit machines.  What becomes somewhat complicated, however, is the testing of OS file versions.  We know that a given native path for a system DLL should have different versions in 32-bit and 64-bit Windows.  This would be expressed using different tests, and different states, but potentially the same object, in conjunction with other tests that determine the "bitness" of the machine.  I think the "best practice" for testing the 32-bit OS emulation libraries would be to access them using the native path (and not using the redirection flag), with the same best practice for OS registry keys.

If we use this flag to signify applicability of the object, as Gunnar suggests doing for only the native 64-bit view, I think it is problematic because then it's not actually defining a behavior (at least, not in my mind).

However, I'm also beginning to wish I'd just kept quiet and just let the content developers have their way (whatever it might be).

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



On 8/25/2011 10:15 AM, [hidden email] wrote:
I would point out, however, that with a name like 32_bit_view and using a boolean value,
we do lose the option of easily extending this should the occasion ever arise.
I'm OK with that. I had considered this approach a while ago, but never suggested it because the community seemed to want generic terms.

Alternatively, David, would last approach I posted be acceptable with a bit more clarification
in the documentation regarding what it means to ignore the behavior?  (To be specific, I'm referring to the
'windows_view' behavior with the values of 32_bit & 64_bit only.)
Honestly, I do like the 'windows_view' name slightly better, but I'm not going to put up a fight against the other approach. Any approach that has two values, and the default is that no redirection occurs is fine with me.

Ken

-----Original Message-----
From: Hansbury, Matt [[hidden email]]
Sent: Thursday, August 25, 2011 9:54 AM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal

Ken/David,

I agree that this solution would work as well.  I would point out, however, that with a name like 32_bit_view and using a boolean value, we do lose the option of easily extending this should the occasion ever arise.

Are we OK with that?

Alternatively, David, would last approach I posted be acceptable with a bit more clarification in the documentation regarding what it means to ignore the behavior?  (To be specific, I'm referring to the 'windows_view' behavior with the values of 32_bit & 64_bit only.)

Are there others out there with thoughts on this?  Either for or against?

Thanks
Matt

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

If we go this route, I propose it look something like this:



Behavior name: 32_bit_view

Description: This behavior affects which file system or registry view is examined on 64bit versions of Windows. This behavior has no effect on other operating systems.

Values: A setting of 'true' directs the probe to examine the 32bit view. A setting of 'false' directs the probe to examine the native, 64bit view.

Default: 'false'



I think you have to keep the concept of "ignored everywhere except on 64bit windows" - because what does a setting of 'false' mean when on a 32bit version of Windows?



Ken



From: Haynes, Dan [[hidden email]]
Sent: Thursday, August 25, 2011 9:21 AM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal



Were you thinking for a default value 'true'?  If you had a default value of 'false', what would be expected to happen there?



You raise a good point about the confusion around what it means to ignore the behavior.  We will need to add some more documentation explaining what "ignore the behavior" means to further clarify how it should work.



Thanks,

Danny



From: David Solin [[hidden email]] On Behalf Of David Solin
Sent: Thursday, August 25, 2011 8:11 AM
To: Haynes, Dan
Cc: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal



Inline...

On 8/24/2011 4:09 PM, Haynes, Dan wrote:

Hi David,



Indeed there are instances where the generality required in the independent schema has ultimately failed to exist, but it is still a practice we should strive to avoid.


I agree.



Along those lines, then, we really need only one behavior -- which is "32-bit".  It is intuitively meaningful on both 32-bit and 64-bit machines -- it signifies some path for a 32-bit object.


That is an interesting proposal, were you thinking something like 32_bit_view="true/false" and if false simply check the native view?  My only concern with that it would be somewhat redundant on a 32-bit system.

Right, that's the idea exactly.  I don't see it as any more redundant than, say ignoring the 32-bit or 64-bit flag on a 32-bit system.





In fact the text "Ignored on a 32-bit system" is itself confusing -- does it mean to ignore the behavior, or to ignore the object on which the behavior is defined -- meaning that no items should be >created?


I would expect that "ignored on a 32-bit system" would mean that the behavior itself would be ignored and the object would go about its item collection as if the behavior did not exist for that object.  If you ignored the object on which the behavior was defined, you would be breaking all of the content on 32-bit systems since the behavior would be there by default.



You and I know what it means, but a reasonable person reading the statement for the first time might be confused.



As for modifying the items themselves, it seems to me that if some proprietary means of associating items is being used to bypass the optional object references (e.g., attributes from another >namespace), then that is hardly a problem that the specification itself needs to address.  Since the specification already provides a means of determining the object origins of items, it is not >really necessary (as a function of the specification) to duplicate the object's behavior information in the item itself.


I wouldn't say the proprietary means is a way of bypassing the optional object references, but rather, just another way of doing things.  One thing that I forgot to mention is that another way to implement a system characteristics producer is to in fact use OVAL objects in which you could get that mapping.  To go into the system characteristics producer scenario some more, an organization may have agents on a system that simply collect certain information of interest whether it be registry keys, file hashes, etc. and then send that information of to another system for evaluation against some OVAL definitions.  If a collected_objects section is not available, in this system-characteristics file, the tool performing the evaluation must consider all items in the OVAL system-characteristics (that are of the same type - i.e. registry_object would consider all registry_items) and compare them to the objects specified in the OVAL definitions to see if they match and should be used 
in the evaluation of the test (there is more on this in Section 5.3.2.4.1 of the spec).  Now if you had an OVAL object that used the windows_view behavior, it would not be able to determine if that item actually matched the object or if it did not exist for that object.  You would need the windows_view entity to make that determination.  As a result, I think we want to support this use case.

I certainly hadn't considered that!  You've convinced me!





Thanks,

Danny



From: David Solin [[hidden email]] On Behalf Of David Solin
Sent: Wednesday, August 24, 2011 4:00 PM
To: Haynes, Dan
Cc: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal



Ah, you're talking about the Independent schema FileBehaviors.  Unix FileBehaviors deprecates the recurse attribute, and Windows FileBehaviors doesn't have one...

Indeed there are instances where the generality required in the independent schema has ultimately failed to exist, but it is still a practice we should strive to avoid.  Along those lines, then, we really need only one behavior -- which is "32-bit".  It is intuitively meaningful on both 32-bit and 64-bit machines -- it signifies some path for a 32-bit object.  In fact the text "Ignored on a 32-bit system" is itself confusing -- does it mean to ignore the behavior, or to ignore the object on which the behavior is defined -- meaning that no items should be created?

As for modifying the items themselves, it seems to me that if some proprietary means of associating items is being used to bypass the optional object references (e.g., attributes from another namespace), then that is hardly a problem that the specification itself needs to address.  Since the specification already provides a means of determining the object origins of items, it is not really necessary (as a function of the specification) to duplicate the object's behavior information in the item itself.

Anyway, if the rest of the community is really pleased with the proposal, I'll fall in line.

jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More <http://www.joval.org>  | Features <http://www.joval.org/features/>  | Download <http://www.joval.org/download/>


On 8/24/2011 2:03 PM, Haynes, Dan wrote:

Hi David,



Not only is it ignored on 32-bit, but the scanner is actually supposed to generate results, right?  I mean, the behavior says "64_bit", so you'd think intuitively that on a 32-bit machine it just >shouldn't generate any results at all.

      

      

      
If you're generating results, then my opinion is that it can be said to "apply".  The name of the behavior should describe the expected results.


Yes, the scanner would be expected to generate results.  I would agree that this it is somewhat counter-intuitive if you were to just look at the content without the full context of how the behavior is meant to work.  That is, if you consider that same content in the context of the behavior only applying to 64-bit Windows operating systems it doesn't seem so confusing (at least to me) as the documentation states that the behavior must be ignored as if it wasn't even there (implicitly or explicitly).  I understand this is not the most elegant solution, but, we have similar restrictions on the use of behaviors today in the OVAL Language so I wouldn't think that this is that far off.  For example, the 'recurse' behavior in the ind-def:FileBehaviors states:

"'recurse' defines...Also note that this behavior does not apply to Windows systems since they do not support symbolic links. On Windows systems the 'recurse' behavior is always equivalent to directories."




Here it is not only saying the behavior value doesn't apply, but, that it must be interpreted as something else.



If you were to use "native" instead of "64_bit", I would anticipate that would mean that this behavior would now apply to 32-bit Windows operating systems along with 64-bit Windows operating systems?  Do you think there would be any confusion between which value a content author should use since "native" and "32_bit" are the same thing in the context of a 32-bit Windows operating system?



I'm just saying that there is already a way to distinguish, which is by looking at the objects with which they're associated.  In fact, it's entirely possible that two objects with different behaviors >could both point to the same item, even though there are two different registry values that happen by coincidence to be equal to one-another, and the generated results would be valid and >correct.


While in some cases you can look at the object to distinguish between where an item came from, it will not always work as the collected_object section is optional.  For example, consider the system characteristics producer adoption capability.  It is completely valid for items to be collected using some proprietary process, without the use of objects, as long as it conforms to the oval-system-characteristics-schema.  In this situation, you would not have a collected_objects section in the system characteristics and would not be able to make that distinction.  I think that the windows_view item entity will be need to make that distinction between those items.




Thanks,

Danny



From: David Solin [[hidden email]] On Behalf Of David Solin
Sent: Wednesday, August 24, 2011 1:16 PM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Cc: Haynes, Dan
Subject: Fwd: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal



Comments below...

jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More <http://www.joval.org>  | Features <http://www.joval.org/features/>  | Download <http://www.joval.org/download/>



On 8/24/2011 9:57 AM, Haynes, Dan wrote:

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?






Not only is it ignored on 32-bit, but the scanner is actually supposed to generate results, right?  I mean, the behavior says "64_bit", so you'd think intuitively that on a 32-bit machine it just shouldn't generate any results at all.





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.




If you're generating results, then my opinion is that it can be said to "apply".  The name of the behavior should describe the expected results.





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.


I'm just saying that there is already a way to distinguish, which is by looking at the objects with which they're associated.  In fact, it's entirely possible that two objects with different behaviors could both point to the same item, even though there are two different registry values that happen by coincidence to be equal to one-another, and the generated results would be valid and correct.







Thanks,

Danny



From: David Solin [[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 <http://www.joval.org>  | Features <http://www.joval.org/features/>  | Download <http://www.joval.org/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" <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].

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

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

Gunnar Engelbach
On 8/25/2011 11:41 AM, David Solin wrote:

> Actually I liked Ken's suggestion too. The idea is that the default
> behavior should be to look at the Registry or Filesystem as a native
> application would. "view=32-bit" would in actuality only apply to 64-bit
> systems, however even though the behavior would technically be ignored
> on a 32-bit Windows machine, one could indeed expect (and be correct)
> that the indicated path would be inspected on a 32-bit Windows machine
> as well.
>
> Setting the flag I propose lets the content developer say, simply, "This
> test is for a 32-bit application". It would be valid for testing that
> 32-bit application on both 32- and 64-bit machines. What becomes
> somewhat complicated, however, is the testing of OS file versions. We
> know that a given /native/ path for a system DLL should have different
> versions in 32-bit and 64-bit Windows. This would be expressed using
> different tests, and different states, but potentially the same object,
> in conjunction with other tests that determine the "bitness" of the
> machine. I think the "best practice" for testing the 32-bit OS emulation
> libraries would be to access them using the native path (and not using
> the redirection flag), with the same best practice for OS registry keys.
>
> If we use this flag to signify applicability of the object, as Gunnar
> suggests doing for only the native 64-bit view, I think it is
> problematic because then it's not actually defining a behavior (at
> least, not in my mind).

Not quite what I said, but never mind.

To throw another sabot into the gears, consider this:

   http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0232

That is, a vulnerability on the 16-bit subsystem of 32-bit OSs that does
not exist on 64-bit systems.



>
> However, I'm also beginning to wish I'd just kept quiet and just let the
> content developers have their way (whatever it might be).
>
> jOVAL.org: OVAL implemented in Java.
> /Scan any machine from any machine. For free!/
> Learn More <http://www.joval.org> | Features
> <http://www.joval.org/features/> | Download
> <http://www.joval.org/download/>
>
>
>
> On 8/25/2011 10:15 AM, [hidden email] wrote:
>>>> I would point out, however, that with a name like 32_bit_view and using a boolean value,
>>>> we do lose the option of easily extending this should the occasion ever arise.
>> I'm OK with that. I had considered this approach a while ago, but never suggested it because the community seemed to want generic terms.
>>
>>>> Alternatively, David, would last approach I posted be acceptable with a bit more clarification
>>>> in the documentation regarding what it means to ignore the behavior?  (To be specific, I'm referring to the
>>>> 'windows_view' behavior with the values of 32_bit&  64_bit only.)
>> Honestly, I do like the 'windows_view' name slightly better, but I'm not going to put up a fight against the other approach. Any approach that has two values, and the default is that no redirection occurs is fine with me.
>>
>> Ken
>>
>> -----Original Message-----
>> From: Hansbury, Matt [mailto:[hidden email]]
>> Sent: Thursday, August 25, 2011 9:54 AM
>> To:[hidden email]
>> Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal
>>
>> Ken/David,
>>
>> I agree that this solution would work as well.  I would point out, however, that with a name like 32_bit_view and using a boolean value, we do lose the option of easily extending this should the occasion ever arise.
>>
>> Are we OK with that?
>>
>> Alternatively, David, would last approach I posted be acceptable with a bit more clarification in the documentation regarding what it means to ignore the behavior?  (To be specific, I'm referring to the 'windows_view' behavior with the values of 32_bit&  64_bit only.)
>>
>> Are there others out there with thoughts on this?  Either for or against?
>>
>> Thanks
>> Matt
>>
>> -----Original Message-----
>> From:[hidden email]  [mailto:[hidden email]]
>> Sent: Thursday, August 25, 2011 10:34 AM
>> To: oval-developer-list OVAL Developer List/Closed Public Discussion
>> Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal
>>
>> If we go this route, I propose it look something like this:
>>
>>
>>
>> Behavior name: 32_bit_view
>>
>> Description: This behavior affects which file system or registry view is examined on 64bit versions of Windows. This behavior has no effect on other operating systems.
>>
>> Values: A setting of 'true' directs the probe to examine the 32bit view. A setting of 'false' directs the probe to examine the native, 64bit view.
>>
>> Default: 'false'
>>
>>
>>
>> I think you have to keep the concept of "ignored everywhere except on 64bit windows" - because what does a setting of 'false' mean when on a 32bit version of Windows?
>>
>>
>>
>> Ken
>>
>>
>>
>> From: Haynes, Dan [mailto:[hidden email]]
>> Sent: Thursday, August 25, 2011 9:21 AM
>> To:[hidden email]
>> Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal
>>
>>
>>
>> Were you thinking for a default value 'true'?  If you had a default value of 'false', what would be expected to happen there?
>>
>>
>>
>> You raise a good point about the confusion around what it means to ignore the behavior.  We will need to add some more documentation explaining what "ignore the behavior" means to further clarify how it should work.
>>
>>
>>
>> Thanks,
>>
>> Danny
>>
>>
>>
>> From: David Solin [mailto:[hidden email]] On Behalf Of David Solin
>> Sent: Thursday, August 25, 2011 8:11 AM
>> To: Haynes, Dan
>> Cc: oval-developer-list OVAL Developer List/Closed Public Discussion
>> Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal
>>
>>
>>
>> Inline...
>>
>> On 8/24/2011 4:09 PM, Haynes, Dan wrote:
>>
>> Hi David,
>>
>>
>>
>>> Indeed there are instances where the generality required in the independent schema has ultimately failed to exist, but it is still a practice we should strive to avoid.
>>
>>
>> I agree.
>>
>>
>>
>>> Along those lines, then, we really need only one behavior -- which is "32-bit".  It is intuitively meaningful on both 32-bit and 64-bit machines -- it signifies some path for a 32-bit object.
>>
>>
>> That is an interesting proposal, were you thinking something like 32_bit_view="true/false" and if false simply check the native view?  My only concern with that it would be somewhat redundant on a 32-bit system.
>>
>> Right, that's the idea exactly.  I don't see it as any more redundant than, say ignoring the 32-bit or 64-bit flag on a 32-bit system.
>>
>>
>>
>>
>>
>>> In fact the text "Ignored on a 32-bit system" is itself confusing -- does it mean to ignore the behavior, or to ignore the object on which the behavior is defined -- meaning that no items should be>created?
>>
>>
>> I would expect that "ignored on a 32-bit system" would mean that the behavior itself would be ignored and the object would go about its item collection as if the behavior did not exist for that object.  If you ignored the object on which the behavior was defined, you would be breaking all of the content on 32-bit systems since the behavior would be there by default.
>>
>>
>>
>> You and I know what it means, but a reasonable person reading the statement for the first time might be confused.
>>
>>
>>
>>> As for modifying the items themselves, it seems to me that if some proprietary means of associating items is being used to bypass the optional object references (e.g., attributes from another>namespace), then that is hardly a problem that the specification itself needs to address.  Since the specification already provides a means of determining the object origins of items, it is not>really necessary (as a function of the specification) to duplicate the object's behavior information in the item itself.
>>
>>
>> I wouldn't say the proprietary means is a way of bypassing the optional object references, but rather, just another way of doing things.  One thing that I forgot to mention is that another way to implement a system characteristics producer is to in fact use OVAL objects in which you could get that mapping.  To go into the system characteristics producer scenario some more, an organization may have agents on a system that simply collect certain information of interest whether it be registry keys, file hashes, etc. and then send that information of to another system for evaluation against some OVAL definitions.  If a collected_objects section is not available, in this system-characteristics file, the tool performing the evaluation must consider all items in the OVAL system-characteristics (that are of the same type - i.e. registry_object would consider all registry_items) and compare them to the objects specified in the OVAL definitions to see if they match and should be us
ed

>> in the evaluation of the test (there is more on this in Section 5.3.2.4.1 of the spec).  Now if you had an OVAL object that used the windows_view behavior, it would not be able to determine if that item actually matched the object or if it did not exist for that object.  You would need the windows_view entity to make that determination.  As a result, I think we want to support this use case.
>>
>> I certainly hadn't considered that!  You've convinced me!
>>
>>
>>
>>
>>
>> Thanks,
>>
>> Danny
>>
>>
>>
>> From: David Solin [mailto:[hidden email]] On Behalf Of David Solin
>> Sent: Wednesday, August 24, 2011 4:00 PM
>> To: Haynes, Dan
>> Cc: oval-developer-list OVAL Developer List/Closed Public Discussion
>> Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal
>>
>>
>>
>> Ah, you're talking about the Independent schema FileBehaviors.  Unix FileBehaviors deprecates the recurse attribute, and Windows FileBehaviors doesn't have one...
>>
>> Indeed there are instances where the generality required in the independent schema has ultimately failed to exist, but it is still a practice we should strive to avoid.  Along those lines, then, we really need only one behavior -- which is "32-bit".  It is intuitively meaningful on both 32-bit and 64-bit machines -- it signifies some path for a 32-bit object.  In fact the text "Ignored on a 32-bit system" is itself confusing -- does it mean to ignore the behavior, or to ignore the object on which the behavior is defined -- meaning that no items should be created?
>>
>> As for modifying the items themselves, it seems to me that if some proprietary means of associating items is being used to bypass the optional object references (e.g., attributes from another namespace), then that is hardly a problem that the specification itself needs to address.  Since the specification already provides a means of determining the object origins of items, it is not really necessary (as a function of the specification) to duplicate the object's behavior information in the item itself.
>>
>> Anyway, if the rest of the community is really pleased with the proposal, I'll fall in line.
>>
>> jOVAL.org: OVAL implemented in Java.
>> Scan any machine from any machine. For free!
>> Learn More<http://www.joval.org>   | Features<http://www.joval.org/features/>   | Download<http://www.joval.org/download/>
>>
>>
>> On 8/24/2011 2:03 PM, Haynes, Dan wrote:
>>
>> Hi David,
>>
>>
>>
>>> Not only is it ignored on 32-bit, but the scanner is actually supposed to generate results, right?  I mean, the behavior says "64_bit", so you'd think intuitively that on a 32-bit machine it just>shouldn't generate any results at all.
>>> If you're generating results, then my opinion is that it can be said to "apply".  The name of the behavior should describe the expected results.
>>
>>
>> Yes, the scanner would be expected to generate results.  I would agree that this it is somewhat counter-intuitive if you were to just look at the content without the full context of how the behavior is meant to work.  That is, if you consider that same content in the context of the behavior only applying to 64-bit Windows operating systems it doesn't seem so confusing (at least to me) as the documentation states that the behavior must be ignored as if it wasn't even there (implicitly or explicitly).  I understand this is not the most elegant solution, but, we have similar restrictions on the use of behaviors today in the OVAL Language so I wouldn't think that this is that far off.  For example, the 'recurse' behavior in the ind-def:FileBehaviors states:
>>
>> "'recurse' defines...Also note that this behavior does not apply to Windows systems since they do not support symbolic links. On Windows systems the 'recurse' behavior is always equivalent to directories."
>>
>>
>>
>>
>> Here it is not only saying the behavior value doesn't apply, but, that it must be interpreted as something else.
>>
>>
>>
>> If you were to use "native" instead of "64_bit", I would anticipate that would mean that this behavior would now apply to 32-bit Windows operating systems along with 64-bit Windows operating systems?  Do you think there would be any confusion between which value a content author should use since "native" and "32_bit" are the same thing in the context of a 32-bit Windows operating system?
>>
>>
>>
>>> I'm just saying that there is already a way to distinguish, which is by looking at the objects with which they're associated.  In fact, it's entirely possible that two objects with different behaviors>could both point to the same item, even though there are two different registry values that happen by coincidence to be equal to one-another, and the generated results would be valid and>correct.
>>
>>
>> While in some cases you can look at the object to distinguish between where an item came from, it will not always work as the collected_object section is optional.  For example, consider the system characteristics producer adoption capability.  It is completely valid for items to be collected using some proprietary process, without the use of objects, as long as it conforms to the oval-system-characteristics-schema.  In this situation, you would not have a collected_objects section in the system characteristics and would not be able to make that distinction.  I think that the windows_view item entity will be need to make that distinction between those items.
>>
>>
>>
>>
>> Thanks,
>>
>> Danny
>>
>>
>>
>> From: David Solin [mailto:[hidden email]] On Behalf Of David Solin
>> Sent: Wednesday, August 24, 2011 1:16 PM
>> To: oval-developer-list OVAL Developer List/Closed Public Discussion
>> Cc: Haynes, Dan
>> Subject: Fwd: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal
>>
>>
>>
>> Comments below...
>>
>> jOVAL.org: OVAL implemented in Java.
>> Scan any machine from any machine. For free!
>> Learn More<http://www.joval.org>   | Features<http://www.joval.org/features/>   | Download<http://www.joval.org/download/>
>>
>>
>>
>> On 8/24/2011 9:57 AM, Haynes, Dan wrote:
>>
>> 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?
>>
>>
>>
>>
>>
>>
>> Not only is it ignored on 32-bit, but the scanner is actually supposed to generate results, right?  I mean, the behavior says "64_bit", so you'd think intuitively that on a 32-bit machine it just shouldn't generate any results at all.
>>
>>
>>
>>
>>
>>> 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.
>>
>>
>>
>>
>> If you're generating results, then my opinion is that it can be said to "apply".  The name of the behavior should describe the expected results.
>>
>>
>>
>>
>>
>>> 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.
>>
>>
>> I'm just saying that there is already a way to distinguish, which is by looking at the objects with which they're associated.  In fact, it's entirely possible that two objects with different behaviors could both point to the same item, even though there are two different registry values that happen by coincidence to be equal to one-another, and the generated results would be valid and correct.
>>
>>
>>
>>
>>
>>
>>
>> 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<http://www.joval.org>   | Features<http://www.joval.org/features/>   | Download<http://www.joval.org/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 [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"  <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
>>                                  [hidden email]
>>
>>                                  To unsubscribe, send an email message [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 [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 [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 [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 [hidden email]  with
>>          SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message.  If you have
>>          difficulties, write [hidden email].
>>
>>          To unsubscribe, send an email message [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 [hidden email]  with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message.  If you have difficulties, write [hidden email].
>>
>> To unsubscribe, send an email message [hidden email]  with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message.  If you have difficulties, write [hidden email].
>>
>> To unsubscribe, send an email message [hidden email]  with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write [hidden email].
>>
>> To unsubscribe, send an email message [hidden email]  with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write [hidden email].
>>
>> To unsubscribe, send an email message [hidden email]  with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write [hidden email].
>>
>> To unsubscribe, send an email message [hidden email]  with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write [hidden email].
>>
>> To unsubscribe, send an email message [hidden email]  with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message.  If you have difficulties, write [hidden email].
>>
>> To unsubscribe, send an email message [hidden email]  with
>> SIGNOFF OVAL-DEVELOPER-LIST
>> in the BODY of the message.  If you have difficulties, write [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

Danny Haynes
Administrator
In reply to this post by joval

I am wondering if this 32_bit_view behavior would bring us back down that road of ambiguity that made us decide not to go with the os_redirection={none,32_bit} proposal.  If we were to move to something like this behavior, anytime the value is “false”, it would essentially mean check the native view on a system.  This means that content authors would not be able to just look at the content and know that it applies to, but rather, they would need to know what system the content was going to be run on.

 

Thanks,

Danny

 

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

 

Actually I liked Ken's suggestion too.  The idea is that the default behavior should be to look at the Registry or Filesystem as a native application would.  "view=32-bit" would in actuality only apply to 64-bit systems, however even though the behavior would technically be ignored on a 32-bit Windows machine, one could indeed expect (and be correct) that the indicated path would be inspected on a 32-bit Windows machine as well.

Setting the flag I propose lets the content developer say, simply, "This test is for a 32-bit application".  It would be valid for testing that 32-bit application on both 32- and 64-bit machines.  What becomes somewhat complicated, however, is the testing of OS file versions.  We know that a given native path for a system DLL should have different versions in 32-bit and 64-bit Windows.  This would be expressed using different tests, and different states, but potentially the same object, in conjunction with other tests that determine the "bitness" of the machine.  I think the "best practice" for testing the 32-bit OS emulation libraries would be to access them using the native path (and not using the redirection flag), with the same best practice for OS registry keys.

If we use this flag to signify applicability of the object, as Gunnar suggests doing for only the native 64-bit view, I think it is problematic because then it's not actually defining a behavior (at least, not in my mind).

However, I'm also beginning to wish I'd just kept quiet and just let the content developers have their way (whatever it might be).

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



On 8/25/2011 10:15 AM, [hidden email] wrote:

I would point out, however, that with a name like 32_bit_view and using a boolean value,
we do lose the option of easily extending this should the occasion ever arise.
 
I'm OK with that. I had considered this approach a while ago, but never suggested it because the community seemed to want generic terms.
 
Alternatively, David, would last approach I posted be acceptable with a bit more clarification
in the documentation regarding what it means to ignore the behavior?  (To be specific, I'm referring to the
'windows_view' behavior with the values of 32_bit & 64_bit only.)
 
Honestly, I do like the 'windows_view' name slightly better, but I'm not going to put up a fight against the other approach. Any approach that has two values, and the default is that no redirection occurs is fine with me.
 
Ken
 
-----Original Message-----
From: Hansbury, Matt [[hidden email]]
Sent: Thursday, August 25, 2011 9:54 AM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal
 
Ken/David,
 
I agree that this solution would work as well.  I would point out, however, that with a name like 32_bit_view and using a boolean value, we do lose the option of easily extending this should the occasion ever arise.
 
Are we OK with that?
 
Alternatively, David, would last approach I posted be acceptable with a bit more clarification in the documentation regarding what it means to ignore the behavior?  (To be specific, I'm referring to the 'windows_view' behavior with the values of 32_bit & 64_bit only.)
 
Are there others out there with thoughts on this?  Either for or against?
 
Thanks
Matt
 
-----Original Message-----
From: [hidden email] [[hidden email]]
Sent: Thursday, August 25, 2011 10:34 AM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal
 
If we go this route, I propose it look something like this:
 
 
 
Behavior name: 32_bit_view
 
Description: This behavior affects which file system or registry view is examined on 64bit versions of Windows. This behavior has no effect on other operating systems.
 
Values: A setting of 'true' directs the probe to examine the 32bit view. A setting of 'false' directs the probe to examine the native, 64bit view.
 
Default: 'false'
 
 
 
I think you have to keep the concept of "ignored everywhere except on 64bit windows" - because what does a setting of 'false' mean when on a 32bit version of Windows?
 
 
 
Ken
 
 
 
From: Haynes, Dan [[hidden email]]
Sent: Thursday, August 25, 2011 9:21 AM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal
 
 
 
Were you thinking for a default value 'true'?  If you had a default value of 'false', what would be expected to happen there?
 
 
 
You raise a good point about the confusion around what it means to ignore the behavior.  We will need to add some more documentation explaining what "ignore the behavior" means to further clarify how it should work.
 
 
 
Thanks,
 
Danny
 
 
 
From: David Solin [[hidden email]] On Behalf Of David Solin
Sent: Thursday, August 25, 2011 8:11 AM
To: Haynes, Dan
Cc: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal
 
 
 
Inline...
 
On 8/24/2011 4:09 PM, Haynes, Dan wrote:
 
Hi David,
 
 
 
Indeed there are instances where the generality required in the independent schema has ultimately failed to exist, but it is still a practice we should strive to avoid.
 
 
 
I agree.
 
 
 
Along those lines, then, we really need only one behavior -- which is "32-bit".  It is intuitively meaningful on both 32-bit and 64-bit machines -- it signifies some path for a 32-bit object.
 
 
 
That is an interesting proposal, were you thinking something like 32_bit_view="true/false" and if false simply check the native view?  My only concern with that it would be somewhat redundant on a 32-bit system.
 
Right, that's the idea exactly.  I don't see it as any more redundant than, say ignoring the 32-bit or 64-bit flag on a 32-bit system.
 
 
 
 
 
In fact the text "Ignored on a 32-bit system" is itself confusing -- does it mean to ignore the behavior, or to ignore the object on which the behavior is defined -- meaning that no items should be >created?
 
 
 
I would expect that "ignored on a 32-bit system" would mean that the behavior itself would be ignored and the object would go about its item collection as if the behavior did not exist for that object.  If you ignored the object on which the behavior was defined, you would be breaking all of the content on 32-bit systems since the behavior would be there by default.
 
 
 
You and I know what it means, but a reasonable person reading the statement for the first time might be confused.
 
 
 
As for modifying the items themselves, it seems to me that if some proprietary means of associating items is being used to bypass the optional object references (e.g., attributes from another >namespace), then that is hardly a problem that the specification itself needs to address.  Since the specification already provides a means of determining the object origins of items, it is not >really necessary (as a function of the specification) to duplicate the object's behavior information in the item itself.
 
 
 
I wouldn't say the proprietary means is a way of bypassing the optional object references, but rather, just another way of doing things.  One thing that I forgot to mention is that another way to implement a system characteristics producer is to in fact use OVAL objects in which you could get that mapping.  To go into the system characteristics producer scenario some more, an organization may have agents on a system that simply collect certain information of interest whether it be registry keys, file hashes, etc. and then send that information of to another system for evaluation against some OVAL definitions.  If a collected_objects section is not available, in this system-characteristics file, the tool performing the evaluation must consider all items in the OVAL system-characteristics (that are of the same type - i.e. registry_object would consider all registry_items) and compare them to the objects specified in the OVAL definitions to see if they match and should be used 
in the evaluation of the test (there is more on this in Section 5.3.2.4.1 of the spec).  Now if you had an OVAL object that used the windows_view behavior, it would not be able to determine if that item actually matched the object or if it did not exist for that object.  You would need the windows_view entity to make that determination.  As a result, I think we want to support this use case.
 
I certainly hadn't considered that!  You've convinced me!
 
 
 
 
 
Thanks,
 
Danny
 
 
 
From: David Solin [[hidden email]] On Behalf Of David Solin
Sent: Wednesday, August 24, 2011 4:00 PM
To: Haynes, Dan
Cc: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal
 
 
 
Ah, you're talking about the Independent schema FileBehaviors.  Unix FileBehaviors deprecates the recurse attribute, and Windows FileBehaviors doesn't have one...
 
Indeed there are instances where the generality required in the independent schema has ultimately failed to exist, but it is still a practice we should strive to avoid.  Along those lines, then, we really need only one behavior -- which is "32-bit".  It is intuitively meaningful on both 32-bit and 64-bit machines -- it signifies some path for a 32-bit object.  In fact the text "Ignored on a 32-bit system" is itself confusing -- does it mean to ignore the behavior, or to ignore the object on which the behavior is defined -- meaning that no items should be created?
 
As for modifying the items themselves, it seems to me that if some proprietary means of associating items is being used to bypass the optional object references (e.g., attributes from another namespace), then that is hardly a problem that the specification itself needs to address.  Since the specification already provides a means of determining the object origins of items, it is not really necessary (as a function of the specification) to duplicate the object's behavior information in the item itself.
 
Anyway, if the rest of the community is really pleased with the proposal, I'll fall in line.
 
jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More <http://www.joval.org>  | Features <http://www.joval.org/features/>  | Download <http://www.joval.org/download/>
 
 
On 8/24/2011 2:03 PM, Haynes, Dan wrote:
 
Hi David,
 
 
 
Not only is it ignored on 32-bit, but the scanner is actually supposed to generate results, right?  I mean, the behavior says "64_bit", so you'd think intuitively that on a 32-bit machine it just >shouldn't generate any results at all.
 
 
 
If you're generating results, then my opinion is that it can be said to "apply".  The name of the behavior should describe the expected results.
 
 
 
Yes, the scanner would be expected to generate results.  I would agree that this it is somewhat counter-intuitive if you were to just look at the content without the full context of how the behavior is meant to work.  That is, if you consider that same content in the context of the behavior only applying to 64-bit Windows operating systems it doesn't seem so confusing (at least to me) as the documentation states that the behavior must be ignored as if it wasn't even there (implicitly or explicitly).  I understand this is not the most elegant solution, but, we have similar restrictions on the use of behaviors today in the OVAL Language so I wouldn't think that this is that far off.  For example, the 'recurse' behavior in the ind-def:FileBehaviors states:
 
"'recurse' defines...Also note that this behavior does not apply to Windows systems since they do not support symbolic links. On Windows systems the 'recurse' behavior is always equivalent to directories."
 
 
 
 
Here it is not only saying the behavior value doesn't apply, but, that it must be interpreted as something else.
 
 
 
If you were to use "native" instead of "64_bit", I would anticipate that would mean that this behavior would now apply to 32-bit Windows operating systems along with 64-bit Windows operating systems?  Do you think there would be any confusion between which value a content author should use since "native" and "32_bit" are the same thing in the context of a 32-bit Windows operating system?
 
 
 
I'm just saying that there is already a way to distinguish, which is by looking at the objects with which they're associated.  In fact, it's entirely possible that two objects with different behaviors >could both point to the same item, even though there are two different registry values that happen by coincidence to be equal to one-another, and the generated results would be valid and >correct.
 
 
 
While in some cases you can look at the object to distinguish between where an item came from, it will not always work as the collected_object section is optional.  For example, consider the system characteristics producer adoption capability.  It is completely valid for items to be collected using some proprietary process, without the use of objects, as long as it conforms to the oval-system-characteristics-schema.  In this situation, you would not have a collected_objects section in the system characteristics and would not be able to make that distinction.  I think that the windows_view item entity will be need to make that distinction between those items.
 
 
 
 
Thanks,
 
Danny
 
 
 
From: David Solin [[hidden email]] On Behalf Of David Solin
Sent: Wednesday, August 24, 2011 1:16 PM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Cc: Haynes, Dan
Subject: Fwd: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal
 
 
 
Comments below...
 
jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More <http://www.joval.org>  | Features <http://www.joval.org/features/>  | Download <http://www.joval.org/download/>
 
 
 
On 8/24/2011 9:57 AM, Haynes, Dan wrote:
 
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?
 
 
 
 
 
 
Not only is it ignored on 32-bit, but the scanner is actually supposed to generate results, right?  I mean, the behavior says "64_bit", so you'd think intuitively that on a 32-bit machine it just shouldn't generate any results at all.
 
 
 
 
 
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.
 
 
 
 
If you're generating results, then my opinion is that it can be said to "apply".  The name of the behavior should describe the expected results.
 
 
 
 
 
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.
 
 
I'm just saying that there is already a way to distinguish, which is by looking at the objects with which they're associated.  In fact, it's entirely possible that two objects with different behaviors could both point to the same item, even though there are two different registry values that happen by coincidence to be equal to one-another, and the generated results would be valid and correct.
 
 
 
 
 
 
 
Thanks,
 
Danny
 
 
 
From: David Solin [[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 <http://www.joval.org>  | Features <http://www.joval.org/features/>  | Download <http://www.joval.org/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" <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].
 
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].

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

KenSimone

From my understanding, the two approaches are identical, and only the terminology has changed. They carry the same set of baggage. I slightly prefer this (unchanged from when it was posted it earlier):

 

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

 

But like I said, I’m not too concerned about the terminology. Either is fine with me.

 

Ken

 

From: Haynes, Dan [mailto:[hidden email]]
Sent: Thursday, August 25, 2011 12:52 PM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal

 

I am wondering if this 32_bit_view behavior would bring us back down that road of ambiguity that made us decide not to go with the os_redirection={none,32_bit} proposal.  If we were to move to something like this behavior, anytime the value is “false”, it would essentially mean check the native view on a system.  This means that content authors would not be able to just look at the content and know that it applies to, but rather, they would need to know what system the content was going to be run on.

 

Thanks,

Danny

 

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

 

Actually I liked Ken's suggestion too.  The idea is that the default behavior should be to look at the Registry or Filesystem as a native application would.  "view=32-bit" would in actuality only apply to 64-bit systems, however even though the behavior would technically be ignored on a 32-bit Windows machine, one could indeed expect (and be correct) that the indicated path would be inspected on a 32-bit Windows machine as well.

Setting the flag I propose lets the content developer say, simply, "This test is for a 32-bit application".  It would be valid for testing that 32-bit application on both 32- and 64-bit machines.  What becomes somewhat complicated, however, is the testing of OS file versions.  We know that a given native path for a system DLL should have different versions in 32-bit and 64-bit Windows.  This would be expressed using different tests, and different states, but potentially the same object, in conjunction with other tests that determine the "bitness" of the machine.  I think the "best practice" for testing the 32-bit OS emulation libraries would be to access them using the native path (and not using the redirection flag), with the same best practice for OS registry keys.

If we use this flag to signify applicability of the object, as Gunnar suggests doing for only the native 64-bit view, I think it is problematic because then it's not actually defining a behavior (at least, not in my mind).

However, I'm also beginning to wish I'd just kept quiet and just let the content developers have their way (whatever it might be).

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



On 8/25/2011 10:15 AM, [hidden email] wrote:

I would point out, however, that with a name like 32_bit_view and using a boolean value,
we do lose the option of easily extending this should the occasion ever arise.
 
I'm OK with that. I had considered this approach a while ago, but never suggested it because the community seemed to want generic terms.
 
Alternatively, David, would last approach I posted be acceptable with a bit more clarification
in the documentation regarding what it means to ignore the behavior?  (To be specific, I'm referring to the
'windows_view' behavior with the values of 32_bit & 64_bit only.)
 
Honestly, I do like the 'windows_view' name slightly better, but I'm not going to put up a fight against the other approach. Any approach that has two values, and the default is that no redirection occurs is fine with me.
 
Ken
 
-----Original Message-----
From: Hansbury, Matt [[hidden email]]
Sent: Thursday, August 25, 2011 9:54 AM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal
 
Ken/David,
 
I agree that this solution would work as well.  I would point out, however, that with a name like 32_bit_view and using a boolean value, we do lose the option of easily extending this should the occasion ever arise.
 
Are we OK with that?
 
Alternatively, David, would last approach I posted be acceptable with a bit more clarification in the documentation regarding what it means to ignore the behavior?  (To be specific, I'm referring to the 'windows_view' behavior with the values of 32_bit & 64_bit only.)
 
Are there others out there with thoughts on this?  Either for or against?
 
Thanks
Matt
 
-----Original Message-----
From: [hidden email] [[hidden email]]
Sent: Thursday, August 25, 2011 10:34 AM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal
 
If we go this route, I propose it look something like this:
 
 
 
Behavior name: 32_bit_view
 
Description: This behavior affects which file system or registry view is examined on 64bit versions of Windows. This behavior has no effect on other operating systems.
 
Values: A setting of 'true' directs the probe to examine the 32bit view. A setting of 'false' directs the probe to examine the native, 64bit view.
 
Default: 'false'
 
 
 
I think you have to keep the concept of "ignored everywhere except on 64bit windows" - because what does a setting of 'false' mean when on a 32bit version of Windows?
 
 
 
Ken
 
 
 
From: Haynes, Dan [[hidden email]]
Sent: Thursday, August 25, 2011 9:21 AM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal
 
 
 
Were you thinking for a default value 'true'?  If you had a default value of 'false', what would be expected to happen there?
 
 
 
You raise a good point about the confusion around what it means to ignore the behavior.  We will need to add some more documentation explaining what "ignore the behavior" means to further clarify how it should work.
 
 
 
Thanks,
 
Danny
 
 
 
From: David Solin [[hidden email]] On Behalf Of David Solin
Sent: Thursday, August 25, 2011 8:11 AM
To: Haynes, Dan
Cc: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal
 
 
 
Inline...
 
On 8/24/2011 4:09 PM, Haynes, Dan wrote:
 
Hi David,
 
 
 
Indeed there are instances where the generality required in the independent schema has ultimately failed to exist, but it is still a practice we should strive to avoid.
 
 
 
I agree.
 
 
 
Along those lines, then, we really need only one behavior -- which is "32-bit".  It is intuitively meaningful on both 32-bit and 64-bit machines -- it signifies some path for a 32-bit object.
 
 
 
That is an interesting proposal, were you thinking something like 32_bit_view="true/false" and if false simply check the native view?  My only concern with that it would be somewhat redundant on a 32-bit system.
 
Right, that's the idea exactly.  I don't see it as any more redundant than, say ignoring the 32-bit or 64-bit flag on a 32-bit system.
 
 
 
 
 
In fact the text "Ignored on a 32-bit system" is itself confusing -- does it mean to ignore the behavior, or to ignore the object on which the behavior is defined -- meaning that no items should be >created?
 
 
 
I would expect that "ignored on a 32-bit system" would mean that the behavior itself would be ignored and the object would go about its item collection as if the behavior did not exist for that object.  If you ignored the object on which the behavior was defined, you would be breaking all of the content on 32-bit systems since the behavior would be there by default.
 
 
 
You and I know what it means, but a reasonable person reading the statement for the first time might be confused.
 
 
 
As for modifying the items themselves, it seems to me that if some proprietary means of associating items is being used to bypass the optional object references (e.g., attributes from another >namespace), then that is hardly a problem that the specification itself needs to address.  Since the specification already provides a means of determining the object origins of items, it is not >really necessary (as a function of the specification) to duplicate the object's behavior information in the item itself.
 
 
 
I wouldn't say the proprietary means is a way of bypassing the optional object references, but rather, just another way of doing things.  One thing that I forgot to mention is that another way to implement a system characteristics producer is to in fact use OVAL objects in which you could get that mapping.  To go into the system characteristics producer scenario some more, an organization may have agents on a system that simply collect certain information of interest whether it be registry keys, file hashes, etc. and then send that information of to another system for evaluation against some OVAL definitions.  If a collected_objects section is not available, in this system-characteristics file, the tool performing the evaluation must consider all items in the OVAL system-characteristics (that are of the same type - i.e. registry_object would consider all registry_items) and compare them to the objects specified in the OVAL definitions to see if they match and should be used 
in the evaluation of the test (there is more on this in Section 5.3.2.4.1 of the spec).  Now if you had an OVAL object that used the windows_view behavior, it would not be able to determine if that item actually matched the object or if it did not exist for that object.  You would need the windows_view entity to make that determination.  As a result, I think we want to support this use case.
 
I certainly hadn't considered that!  You've convinced me!
 
 
 
 
 
Thanks,
 
Danny
 
 
 
From: David Solin [[hidden email]] On Behalf Of David Solin
Sent: Wednesday, August 24, 2011 4:00 PM
To: Haynes, Dan
Cc: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: Re: [OVAL-DEVELOPER-LIST] 32/64 bit updated proposal
 
 
 
Ah, you're talking about the Independent schema FileBehaviors.  Unix FileBehaviors deprecates the recurse attribute, and Windows FileBehaviors doesn't have one...
 
Indeed there are instances where the generality required in the independent schema has ultimately failed to exist, but it is still a practice we should strive to avoid.  Along those lines, then, we really need only one behavior -- which is "32-bit".  It is intuitively meaningful on both 32-bit and 64-bit machines -- it signifies some path for a 32-bit object.  In fact the text "Ignored on a 32-bit system" is itself confusing -- does it mean to ignore the behavior, or to ignore the object on which the behavior is defined -- meaning that no items should be created?
 
As for modifying the items themselves, it seems to me that if some proprietary means of associating items is being used to bypass the optional object references (e.g., attributes from another namespace), then that is hardly a problem that the specification itself needs to address.  Since the specification already provides a means of determining the object origins of items, it is not really necessary (as a function of the specification) to duplicate the object's behavior information in the item itself.
 
Anyway, if the rest of the community is really pleased with the proposal, I'll fall in line.
 
jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More <http://www.joval.org>  | Features <http://www.joval.org/features/>  | Download <http://www.joval.org/download/>
 
 
On 8/24/2011 2:03 PM, Haynes, Dan wrote:
 
Hi David,
 
 
 
Not only is it ignored on 32-bit, but the scanner is actually supposed to generate results, right?  I mean, the behavior says "64_bit", so you'd think intuitively that on a 32-bit machine it just >shouldn't generate any results at all.
 
 
 
If you're generating results, then my opinion is that it can be said to "apply".  The name of the behavior should describe the expected results.
 
 
 
Yes, the scanner would be expected to generate results.  I would agree that this it is somewhat counter-intuitive if you were to just look at the content without the full context of how the behavior is meant to work.  That is, if you consider that same content in the context of the behavior only applying to 64-bit Windows operating systems it doesn't seem so confusing (at least to me) as the documentation states that the behavior must be ignored as if it wasn't even there (implicitly or explicitly).  I understand this is not the most elegant solution, but, we have similar restrictions on the use of behaviors today in the OVAL Language so I wouldn't think that this is that far off.  For example, the 'recurse' behavior in the ind-def:FileBehaviors states:
 
"'recurse' defines...Also note that this behavior does not apply to Windows systems since they do not support symbolic links. On Windows systems the 'recurse' behavior is always equivalent to directories."
 
 
 
 
Here it is not only saying the behavior value doesn't apply, but, that it must be interpreted as something else.
 
 
 
If you were to use "native" instead of "64_bit", I would anticipate that would mean that this behavior would now apply to 32-bit Windows operating systems along with 64-bit Windows operating systems?  Do you think there would be any confusion between which value a content author should use since "native" and "32_bit" are the same thing in the context of a 32-bit Windows operating system?
 
 
 
I'm just saying that there is already a way to distinguish, which is by looking at the objects with which they're associated.  In fact, it's entirely possible that two objects with different behaviors >could both point to the same item, even though there are two different registry values that happen by coincidence to be equal to one-another, and the generated results would be valid and >correct.
 
 
 
While in some cases you can look at the object to distinguish between where an item came from, it will not always work as the collected_object section is optional.  For example, consider the system characteristics producer adoption capability.  It is completely valid for items to be collected using some proprietary process, without the use of objects, as long as it conforms to the oval-system-characteristics-schema.  In this situation, you would not have a collected_objects section in the system characteristics and would not be able to make that distinction.  I think that the windows_view item entity will be need to make that distinction between those items.
 
 
 
 
Thanks,
 
Danny
 
 
 
From: David Solin [