Community Call - 8/10/2011

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

Community Call - 8/10/2011

Hansbury, Matt
All,

We had a very productive call yesterday and I would like to thank those of you that were able to join.  The call was attended by around 30 people, representing about 15 different organizations.

The call started with a brief review of the proposed plan to address the uncertainty around assessment of different combination of "bitness" on 64 bit Windows architectures.  The proposal included adding the following:

1. A new behavior (called 'target_architecture') for a subset of tests (the full list is added below*) that will indicate the intended target architecture.  The value for this behavior will be an enumeration that allows for the following values:
  a. 32_bit - Indicating an intent to test for 32-bit.
  b. 64_bit - indicating an intent to test for 64-bit.
  c. os_native - indicating an intent to test the native architecture of the target system.
2. A new OVAL Item entity to allow tools to indicate the architecture on which the OVAL Item was found.    This would also be added to OVAL States.

The discussion around the proposal was mainly positive to the proposal and the general consensus appeared to be that these changes were a positive step in making the author's intent regarding 32 vs. 64 bit more clear and provide more consistent results across tools.  Specifically, the vendor community seemed to think that the tool changes were not overly burdensome to them and generally seemed to favor the changes.

Additionally, content authors also seemed to believe that the proposed changes would benefit the OVAL Language, and that with the proper default setting, the burden of re-writing content would be minimal.  With regards to the proposed default behavior value of '32_bit', it seems that, in general, folks were more comfortable with using the 'os_native' value, as it more accurately reflected the disposition of their content.

The group was also asked if there was a use case for adding the concept of 'both' to the enumeration, meaning that a check would be targeted at both 32-bit and 64-bit.  No clear consensus was reached here, so the current proposal does not include this.    Also, given that the enumeration could be expanded to other architectures, the name of such a concept would likely be 'all', not 'both'.  If any other folks see a clear use case for this value, please let us know.

Lastly, it was also brought up that the environment variable test may also require this behavior.  More research is required to determine if that is the case.

As follow up to this call, the MITRE team is going to do the following:

1. Research the OVAL Repository to confirm the best value for the default behavior value.  (This would be highly recommended as well, for any other content owners out there.)
2. Consider whether an 'all' behavior enumeration value is required by any use cases.
3. Begin implementation of the above proposal for inclusion in the OVAL 5.10 version.
4. Consider whether the environment variable test needs to be included in discussion.

Also note that the MITRE team announced their intent to push back the OVAL 5.10 version release by some amount of time to accommodate these changes.  A formal announcement regarding the new release date will be sent out soon to confirm this.

Thanks
Matt


* Affected Test:

-              win-def:file_test
-              win-def:fileauditedpermissions_test
-              win-def:fileauditedpermissions53_test
-              win-def:fileeffectiverights_test
-              win-def:fileeffectiverights53_test
-              win-def:registry_test,
-              win-def:regkeyauditedpermissions_test
-              win-def:regkeyauditedpermissions53_test
-              win-def:regkeyeffectiverights_test
-              win-def:regkeyeffectiverights53_test
-              ind-def:filehash_test
-              ind-def:filehash58_test
-              ind-def:textfilecontent_test
-              ind-def:textfilecontent54_test
-              ind-def:xmlfilecontent_test

====================================================
Matt Hansbury
G022 -  Information Assurance Industry Collaboration
The MITRE Corporation
[hidden email]

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: Community Call - 8/10/2011

Gunnar Engelbach
Comments in-line below:


On 8/11/2011 11:23 AM, Hansbury, Matt wrote:
> All,
>
> We had a very productive call yesterday and I would like to thank those of you that were able to join.  The call was attended by around 30 people, representing about 15 different organizations.
>
> The call started with a brief review of the proposed plan to address the uncertainty around assessment of different combination of "bitness" on 64 bit Windows architectures.  The proposal included adding the following:
>
> 1. A new behavior (called 'target_architecture') for a subset of tests (the full list is added below*) that will indicate the intended target architecture.  The value for this behavior will be an enumeration that allows for the following values:


At the risk of being nit-picky, the name 'target_architecture' seems to
have a misleading connotation.  That term is generally used to indicate
x86 versus Itanium, PA-RISC, ARM, etc.  In my head at least.

The point brought up on the call to not limit this strictly to 32-bit
vice 64-bit is a good one, but it strikes me that what we are discussing
with bitness subsystems seems to be more akin to virtualization.

As other possible examples, consider "XP Mode" available in Windows 7,
or even the different runtime environment you get from running an
application within a JVM, Adobe AIR, or Android within a Chrome browser.



>    a. 32_bit - Indicating an intent to test for 32-bit.
>    b. 64_bit - indicating an intent to test for 64-bit.
>    c. os_native - indicating an intent to test the native architecture of the target system.

The native architecture of the target system, or the native architecture
of the scanner?

If the intent is for the target of the rule to be native to the target
system, then both a 32-bit and a 64-bit scanner should return the same
results.  The 32-bit scanner will need to be able to do redirection to
achieve that, or else have to mark the rule as error.

Or if it means native to the scanner, then the same rule could be used
by a 32-bit scanner to check settings for, example, applications
installed as 32-bit applications and then run a second time by a 64-bit
scanner to check compliance for the same application on the same machine
installed as a 64-bit application.

I can certainly see a case for going with the former, but if instead it
is used to indicate the view of the interpreter running the test and
that is considered the default value, then the only time existing
content would need to be updated in order to be usable for both 32- and
64-bit assessments is when there is a rule that is not the same between
the two subsystems.



> 2. A new OVAL Item entity to allow tools to indicate the architecture on which the OVAL Item was found.    This would also be added to OVAL States.
>
> The discussion around the proposal was mainly positive to the proposal and the general consensus appeared to be that these changes were a positive step in making the author's intent regarding 32 vs. 64 bit more clear and provide more consistent results across tools.  Specifically, the vendor community seemed to think that the tool changes were not overly burdensome to them and generally seemed to favor the changes.
>
> Additionally, content authors also seemed to believe that the proposed changes would benefit the OVAL Language, and that with the proper default setting, the burden of re-writing content would be minimal.  With regards to the proposed default behavior value of '32_bit', it seems that, in general, folks were more comfortable with using the 'os_native' value, as it more accurately reflected the disposition of their content.
>
> The group was also asked if there was a use case for adding the concept of 'both' to the enumeration, meaning that a check would be targeted at both 32-bit and 64-bit.  No clear consensus was reached here, so the current proposal does not include this.    Also, given that the enumeration could be expanded to other architectures, the name of such a concept would likely be 'all', not 'both'.  If any other folks see a clear use case for this value, please let us know.
>
> Lastly, it was also brought up that the environment variable test may also require this behavior.  More research is required to determine if that is the case.
>
> As follow up to this call, the MITRE team is going to do the following:
>
> 1. Research the OVAL Repository to confirm the best value for the default behavior value.  (This would be highly recommended as well, for any other content owners out there.)
> 2. Consider whether an 'all' behavior enumeration value is required by any use cases.
> 3. Begin implementation of the above proposal for inclusion in the OVAL 5.10 version.
> 4. Consider whether the environment variable test needs to be included in discussion.
>
> Also note that the MITRE team announced their intent to push back the OVAL 5.10 version release by some amount of time to accommodate these changes.  A formal announcement regarding the new release date will be sent out soon to confirm this.
>
> Thanks
> Matt
>
>
> * Affected Test:
>
> -              win-def:file_test
> -              win-def:fileauditedpermissions_test
> -              win-def:fileauditedpermissions53_test
> -              win-def:fileeffectiverights_test
> -              win-def:fileeffectiverights53_test
> -              win-def:registry_test,
> -              win-def:regkeyauditedpermissions_test
> -              win-def:regkeyauditedpermissions53_test
> -              win-def:regkeyeffectiverights_test
> -              win-def:regkeyeffectiverights53_test
> -              ind-def:filehash_test
> -              ind-def:filehash58_test
> -              ind-def:textfilecontent_test
> -              ind-def:textfilecontent54_test
> -              ind-def:xmlfilecontent_test
>
> ====================================================
> Matt Hansbury
> G022 -  Information Assurance Industry Collaboration
> The MITRE Corporation
> [hidden email]
>
> To unsubscribe, send an email message to [hidden email] with
> SIGNOFF OVAL-DEVELOPER-LIST
> in the BODY of the message.  If you have difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: Community Call - 8/10/2011

Shane Shaffer
By calling the parameter "os_native" I've been assuming that it meant the bitness of the OS, not the scanner - clarification is important so we don't get wrapped up in non-issues.
 
My understanding of this new attribute is to indicate the bitness of the entity it is associated with - i.e. am I searching for a 32 bit registry key, a 64 bit registry key, or whatever bitness my system is.  Given that interpretation I'm not convinced that having a default value of os_native is the right way to go.  I would think that nearly all content anyone has, including the OVAL Repository, pertaining to an application would need to be modified to explicitly state 32 bit, as the overwhelming majority of existing applications are 32 bit.  If we left the default value as os_native it seems that you wouldn't find keys associated with a 32 bit application on a 64 bit system, leaving the majority of existing application related content non-functional.  On the other hand, for OS related content that would naturally only ever reside in the native registry/file location os_native seems to be be preferable.  If I'm understanding how we would use this attribute correctly, I think it comes down to whether we want to keep OS or application content intact.
 
For the sake of clarity, would someone on the MITRE side explicitly state what interpretation of the proposed attribute you're using as you're working on the implementation, and enumerate the expected behaviors for all combinations of OS, interpreter, and "application" bitness?  This would include whether or not the redirection is automagic or if it would have to be done manually. 

 
Shane Shaffer
G2, Inc.
Technical Director, Security Automation
[hidden email]
 
On Thu, Aug 11, 2011 at 12:04 PM, Gunnar Engelbach <[hidden email]> wrote:
Comments in-line below:



On 8/11/2011 11:23 AM, Hansbury, Matt wrote:
All,

We had a very productive call yesterday and I would like to thank those of you that were able to join.  The call was attended by around 30 people, representing about 15 different organizations.

The call started with a brief review of the proposed plan to address the uncertainty around assessment of different combination of "bitness" on 64 bit Windows architectures.  The proposal included adding the following:

1. A new behavior (called 'target_architecture') for a subset of tests (the full list is added below*) that will indicate the intended target architecture.  The value for this behavior will be an enumeration that allows for the following values:


At the risk of being nit-picky, the name 'target_architecture' seems to have a misleading connotation.  That term is generally used to indicate x86 versus Itanium, PA-RISC, ARM, etc.  In my head at least.

The point brought up on the call to not limit this strictly to 32-bit vice 64-bit is a good one, but it strikes me that what we are discussing with bitness subsystems seems to be more akin to virtualization.

As other possible examples, consider "XP Mode" available in Windows 7, or even the different runtime environment you get from running an application within a JVM, Adobe AIR, or Android within a Chrome browser.




  a. 32_bit - Indicating an intent to test for 32-bit.
  b. 64_bit - indicating an intent to test for 64-bit.
  c. os_native - indicating an intent to test the native architecture of the target system.

The native architecture of the target system, or the native architecture of the scanner?

If the intent is for the target of the rule to be native to the target system, then both a 32-bit and a 64-bit scanner should return the same results.  The 32-bit scanner will need to be able to do redirection to achieve that, or else have to mark the rule as error.

Or if it means native to the scanner, then the same rule could be used by a 32-bit scanner to check settings for, example, applications installed as 32-bit applications and then run a second time by a 64-bit scanner to check compliance for the same application on the same machine installed as a 64-bit application.

I can certainly see a case for going with the former, but if instead it is used to indicate the view of the interpreter running the test and that is considered the default value, then the only time existing content would need to be updated in order to be usable for both 32- and 64-bit assessments is when there is a rule that is not the same between the two subsystems.




2. A new OVAL Item entity to allow tools to indicate the architecture on which the OVAL Item was found.    This would also be added to OVAL States.

The discussion around the proposal was mainly positive to the proposal and the general consensus appeared to be that these changes were a positive step in making the author's intent regarding 32 vs. 64 bit more clear and provide more consistent results across tools.  Specifically, the vendor community seemed to think that the tool changes were not overly burdensome to them and generally seemed to favor the changes.

Additionally, content authors also seemed to believe that the proposed changes would benefit the OVAL Language, and that with the proper default setting, the burden of re-writing content would be minimal.  With regards to the proposed default behavior value of '32_bit', it seems that, in general, folks were more comfortable with using the 'os_native' value, as it more accurately reflected the disposition of their content.

The group was also asked if there was a use case for adding the concept of 'both' to the enumeration, meaning that a check would be targeted at both 32-bit and 64-bit.  No clear consensus was reached here, so the current proposal does not include this.    Also, given that the enumeration could be expanded to other architectures, the name of such a concept would likely be 'all', not 'both'.  If any other folks see a clear use case for this value, please let us know.

Lastly, it was also brought up that the environment variable test may also require this behavior.  More research is required to determine if that is the case.

As follow up to this call, the MITRE team is going to do the following:

1. Research the OVAL Repository to confirm the best value for the default behavior value.  (This would be highly recommended as well, for any other content owners out there.)
2. Consider whether an 'all' behavior enumeration value is required by any use cases.
3. Begin implementation of the above proposal for inclusion in the OVAL 5.10 version.
4. Consider whether the environment variable test needs to be included in discussion.

Also note that the MITRE team announced their intent to push back the OVAL 5.10 version release by some amount of time to accommodate these changes.  A formal announcement regarding the new release date will be sent out soon to confirm this.

Thanks
Matt


* Affected Test:

-              win-def:file_test
-              win-def:fileauditedpermissions_test
-              win-def:fileauditedpermissions53_test
-              win-def:fileeffectiverights_test
-              win-def:fileeffectiverights53_test
-              win-def:registry_test,
-              win-def:regkeyauditedpermissions_test
-              win-def:regkeyauditedpermissions53_test
-              win-def:regkeyeffectiverights_test
-              win-def:regkeyeffectiverights53_test
-              ind-def:filehash_test
-              ind-def:filehash58_test
-              ind-def:textfilecontent_test
-              ind-def:textfilecontent54_test
-              ind-def:xmlfilecontent_test

====================================================
Matt Hansbury
G022 -  Information Assurance Industry Collaboration
The MITRE Corporation
[hidden email]

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: Community Call - 8/10/2011

Vladimir Giszpenc
In reply to this post by Hansbury, Matt
Matt,

Microsoft claims that Windows 8 will run on ARM 32 bit RISC architecture.
http://www.microsoft.com/presspass/press/2011/jan11/01-05socsupport.mspx
NVIDIA is reportedly working on a 64 bit ARM architecture.
http://www.brightsideofnews.com/news/2011/3/8/nvidia-project-denver-is-a-64-
bit-arm-processor-architecture.aspx

This is the future I was referring to.  It is certainly not yet here, but
Windows 8 should come next year.

Cheers,

Vladimir Giszpenc
Armadillo Technical Lead
DSCI Contractor Supporting
U.S. Army CERDEC S&TCD CSIAD
Tactical Network Protection Branch
(732) 542-3113 x1328

> -----Original Message-----
> From: Hansbury, Matt [mailto:[hidden email]]
> Sent: Thursday, August 11, 2011 11:23 AM
> To: [hidden email]
> Subject: [OVAL-DEVELOPER-LIST] Community Call - 8/10/2011
>
> All,
>
> We had a very productive call yesterday and I would like to thank those of
you
> that were able to join.  The call was attended by around 30 people,
representing
> about 15 different organizations.
>
> The call started with a brief review of the proposed plan to address the
> uncertainty around assessment of different combination of "bitness" on 64
bit
> Windows architectures.  The proposal included adding the following:
>
> 1. A new behavior (called 'target_architecture') for a subset of tests
(the full list
> is added below*) that will indicate the intended target architecture.  The
value
> for this behavior will be an enumeration that allows for the following
values:
>   a. 32_bit - Indicating an intent to test for 32-bit.
>   b. 64_bit - indicating an intent to test for 64-bit.
>   c. os_native - indicating an intent to test the native architecture of
the target
> system.
> 2. A new OVAL Item entity to allow tools to indicate the architecture on
which
> the OVAL Item was found.    This would also be added to OVAL States.
>
> The discussion around the proposal was mainly positive to the proposal and
the
> general consensus appeared to be that these changes were a positive step
in
> making the author's intent regarding 32 vs. 64 bit more clear and provide
more
> consistent results across tools.  Specifically, the vendor community
seemed to
> think that the tool changes were not overly burdensome to them and
generally
> seemed to favor the changes.
>
> Additionally, content authors also seemed to believe that the proposed
changes
> would benefit the OVAL Language, and that with the proper default setting,
the
> burden of re-writing content would be minimal.  With regards to the
proposed
> default behavior value of '32_bit', it seems that, in general, folks were
more
> comfortable with using the 'os_native' value, as it more accurately
reflected the
> disposition of their content.
>
> The group was also asked if there was a use case for adding the concept of
> 'both' to the enumeration, meaning that a check would be targeted at both
32-
> bit and 64-bit.  No clear consensus was reached here, so the current
proposal
> does not include this.    Also, given that the enumeration could be
expanded to
> other architectures, the name of such a concept would likely be 'all', not
'both'.
> If any other folks see a clear use case for this value, please let us
know.
>
> Lastly, it was also brought up that the environment variable test may also
> require this behavior.  More research is required to determine if that is
the case.
>
> As follow up to this call, the MITRE team is going to do the following:
>
> 1. Research the OVAL Repository to confirm the best value for the default
> behavior value.  (This would be highly recommended as well, for any other
> content owners out there.) 2. Consider whether an 'all' behavior
enumeration
> value is required by any use cases.
> 3. Begin implementation of the above proposal for inclusion in the OVAL
5.10
> version.
> 4. Consider whether the environment variable test needs to be included in
> discussion.
>
> Also note that the MITRE team announced their intent to push back the OVAL
> 5.10 version release by some amount of time to accommodate these changes.
> A formal announcement regarding the new release date will be sent out soon
to

> confirm this.
>
> Thanks
> Matt
>
>
> * Affected Test:
>
> -              win-def:file_test
> -              win-def:fileauditedpermissions_test
> -              win-def:fileauditedpermissions53_test
> -              win-def:fileeffectiverights_test
> -              win-def:fileeffectiverights53_test
> -              win-def:registry_test,
> -              win-def:regkeyauditedpermissions_test
> -              win-def:regkeyauditedpermissions53_test
> -              win-def:regkeyeffectiverights_test
> -              win-def:regkeyeffectiverights53_test
> -              ind-def:filehash_test
> -              ind-def:filehash58_test
> -              ind-def:textfilecontent_test
> -              ind-def:textfilecontent54_test
> -              ind-def:xmlfilecontent_test
>
> ====================================================
> Matt Hansbury
> G022 -  Information Assurance Industry Collaboration The MITRE Corporation
> [hidden email]
>
> To unsubscribe, send an email message to [hidden email] with
> SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message.  If you have
> difficulties, write to [hidden email].
To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].

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

Re: Community Call - 8/10/2011

Shane Shaffer
While we were on the call yesterday I was searching for other architectures on Windows 8, but ultimately doesn't it come down to whether or not there is redirection?  There could be a dozen different true architectures of Windows, but unless you can install conventional 32 and 64 bit apps on a Windows 8 phone and you have redirection going on for each architecture, does it matter?
 
Of course, we've had different architectures before - we had x64 and ia64 variants of Windows.  We didn't need to indicate a difference in those architectures because the registry and file systems behaved the same.
 
 
Shane Shaffer
G2, Inc.
Technical Director, Security Automation
[hidden email]


On Thu, Aug 11, 2011 at 12:30 PM, Vladimir Giszpenc <[hidden email]> wrote:
Matt,

Microsoft claims that Windows 8 will run on ARM 32 bit RISC architecture.
http://www.microsoft.com/presspass/press/2011/jan11/01-05socsupport.mspx
NVIDIA is reportedly working on a 64 bit ARM architecture.
http://www.brightsideofnews.com/news/2011/3/8/nvidia-project-denver-is-a-64-
bit-arm-processor-architecture.aspx


This is the future I was referring to.  It is certainly not yet here, but
Windows 8 should come next year.

Cheers,

Vladimir Giszpenc
Armadillo Technical Lead
DSCI Contractor Supporting
U.S. Army CERDEC S&TCD CSIAD
Tactical Network Protection Branch
<a href="tel:%28732%29%20542-3113%20x1328" value="+17325423113">(732) 542-3113 x1328

> -----Original Message-----
> From: Hansbury, Matt [mailto:[hidden email]]
> Sent: Thursday, August 11, 2011 11:23 AM
> To: [hidden email]
> Subject: [OVAL-DEVELOPER-LIST] Community Call - 8/10/2011
>
> All,
>
> We had a very productive call yesterday and I would like to thank those of
you
> that were able to join.  The call was attended by around 30 people,
representing
> about 15 different organizations.
>
> The call started with a brief review of the proposed plan to address the
> uncertainty around assessment of different combination of "bitness" on 64
bit
> Windows architectures.  The proposal included adding the following:
>
> 1. A new behavior (called 'target_architecture') for a subset of tests
(the full list
> is added below*) that will indicate the intended target architecture.  The
value
> for this behavior will be an enumeration that allows for the following
values:
>   a. 32_bit - Indicating an intent to test for 32-bit.
>   b. 64_bit - indicating an intent to test for 64-bit.
>   c. os_native - indicating an intent to test the native architecture of
the target
> system.
> 2. A new OVAL Item entity to allow tools to indicate the architecture on
which
> the OVAL Item was found.    This would also be added to OVAL States.
>
> The discussion around the proposal was mainly positive to the proposal and
the
> general consensus appeared to be that these changes were a positive step
in
> making the author's intent regarding 32 vs. 64 bit more clear and provide
more
> consistent results across tools.  Specifically, the vendor community
seemed to
> think that the tool changes were not overly burdensome to them and
generally
> seemed to favor the changes.
>
> Additionally, content authors also seemed to believe that the proposed
changes
> would benefit the OVAL Language, and that with the proper default setting,
the
> burden of re-writing content would be minimal.  With regards to the
proposed
> default behavior value of '32_bit', it seems that, in general, folks were
more
> comfortable with using the 'os_native' value, as it more accurately
reflected the
> disposition of their content.
>
> The group was also asked if there was a use case for adding the concept of
> 'both' to the enumeration, meaning that a check would be targeted at both
32-
> bit and 64-bit.  No clear consensus was reached here, so the current
proposal
> does not include this.    Also, given that the enumeration could be
expanded to
> other architectures, the name of such a concept would likely be 'all', not
'both'.
> If any other folks see a clear use case for this value, please let us
know.
>
> Lastly, it was also brought up that the environment variable test may also
> require this behavior.  More research is required to determine if that is
the case.
>
> As follow up to this call, the MITRE team is going to do the following:
>
> 1. Research the OVAL Repository to confirm the best value for the default
> behavior value.  (This would be highly recommended as well, for any other
> content owners out there.) 2. Consider whether an 'all' behavior
enumeration
> value is required by any use cases.
> 3. Begin implementation of the above proposal for inclusion in the OVAL
5.10
> version.
> 4. Consider whether the environment variable test needs to be included in
> discussion.
>
> Also note that the MITRE team announced their intent to push back the OVAL
> 5.10 version release by some amount of time to accommodate these changes.
> A formal announcement regarding the new release date will be sent out soon
to
> confirm this.
>
> Thanks
> Matt
>
>
> * Affected Test:
>
> -              win-def:file_test
> -              win-def:fileauditedpermissions_test
> -              win-def:fileauditedpermissions53_test
> -              win-def:fileeffectiverights_test
> -              win-def:fileeffectiverights53_test
> -              win-def:registry_test,
> -              win-def:regkeyauditedpermissions_test
> -              win-def:regkeyauditedpermissions53_test
> -              win-def:regkeyeffectiverights_test
> -              win-def:regkeyeffectiverights53_test
> -              ind-def:filehash_test
> -              ind-def:filehash58_test
> -              ind-def:textfilecontent_test
> -              ind-def:textfilecontent54_test
> -              ind-def:xmlfilecontent_test
>
> ====================================================
> Matt Hansbury
> G022 -  Information Assurance Industry Collaboration The MITRE Corporation
> [hidden email]
>
> To unsubscribe, send an email message to [hidden email] with
> SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message.  If you have
> difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: Community Call - 8/10/2011

Gunnar Engelbach
In reply to this post by Vladimir Giszpenc
It could be that this will cause a need for another registry/system
view, but I seriously doubt it.

The registry path to a value on a 32-bit ARM system should be exactly
the same as it is on a 32-bit x86 system.  When it would be different is
a 32-bit ARM system vice a 64-bit ARM system.  That's how it was when
Microsoft maintained a version of NT for the Alpha.

So saying that a value should be retrieved from the 64-bit view would
have the same meaning regardless of whether the hardware was x86, ARM,
SPARC, whatever.

The future could easily prove me wrong on that and it's worth
considering the possibility for the sake of "future-proofing," but based
on my own experience the likelihood is very small.



On 8/11/2011 12:30 PM, Vladimir Giszpenc wrote:

> Matt,
>
> Microsoft claims that Windows 8 will run on ARM 32 bit RISC architecture.
> http://www.microsoft.com/presspass/press/2011/jan11/01-05socsupport.mspx
> NVIDIA is reportedly working on a 64 bit ARM architecture.
> http://www.brightsideofnews.com/news/2011/3/8/nvidia-project-denver-is-a-64-
> bit-arm-processor-architecture.aspx
>
> This is the future I was referring to.  It is certainly not yet here, but
> Windows 8 should come next year.
>
> Cheers,
>
> Vladimir Giszpenc
> Armadillo Technical Lead
> DSCI Contractor Supporting
> U.S. Army CERDEC S&TCD CSIAD
> Tactical Network Protection Branch
> (732) 542-3113 x1328
>
>> -----Original Message-----
>> From: Hansbury, Matt [mailto:[hidden email]]
>> Sent: Thursday, August 11, 2011 11:23 AM
>> To: [hidden email]
>> Subject: [OVAL-DEVELOPER-LIST] Community Call - 8/10/2011
>>
>> All,
>>
>> We had a very productive call yesterday and I would like to thank those of
> you
>> that were able to join.  The call was attended by around 30 people,
> representing
>> about 15 different organizations.
>>
>> The call started with a brief review of the proposed plan to address the
>> uncertainty around assessment of different combination of "bitness" on 64
> bit
>> Windows architectures.  The proposal included adding the following:
>>
>> 1. A new behavior (called 'target_architecture') for a subset of tests
> (the full list
>> is added below*) that will indicate the intended target architecture.  The
> value
>> for this behavior will be an enumeration that allows for the following
> values:
>>    a. 32_bit - Indicating an intent to test for 32-bit.
>>    b. 64_bit - indicating an intent to test for 64-bit.
>>    c. os_native - indicating an intent to test the native architecture of
> the target
>> system.
>> 2. A new OVAL Item entity to allow tools to indicate the architecture on
> which
>> the OVAL Item was found.    This would also be added to OVAL States.
>>
>> The discussion around the proposal was mainly positive to the proposal and
> the
>> general consensus appeared to be that these changes were a positive step
> in
>> making the author's intent regarding 32 vs. 64 bit more clear and provide
> more
>> consistent results across tools.  Specifically, the vendor community
> seemed to
>> think that the tool changes were not overly burdensome to them and
> generally
>> seemed to favor the changes.
>>
>> Additionally, content authors also seemed to believe that the proposed
> changes
>> would benefit the OVAL Language, and that with the proper default setting,
> the
>> burden of re-writing content would be minimal.  With regards to the
> proposed
>> default behavior value of '32_bit', it seems that, in general, folks were
> more
>> comfortable with using the 'os_native' value, as it more accurately
> reflected the
>> disposition of their content.
>>
>> The group was also asked if there was a use case for adding the concept of
>> 'both' to the enumeration, meaning that a check would be targeted at both
> 32-
>> bit and 64-bit.  No clear consensus was reached here, so the current
> proposal
>> does not include this.    Also, given that the enumeration could be
> expanded to
>> other architectures, the name of such a concept would likely be 'all', not
> 'both'.
>> If any other folks see a clear use case for this value, please let us
> know.
>>
>> Lastly, it was also brought up that the environment variable test may also
>> require this behavior.  More research is required to determine if that is
> the case.
>>
>> As follow up to this call, the MITRE team is going to do the following:
>>
>> 1. Research the OVAL Repository to confirm the best value for the default
>> behavior value.  (This would be highly recommended as well, for any other
>> content owners out there.) 2. Consider whether an 'all' behavior
> enumeration
>> value is required by any use cases.
>> 3. Begin implementation of the above proposal for inclusion in the OVAL
> 5.10
>> version.
>> 4. Consider whether the environment variable test needs to be included in
>> discussion.
>>
>> Also note that the MITRE team announced their intent to push back the OVAL
>> 5.10 version release by some amount of time to accommodate these changes.
>> A formal announcement regarding the new release date will be sent out soon
> to
>> confirm this.
>>
>> Thanks
>> Matt
>>
>>
>> * Affected Test:
>>
>> -              win-def:file_test
>> -              win-def:fileauditedpermissions_test
>> -              win-def:fileauditedpermissions53_test
>> -              win-def:fileeffectiverights_test
>> -              win-def:fileeffectiverights53_test
>> -              win-def:registry_test,
>> -              win-def:regkeyauditedpermissions_test
>> -              win-def:regkeyauditedpermissions53_test
>> -              win-def:regkeyeffectiverights_test
>> -              win-def:regkeyeffectiverights53_test
>> -              ind-def:filehash_test
>> -              ind-def:filehash58_test
>> -              ind-def:textfilecontent_test
>> -              ind-def:textfilecontent54_test
>> -              ind-def:xmlfilecontent_test
>>
>> ====================================================
>> Matt Hansbury
>> G022 -  Information Assurance Industry Collaboration The MITRE Corporation
>> [hidden email]
>>
>> To unsubscribe, send an email message to [hidden email] with
>> SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message.  If you have
>> difficulties, write to [hidden email].
>
> To unsubscribe, send an email message to [hidden email] with
> SIGNOFF OVAL-DEVELOPER-LIST
> in the BODY of the message.  If you have difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: Community Call - 8/10/2011

joval
In reply to this post by Shane Shaffer
This redirection business only applies to "32-bit Windows on 64-bit Windows" (i.e., WOW), it has nothing really to do with processor architecture.

There could be implications if Microsoft decided to emulate x86 at the OS level by using redirection of the registry and filesystem, but how likely does that seem?  You cannot, for instance, run an x86 application on Windows Phone or vice-versa...

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



On 8/11/2011 11:48 AM, Shane Shaffer wrote:
While we were on the call yesterday I was searching for other architectures on Windows 8, but ultimately doesn't it come down to whether or not there is redirection?  There could be a dozen different true architectures of Windows, but unless you can install conventional 32 and 64 bit apps on a Windows 8 phone and you have redirection going on for each architecture, does it matter?
 
Of course, we've had different architectures before - we had x64 and ia64 variants of Windows.  We didn't need to indicate a difference in those architectures because the registry and file systems behaved the same.
 
 
Shane Shaffer
G2, Inc.
Technical Director, Security Automation
[hidden email]


On Thu, Aug 11, 2011 at 12:30 PM, Vladimir Giszpenc <[hidden email]> wrote:
Matt,

Microsoft claims that Windows 8 will run on ARM 32 bit RISC architecture.
http://www.microsoft.com/presspass/press/2011/jan11/01-05socsupport.mspx
NVIDIA is reportedly working on a 64 bit ARM architecture.
http://www.brightsideofnews.com/news/2011/3/8/nvidia-project-denver-is-a-64-
bit-arm-processor-architecture.aspx


This is the future I was referring to.  It is certainly not yet here, but
Windows 8 should come next year.

Cheers,

Vladimir Giszpenc
Armadillo Technical Lead
DSCI Contractor Supporting
U.S. Army CERDEC S&TCD CSIAD
Tactical Network Protection Branch
<a moz-do-not-send="true" href="tel:%28732%29%20542-3113%20x1328" value="+17325423113">(732) 542-3113 x1328

> -----Original Message-----
> From: Hansbury, Matt [mailto:[hidden email]]
> Sent: Thursday, August 11, 2011 11:23 AM
> To: [hidden email]
> Subject: [OVAL-DEVELOPER-LIST] Community Call - 8/10/2011
>
> All,
>
> We had a very productive call yesterday and I would like to thank those of
you
> that were able to join.  The call was attended by around 30 people,
representing
> about 15 different organizations.
>
> The call started with a brief review of the proposed plan to address the
> uncertainty around assessment of different combination of "bitness" on 64
bit
> Windows architectures.  The proposal included adding the following:
>
> 1. A new behavior (called 'target_architecture') for a subset of tests
(the full list
> is added below*) that will indicate the intended target architecture.  The
value
> for this behavior will be an enumeration that allows for the following
values:
>   a. 32_bit - Indicating an intent to test for 32-bit.
>   b. 64_bit - indicating an intent to test for 64-bit.
>   c. os_native - indicating an intent to test the native architecture of
the target
> system.
> 2. A new OVAL Item entity to allow tools to indicate the architecture on
which
> the OVAL Item was found.    This would also be added to OVAL States.
>
> The discussion around the proposal was mainly positive to the proposal and
the
> general consensus appeared to be that these changes were a positive step
in
> making the author's intent regarding 32 vs. 64 bit more clear and provide
more
> consistent results across tools.  Specifically, the vendor community
seemed to
> think that the tool changes were not overly burdensome to them and
generally
> seemed to favor the changes.
>
> Additionally, content authors also seemed to believe that the proposed
changes
> would benefit the OVAL Language, and that with the proper default setting,
the
> burden of re-writing content would be minimal.  With regards to the
proposed
> default behavior value of '32_bit', it seems that, in general, folks were
more
> comfortable with using the 'os_native' value, as it more accurately
reflected the
> disposition of their content.
>
> The group was also asked if there was a use case for adding the concept of
> 'both' to the enumeration, meaning that a check would be targeted at both
32-
> bit and 64-bit.  No clear consensus was reached here, so the current
proposal
> does not include this.    Also, given that the enumeration could be
expanded to
> other architectures, the name of such a concept would likely be 'all', not
'both'.
> If any other folks see a clear use case for this value, please let us
know.
>
> Lastly, it was also brought up that the environment variable test may also
> require this behavior.  More research is required to determine if that is
the case.
>
> As follow up to this call, the MITRE team is going to do the following:
>
> 1. Research the OVAL Repository to confirm the best value for the default
> behavior value.  (This would be highly recommended as well, for any other
> content owners out there.) 2. Consider whether an 'all' behavior
enumeration
> value is required by any use cases.
> 3. Begin implementation of the above proposal for inclusion in the OVAL
5.10
> version.
> 4. Consider whether the environment variable test needs to be included in
> discussion.
>
> Also note that the MITRE team announced their intent to push back the OVAL
> 5.10 version release by some amount of time to accommodate these changes.
> A formal announcement regarding the new release date will be sent out soon
to
> confirm this.
>
> Thanks
> Matt
>
>
> * Affected Test:
>
> -              win-def:file_test
> -              win-def:fileauditedpermissions_test
> -              win-def:fileauditedpermissions53_test
> -              win-def:fileeffectiverights_test
> -              win-def:fileeffectiverights53_test
> -              win-def:registry_test,
> -              win-def:regkeyauditedpermissions_test
> -              win-def:regkeyauditedpermissions53_test
> -              win-def:regkeyeffectiverights_test
> -              win-def:regkeyeffectiverights53_test
> -              ind-def:filehash_test
> -              ind-def:filehash58_test
> -              ind-def:textfilecontent_test
> -              ind-def:textfilecontent54_test
> -              ind-def:xmlfilecontent_test
>
> ====================================================
> Matt Hansbury
> G022 -  Information Assurance Industry Collaboration The MITRE Corporation
> [hidden email]
>
> To unsubscribe, send an email message to [hidden email] with
> SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message.  If you have
> difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].
To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

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: Community Call - 8/10/2011

Gunnar Engelbach
In reply to this post by Shane Shaffer
Would it make more sense to have both "os_native" and "os_any" flags?

The "os_native" is nice in that it allows for the future possibility
where the OS is not one of 32 or 64, but I think the "os_any" is more
useful and should be default if not explicitly set.  That would be the
equivalent of saying "this rule is accurate regardless of which
subsystem is being checked" meaning that existing content can be used to
check both subsystems without change until is is found that there is a
difference that needs to be accounted for.

This also depends on your goal for rules.  Do you want to treat both the
32- and 64-bit views as a single check where both most pass, or do you
want to treat them separately where it's possible to get a pass on the
64-bit version and a fail on the 32-bit?


On 8/11/2011 12:29 PM, Shane Shaffer wrote:

> By calling the parameter "os_native" I've been assuming that it meant
> the bitness of the OS, not the scanner - clarification is important so
> we don't get wrapped up in non-issues.
> My understanding of this new attribute is to indicate the bitness of the
> entity it is associated with - i.e. am I searching for a 32 bit registry
> key, a 64 bit registry key, or whatever bitness my system is.  Given
> that interpretation I'm not convinced that having a default value of
> os_native is the right way to go.  I would think that nearly all content
> anyone has, including the OVAL Repository, pertaining to an application
> would need to be modified to explicitly state 32 bit, as the
> overwhelming majority of existing applications are 32 bit.  If we left
> the default value as os_native it seems that you wouldn't find keys
> associated with a 32 bit application on a 64 bit system, leaving the
> majority of existing application related content non-functional.  On the
> other hand, for OS related content that would naturally only ever reside
> in the native registry/file location os_native seems to be be
> preferable.  If I'm understanding how we would use this attribute
> correctly, I think it comes down to whether we want to keep OS or
> application content intact.
> For the sake of clarity, would someone on the MITRE side explicitly
> state what interpretation of the proposed attribute you're using as
> you're working on the implementation, and enumerate the expected
> behaviors for all combinations of OS, interpreter, and "application"
> bitness?  This would include whether or not the redirection is automagic
> or if it would have to be done manually.
>
> Shane Shaffer
> G2, Inc.
> Technical Director, Security Automation
> [hidden email] <mailto:[hidden email]>
> On Thu, Aug 11, 2011 at 12:04 PM, Gunnar Engelbach
> <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Comments in-line below:
>
>
>
>     On 8/11/2011 11:23 AM, Hansbury, Matt wrote:
>
>         All,
>
>         We had a very productive call yesterday and I would like to
>         thank those of you that were able to join.  The call was
>         attended by around 30 people, representing about 15 different
>         organizations.
>
>         The call started with a brief review of the proposed plan to
>         address the uncertainty around assessment of different
>         combination of "bitness" on 64 bit Windows architectures.  The
>         proposal included adding the following:
>
>         1. A new behavior (called 'target_architecture') for a subset of
>         tests (the full list is added below*) that will indicate the
>         intended target architecture.  The value for this behavior will
>         be an enumeration that allows for the following values:
>
>
>
>     At the risk of being nit-picky, the name 'target_architecture' seems
>     to have a misleading connotation.  That term is generally used to
>     indicate x86 versus Itanium, PA-RISC, ARM, etc.  In my head at least.
>
>     The point brought up on the call to not limit this strictly to
>     32-bit vice 64-bit is a good one, but it strikes me that what we are
>     discussing with bitness subsystems seems to be more akin to
>     virtualization.
>
>     As other possible examples, consider "XP Mode" available in Windows
>     7, or even the different runtime environment you get from running an
>     application within a JVM, Adobe AIR, or Android within a Chrome
>     browser.
>
>
>
>
>            a. 32_bit - Indicating an intent to test for 32-bit.
>            b. 64_bit - indicating an intent to test for 64-bit.
>            c. os_native - indicating an intent to test the native
>         architecture of the target system.
>
>
>     The native architecture of the target system, or the native
>     architecture of the scanner?
>
>     If the intent is for the target of the rule to be native to the
>     target system, then both a 32-bit and a 64-bit scanner should return
>     the same results.  The 32-bit scanner will need to be able to do
>     redirection to achieve that, or else have to mark the rule as error.
>
>     Or if it means native to the scanner, then the same rule could be
>     used by a 32-bit scanner to check settings for, example,
>     applications installed as 32-bit applications and then run a second
>     time by a 64-bit scanner to check compliance for the same
>     application on the same machine installed as a 64-bit application.
>
>     I can certainly see a case for going with the former, but if instead
>     it is used to indicate the view of the interpreter running the test
>     and that is considered the default value, then the only time
>     existing content would need to be updated in order to be usable for
>     both 32- and 64-bit assessments is when there is a rule that is not
>     the same between the two subsystems.
>
>
>
>
>         2. A new OVAL Item entity to allow tools to indicate the
>         architecture on which the OVAL Item was found.    This would
>         also be added to OVAL States.
>
>         The discussion around the proposal was mainly positive to the
>         proposal and the general consensus appeared to be that these
>         changes were a positive step in making the author's intent
>         regarding 32 vs. 64 bit more clear and provide more consistent
>         results across tools.  Specifically, the vendor community seemed
>         to think that the tool changes were not overly burdensome to
>         them and generally seemed to favor the changes.
>
>         Additionally, content authors also seemed to believe that the
>         proposed changes would benefit the OVAL Language, and that with
>         the proper default setting, the burden of re-writing content
>         would be minimal.  With regards to the proposed default behavior
>         value of '32_bit', it seems that, in general, folks were more
>         comfortable with using the 'os_native' value, as it more
>         accurately reflected the disposition of their content.
>
>         The group was also asked if there was a use case for adding the
>         concept of 'both' to the enumeration, meaning that a check would
>         be targeted at both 32-bit and 64-bit.  No clear consensus was
>         reached here, so the current proposal does not include this.
>           Also, given that the enumeration could be expanded to other
>         architectures, the name of such a concept would likely be 'all',
>         not 'both'.  If any other folks see a clear use case for this
>         value, please let us know.
>
>         Lastly, it was also brought up that the environment variable
>         test may also require this behavior.  More research is required
>         to determine if that is the case.
>
>         As follow up to this call, the MITRE team is going to do the
>         following:
>
>         1. Research the OVAL Repository to confirm the best value for
>         the default behavior value.  (This would be highly recommended
>         as well, for any other content owners out there.)
>         2. Consider whether an 'all' behavior enumeration value is
>         required by any use cases.
>         3. Begin implementation of the above proposal for inclusion in
>         the OVAL 5.10 version.
>         4. Consider whether the environment variable test needs to be
>         included in discussion.
>
>         Also note that the MITRE team announced their intent to push
>         back the OVAL 5.10 version release by some amount of time to
>         accommodate these changes.  A formal announcement regarding the
>         new release date will be sent out soon to confirm this.
>
>         Thanks
>         Matt
>
>
>         * Affected Test:
>
>         -              win-def:file_test
>         -              win-def:__fileauditedpermissions_test
>         -              win-def:__fileauditedpermissions53_test
>         -              win-def:fileeffectiverights___test
>         -              win-def:fileeffectiverights53___test
>         -              win-def:registry_test,
>         -              win-def:__regkeyauditedpermissions_test
>         -              win-def:__regkeyauditedpermissions53___test
>         -              win-def:regkeyeffectiverights___test
>         -              win-def:__regkeyeffectiverights53_test
>         -              ind-def:filehash_test
>         -              ind-def:filehash58_test
>         -              ind-def:textfilecontent_test
>         -              ind-def:textfilecontent54_test
>         -              ind-def:xmlfilecontent_test
>
>         ==============================__======================
>         Matt Hansbury
>         G022 -  Information Assurance Industry Collaboration
>         The MITRE Corporation
>         [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: Community Call - 8/10/2011

Steve Grubb
In reply to this post by Hansbury, Matt
On Thursday, August 11, 2011 11:23:00 AM Hansbury, Matt wrote:

> * Affected Test:
>
> -              win-def:file_test
> -              win-def:fileauditedpermissions_test
> -              win-def:fileauditedpermissions53_test
> -              win-def:fileeffectiverights_test
> -              win-def:fileeffectiverights53_test
> -              win-def:registry_test,
> -              win-def:regkeyauditedpermissions_test
> -              win-def:regkeyauditedpermissions53_test
> -              win-def:regkeyeffectiverights_test
> -              win-def:regkeyeffectiverights53_test

vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv

> -              ind-def:filehash_test
> -              ind-def:filehash58_test
> -              ind-def:textfilecontent_test
> -              ind-def:textfilecontent54_test
> -              ind-def:xmlfilecontent_test

^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Does this mean that the issue is not just Windows? Seems to me that its spilling over
into Linux if tests in the independent schema get touched. How would changing these
tests affect non-Windows platforms? (I didn't attend since it was a windows call.)

Thanks,
-Steve

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: Community Call - 8/10/2011

Gunnar Engelbach
In reply to this post by joval
On 8/11/2011 12:57 PM, David Solin wrote:
> This redirection business only applies to "32-bit Windows on 64-bit
> Windows" (i.e., WOW), it has nothing really to do with processor
> architecture.
>
> There could be implications if Microsoft decided to emulate x86 at the
> OS level by using redirection of the registry and filesystem, but how
> likely does that seem? You cannot, for instance, run an x86 application
> on Windows Phone or vice-versa...

Certainly not as a native application, but via hardware emulation...

http://www.amigaforever.com/system/
http://mamedev.org/release.html
http://www.emulator-zone.com/
http://www.ccs64.com/


OK, a more serious example:

http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=9263


But at least accounting for Transmeta is no longer a concern.



>
> 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/11/2011 11:48 AM, Shane Shaffer wrote:
>> While we were on the call yesterday I was searching for other
>> architectures on Windows 8, but ultimately doesn't it come down to
>> whether or not there is redirection? There could be a dozen different
>> true architectures of Windows, but unless you can install conventional
>> 32 and 64 bit apps on a Windows 8 phone and you have redirection going
>> on for each architecture, does it matter?
>> Of course, we've had different architectures before - we had x64 and
>> ia64 variants of Windows. We didn't need to indicate a difference in
>> those architectures because the registry and file systems behaved the
>> same.
>> Shane Shaffer
>> G2, Inc.
>> Technical Director, Security Automation
>> [hidden email] <mailto:[hidden email]>
>>
>>
>> On Thu, Aug 11, 2011 at 12:30 PM, Vladimir Giszpenc
>> <[hidden email] <mailto:[hidden email]>> wrote:
>>
>>     Matt,
>>
>>     Microsoft claims that Windows 8 will run on ARM 32 bit RISC
>>     architecture.
>>     http://www.microsoft.com/presspass/press/2011/jan11/01-05socsupport.mspx
>>     NVIDIA is reportedly working on a 64 bit ARM architecture.
>>     http://www.brightsideofnews.com/news/2011/3/8/nvidia-project-denver-is-a-64-
>>     bit-arm-processor-architecture.aspx
>>     <http://www.brightsideofnews.com/news/2011/3/8/nvidia-project-denver-is-a-64-bit-arm-processor-architecture.aspx>
>>
>>     This is the future I was referring to. It is certainly not yet
>>     here, but
>>     Windows 8 should come next year.
>>
>>     Cheers,
>>
>>     Vladimir Giszpenc
>>     Armadillo Technical Lead
>>     DSCI Contractor Supporting
>>     U.S. Army CERDEC S&TCD CSIAD
>>     Tactical Network Protection Branch
>>     (732) 542-3113 x1328 <tel:%28732%29%20542-3113%20x1328>
>>
>>     > -----Original Message-----
>>     > From: Hansbury, Matt [mailto:[hidden email]
>>     <mailto:[hidden email]>]
>>     > Sent: Thursday, August 11, 2011 11:23 AM
>>     > To: [hidden email]
>>     <mailto:[hidden email]>
>>     > Subject: [OVAL-DEVELOPER-LIST] Community Call - 8/10/2011
>>     >
>>     > All,
>>     >
>>     > We had a very productive call yesterday and I would like to
>>     thank those of
>>     you
>>     > that were able to join. The call was attended by around 30 people,
>>     representing
>>     > about 15 different organizations.
>>     >
>>     > The call started with a brief review of the proposed plan to
>>     address the
>>     > uncertainty around assessment of different combination of
>>     "bitness" on 64
>>     bit
>>     > Windows architectures. The proposal included adding the following:
>>     >
>>     > 1. A new behavior (called 'target_architecture') for a subset of
>>     tests
>>     (the full list
>>     > is added below*) that will indicate the intended target
>>     architecture. The
>>     value
>>     > for this behavior will be an enumeration that allows for the
>>     following
>>     values:
>>     > a. 32_bit - Indicating an intent to test for 32-bit.
>>     > b. 64_bit - indicating an intent to test for 64-bit.
>>     > c. os_native - indicating an intent to test the native
>>     architecture of
>>     the target
>>     > system.
>>     > 2. A new OVAL Item entity to allow tools to indicate the
>>     architecture on
>>     which
>>     > the OVAL Item was found. This would also be added to OVAL States.
>>     >
>>     > The discussion around the proposal was mainly positive to the
>>     proposal and
>>     the
>>     > general consensus appeared to be that these changes were a
>>     positive step
>>     in
>>     > making the author's intent regarding 32 vs. 64 bit more clear
>>     and provide
>>     more
>>     > consistent results across tools. Specifically, the vendor community
>>     seemed to
>>     > think that the tool changes were not overly burdensome to them and
>>     generally
>>     > seemed to favor the changes.
>>     >
>>     > Additionally, content authors also seemed to believe that the
>>     proposed
>>     changes
>>     > would benefit the OVAL Language, and that with the proper
>>     default setting,
>>     the
>>     > burden of re-writing content would be minimal. With regards to the
>>     proposed
>>     > default behavior value of '32_bit', it seems that, in general,
>>     folks were
>>     more
>>     > comfortable with using the 'os_native' value, as it more accurately
>>     reflected the
>>     > disposition of their content.
>>     >
>>     > The group was also asked if there was a use case for adding the
>>     concept of
>>     > 'both' to the enumeration, meaning that a check would be
>>     targeted at both
>>     32-
>>     > bit and 64-bit. No clear consensus was reached here, so the current
>>     proposal
>>     > does not include this. Also, given that the enumeration could be
>>     expanded to
>>     > other architectures, the name of such a concept would likely be
>>     'all', not
>>     'both'.
>>     > If any other folks see a clear use case for this value, please
>>     let us
>>     know.
>>     >
>>     > Lastly, it was also brought up that the environment variable
>>     test may also
>>     > require this behavior. More research is required to determine if
>>     that is
>>     the case.
>>     >
>>     > As follow up to this call, the MITRE team is going to do the
>>     following:
>>     >
>>     > 1. Research the OVAL Repository to confirm the best value for
>>     the default
>>     > behavior value. (This would be highly recommended as well, for
>>     any other
>>     > content owners out there.) 2. Consider whether an 'all' behavior
>>     enumeration
>>     > value is required by any use cases.
>>     > 3. Begin implementation of the above proposal for inclusion in
>>     the OVAL
>>     5.10
>>     > version.
>>     > 4. Consider whether the environment variable test needs to be
>>     included in
>>     > discussion.
>>     >
>>     > Also note that the MITRE team announced their intent to push
>>     back the OVAL
>>     > 5.10 version release by some amount of time to accommodate these
>>     changes.
>>     > A formal announcement regarding the new release date will be
>>     sent out soon
>>     to
>>     > confirm this.
>>     >
>>     > Thanks
>>     > Matt
>>     >
>>     >
>>     > * Affected Test:
>>     >
>>     > - win-def:file_test
>>     > - win-def:fileauditedpermissions_test
>>     > - win-def:fileauditedpermissions53_test
>>     > - win-def:fileeffectiverights_test
>>     > - win-def:fileeffectiverights53_test
>>     > - win-def:registry_test,
>>     > - win-def:regkeyauditedpermissions_test
>>     > - win-def:regkeyauditedpermissions53_test
>>     > - win-def:regkeyeffectiverights_test
>>     > - win-def:regkeyeffectiverights53_test
>>     > - ind-def:filehash_test
>>     > - ind-def:filehash58_test
>>     > - ind-def:textfilecontent_test
>>     > - ind-def:textfilecontent54_test
>>     > - ind-def:xmlfilecontent_test
>>     >
>>     > ====================================================
>>     > Matt Hansbury
>>     > G022 - Information Assurance Industry Collaboration The MITRE
>>     Corporation
>>     > [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].

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: Community Call - 8/10/2011

joval
Well, indeed those are all emulators.  But an app running in an emulator runs no risk of accidentally loading an incompatible library, or doing anything else that would call for redirection.  I'm just wondering, how likely is it that Microsoft will introduce another thing that is somewhere between emulation or virtualization, and native execution, that will require similar attention.

A 32-bit-app-on-64-bit-OS a bit of a unique case, I think.

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



On 8/11/2011 12:30 PM, Gunnar Engelbach wrote:
On 8/11/2011 12:57 PM, David Solin wrote:
This redirection business only applies to "32-bit Windows on 64-bit
Windows" (i.e., WOW), it has nothing really to do with processor
architecture.

There could be implications if Microsoft decided to emulate x86 at the
OS level by using redirection of the registry and filesystem, but how
likely does that seem? You cannot, for instance, run an x86 application
on Windows Phone or vice-versa...

Certainly not as a native application, but via hardware emulation...

http://www.amigaforever.com/system/
http://mamedev.org/release.html
http://www.emulator-zone.com/
http://www.ccs64.com/


OK, a more serious example:

http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=9263


But at least accounting for Transmeta is no longer a concern.




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/11/2011 11:48 AM, Shane Shaffer wrote:
While we were on the call yesterday I was searching for other
architectures on Windows 8, but ultimately doesn't it come down to
whether or not there is redirection? There could be a dozen different
true architectures of Windows, but unless you can install conventional
32 and 64 bit apps on a Windows 8 phone and you have redirection going
on for each architecture, does it matter?
Of course, we've had different architectures before - we had x64 and
ia64 variants of Windows. We didn't need to indicate a difference in
those architectures because the registry and file systems behaved the
same.
Shane Shaffer
G2, Inc.
Technical Director, Security Automation
[hidden email] [hidden email]


On Thu, Aug 11, 2011 at 12:30 PM, Vladimir Giszpenc
<[hidden email] [hidden email]> wrote:

    Matt,

    Microsoft claims that Windows 8 will run on ARM 32 bit RISC
    architecture.
    http://www.microsoft.com/presspass/press/2011/jan11/01-05socsupport.mspx
    NVIDIA is reportedly working on a 64 bit ARM architecture.
    http://www.brightsideofnews.com/news/2011/3/8/nvidia-project-denver-is-a-64-
    bit-arm-processor-architecture.aspx
    <http://www.brightsideofnews.com/news/2011/3/8/nvidia-project-denver-is-a-64-bit-arm-processor-architecture.aspx>

    This is the future I was referring to. It is certainly not yet
    here, but
    Windows 8 should come next year.

    Cheers,

    Vladimir Giszpenc
    Armadillo Technical Lead
    DSCI Contractor Supporting
    U.S. Army CERDEC S&TCD CSIAD
    Tactical Network Protection Branch
    (732) 542-3113 x1328 <tel:%28732%29%20542-3113%20x1328>

    > -----Original Message-----
    > From: Hansbury, Matt [[hidden email]
    [hidden email]]
    > Sent: Thursday, August 11, 2011 11:23 AM
    > To: [hidden email]
    [hidden email]
    > Subject: [OVAL-DEVELOPER-LIST] Community Call - 8/10/2011
    >
    > All,
    >
    > We had a very productive call yesterday and I would like to
    thank those of
    you
    > that were able to join. The call was attended by around 30 people,
    representing
    > about 15 different organizations.
    >
    > The call started with a brief review of the proposed plan to
    address the
    > uncertainty around assessment of different combination of
    "bitness" on 64
    bit
    > Windows architectures. The proposal included adding the following:
    >
    > 1. A new behavior (called 'target_architecture') for a subset of
    tests
    (the full list
    > is added below*) that will indicate the intended target
    architecture. The
    value
    > for this behavior will be an enumeration that allows for the
    following
    values:
    > a. 32_bit - Indicating an intent to test for 32-bit.
    > b. 64_bit - indicating an intent to test for 64-bit.
    > c. os_native - indicating an intent to test the native
    architecture of
    the target
    > system.
    > 2. A new OVAL Item entity to allow tools to indicate the
    architecture on
    which
    > the OVAL Item was found. This would also be added to OVAL States.
    >
    > The discussion around the proposal was mainly positive to the
    proposal and
    the
    > general consensus appeared to be that these changes were a
    positive step
    in
    > making the author's intent regarding 32 vs. 64 bit more clear
    and provide
    more
    > consistent results across tools. Specifically, the vendor community
    seemed to
    > think that the tool changes were not overly burdensome to them and
    generally
    > seemed to favor the changes.
    >
    > Additionally, content authors also seemed to believe that the
    proposed
    changes
    > would benefit the OVAL Language, and that with the proper
    default setting,
    the
    > burden of re-writing content would be minimal. With regards to the
    proposed
    > default behavior value of '32_bit', it seems that, in general,
    folks were
    more
    > comfortable with using the 'os_native' value, as it more accurately
    reflected the
    > disposition of their content.
    >
    > The group was also asked if there was a use case for adding the
    concept of
    > 'both' to the enumeration, meaning that a check would be
    targeted at both
    32-
    > bit and 64-bit. No clear consensus was reached here, so the current
    proposal
    > does not include this. Also, given that the enumeration could be
    expanded to
    > other architectures, the name of such a concept would likely be
    'all', not
    'both'.
    > If any other folks see a clear use case for this value, please
    let us
    know.
    >
    > Lastly, it was also brought up that the environment variable
    test may also
    > require this behavior. More research is required to determine if
    that is
    the case.
    >
    > As follow up to this call, the MITRE team is going to do the
    following:
    >
    > 1. Research the OVAL Repository to confirm the best value for
    the default
    > behavior value. (This would be highly recommended as well, for
    any other
    > content owners out there.) 2. Consider whether an 'all' behavior
    enumeration
    > value is required by any use cases.
    > 3. Begin implementation of the above proposal for inclusion in
    the OVAL
    5.10
    > version.
    > 4. Consider whether the environment variable test needs to be
    included in
    > discussion.
    >
    > Also note that the MITRE team announced their intent to push
    back the OVAL
    > 5.10 version release by some amount of time to accommodate these
    changes.
    > A formal announcement regarding the new release date will be
    sent out soon
    to
    > confirm this.
    >
    > Thanks
    > Matt
    >
    >
    > * Affected Test:
    >
    > - win-def:file_test
    > - win-def:fileauditedpermissions_test
    > - win-def:fileauditedpermissions53_test
    > - win-def:fileeffectiverights_test
    > - win-def:fileeffectiverights53_test
    > - win-def:registry_test,
    > - win-def:regkeyauditedpermissions_test
    > - win-def:regkeyauditedpermissions53_test
    > - win-def:regkeyeffectiverights_test
    > - win-def:regkeyeffectiverights53_test
    > - ind-def:filehash_test
    > - ind-def:filehash58_test
    > - ind-def:textfilecontent_test
    > - ind-def:textfilecontent54_test
    > - ind-def:xmlfilecontent_test
    >
    > ====================================================
    > Matt Hansbury
    > G022 - Information Assurance Industry Collaboration The MITRE
    Corporation
    > [hidden email] [hidden email]
    >
    > To unsubscribe, send an email message to
    [hidden email] [hidden email] with
    > SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have
    > difficulties, write to
    [hidden email]
    [hidden email].

    To unsubscribe, send an email message to [hidden email]
    [hidden email] with
    SIGNOFF OVAL-DEVELOPER-LIST
    in the BODY of the message. If you have difficulties, write to
    [hidden email]
    [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: Community Call - 8/10/2011

Danny Haynes
Administrator
In reply to this post by Steve Grubb
Hi Steve,

During the call, we discussed how we would be adding documentation to the
independent tests stating that this behavior would only apply to the Windows
platform and should be disregarded for all other platforms.  This would also
mean that the new item entity, used to hold the architecture (e.g. 32-bit,
64-bit, etc.), would be given a status of 'not collected' on all non-Windows
platforms.  Does that help clarify things?  Sorry that we forgot to mention
this in the meeting follow up message.

Thanks,

Danny

>-----Original Message-----
>From: Steve Grubb [mailto:[hidden email]]
>Sent: Thursday, August 11, 2011 1:12 PM
>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>Subject: Re: [OVAL-DEVELOPER-LIST] Community Call - 8/10/2011
>
>On Thursday, August 11, 2011 11:23:00 AM Hansbury, Matt wrote:
>> * Affected Test:
>>
>> -              win-def:file_test
>> -              win-def:fileauditedpermissions_test
>> -              win-def:fileauditedpermissions53_test
>> -              win-def:fileeffectiverights_test
>> -              win-def:fileeffectiverights53_test
>> -              win-def:registry_test,
>> -              win-def:regkeyauditedpermissions_test
>> -              win-def:regkeyauditedpermissions53_test
>> -              win-def:regkeyeffectiverights_test
>> -              win-def:regkeyeffectiverights53_test
>
>vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
>
>> -              ind-def:filehash_test
>> -              ind-def:filehash58_test
>> -              ind-def:textfilecontent_test
>> -              ind-def:textfilecontent54_test
>> -              ind-def:xmlfilecontent_test
>
>^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>Does this mean that the issue is not just Windows? Seems to me that its
>spilling over
>into Linux if tests in the independent schema get touched. How would
>changing these
>tests affect non-Windows platforms? (I didn't attend since it was a windows
>call.)
>
>Thanks,
>-Steve
>
>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-DEVELOPER-
>[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: Community Call - 8/10/2011

Gunnar Engelbach
In reply to this post by joval
Yeah, my examples were more of a tongue-in-cheek exaggeration.  I was
just trying to make the point that 32/64 redirection is not about
architecture and more like emulation.

In a practical sense a rule author is not going to be concerned if
Microsoft Excel is being run inside a Java virtual machine, but is it
possible he might need to consider if it is being run in XP
Compatibility Mode, XP Mode on Windows 7, or in a debugger?  Or to
differentiate between a Windows-native version of a unix command vice
one that is running in Cygwin?

Outside of the name of the attribute and the documented intention for
the scope of it, none of this makes any difference from what has been
proposed, so I'll leave it at that.



On 8/11/2011 2:12 PM, David Solin wrote:

> Well, indeed those are all /emulators/. But an app running in an
> emulator runs no risk of accidentally loading an incompatible library,
> or doing anything else that would call for redirection. I'm just
> wondering, how likely is it that Microsoft will introduce another thing
> that is somewhere between emulation or virtualization, and native
> execution, that will require similar attention.
>
> A 32-bit-app-on-64-bit-OS a bit of a unique case, I think.
>
> 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/11/2011 12:30 PM, Gunnar Engelbach wrote:
>> On 8/11/2011 12:57 PM, David Solin wrote:
>>> This redirection business only applies to "32-bit Windows on 64-bit
>>> Windows" (i.e., WOW), it has nothing really to do with processor
>>> architecture.
>>>
>>> There could be implications if Microsoft decided to emulate x86 at the
>>> OS level by using redirection of the registry and filesystem, but how
>>> likely does that seem? You cannot, for instance, run an x86 application
>>> on Windows Phone or vice-versa...
>>
>> Certainly not as a native application, but via hardware emulation...
>>
>> http://www.amigaforever.com/system/
>> http://mamedev.org/release.html
>> http://www.emulator-zone.com/
>> http://www.ccs64.com/
>>
>>
>> OK, a more serious example:
>>
>> http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=9263
>>
>>
>> But at least accounting for Transmeta is no longer a concern.
>>
>>
>>
>>>
>>> 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/11/2011 11:48 AM, Shane Shaffer wrote:
>>>> While we were on the call yesterday I was searching for other
>>>> architectures on Windows 8, but ultimately doesn't it come down to
>>>> whether or not there is redirection? There could be a dozen different
>>>> true architectures of Windows, but unless you can install conventional
>>>> 32 and 64 bit apps on a Windows 8 phone and you have redirection going
>>>> on for each architecture, does it matter?
>>>> Of course, we've had different architectures before - we had x64 and
>>>> ia64 variants of Windows. We didn't need to indicate a difference in
>>>> those architectures because the registry and file systems behaved the
>>>> same.
>>>> Shane Shaffer
>>>> G2, Inc.
>>>> Technical Director, Security Automation
>>>> [hidden email] <mailto:[hidden email]>
>>>>
>>>>
>>>> On Thu, Aug 11, 2011 at 12:30 PM, Vladimir Giszpenc
>>>> <[hidden email] <mailto:[hidden email]>> wrote:
>>>>
>>>> Matt,
>>>>
>>>> Microsoft claims that Windows 8 will run on ARM 32 bit RISC
>>>> architecture.
>>>> http://www.microsoft.com/presspass/press/2011/jan11/01-05socsupport.mspx
>>>>
>>>> NVIDIA is reportedly working on a 64 bit ARM architecture.
>>>> http://www.brightsideofnews.com/news/2011/3/8/nvidia-project-denver-is-a-64-
>>>> bit-arm-processor-architecture.aspx
>>>> <http://www.brightsideofnews.com/news/2011/3/8/nvidia-project-denver-is-a-64-bit-arm-processor-architecture.aspx>
>>>>
>>>> This is the future I was referring to. It is certainly not yet
>>>> here, but
>>>> Windows 8 should come next year.
>>>>
>>>> Cheers,
>>>>
>>>> Vladimir Giszpenc
>>>> Armadillo Technical Lead
>>>> DSCI Contractor Supporting
>>>> U.S. Army CERDEC S&TCD CSIAD
>>>> Tactical Network Protection Branch
>>>> (732) 542-3113 x1328 <tel:%28732%29%20542-3113%20x1328>
>>>>
>>>> > -----Original Message-----
>>>> > From: Hansbury, Matt [mailto:[hidden email]
>>>> <mailto:[hidden email]>]
>>>> > Sent: Thursday, August 11, 2011 11:23 AM
>>>> > To: [hidden email]
>>>> <mailto:[hidden email]>
>>>> > Subject: [OVAL-DEVELOPER-LIST] Community Call - 8/10/2011
>>>> >
>>>> > All,
>>>> >
>>>> > We had a very productive call yesterday and I would like to
>>>> thank those of
>>>> you
>>>> > that were able to join. The call was attended by around 30 people,
>>>> representing
>>>> > about 15 different organizations.
>>>> >
>>>> > The call started with a brief review of the proposed plan to
>>>> address the
>>>> > uncertainty around assessment of different combination of
>>>> "bitness" on 64
>>>> bit
>>>> > Windows architectures. The proposal included adding the following:
>>>> >
>>>> > 1. A new behavior (called 'target_architecture') for a subset of
>>>> tests
>>>> (the full list
>>>> > is added below*) that will indicate the intended target
>>>> architecture. The
>>>> value
>>>> > for this behavior will be an enumeration that allows for the
>>>> following
>>>> values:
>>>> > a. 32_bit - Indicating an intent to test for 32-bit.
>>>> > b. 64_bit - indicating an intent to test for 64-bit.
>>>> > c. os_native - indicating an intent to test the native
>>>> architecture of
>>>> the target
>>>> > system.
>>>> > 2. A new OVAL Item entity to allow tools to indicate the
>>>> architecture on
>>>> which
>>>> > the OVAL Item was found. This would also be added to OVAL States.
>>>> >
>>>> > The discussion around the proposal was mainly positive to the
>>>> proposal and
>>>> the
>>>> > general consensus appeared to be that these changes were a
>>>> positive step
>>>> in
>>>> > making the author's intent regarding 32 vs. 64 bit more clear
>>>> and provide
>>>> more
>>>> > consistent results across tools. Specifically, the vendor community
>>>> seemed to
>>>> > think that the tool changes were not overly burdensome to them and
>>>> generally
>>>> > seemed to favor the changes.
>>>> >
>>>> > Additionally, content authors also seemed to believe that the
>>>> proposed
>>>> changes
>>>> > would benefit the OVAL Language, and that with the proper
>>>> default setting,
>>>> the
>>>> > burden of re-writing content would be minimal. With regards to the
>>>> proposed
>>>> > default behavior value of '32_bit', it seems that, in general,
>>>> folks were
>>>> more
>>>> > comfortable with using the 'os_native' value, as it more accurately
>>>> reflected the
>>>> > disposition of their content.
>>>> >
>>>> > The group was also asked if there was a use case for adding the
>>>> concept of
>>>> > 'both' to the enumeration, meaning that a check would be
>>>> targeted at both
>>>> 32-
>>>> > bit and 64-bit. No clear consensus was reached here, so the current
>>>> proposal
>>>> > does not include this. Also, given that the enumeration could be
>>>> expanded to
>>>> > other architectures, the name of such a concept would likely be
>>>> 'all', not
>>>> 'both'.
>>>> > If any other folks see a clear use case for this value, please
>>>> let us
>>>> know.
>>>> >
>>>> > Lastly, it was also brought up that the environment variable
>>>> test may also
>>>> > require this behavior. More research is required to determine if
>>>> that is
>>>> the case.
>>>> >
>>>> > As follow up to this call, the MITRE team is going to do the
>>>> following:
>>>> >
>>>> > 1. Research the OVAL Repository to confirm the best value for
>>>> the default
>>>> > behavior value. (This would be highly recommended as well, for
>>>> any other
>>>> > content owners out there.) 2. Consider whether an 'all' behavior
>>>> enumeration
>>>> > value is required by any use cases.
>>>> > 3. Begin implementation of the above proposal for inclusion in
>>>> the OVAL
>>>> 5.10
>>>> > version.
>>>> > 4. Consider whether the environment variable test needs to be
>>>> included in
>>>> > discussion.
>>>> >
>>>> > Also note that the MITRE team announced their intent to push
>>>> back the OVAL
>>>> > 5.10 version release by some amount of time to accommodate these
>>>> changes.
>>>> > A formal announcement regarding the new release date will be
>>>> sent out soon
>>>> to
>>>> > confirm this.
>>>> >
>>>> > Thanks
>>>> > Matt
>>>> >
>>>> >
>>>> > * Affected Test:
>>>> >
>>>> > - win-def:file_test
>>>> > - win-def:fileauditedpermissions_test
>>>> > - win-def:fileauditedpermissions53_test
>>>> > - win-def:fileeffectiverights_test
>>>> > - win-def:fileeffectiverights53_test
>>>> > - win-def:registry_test,
>>>> > - win-def:regkeyauditedpermissions_test
>>>> > - win-def:regkeyauditedpermissions53_test
>>>> > - win-def:regkeyeffectiverights_test
>>>> > - win-def:regkeyeffectiverights53_test
>>>> > - ind-def:filehash_test
>>>> > - ind-def:filehash58_test
>>>> > - ind-def:textfilecontent_test
>>>> > - ind-def:textfilecontent54_test
>>>> > - ind-def:xmlfilecontent_test
>>>> >
>>>> > ====================================================
>>>> > Matt Hansbury
>>>> > G022 - Information Assurance Industry Collaboration The MITRE
>>>> Corporation
>>>> > [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].
>>
>> 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: Community Call - 8/10/2011

KenSimone
I think we're making this overly complex. Perhaps the behavior should just be called "OS redirection", and the settings should be "32 bit" or "none". If Microsoft adds more redirection scenarios, we can add those to the enumeration as needed.

Also, we didn't talk about what the collected item reports as the path/key. I think it should always be the full, non-redirected path. If the collected item contains the redirected path, then it makes it harder for consumers of the OVAL results to act on the information. If I'm a sys admin, and I've got a result file that states permissions are wrong, I'd much rather have the complete "wow64" path than the 32 bit path to work off of. This also removes the need for the additional entity item specifying "bitness".

Lastly, I just want to champion one more time the idea that the default should be "os native" (or in my proposed alternative above, "none"). The OVAL spec has never mentioned anything about accommodating redirection, and so this is really the only choice that's backwards compatible with the spec, in my opinion.

Ken

-----Original Message-----
From: Gunnar Engelbach [mailto:[hidden email]]
Sent: Thursday, August 11, 2011 1:47 PM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] Community Call - 8/10/2011

Yeah, my examples were more of a tongue-in-cheek exaggeration.  I was just trying to make the point that 32/64 redirection is not about architecture and more like emulation.

In a practical sense a rule author is not going to be concerned if Microsoft Excel is being run inside a Java virtual machine, but is it possible he might need to consider if it is being run in XP Compatibility Mode, XP Mode on Windows 7, or in a debugger?  Or to differentiate between a Windows-native version of a unix command vice one that is running in Cygwin?

Outside of the name of the attribute and the documented intention for the scope of it, none of this makes any difference from what has been proposed, so I'll leave it at that.



On 8/11/2011 2:12 PM, David Solin wrote:

> Well, indeed those are all /emulators/. But an app running in an
> emulator runs no risk of accidentally loading an incompatible library,
> or doing anything else that would call for redirection. I'm just
> wondering, how likely is it that Microsoft will introduce another
> thing that is somewhere between emulation or virtualization, and
> native execution, that will require similar attention.
>
> A 32-bit-app-on-64-bit-OS a bit of a unique case, I think.
>
> 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/11/2011 12:30 PM, Gunnar Engelbach wrote:
>> On 8/11/2011 12:57 PM, David Solin wrote:
>>> This redirection business only applies to "32-bit Windows on 64-bit
>>> Windows" (i.e., WOW), it has nothing really to do with processor
>>> architecture.
>>>
>>> There could be implications if Microsoft decided to emulate x86 at
>>> the OS level by using redirection of the registry and filesystem,
>>> but how likely does that seem? You cannot, for instance, run an x86
>>> application on Windows Phone or vice-versa...
>>
>> Certainly not as a native application, but via hardware emulation...
>>
>> http://www.amigaforever.com/system/
>> http://mamedev.org/release.html
>> http://www.emulator-zone.com/
>> http://www.ccs64.com/
>>
>>
>> OK, a more serious example:
>>
>> http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=9
>> 263
>>
>>
>> But at least accounting for Transmeta is no longer a concern.
>>
>>
>>
>>>
>>> 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/11/2011 11:48 AM, Shane Shaffer wrote:
>>>> While we were on the call yesterday I was searching for other
>>>> architectures on Windows 8, but ultimately doesn't it come down to
>>>> whether or not there is redirection? There could be a dozen
>>>> different true architectures of Windows, but unless you can install
>>>> conventional
>>>> 32 and 64 bit apps on a Windows 8 phone and you have redirection
>>>> going on for each architecture, does it matter?
>>>> Of course, we've had different architectures before - we had x64
>>>> and
>>>> ia64 variants of Windows. We didn't need to indicate a difference
>>>> in those architectures because the registry and file systems
>>>> behaved the same.
>>>> Shane Shaffer
>>>> G2, Inc.
>>>> Technical Director, Security Automation [hidden email]
>>>> <mailto:[hidden email]>
>>>>
>>>>
>>>> On Thu, Aug 11, 2011 at 12:30 PM, Vladimir Giszpenc
>>>> <[hidden email] <mailto:[hidden email]>> wrote:
>>>>
>>>> Matt,
>>>>
>>>> Microsoft claims that Windows 8 will run on ARM 32 bit RISC
>>>> architecture.
>>>> http://www.microsoft.com/presspass/press/2011/jan11/01-05socsupport
>>>> .mspx
>>>>
>>>> NVIDIA is reportedly working on a 64 bit ARM architecture.
>>>> http://www.brightsideofnews.com/news/2011/3/8/nvidia-project-denver
>>>> -is-a-64- bit-arm-processor-architecture.aspx
>>>> <http://www.brightsideofnews.com/news/2011/3/8/nvidia-project-denve
>>>> r-is-a-64-bit-arm-processor-architecture.aspx>
>>>>
>>>> This is the future I was referring to. It is certainly not yet
>>>> here, but Windows 8 should come next year.
>>>>
>>>> Cheers,
>>>>
>>>> Vladimir Giszpenc
>>>> Armadillo Technical Lead
>>>> DSCI Contractor Supporting
>>>> U.S. Army CERDEC S&TCD CSIAD
>>>> Tactical Network Protection Branch
>>>> (732) 542-3113 x1328 <tel:%28732%29%20542-3113%20x1328>
>>>>
>>>> > -----Original Message-----
>>>> > From: Hansbury, Matt [mailto:[hidden email]
>>>> <mailto:[hidden email]>]
>>>> > Sent: Thursday, August 11, 2011 11:23 AM
>>>> > To: [hidden email]
>>>> <mailto:[hidden email]>
>>>> > Subject: [OVAL-DEVELOPER-LIST] Community Call - 8/10/2011
>>>> >
>>>> > All,
>>>> >
>>>> > We had a very productive call yesterday and I would like to
>>>> thank those of
>>>> you
>>>> > that were able to join. The call was attended by around 30
>>>> > people,
>>>> representing
>>>> > about 15 different organizations.
>>>> >
>>>> > The call started with a brief review of the proposed plan to
>>>> address the
>>>> > uncertainty around assessment of different combination of
>>>> "bitness" on 64
>>>> bit
>>>> > Windows architectures. The proposal included adding the following:
>>>> >
>>>> > 1. A new behavior (called 'target_architecture') for a subset of
>>>> tests
>>>> (the full list
>>>> > is added below*) that will indicate the intended target
>>>> architecture. The
>>>> value
>>>> > for this behavior will be an enumeration that allows for the
>>>> following
>>>> values:
>>>> > a. 32_bit - Indicating an intent to test for 32-bit.
>>>> > b. 64_bit - indicating an intent to test for 64-bit.
>>>> > c. os_native - indicating an intent to test the native
>>>> architecture of
>>>> the target
>>>> > system.
>>>> > 2. A new OVAL Item entity to allow tools to indicate the
>>>> architecture on
>>>> which
>>>> > the OVAL Item was found. This would also be added to OVAL States.
>>>> >
>>>> > The discussion around the proposal was mainly positive to the
>>>> proposal and
>>>> the
>>>> > general consensus appeared to be that these changes were a
>>>> positive step
>>>> in
>>>> > making the author's intent regarding 32 vs. 64 bit more clear
>>>> and provide
>>>> more
>>>> > consistent results across tools. Specifically, the vendor
>>>> > community
>>>> seemed to
>>>> > think that the tool changes were not overly burdensome to them
>>>> > and
>>>> generally
>>>> > seemed to favor the changes.
>>>> >
>>>> > Additionally, content authors also seemed to believe that the
>>>> proposed
>>>> changes
>>>> > would benefit the OVAL Language, and that with the proper
>>>> default setting,
>>>> the
>>>> > burden of re-writing content would be minimal. With regards to
>>>> > the
>>>> proposed
>>>> > default behavior value of '32_bit', it seems that, in general,
>>>> folks were
>>>> more
>>>> > comfortable with using the 'os_native' value, as it more
>>>> > accurately
>>>> reflected the
>>>> > disposition of their content.
>>>> >
>>>> > The group was also asked if there was a use case for adding the
>>>> concept of
>>>> > 'both' to the enumeration, meaning that a check would be
>>>> targeted at both
>>>> 32-
>>>> > bit and 64-bit. No clear consensus was reached here, so the
>>>> > current
>>>> proposal
>>>> > does not include this. Also, given that the enumeration could be
>>>> expanded to
>>>> > other architectures, the name of such a concept would likely be
>>>> 'all', not
>>>> 'both'.
>>>> > If any other folks see a clear use case for this value, please
>>>> let us
>>>> know.
>>>> >
>>>> > Lastly, it was also brought up that the environment variable
>>>> test may also
>>>> > require this behavior. More research is required to determine if
>>>> that is
>>>> the case.
>>>> >
>>>> > As follow up to this call, the MITRE team is going to do the
>>>> following:
>>>> >
>>>> > 1. Research the OVAL Repository to confirm the best value for
>>>> the default
>>>> > behavior value. (This would be highly recommended as well, for
>>>> any other
>>>> > content owners out there.) 2. Consider whether an 'all' behavior
>>>> enumeration
>>>> > value is required by any use cases.
>>>> > 3. Begin implementation of the above proposal for inclusion in
>>>> the OVAL
>>>> 5.10
>>>> > version.
>>>> > 4. Consider whether the environment variable test needs to be
>>>> included in
>>>> > discussion.
>>>> >
>>>> > Also note that the MITRE team announced their intent to push
>>>> back the OVAL
>>>> > 5.10 version release by some amount of time to accommodate these
>>>> changes.
>>>> > A formal announcement regarding the new release date will be
>>>> sent out soon
>>>> to
>>>> > confirm this.
>>>> >
>>>> > Thanks
>>>> > Matt
>>>> >
>>>> >
>>>> > * Affected Test:
>>>> >
>>>> > - win-def:file_test
>>>> > - win-def:fileauditedpermissions_test
>>>> > - win-def:fileauditedpermissions53_test
>>>> > - win-def:fileeffectiverights_test
>>>> > - win-def:fileeffectiverights53_test
>>>> > - win-def:registry_test,
>>>> > - win-def:regkeyauditedpermissions_test
>>>> > - win-def:regkeyauditedpermissions53_test
>>>> > - win-def:regkeyeffectiverights_test
>>>> > - win-def:regkeyeffectiverights53_test
>>>> > - ind-def:filehash_test
>>>> > - ind-def:filehash58_test
>>>> > - ind-def:textfilecontent_test
>>>> > - ind-def:textfilecontent54_test
>>>> > - ind-def:xmlfilecontent_test
>>>> >
>>>> > ====================================================
>>>> > Matt Hansbury
>>>> > G022 - Information Assurance Industry Collaboration The MITRE
>>>> Corporation
>>>> > [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].
>>
>> 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: Community Call - 8/10/2011

Kurt Dillard
I agree Ken, well stated.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]]
Sent: Thursday, August 11, 2011 12:13 PM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] Community Call - 8/10/2011

I think we're making this overly complex. Perhaps the behavior should just
be called "OS redirection", and the settings should be "32 bit" or "none".
If Microsoft adds more redirection scenarios, we can add those to the
enumeration as needed.

Also, we didn't talk about what the collected item reports as the path/key.
I think it should always be the full, non-redirected path. If the collected
item contains the redirected path, then it makes it harder for consumers of
the OVAL results to act on the information. If I'm a sys admin, and I've got
a result file that states permissions are wrong, I'd much rather have the
complete "wow64" path than the 32 bit path to work off of. This also removes
the need for the additional entity item specifying "bitness".

Lastly, I just want to champion one more time the idea that the default
should be "os native" (or in my proposed alternative above, "none"). The
OVAL spec has never mentioned anything about accommodating redirection, and
so this is really the only choice that's backwards compatible with the spec,
in my opinion.

Ken

-----Original Message-----
From: Gunnar Engelbach [mailto:[hidden email]]
Sent: Thursday, August 11, 2011 1:47 PM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] Community Call - 8/10/2011

Yeah, my examples were more of a tongue-in-cheek exaggeration.  I was just
trying to make the point that 32/64 redirection is not about architecture
and more like emulation.

In a practical sense a rule author is not going to be concerned if Microsoft
Excel is being run inside a Java virtual machine, but is it possible he
might need to consider if it is being run in XP Compatibility Mode, XP Mode
on Windows 7, or in a debugger?  Or to differentiate between a
Windows-native version of a unix command vice one that is running in Cygwin?

Outside of the name of the attribute and the documented intention for the
scope of it, none of this makes any difference from what has been proposed,
so I'll leave it at that.



On 8/11/2011 2:12 PM, David Solin wrote:

> Well, indeed those are all /emulators/. But an app running in an
> emulator runs no risk of accidentally loading an incompatible library,
> or doing anything else that would call for redirection. I'm just
> wondering, how likely is it that Microsoft will introduce another
> thing that is somewhere between emulation or virtualization, and
> native execution, that will require similar attention.
>
> A 32-bit-app-on-64-bit-OS a bit of a unique case, I think.
>
> 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/11/2011 12:30 PM, Gunnar Engelbach wrote:
>> On 8/11/2011 12:57 PM, David Solin wrote:
>>> This redirection business only applies to "32-bit Windows on 64-bit
>>> Windows" (i.e., WOW), it has nothing really to do with processor
>>> architecture.
>>>
>>> There could be implications if Microsoft decided to emulate x86 at
>>> the OS level by using redirection of the registry and filesystem,
>>> but how likely does that seem? You cannot, for instance, run an x86
>>> application on Windows Phone or vice-versa...
>>
>> Certainly not as a native application, but via hardware emulation...
>>
>> http://www.amigaforever.com/system/
>> http://mamedev.org/release.html
>> http://www.emulator-zone.com/
>> http://www.ccs64.com/
>>
>>
>> OK, a more serious example:
>>
>> http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=9
>> 263
>>
>>
>> But at least accounting for Transmeta is no longer a concern.
>>
>>
>>
>>>
>>> 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/11/2011 11:48 AM, Shane Shaffer wrote:
>>>> While we were on the call yesterday I was searching for other
>>>> architectures on Windows 8, but ultimately doesn't it come down to
>>>> whether or not there is redirection? There could be a dozen
>>>> different true architectures of Windows, but unless you can install
>>>> conventional
>>>> 32 and 64 bit apps on a Windows 8 phone and you have redirection
>>>> going on for each architecture, does it matter?
>>>> Of course, we've had different architectures before - we had x64
>>>> and
>>>> ia64 variants of Windows. We didn't need to indicate a difference
>>>> in those architectures because the registry and file systems
>>>> behaved the same.
>>>> Shane Shaffer
>>>> G2, Inc.
>>>> Technical Director, Security Automation [hidden email]
>>>> <mailto:[hidden email]>
>>>>
>>>>
>>>> On Thu, Aug 11, 2011 at 12:30 PM, Vladimir Giszpenc
>>>> <[hidden email] <mailto:[hidden email]>> wrote:
>>>>
>>>> Matt,
>>>>
>>>> Microsoft claims that Windows 8 will run on ARM 32 bit RISC
>>>> architecture.
>>>> http://www.microsoft.com/presspass/press/2011/jan11/01-05socsupport
>>>> .mspx
>>>>
>>>> NVIDIA is reportedly working on a 64 bit ARM architecture.
>>>> http://www.brightsideofnews.com/news/2011/3/8/nvidia-project-denver
>>>> -is-a-64- bit-arm-processor-architecture.aspx
>>>> <http://www.brightsideofnews.com/news/2011/3/8/nvidia-project-denve
>>>> r-is-a-64-bit-arm-processor-architecture.aspx>
>>>>
>>>> This is the future I was referring to. It is certainly not yet
>>>> here, but Windows 8 should come next year.
>>>>
>>>> Cheers,
>>>>
>>>> Vladimir Giszpenc
>>>> Armadillo Technical Lead
>>>> DSCI Contractor Supporting
>>>> U.S. Army CERDEC S&TCD CSIAD
>>>> Tactical Network Protection Branch
>>>> (732) 542-3113 x1328 <tel:%28732%29%20542-3113%20x1328>
>>>>
>>>> > -----Original Message-----
>>>> > From: Hansbury, Matt [mailto:[hidden email]
>>>> <mailto:[hidden email]>]
>>>> > Sent: Thursday, August 11, 2011 11:23 AM
>>>> > To: [hidden email]
>>>> <mailto:[hidden email]>
>>>> > Subject: [OVAL-DEVELOPER-LIST] Community Call - 8/10/2011
>>>> >
>>>> > All,
>>>> >
>>>> > We had a very productive call yesterday and I would like to
>>>> thank those of
>>>> you
>>>> > that were able to join. The call was attended by around 30
>>>> > people,
>>>> representing
>>>> > about 15 different organizations.
>>>> >
>>>> > The call started with a brief review of the proposed plan to
>>>> address the
>>>> > uncertainty around assessment of different combination of
>>>> "bitness" on 64
>>>> bit
>>>> > Windows architectures. The proposal included adding the following:
>>>> >
>>>> > 1. A new behavior (called 'target_architecture') for a subset of
>>>> tests
>>>> (the full list
>>>> > is added below*) that will indicate the intended target
>>>> architecture. The
>>>> value
>>>> > for this behavior will be an enumeration that allows for the
>>>> following
>>>> values:
>>>> > a. 32_bit - Indicating an intent to test for 32-bit.
>>>> > b. 64_bit - indicating an intent to test for 64-bit.
>>>> > c. os_native - indicating an intent to test the native
>>>> architecture of
>>>> the target
>>>> > system.
>>>> > 2. A new OVAL Item entity to allow tools to indicate the
>>>> architecture on
>>>> which
>>>> > the OVAL Item was found. This would also be added to OVAL States.
>>>> >
>>>> > The discussion around the proposal was mainly positive to the
>>>> proposal and
>>>> the
>>>> > general consensus appeared to be that these changes were a
>>>> positive step
>>>> in
>>>> > making the author's intent regarding 32 vs. 64 bit more clear
>>>> and provide
>>>> more
>>>> > consistent results across tools. Specifically, the vendor
>>>> > community
>>>> seemed to
>>>> > think that the tool changes were not overly burdensome to them
>>>> > and
>>>> generally
>>>> > seemed to favor the changes.
>>>> >
>>>> > Additionally, content authors also seemed to believe that the
>>>> proposed
>>>> changes
>>>> > would benefit the OVAL Language, and that with the proper
>>>> default setting,
>>>> the
>>>> > burden of re-writing content would be minimal. With regards to
>>>> > the
>>>> proposed
>>>> > default behavior value of '32_bit', it seems that, in general,
>>>> folks were
>>>> more
>>>> > comfortable with using the 'os_native' value, as it more
>>>> > accurately
>>>> reflected the
>>>> > disposition of their content.
>>>> >
>>>> > The group was also asked if there was a use case for adding the
>>>> concept of
>>>> > 'both' to the enumeration, meaning that a check would be
>>>> targeted at both
>>>> 32-
>>>> > bit and 64-bit. No clear consensus was reached here, so the
>>>> > current
>>>> proposal
>>>> > does not include this. Also, given that the enumeration could be
>>>> expanded to
>>>> > other architectures, the name of such a concept would likely be
>>>> 'all', not
>>>> 'both'.
>>>> > If any other folks see a clear use case for this value, please
>>>> let us
>>>> know.
>>>> >
>>>> > Lastly, it was also brought up that the environment variable
>>>> test may also
>>>> > require this behavior. More research is required to determine if
>>>> that is
>>>> the case.
>>>> >
>>>> > As follow up to this call, the MITRE team is going to do the
>>>> following:
>>>> >
>>>> > 1. Research the OVAL Repository to confirm the best value for
>>>> the default
>>>> > behavior value. (This would be highly recommended as well, for
>>>> any other
>>>> > content owners out there.) 2. Consider whether an 'all' behavior
>>>> enumeration
>>>> > value is required by any use cases.
>>>> > 3. Begin implementation of the above proposal for inclusion in
>>>> the OVAL
>>>> 5.10
>>>> > version.
>>>> > 4. Consider whether the environment variable test needs to be
>>>> included in
>>>> > discussion.
>>>> >
>>>> > Also note that the MITRE team announced their intent to push
>>>> back the OVAL
>>>> > 5.10 version release by some amount of time to accommodate these
>>>> changes.
>>>> > A formal announcement regarding the new release date will be
>>>> sent out soon
>>>> to
>>>> > confirm this.
>>>> >
>>>> > Thanks
>>>> > Matt
>>>> >
>>>> >
>>>> > * Affected Test:
>>>> >
>>>> > - win-def:file_test
>>>> > - win-def:fileauditedpermissions_test
>>>> > - win-def:fileauditedpermissions53_test
>>>> > - win-def:fileeffectiverights_test
>>>> > - win-def:fileeffectiverights53_test
>>>> > - win-def:registry_test,
>>>> > - win-def:regkeyauditedpermissions_test
>>>> > - win-def:regkeyauditedpermissions53_test
>>>> > - win-def:regkeyeffectiverights_test
>>>> > - win-def:regkeyeffectiverights53_test
>>>> > - ind-def:filehash_test
>>>> > - ind-def:filehash58_test
>>>> > - ind-def:textfilecontent_test
>>>> > - ind-def:textfilecontent54_test
>>>> > - ind-def:xmlfilecontent_test
>>>> >
>>>> > ====================================================
>>>> > Matt Hansbury
>>>> > G022 - Information Assurance Industry Collaboration The MITRE
>>>> Corporation
>>>> > [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].
>>
>> 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: Community Call - 8/10/2011

Gunnar Engelbach
Except that it presumes that a 64-bit OS will only ever get assessed by
a 64-bit application.  But it's entirely possible to do it from a 32-bit
application, which is also an important consideration for remote
agentless assessments.

My perspective is that a rule should be considered agnostic to
redirection unless there is a reason why that would be inaccurate, in
which case the content author should have a way to indicate under which
conditions the rule would be accurate.


On 8/11/2011 4:05 PM, Kurt Dillard wrote:

> I agree Ken, well stated.
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]]
> Sent: Thursday, August 11, 2011 12:13 PM
> To: [hidden email]
> Subject: Re: [OVAL-DEVELOPER-LIST] Community Call - 8/10/2011
>
> I think we're making this overly complex. Perhaps the behavior should just
> be called "OS redirection", and the settings should be "32 bit" or "none".
> If Microsoft adds more redirection scenarios, we can add those to the
> enumeration as needed.
>
> Also, we didn't talk about what the collected item reports as the path/key.
> I think it should always be the full, non-redirected path. If the collected
> item contains the redirected path, then it makes it harder for consumers of
> the OVAL results to act on the information. If I'm a sys admin, and I've got
> a result file that states permissions are wrong, I'd much rather have the
> complete "wow64" path than the 32 bit path to work off of. This also removes
> the need for the additional entity item specifying "bitness".
>
> Lastly, I just want to champion one more time the idea that the default
> should be "os native" (or in my proposed alternative above, "none"). The
> OVAL spec has never mentioned anything about accommodating redirection, and
> so this is really the only choice that's backwards compatible with the spec,
> in my opinion.
>
> Ken
>
> -----Original Message-----
> From: Gunnar Engelbach [mailto:[hidden email]]
> Sent: Thursday, August 11, 2011 1:47 PM
> To: [hidden email]
> Subject: Re: [OVAL-DEVELOPER-LIST] Community Call - 8/10/2011
>
> Yeah, my examples were more of a tongue-in-cheek exaggeration.  I was just
> trying to make the point that 32/64 redirection is not about architecture
> and more like emulation.
>
> In a practical sense a rule author is not going to be concerned if Microsoft
> Excel is being run inside a Java virtual machine, but is it possible he
> might need to consider if it is being run in XP Compatibility Mode, XP Mode
> on Windows 7, or in a debugger?  Or to differentiate between a
> Windows-native version of a unix command vice one that is running in Cygwin?
>
> Outside of the name of the attribute and the documented intention for the
> scope of it, none of this makes any difference from what has been proposed,
> so I'll leave it at that.
>
>
>
> On 8/11/2011 2:12 PM, David Solin wrote:
>> Well, indeed those are all /emulators/. But an app running in an
>> emulator runs no risk of accidentally loading an incompatible library,
>> or doing anything else that would call for redirection. I'm just
>> wondering, how likely is it that Microsoft will introduce another
>> thing that is somewhere between emulation or virtualization, and
>> native execution, that will require similar attention.
>>
>> A 32-bit-app-on-64-bit-OS a bit of a unique case, I think.
>>
>> 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/11/2011 12:30 PM, Gunnar Engelbach wrote:
>>> On 8/11/2011 12:57 PM, David Solin wrote:
>>>> This redirection business only applies to "32-bit Windows on 64-bit
>>>> Windows" (i.e., WOW), it has nothing really to do with processor
>>>> architecture.
>>>>
>>>> There could be implications if Microsoft decided to emulate x86 at
>>>> the OS level by using redirection of the registry and filesystem,
>>>> but how likely does that seem? You cannot, for instance, run an x86
>>>> application on Windows Phone or vice-versa...
>>>
>>> Certainly not as a native application, but via hardware emulation...
>>>
>>> http://www.amigaforever.com/system/
>>> http://mamedev.org/release.html
>>> http://www.emulator-zone.com/
>>> http://www.ccs64.com/
>>>
>>>
>>> OK, a more serious example:
>>>
>>> http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=9
>>> 263
>>>
>>>
>>> But at least accounting for Transmeta is no longer a concern.
>>>
>>>
>>>
>>>>
>>>> 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/11/2011 11:48 AM, Shane Shaffer wrote:
>>>>> While we were on the call yesterday I was searching for other
>>>>> architectures on Windows 8, but ultimately doesn't it come down to
>>>>> whether or not there is redirection? There could be a dozen
>>>>> different true architectures of Windows, but unless you can install
>>>>> conventional
>>>>> 32 and 64 bit apps on a Windows 8 phone and you have redirection
>>>>> going on for each architecture, does it matter?
>>>>> Of course, we've had different architectures before - we had x64
>>>>> and
>>>>> ia64 variants of Windows. We didn't need to indicate a difference
>>>>> in those architectures because the registry and file systems
>>>>> behaved the same.
>>>>> Shane Shaffer
>>>>> G2, Inc.
>>>>> Technical Director, Security Automation [hidden email]
>>>>> <mailto:[hidden email]>
>>>>>
>>>>>
>>>>> On Thu, Aug 11, 2011 at 12:30 PM, Vladimir Giszpenc
>>>>> <[hidden email]<mailto:[hidden email]>>  wrote:
>>>>>
>>>>> Matt,
>>>>>
>>>>> Microsoft claims that Windows 8 will run on ARM 32 bit RISC
>>>>> architecture.
>>>>> http://www.microsoft.com/presspass/press/2011/jan11/01-05socsupport
>>>>> .mspx
>>>>>
>>>>> NVIDIA is reportedly working on a 64 bit ARM architecture.
>>>>> http://www.brightsideofnews.com/news/2011/3/8/nvidia-project-denver
>>>>> -is-a-64- bit-arm-processor-architecture.aspx
>>>>> <http://www.brightsideofnews.com/news/2011/3/8/nvidia-project-denve
>>>>> r-is-a-64-bit-arm-processor-architecture.aspx>
>>>>>
>>>>> This is the future I was referring to. It is certainly not yet
>>>>> here, but Windows 8 should come next year.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Vladimir Giszpenc
>>>>> Armadillo Technical Lead
>>>>> DSCI Contractor Supporting
>>>>> U.S. Army CERDEC S&TCD CSIAD
>>>>> Tactical Network Protection Branch
>>>>> (732) 542-3113 x1328<tel:%28732%29%20542-3113%20x1328>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Hansbury, Matt [mailto:[hidden email]
>>>>> <mailto:[hidden email]>]
>>>>>> Sent: Thursday, August 11, 2011 11:23 AM
>>>>>> To: [hidden email]
>>>>> <mailto:[hidden email]>
>>>>>> Subject: [OVAL-DEVELOPER-LIST] Community Call - 8/10/2011
>>>>>>
>>>>>> All,
>>>>>>
>>>>>> We had a very productive call yesterday and I would like to
>>>>> thank those of
>>>>> you
>>>>>> that were able to join. The call was attended by around 30
>>>>>> people,
>>>>> representing
>>>>>> about 15 different organizations.
>>>>>>
>>>>>> The call started with a brief review of the proposed plan to
>>>>> address the
>>>>>> uncertainty around assessment of different combination of
>>>>> "bitness" on 64
>>>>> bit
>>>>>> Windows architectures. The proposal included adding the following:
>>>>>>
>>>>>> 1. A new behavior (called 'target_architecture') for a subset of
>>>>> tests
>>>>> (the full list
>>>>>> is added below*) that will indicate the intended target
>>>>> architecture. The
>>>>> value
>>>>>> for this behavior will be an enumeration that allows for the
>>>>> following
>>>>> values:
>>>>>> a. 32_bit - Indicating an intent to test for 32-bit.
>>>>>> b. 64_bit - indicating an intent to test for 64-bit.
>>>>>> c. os_native - indicating an intent to test the native
>>>>> architecture of
>>>>> the target
>>>>>> system.
>>>>>> 2. A new OVAL Item entity to allow tools to indicate the
>>>>> architecture on
>>>>> which
>>>>>> the OVAL Item was found. This would also be added to OVAL States.
>>>>>>
>>>>>> The discussion around the proposal was mainly positive to the
>>>>> proposal and
>>>>> the
>>>>>> general consensus appeared to be that these changes were a
>>>>> positive step
>>>>> in
>>>>>> making the author's intent regarding 32 vs. 64 bit more clear
>>>>> and provide
>>>>> more
>>>>>> consistent results across tools. Specifically, the vendor
>>>>>> community
>>>>> seemed to
>>>>>> think that the tool changes were not overly burdensome to them
>>>>>> and
>>>>> generally
>>>>>> seemed to favor the changes.
>>>>>>
>>>>>> Additionally, content authors also seemed to believe that the
>>>>> proposed
>>>>> changes
>>>>>> would benefit the OVAL Language, and that with the proper
>>>>> default setting,
>>>>> the
>>>>>> burden of re-writing content would be minimal. With regards to
>>>>>> the
>>>>> proposed
>>>>>> default behavior value of '32_bit', it seems that, in general,
>>>>> folks were
>>>>> more
>>>>>> comfortable with using the 'os_native' value, as it more
>>>>>> accurately
>>>>> reflected the
>>>>>> disposition of their content.
>>>>>>
>>>>>> The group was also asked if there was a use case for adding the
>>>>> concept of
>>>>>> 'both' to the enumeration, meaning that a check would be
>>>>> targeted at both
>>>>> 32-
>>>>>> bit and 64-bit. No clear consensus was reached here, so the
>>>>>> current
>>>>> proposal
>>>>>> does not include this. Also, given that the enumeration could be
>>>>> expanded to
>>>>>> other architectures, the name of such a concept would likely be
>>>>> 'all', not
>>>>> 'both'.
>>>>>> If any other folks see a clear use case for this value, please
>>>>> let us
>>>>> know.
>>>>>>
>>>>>> Lastly, it was also brought up that the environment variable
>>>>> test may also
>>>>>> require this behavior. More research is required to determine if
>>>>> that is
>>>>> the case.
>>>>>>
>>>>>> As follow up to this call, the MITRE team is going to do the
>>>>> following:
>>>>>>
>>>>>> 1. Research the OVAL Repository to confirm the best value for
>>>>> the default
>>>>>> behavior value. (This would be highly recommended as well, for
>>>>> any other
>>>>>> content owners out there.) 2. Consider whether an 'all' behavior
>>>>> enumeration
>>>>>> value is required by any use cases.
>>>>>> 3. Begin implementation of the above proposal for inclusion in
>>>>> the OVAL
>>>>> 5.10
>>>>>> version.
>>>>>> 4. Consider whether the environment variable test needs to be
>>>>> included in
>>>>>> discussion.
>>>>>>
>>>>>> Also note that the MITRE team announced their intent to push
>>>>> back the OVAL
>>>>>> 5.10 version release by some amount of time to accommodate these
>>>>> changes.
>>>>>> A formal announcement regarding the new release date will be
>>>>> sent out soon
>>>>> to
>>>>>> confirm this.
>>>>>>
>>>>>> Thanks
>>>>>> Matt
>>>>>>
>>>>>>
>>>>>> * Affected Test:
>>>>>>
>>>>>> - win-def:file_test
>>>>>> - win-def:fileauditedpermissions_test
>>>>>> - win-def:fileauditedpermissions53_test
>>>>>> - win-def:fileeffectiverights_test
>>>>>> - win-def:fileeffectiverights53_test
>>>>>> - win-def:registry_test,
>>>>>> - win-def:regkeyauditedpermissions_test
>>>>>> - win-def:regkeyauditedpermissions53_test
>>>>>> - win-def:regkeyeffectiverights_test
>>>>>> - win-def:regkeyeffectiverights53_test
>>>>>> - ind-def:filehash_test
>>>>>> - ind-def:filehash58_test
>>>>>> - ind-def:textfilecontent_test
>>>>>> - ind-def:textfilecontent54_test
>>>>>> - ind-def:xmlfilecontent_test
>>>>>>
>>>>>> ====================================================
>>>>>> Matt Hansbury
>>>>>> G022 - Information Assurance Industry Collaboration The MITRE
>>>>> Corporation
>>>>>> [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].
>>>
>>> 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: Community Call - 8/10/2011

KenSimone
>> Except that it presumes that a 64-bit OS will only ever get assessed by a 64-bit application.
>> But it's entirely possible to do it from a 32-bit application, which is also an important consideration for remote agentless assessments.

How does it presume that? It very clearly states that the content either wants no re-direction, or 32 bit redirection. It's independent of the engine.

>> My perspective is that a rule should be considered agnostic to redirection unless there is a reason why that would be
>> inaccurate, in which case the content author should have a way to indicate under which conditions the rule would be accurate.

I'm not sure I understand what you mean by agnostic in this case. Can you please explain?

Thanks,
Ken

-----Original Message-----
From: Gunnar Engelbach [mailto:[hidden email]]
Sent: Thursday, August 11, 2011 3:35 PM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] Community Call - 8/10/2011

Except that it presumes that a 64-bit OS will only ever get assessed by a 64-bit application.  But it's entirely possible to do it from a 32-bit application, which is also an important consideration for remote agentless assessments.

My perspective is that a rule should be considered agnostic to redirection unless there is a reason why that would be inaccurate, in which case the content author should have a way to indicate under which conditions the rule would be accurate.


On 8/11/2011 4:05 PM, Kurt Dillard wrote:

> I agree Ken, well stated.
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]]
> Sent: Thursday, August 11, 2011 12:13 PM
> To: [hidden email]
> Subject: Re: [OVAL-DEVELOPER-LIST] Community Call - 8/10/2011
>
> I think we're making this overly complex. Perhaps the behavior should
> just be called "OS redirection", and the settings should be "32 bit" or "none".
> If Microsoft adds more redirection scenarios, we can add those to the
> enumeration as needed.
>
> Also, we didn't talk about what the collected item reports as the path/key.
> I think it should always be the full, non-redirected path. If the
> collected item contains the redirected path, then it makes it harder
> for consumers of the OVAL results to act on the information. If I'm a
> sys admin, and I've got a result file that states permissions are
> wrong, I'd much rather have the complete "wow64" path than the 32 bit
> path to work off of. This also removes the need for the additional entity item specifying "bitness".
>
> Lastly, I just want to champion one more time the idea that the
> default should be "os native" (or in my proposed alternative above,
> "none"). The OVAL spec has never mentioned anything about
> accommodating redirection, and so this is really the only choice
> that's backwards compatible with the spec, in my opinion.
>
> Ken
>
> -----Original Message-----
> From: Gunnar Engelbach [mailto:[hidden email]]
> Sent: Thursday, August 11, 2011 1:47 PM
> To: [hidden email]
> Subject: Re: [OVAL-DEVELOPER-LIST] Community Call - 8/10/2011
>
> Yeah, my examples were more of a tongue-in-cheek exaggeration.  I was
> just trying to make the point that 32/64 redirection is not about
> architecture and more like emulation.
>
> In a practical sense a rule author is not going to be concerned if
> Microsoft Excel is being run inside a Java virtual machine, but is it
> possible he might need to consider if it is being run in XP
> Compatibility Mode, XP Mode on Windows 7, or in a debugger?  Or to
> differentiate between a Windows-native version of a unix command vice one that is running in Cygwin?
>
> Outside of the name of the attribute and the documented intention for
> the scope of it, none of this makes any difference from what has been
> proposed, so I'll leave it at that.
>
>
>
> On 8/11/2011 2:12 PM, David Solin wrote:
>> Well, indeed those are all /emulators/. But an app running in an
>> emulator runs no risk of accidentally loading an incompatible
>> library, or doing anything else that would call for redirection. I'm
>> just wondering, how likely is it that Microsoft will introduce
>> another thing that is somewhere between emulation or virtualization,
>> and native execution, that will require similar attention.
>>
>> A 32-bit-app-on-64-bit-OS a bit of a unique case, I think.
>>
>> 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/11/2011 12:30 PM, Gunnar Engelbach wrote:
>>> On 8/11/2011 12:57 PM, David Solin wrote:
>>>> This redirection business only applies to "32-bit Windows on 64-bit
>>>> Windows" (i.e., WOW), it has nothing really to do with processor
>>>> architecture.
>>>>
>>>> There could be implications if Microsoft decided to emulate x86 at
>>>> the OS level by using redirection of the registry and filesystem,
>>>> but how likely does that seem? You cannot, for instance, run an x86
>>>> application on Windows Phone or vice-versa...
>>>
>>> Certainly not as a native application, but via hardware emulation...
>>>
>>> http://www.amigaforever.com/system/
>>> http://mamedev.org/release.html
>>> http://www.emulator-zone.com/
>>> http://www.ccs64.com/
>>>
>>>
>>> OK, a more serious example:
>>>
>>> http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=
>>> 9
>>> 263
>>>
>>>
>>> But at least accounting for Transmeta is no longer a concern.
>>>
>>>
>>>
>>>>
>>>> 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/11/2011 11:48 AM, Shane Shaffer wrote:
>>>>> While we were on the call yesterday I was searching for other
>>>>> architectures on Windows 8, but ultimately doesn't it come down to
>>>>> whether or not there is redirection? There could be a dozen
>>>>> different true architectures of Windows, but unless you can
>>>>> install conventional
>>>>> 32 and 64 bit apps on a Windows 8 phone and you have redirection
>>>>> going on for each architecture, does it matter?
>>>>> Of course, we've had different architectures before - we had x64
>>>>> and
>>>>> ia64 variants of Windows. We didn't need to indicate a difference
>>>>> in those architectures because the registry and file systems
>>>>> behaved the same.
>>>>> Shane Shaffer
>>>>> G2, Inc.
>>>>> Technical Director, Security Automation [hidden email]
>>>>> <mailto:[hidden email]>
>>>>>
>>>>>
>>>>> On Thu, Aug 11, 2011 at 12:30 PM, Vladimir Giszpenc
>>>>> <[hidden email]<mailto:[hidden email]>>  wrote:
>>>>>
>>>>> Matt,
>>>>>
>>>>> Microsoft claims that Windows 8 will run on ARM 32 bit RISC
>>>>> architecture.
>>>>> http://www.microsoft.com/presspass/press/2011/jan11/01-05socsuppor
>>>>> t
>>>>> .mspx
>>>>>
>>>>> NVIDIA is reportedly working on a 64 bit ARM architecture.
>>>>> http://www.brightsideofnews.com/news/2011/3/8/nvidia-project-denve
>>>>> r
>>>>> -is-a-64- bit-arm-processor-architecture.aspx
>>>>> <http://www.brightsideofnews.com/news/2011/3/8/nvidia-project-denv
>>>>> e r-is-a-64-bit-arm-processor-architecture.aspx>
>>>>>
>>>>> This is the future I was referring to. It is certainly not yet
>>>>> here, but Windows 8 should come next year.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Vladimir Giszpenc
>>>>> Armadillo Technical Lead
>>>>> DSCI Contractor Supporting
>>>>> U.S. Army CERDEC S&TCD CSIAD
>>>>> Tactical Network Protection Branch
>>>>> (732) 542-3113 x1328<tel:%28732%29%20542-3113%20x1328>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Hansbury, Matt [mailto:[hidden email]
>>>>> <mailto:[hidden email]>]
>>>>>> Sent: Thursday, August 11, 2011 11:23 AM
>>>>>> To: [hidden email]
>>>>> <mailto:[hidden email]>
>>>>>> Subject: [OVAL-DEVELOPER-LIST] Community Call - 8/10/2011
>>>>>>
>>>>>> All,
>>>>>>
>>>>>> We had a very productive call yesterday and I would like to
>>>>> thank those of
>>>>> you
>>>>>> that were able to join. The call was attended by around 30
>>>>>> people,
>>>>> representing
>>>>>> about 15 different organizations.
>>>>>>
>>>>>> The call started with a brief review of the proposed plan to
>>>>> address the
>>>>>> uncertainty around assessment of different combination of
>>>>> "bitness" on 64
>>>>> bit
>>>>>> Windows architectures. The proposal included adding the following:
>>>>>>
>>>>>> 1. A new behavior (called 'target_architecture') for a subset of
>>>>> tests
>>>>> (the full list
>>>>>> is added below*) that will indicate the intended target
>>>>> architecture. The
>>>>> value
>>>>>> for this behavior will be an enumeration that allows for the
>>>>> following
>>>>> values:
>>>>>> a. 32_bit - Indicating an intent to test for 32-bit.
>>>>>> b. 64_bit - indicating an intent to test for 64-bit.
>>>>>> c. os_native - indicating an intent to test the native
>>>>> architecture of
>>>>> the target
>>>>>> system.
>>>>>> 2. A new OVAL Item entity to allow tools to indicate the
>>>>> architecture on
>>>>> which
>>>>>> the OVAL Item was found. This would also be added to OVAL States.
>>>>>>
>>>>>> The discussion around the proposal was mainly positive to the
>>>>> proposal and
>>>>> the
>>>>>> general consensus appeared to be that these changes were a
>>>>> positive step
>>>>> in
>>>>>> making the author's intent regarding 32 vs. 64 bit more clear
>>>>> and provide
>>>>> more
>>>>>> consistent results across tools. Specifically, the vendor
>>>>>> community
>>>>> seemed to
>>>>>> think that the tool changes were not overly burdensome to them
>>>>>> and
>>>>> generally
>>>>>> seemed to favor the changes.
>>>>>>
>>>>>> Additionally, content authors also seemed to believe that the
>>>>> proposed
>>>>> changes
>>>>>> would benefit the OVAL Language, and that with the proper
>>>>> default setting,
>>>>> the
>>>>>> burden of re-writing content would be minimal. With regards to
>>>>>> the
>>>>> proposed
>>>>>> default behavior value of '32_bit', it seems that, in general,
>>>>> folks were
>>>>> more
>>>>>> comfortable with using the 'os_native' value, as it more
>>>>>> accurately
>>>>> reflected the
>>>>>> disposition of their content.
>>>>>>
>>>>>> The group was also asked if there was a use case for adding the
>>>>> concept of
>>>>>> 'both' to the enumeration, meaning that a check would be
>>>>> targeted at both
>>>>> 32-
>>>>>> bit and 64-bit. No clear consensus was reached here, so the
>>>>>> current
>>>>> proposal
>>>>>> does not include this. Also, given that the enumeration could be
>>>>> expanded to
>>>>>> other architectures, the name of such a concept would likely be
>>>>> 'all', not
>>>>> 'both'.
>>>>>> If any other folks see a clear use case for this value, please
>>>>> let us
>>>>> know.
>>>>>>
>>>>>> Lastly, it was also brought up that the environment variable
>>>>> test may also
>>>>>> require this behavior. More research is required to determine if
>>>>> that is
>>>>> the case.
>>>>>>
>>>>>> As follow up to this call, the MITRE team is going to do the
>>>>> following:
>>>>>>
>>>>>> 1. Research the OVAL Repository to confirm the best value for
>>>>> the default
>>>>>> behavior value. (This would be highly recommended as well, for
>>>>> any other
>>>>>> content owners out there.) 2. Consider whether an 'all' behavior
>>>>> enumeration
>>>>>> value is required by any use cases.
>>>>>> 3. Begin implementation of the above proposal for inclusion in
>>>>> the OVAL
>>>>> 5.10
>>>>>> version.
>>>>>> 4. Consider whether the environment variable test needs to be
>>>>> included in
>>>>>> discussion.
>>>>>>
>>>>>> Also note that the MITRE team announced their intent to push
>>>>> back the OVAL
>>>>>> 5.10 version release by some amount of time to accommodate these
>>>>> changes.
>>>>>> A formal announcement regarding the new release date will be
>>>>> sent out soon
>>>>> to
>>>>>> confirm this.
>>>>>>
>>>>>> Thanks
>>>>>> Matt
>>>>>>
>>>>>>
>>>>>> * Affected Test:
>>>>>>
>>>>>> - win-def:file_test
>>>>>> - win-def:fileauditedpermissions_test
>>>>>> - win-def:fileauditedpermissions53_test
>>>>>> - win-def:fileeffectiverights_test
>>>>>> - win-def:fileeffectiverights53_test
>>>>>> - win-def:registry_test,
>>>>>> - win-def:regkeyauditedpermissions_test
>>>>>> - win-def:regkeyauditedpermissions53_test
>>>>>> - win-def:regkeyeffectiverights_test
>>>>>> - win-def:regkeyeffectiverights53_test
>>>>>> - ind-def:filehash_test
>>>>>> - ind-def:filehash58_test
>>>>>> - ind-def:textfilecontent_test
>>>>>> - ind-def:textfilecontent54_test
>>>>>> - ind-def:xmlfilecontent_test
>>>>>>
>>>>>> ====================================================
>>>>>> Matt Hansbury
>>>>>> G022 - Information Assurance Industry Collaboration The MITRE
>>>>> Corporation
>>>>>> [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].
>>>
>>> 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: Community Call - 8/10/2011

Gunnar Engelbach
On 8/11/2011 4:42 PM, [hidden email] wrote:
>>> Except that it presumes that a 64-bit OS will only ever get assessed by a 64-bit application.
>>> But it's entirely possible to do it from a 32-bit application, which is also an important consideration for remote agentless assessments.
>
> How does it presume that? It very clearly states that the content either wants no re-direction, or 32 bit redirection. It's independent of the engine.

Because it doesn't allow for 64-bit redirection, which is what a 32-bit
interpreter would need to do if the rule was specific to the 64-bit
subsystem.

It also means that a rule with no tag is expected to apply whether it is
applied on a 32 bit OS or a 64-bit OS -- whichever happens to be
"native" on the machine where it is run.  Which, actually, I hope is the
case.  But if that's reliably true then we can forget about the bitness
flag and just run each rule twice on those systems that do redirection*.

Also, what does it mean if the content is run on a system where 32-bit
is the native system and it encounters a rule that specifies 32-bit
redirection?

Frankly, I don't think a content author should have to worry about
redirection.  Her considerations should be
  * Does this rule always apply?
  * Does this rule only apply to 64-bit?
  * Does this rule only apply to 32-bit?
  * Or even possibly: Does this rule only apply to 32-bit and 64-bit but
not any other time?


* This also depends on your goals for the content.  Should the 32- and
64-bit system be treated independently, or should a single check fail if
either or both subsystems fail?  The former is more explicit and aids
management/remediation, the latter is less likely to give a false positive.

>
>>> My perspective is that a rule should be considered agnostic to redirection unless there is a reason why that would be
>>> inaccurate, in which case the content author should have a way to indicate under which conditions the rule would be accurate.
>
> I'm not sure I understand what you mean by agnostic in this case. Can you please explain?

Maybe "indifferent" or "universal" would be better terms.  Which I think
is also what you are getting at with your "no redirection" case.

That is to say that if a rule isn't explicitly tagged for redirection
then the expectation is that is produces correct results no matter what
platform it is run on or which subsystem on a 64-bit system it is run
against.


>
> Thanks,
> Ken
>
> -----Original Message-----
> From: Gunnar Engelbach [mailto:[hidden email]]
> Sent: Thursday, August 11, 2011 3:35 PM
> To: [hidden email]
> Subject: Re: [OVAL-DEVELOPER-LIST] Community Call - 8/10/2011
>
> Except that it presumes that a 64-bit OS will only ever get assessed by a 64-bit application.  But it's entirely possible to do it from a 32-bit application, which is also an important consideration for remote agentless assessments.
>
> My perspective is that a rule should be considered agnostic to redirection unless there is a reason why that would be inaccurate, in which case the content author should have a way to indicate under which conditions the rule would be accurate.
>
>
> On 8/11/2011 4:05 PM, Kurt Dillard wrote:
>> I agree Ken, well stated.
>>
>> -----Original Message-----
>> From: [hidden email] [mailto:[hidden email]]
>> Sent: Thursday, August 11, 2011 12:13 PM
>> To: [hidden email]
>> Subject: Re: [OVAL-DEVELOPER-LIST] Community Call - 8/10/2011
>>
>> I think we're making this overly complex. Perhaps the behavior should
>> just be called "OS redirection", and the settings should be "32 bit" or "none".
>> If Microsoft adds more redirection scenarios, we can add those to the
>> enumeration as needed.
>>
>> Also, we didn't talk about what the collected item reports as the path/key.
>> I think it should always be the full, non-redirected path. If the
>> collected item contains the redirected path, then it makes it harder
>> for consumers of the OVAL results to act on the information. If I'm a
>> sys admin, and I've got a result file that states permissions are
>> wrong, I'd much rather have the complete "wow64" path than the 32 bit
>> path to work off of. This also removes the need for the additional entity item specifying "bitness".
>>
>> Lastly, I just want to champion one more time the idea that the
>> default should be "os native" (or in my proposed alternative above,
>> "none"). The OVAL spec has never mentioned anything about
>> accommodating redirection, and so this is really the only choice
>> that's backwards compatible with the spec, in my opinion.
>>
>> Ken
>>
>> -----Original Message-----
>> From: Gunnar Engelbach [mailto:[hidden email]]
>> Sent: Thursday, August 11, 2011 1:47 PM
>> To: [hidden email]
>> Subject: Re: [OVAL-DEVELOPER-LIST] Community Call - 8/10/2011
>>
>> Yeah, my examples were more of a tongue-in-cheek exaggeration.  I was
>> just trying to make the point that 32/64 redirection is not about
>> architecture and more like emulation.
>>
>> In a practical sense a rule author is not going to be concerned if
>> Microsoft Excel is being run inside a Java virtual machine, but is it
>> possible he might need to consider if it is being run in XP
>> Compatibility Mode, XP Mode on Windows 7, or in a debugger?  Or to
>> differentiate between a Windows-native version of a unix command vice one that is running in Cygwin?
>>
>> Outside of the name of the attribute and the documented intention for
>> the scope of it, none of this makes any difference from what has been
>> proposed, so I'll leave it at that.
>>
>>
>>
>> On 8/11/2011 2:12 PM, David Solin wrote:
>>> Well, indeed those are all /emulators/. But an app running in an
>>> emulator runs no risk of accidentally loading an incompatible
>>> library, or doing anything else that would call for redirection. I'm
>>> just wondering, how likely is it that Microsoft will introduce
>>> another thing that is somewhere between emulation or virtualization,
>>> and native execution, that will require similar attention.
>>>
>>> A 32-bit-app-on-64-bit-OS a bit of a unique case, I think.
>>>
>>> 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/11/2011 12:30 PM, Gunnar Engelbach wrote:
>>>> On 8/11/2011 12:57 PM, David Solin wrote:
>>>>> This redirection business only applies to "32-bit Windows on 64-bit
>>>>> Windows" (i.e., WOW), it has nothing really to do with processor
>>>>> architecture.
>>>>>
>>>>> There could be implications if Microsoft decided to emulate x86 at
>>>>> the OS level by using redirection of the registry and filesystem,
>>>>> but how likely does that seem? You cannot, for instance, run an x86
>>>>> application on Windows Phone or vice-versa...
>>>>
>>>> Certainly not as a native application, but via hardware emulation...
>>>>
>>>> http://www.amigaforever.com/system/
>>>> http://mamedev.org/release.html
>>>> http://www.emulator-zone.com/
>>>> http://www.ccs64.com/
>>>>
>>>>
>>>> OK, a more serious example:
>>>>
>>>> http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=
>>>> 9
>>>> 263
>>>>
>>>>
>>>> But at least accounting for Transmeta is no longer a concern.
>>>>
>>>>
>>>>
>>>>>
>>>>> 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/11/2011 11:48 AM, Shane Shaffer wrote:
>>>>>> While we were on the call yesterday I was searching for other
>>>>>> architectures on Windows 8, but ultimately doesn't it come down to
>>>>>> whether or not there is redirection? There could be a dozen
>>>>>> different true architectures of Windows, but unless you can
>>>>>> install conventional
>>>>>> 32 and 64 bit apps on a Windows 8 phone and you have redirection
>>>>>> going on for each architecture, does it matter?
>>>>>> Of course, we've had different architectures before - we had x64
>>>>>> and
>>>>>> ia64 variants of Windows. We didn't need to indicate a difference
>>>>>> in those architectures because the registry and file systems
>>>>>> behaved the same.
>>>>>> Shane Shaffer
>>>>>> G2, Inc.
>>>>>> Technical Director, Security Automation [hidden email]
>>>>>> <mailto:[hidden email]>
>>>>>>
>>>>>>
>>>>>> On Thu, Aug 11, 2011 at 12:30 PM, Vladimir Giszpenc
>>>>>> <[hidden email]<mailto:[hidden email]>>   wrote:
>>>>>>
>>>>>> Matt,
>>>>>>
>>>>>> Microsoft claims that Windows 8 will run on ARM 32 bit RISC
>>>>>> architecture.
>>>>>> http://www.microsoft.com/presspass/press/2011/jan11/01-05socsuppor
>>>>>> t
>>>>>> .mspx
>>>>>>
>>>>>> NVIDIA is reportedly working on a 64 bit ARM architecture.
>>>>>> http://www.brightsideofnews.com/news/2011/3/8/nvidia-project-denve
>>>>>> r
>>>>>> -is-a-64- bit-arm-processor-architecture.aspx
>>>>>> <http://www.brightsideofnews.com/news/2011/3/8/nvidia-project-denv
>>>>>> e r-is-a-64-bit-arm-processor-architecture.aspx>
>>>>>>
>>>>>> This is the future I was referring to. It is certainly not yet
>>>>>> here, but Windows 8 should come next year.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Vladimir Giszpenc
>>>>>> Armadillo Technical Lead
>>>>>> DSCI Contractor Supporting
>>>>>> U.S. Army CERDEC S&TCD CSIAD
>>>>>> Tactical Network Protection Branch
>>>>>> (732) 542-3113 x1328<tel:%28732%29%20542-3113%20x1328>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Hansbury, Matt [mailto:[hidden email]
>>>>>> <mailto:[hidden email]>]
>>>>>>> Sent: Thursday, August 11, 2011 11:23 AM
>>>>>>> To: [hidden email]
>>>>>> <mailto:[hidden email]>
>>>>>>> Subject: [OVAL-DEVELOPER-LIST] Community Call - 8/10/2011
>>>>>>>
>>>>>>> All,
>>>>>>>
>>>>>>> We had a very productive call yesterday and I would like to
>>>>>> thank those of
>>>>>> you
>>>>>>> that were able to join. The call was attended by around 30
>>>>>>> people,
>>>>>> representing
>>>>>>> about 15 different organizations.
>>>>>>>
>>>>>>> The call started with a brief review of the proposed plan to
>>>>>> address the
>>>>>>> uncertainty around assessment of different combination of
>>>>>> "bitness" on 64
>>>>>> bit
>>>>>>> Windows architectures. The proposal included adding the following:
>>>>>>>
>>>>>>> 1. A new behavior (called 'target_architecture') for a subset of
>>>>>> tests
>>>>>> (the full list
>>>>>>> is added below*) that will indicate the intended target
>>>>>> architecture. The
>>>>>> value
>>>>>>> for this behavior will be an enumeration that allows for the
>>>>>> following
>>>>>> values:
>>>>>>> a. 32_bit - Indicating an intent to test for 32-bit.
>>>>>>> b. 64_bit - indicating an intent to test for 64-bit.
>>>>>>> c. os_native - indicating an intent to test the native
>>>>>> architecture of
>>>>>> the target
>>>>>>> system.
>>>>>>> 2. A new OVAL Item entity to allow tools to indicate the
>>>>>> architecture on
>>>>>> which
>>>>>>> the OVAL Item was found. This would also be added to OVAL States.
>>>>>>>
>>>>>>> The discussion around the proposal was mainly positive to the
>>>>>> proposal and
>>>>>> the
>>>>>>> general consensus appeared to be that these changes were a
>>>>>> positive step
>>>>>> in
>>>>>>> making the author's intent regarding 32 vs. 64 bit more clear
>>>>>> and provide
>>>>>> more
>>>>>>> consistent results across tools. Specifically, the vendor
>>>>>>> community
>>>>>> seemed to
>>>>>>> think that the tool changes were not overly burdensome to them
>>>>>>> and
>>>>>> generally
>>>>>>> seemed to favor the changes.
>>>>>>>
>>>>>>> Additionally, content authors also seemed to believe that the
>>>>>> proposed
>>>>>> changes
>>>>>>> would benefit the OVAL Language, and that with the proper
>>>>>> default setting,
>>>>>> the
>>>>>>> burden of re-writing content would be minimal. With regards to
>>>>>>> the
>>>>>> proposed
>>>>>>> default behavior value of '32_bit', it seems that, in general,
>>>>>> folks were
>>>>>> more
>>>>>>> comfortable with using the 'os_native' value, as it more
>>>>>>> accurately
>>>>>> reflected the
>>>>>>> disposition of their content.
>>>>>>>
>>>>>>> The group was also asked if there was a use case for adding the
>>>>>> concept of
>>>>>>> 'both' to the enumeration, meaning that a check would be
>>>>>> targeted at both
>>>>>> 32-
>>>>>>> bit and 64-bit. No clear consensus was reached here, so the
>>>>>>> current
>>>>>> proposal
>>>>>>> does not include this. Also, given that the enumeration could be
>>>>>> expanded to
>>>>>>> other architectures, the name of such a concept would likely be
>>>>>> 'all', not
>>>>>> 'both'.
>>>>>>> If any other folks see a clear use case for this value, please
>>>>>> let us
>>>>>> know.
>>>>>>>
>>>>>>> Lastly, it was also brought up that the environment variable
>>>>>> test may also
>>>>>>> require this behavior. More research is required to determine if
>>>>>> that is
>>>>>> the case.
>>>>>>>
>>>>>>> As follow up to this call, the MITRE team is going to do the
>>>>>> following:
>>>>>>>
>>>>>>> 1. Research the OVAL Repository to confirm the best value for
>>>>>> the default
>>>>>>> behavior value. (This would be highly recommended as well, for
>>>>>> any other
>>>>>>> content owners out there.) 2. Consider whether an 'all' behavior
>>>>>> enumeration
>>>>>>> value is required by any use cases.
>>>>>>> 3. Begin implementation of the above proposal for inclusion in
>>>>>> the OVAL
>>>>>> 5.10
>>>>>>> version.
>>>>>>> 4. Consider whether the environment variable test needs to be
>>>>>> included in
>>>>>>> discussion.
>>>>>>>
>>>>>>> Also note that the MITRE team announced their intent to push
>>>>>> back the OVAL
>>>>>>> 5.10 version release by some amount of time to accommodate these
>>>>>> changes.
>>>>>>> A formal announcement regarding the new release date will be
>>>>>> sent out soon
>>>>>> to
>>>>>>> confirm this.
>>>>>>>
>>>>>>> Thanks
>>>>>>> Matt
>>>>>>>
>>>>>>>
>>>>>>> * Affected Test:
>>>>>>>
>>>>>>> - win-def:file_test
>>>>>>> - win-def:fileauditedpermissions_test
>>>>>>> - win-def:fileauditedpermissions53_test
>>>>>>> - win-def:fileeffectiverights_test
>>>>>>> - win-def:fileeffectiverights53_test
>>>>>>> - win-def:registry_test,
>>>>>>> - win-def:regkeyauditedpermissions_test
>>>>>>> - win-def:regkeyauditedpermissions53_test
>>>>>>> - win-def:regkeyeffectiverights_test
>>>>>>> - win-def:regkeyeffectiverights53_test
>>>>>>> - ind-def:filehash_test
>>>>>>> - ind-def:filehash58_test
>>>>>>> - ind-def:textfilecontent_test
>>>>>>> - ind-def:textfilecontent54_test
>>>>>>> - ind-def:xmlfilecontent_test
>>>>>>>
>>>>>>> ====================================================
>>>>>>> Matt Hansbury
>>>>>>> G022 - Information Assurance Industry Collaboration The MITRE
>>>>>> Corporation
>>>>>>> [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].
>>>>
>>>> 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: Community Call - 8/10/2011

KenSimone
Let's see if we can agree on some base premises, because I think we're not that far apart.

1)  We want to be able to toggle redirection on or off when scanning 64 bit systems.
2)  There are only two possible states, redirected, and not redirected.

If we can all agree on that, then we need to figure out how, in OVAL, to best to state "If on a 64 bit system, look at the redirected view".

To me, a behavior called "os redirection" and values of "none" and "32bit" make sense, and "32 bit" redirection on a 32 bit version of Windows simply does nothing.

The below table pretty much sums it up (if it's not mangled in e-mail formatting)

OS     Behavior     Redirection that occurs during scan
-----  ------------   -------------------------------------------
32     32bit              none
32     none              none
64     32bit              32 (redirected)
64     none              none

Anything more than that, in my opinion, is overly complex.

Actually, rather than trying to make the terminology make sense in a 32 bit environment, it might make more sense to just document the behavior as only having an effect on 64 bit versions of windows.

Ken

-----Original Message-----
From: Gunnar Engelbach [mailto:[hidden email]]
Sent: Thursday, August 11, 2011 4:32 PM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] Community Call - 8/10/2011

On 8/11/2011 4:42 PM, [hidden email] wrote:
>>> Except that it presumes that a 64-bit OS will only ever get assessed by a 64-bit application.
>>> But it's entirely possible to do it from a 32-bit application, which is also an important consideration for remote agentless assessments.
>
> How does it presume that? It very clearly states that the content either wants no re-direction, or 32 bit redirection. It's independent of the engine.

Because it doesn't allow for 64-bit redirection, which is what a 32-bit interpreter would need to do if the rule was specific to the 64-bit subsystem.

It also means that a rule with no tag is expected to apply whether it is applied on a 32 bit OS or a 64-bit OS -- whichever happens to be "native" on the machine where it is run.  Which, actually, I hope is the case.  But if that's reliably true then we can forget about the bitness flag and just run each rule twice on those systems that do redirection*.

Also, what does it mean if the content is run on a system where 32-bit is the native system and it encounters a rule that specifies 32-bit redirection?

Frankly, I don't think a content author should have to worry about redirection.  Her considerations should be
  * Does this rule always apply?
  * Does this rule only apply to 64-bit?
  * Does this rule only apply to 32-bit?
  * Or even possibly: Does this rule only apply to 32-bit and 64-bit but not any other time?


* This also depends on your goals for the content.  Should the 32- and 64-bit system be treated independently, or should a single check fail if either or both subsystems fail?  The former is more explicit and aids management/remediation, the latter is less likely to give a false positive.

>
>>> My perspective is that a rule should be considered agnostic to
>>> redirection unless there is a reason why that would be inaccurate, in which case the content author should have a way to indicate under which conditions the rule would be accurate.
>
> I'm not sure I understand what you mean by agnostic in this case. Can you please explain?

Maybe "indifferent" or "universal" would be better terms.  Which I think is also what you are getting at with your "no redirection" case.

That is to say that if a rule isn't explicitly tagged for redirection then the expectation is that is produces correct results no matter what platform it is run on or which subsystem on a 64-bit system it is run against.


>
> Thanks,
> Ken
>
> -----Original Message-----
> From: Gunnar Engelbach [mailto:[hidden email]]
> Sent: Thursday, August 11, 2011 3:35 PM
> To: [hidden email]
> Subject: Re: [OVAL-DEVELOPER-LIST] Community Call - 8/10/2011
>
> Except that it presumes that a 64-bit OS will only ever get assessed by a 64-bit application.  But it's entirely possible to do it from a 32-bit application, which is also an important consideration for remote agentless assessments.
>
> My perspective is that a rule should be considered agnostic to redirection unless there is a reason why that would be inaccurate, in which case the content author should have a way to indicate under which conditions the rule would be accurate.
>
>
> On 8/11/2011 4:05 PM, Kurt Dillard wrote:
>> I agree Ken, well stated.
>>
>> -----Original Message-----
>> From: [hidden email] [mailto:[hidden email]]
>> Sent: Thursday, August 11, 2011 12:13 PM
>> To: [hidden email]
>> Subject: Re: [OVAL-DEVELOPER-LIST] Community Call - 8/10/2011
>>
>> I think we're making this overly complex. Perhaps the behavior should
>> just be called "OS redirection", and the settings should be "32 bit" or "none".
>> If Microsoft adds more redirection scenarios, we can add those to the
>> enumeration as needed.
>>
>> Also, we didn't talk about what the collected item reports as the path/key.
>> I think it should always be the full, non-redirected path. If the
>> collected item contains the redirected path, then it makes it harder
>> for consumers of the OVAL results to act on the information. If I'm a
>> sys admin, and I've got a result file that states permissions are
>> wrong, I'd much rather have the complete "wow64" path than the 32 bit
>> path to work off of. This also removes the need for the additional entity item specifying "bitness".
>>
>> Lastly, I just want to champion one more time the idea that the
>> default should be "os native" (or in my proposed alternative above,
>> "none"). The OVAL spec has never mentioned anything about
>> accommodating redirection, and so this is really the only choice
>> that's backwards compatible with the spec, in my opinion.
>>
>> Ken
>>
>> -----Original Message-----
>> From: Gunnar Engelbach [mailto:[hidden email]]
>> Sent: Thursday, August 11, 2011 1:47 PM
>> To: [hidden email]
>> Subject: Re: [OVAL-DEVELOPER-LIST] Community Call - 8/10/2011
>>
>> Yeah, my examples were more of a tongue-in-cheek exaggeration.  I was
>> just trying to make the point that 32/64 redirection is not about
>> architecture and more like emulation.
>>
>> In a practical sense a rule author is not going to be concerned if
>> Microsoft Excel is being run inside a Java virtual machine, but is it
>> possible he might need to consider if it is being run in XP
>> Compatibility Mode, XP Mode on Windows 7, or in a debugger?  Or to
>> differentiate between a Windows-native version of a unix command vice one that is running in Cygwin?
>>
>> Outside of the name of the attribute and the documented intention for
>> the scope of it, none of this makes any difference from what has been
>> proposed, so I'll leave it at that.
>>
>>
>>
>> On 8/11/2011 2:12 PM, David Solin wrote:
>>> Well, indeed those are all /emulators/. But an app running in an
>>> emulator runs no risk of accidentally loading an incompatible
>>> library, or doing anything else that would call for redirection. I'm
>>> just wondering, how likely is it that Microsoft will introduce
>>> another thing that is somewhere between emulation or virtualization,
>>> and native execution, that will require similar attention.
>>>
>>> A 32-bit-app-on-64-bit-OS a bit of a unique case, I think.
>>>
>>> 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/11/2011 12:30 PM, Gunnar Engelbach wrote:
>>>> On 8/11/2011 12:57 PM, David Solin wrote:
>>>>> This redirection business only applies to "32-bit Windows on
>>>>> 64-bit Windows" (i.e., WOW), it has nothing really to do with
>>>>> processor architecture.
>>>>>
>>>>> There could be implications if Microsoft decided to emulate x86 at
>>>>> the OS level by using redirection of the registry and filesystem,
>>>>> but how likely does that seem? You cannot, for instance, run an
>>>>> x86 application on Windows Phone or vice-versa...
>>>>
>>>> Certainly not as a native application, but via hardware emulation...
>>>>
>>>> http://www.amigaforever.com/system/
>>>> http://mamedev.org/release.html
>>>> http://www.emulator-zone.com/
>>>> http://www.ccs64.com/
>>>>
>>>>
>>>> OK, a more serious example:
>>>>
>>>> http://www.microsoft.com/download/en/details.aspx?displaylang=en&id
>>>> =
>>>> 9
>>>> 263
>>>>
>>>>
>>>> But at least accounting for Transmeta is no longer a concern.
>>>>
>>>>
>>>>
>>>>>
>>>>> 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/11/2011 11:48 AM, Shane Shaffer wrote:
>>>>>> While we were on the call yesterday I was searching for other
>>>>>> architectures on Windows 8, but ultimately doesn't it come down
>>>>>> to whether or not there is redirection? There could be a dozen
>>>>>> different true architectures of Windows, but unless you can
>>>>>> install conventional
>>>>>> 32 and 64 bit apps on a Windows 8 phone and you have redirection
>>>>>> going on for each architecture, does it matter?
>>>>>> Of course, we've had different architectures before - we had x64
>>>>>> and
>>>>>> ia64 variants of Windows. We didn't need to indicate a difference
>>>>>> in those architectures because the registry and file systems
>>>>>> behaved the same.
>>>>>> Shane Shaffer
>>>>>> G2, Inc.
>>>>>> Technical Director, Security Automation [hidden email]
>>>>>> <mailto:[hidden email]>
>>>>>>
>>>>>>
>>>>>> On Thu, Aug 11, 2011 at 12:30 PM, Vladimir Giszpenc
>>>>>> <[hidden email]<mailto:[hidden email]>>   wrote:
>>>>>>
>>>>>> Matt,
>>>>>>
>>>>>> Microsoft claims that Windows 8 will run on ARM 32 bit RISC
>>>>>> architecture.
>>>>>> http://www.microsoft.com/presspass/press/2011/jan11/01-05socsuppo
>>>>>> r
>>>>>> t
>>>>>> .mspx
>>>>>>
>>>>>> NVIDIA is reportedly working on a 64 bit ARM architecture.
>>>>>> http://www.brightsideofnews.com/news/2011/3/8/nvidia-project-denv
>>>>>> e
>>>>>> r
>>>>>> -is-a-64- bit-arm-processor-architecture.aspx
>>>>>> <http://www.brightsideofnews.com/news/2011/3/8/nvidia-project-den
>>>>>> v e r-is-a-64-bit-arm-processor-architecture.aspx>
>>>>>>
>>>>>> This is the future I was referring to. It is certainly not yet
>>>>>> here, but Windows 8 should come next year.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Vladimir Giszpenc
>>>>>> Armadillo Technical Lead
>>>>>> DSCI Contractor Supporting
>>>>>> U.S. Army CERDEC S&TCD CSIAD
>>>>>> Tactical Network Protection Branch
>>>>>> (732) 542-3113 x1328<tel:%28732%29%20542-3113%20x1328>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Hansbury, Matt [mailto:[hidden email]
>>>>>> <mailto:[hidden email]>]
>>>>>>> Sent: Thursday, August 11, 2011 11:23 AM
>>>>>>> To: [hidden email]
>>>>>> <mailto:[hidden email]>
>>>>>>> Subject: [OVAL-DEVELOPER-LIST] Community Call - 8/10/2011
>>>>>>>
>>>>>>> All,
>>>>>>>
>>>>>>> We had a very productive call yesterday and I would like to
>>>>>> thank those of
>>>>>> you
>>>>>>> that were able to join. The call was attended by around 30
>>>>>>> people,
>>>>>> representing
>>>>>>> about 15 different organizations.
>>>>>>>
>>>>>>> The call started with a brief review of the proposed plan to
>>>>>> address the
>>>>>>> uncertainty around assessment of different combination of
>>>>>> "bitness" on 64
>>>>>> bit
>>>>>>> Windows architectures. The proposal included adding the following:
>>>>>>>
>>>>>>> 1. A new behavior (called 'target_architecture') for a subset of
>>>>>> tests
>>>>>> (the full list
>>>>>>> is added below*) that will indicate the intended target
>>>>>> architecture. The
>>>>>> value
>>>>>>> for this behavior will be an enumeration that allows for the
>>>>>> following
>>>>>> values:
>>>>>>> a. 32_bit - Indicating an intent to test for 32-bit.
>>>>>>> b. 64_bit - indicating an intent to test for 64-bit.
>>>>>>> c. os_native - indicating an intent to test the native
>>>>>> architecture of
>>>>>> the target
>>>>>>> system.
>>>>>>> 2. A new OVAL Item entity to allow tools to indicate the
>>>>>> architecture on
>>>>>> which
>>>>>>> the OVAL Item was found. This would also be added to OVAL States.
>>>>>>>
>>>>>>> The discussion around the proposal was mainly positive to the
>>>>>> proposal and
>>>>>> the
>>>>>>> general consensus appeared to be that these changes were a
>>>>>> positive step
>>>>>> in
>>>>>>> making the author's intent regarding 32 vs. 64 bit more clear
>>>>>> and provide
>>>>>> more
>>>>>>> consistent results across tools. Specifically, the vendor
>>>>>>> community
>>>>>> seemed to
>>>>>>> think that the tool changes were not overly burdensome to them
>>>>>>> and
>>>>>> generally
>>>>>>> seemed to favor the changes.
>>>>>>>
>>>>>>> Additionally, content authors also seemed to believe that the
>>>>>> proposed
>>>>>> changes
>>>>>>> would benefit the OVAL Language, and that with the proper
>>>>>> default setting,
>>>>>> the
>>>>>>> burden of re-writing content would be minimal. With regards to
>>>>>>> the
>>>>>> proposed
>>>>>>> default behavior value of '32_bit', it seems that, in general,
>>>>>> folks were
>>>>>> more
>>>>>>> comfortable with using the 'os_native' value, as it more
>>>>>>> accurately
>>>>>> reflected the
>>>>>>> disposition of their content.
>>>>>>>
>>>>>>> The group was also asked if there was a use case for adding the
>>>>>> concept of
>>>>>>> 'both' to the enumeration, meaning that a check would be
>>>>>> targeted at both
>>>>>> 32-
>>>>>>> bit and 64-bit. No clear consensus was reached here, so the
>>>>>>> current
>>>>>> proposal
>>>>>>> does not include this. Also, given that the enumeration could be
>>>>>> expanded to
>>>>>>> other architectures, the name of such a concept would likely be
>>>>>> 'all', not
>>>>>> 'both'.
>>>>>>> If any other folks see a clear use case for this value, please
>>>>>> let us
>>>>>> know.
>>>>>>>
>>>>>>> Lastly, it was also brought up that the environment variable
>>>>>> test may also
>>>>>>> require this behavior. More research is required to determine if
>>>>>> that is
>>>>>> the case.
>>>>>>>
>>>>>>> As follow up to this call, the MITRE team is going to do the
>>>>>> following:
>>>>>>>
>>>>>>> 1. Research the OVAL Repository to confirm the best value for
>>>>>> the default
>>>>>>> behavior value. (This would be highly recommended as well, for
>>>>>> any other
>>>>>>> content owners out there.) 2. Consider whether an 'all' behavior
>>>>>> enumeration
>>>>>>> value is required by any use cases.
>>>>>>> 3. Begin implementation of the above proposal for inclusion in
>>>>>> the OVAL
>>>>>> 5.10
>>>>>>> version.
>>>>>>> 4. Consider whether the environment variable test needs to be
>>>>>> included in
>>>>>>> discussion.
>>>>>>>
>>>>>>> Also note that the MITRE team announced their intent to push
>>>>>> back the OVAL
>>>>>>> 5.10 version release by some amount of time to accommodate these
>>>>>> changes.
>>>>>>> A formal announcement regarding the new release date will be
>>>>>> sent out soon
>>>>>> to
>>>>>>> confirm this.
>>>>>>>
>>>>>>> Thanks
>>>>>>> Matt
>>>>>>>
>>>>>>>
>>>>>>> * Affected Test:
>>>>>>>
>>>>>>> - win-def:file_test
>>>>>>> - win-def:fileauditedpermissions_test
>>>>>>> - win-def:fileauditedpermissions53_test
>>>>>>> - win-def:fileeffectiverights_test
>>>>>>> - win-def:fileeffectiverights53_test
>>>>>>> - win-def:registry_test,
>>>>>>> - win-def:regkeyauditedpermissions_test
>>>>>>> - win-def:regkeyauditedpermissions53_test
>>>>>>> - win-def:regkeyeffectiverights_test
>>>>>>> - win-def:regkeyeffectiverights53_test
>>>>>>> - ind-def:filehash_test
>>>>>>> - ind-def:filehash58_test
>>>>>>> - ind-def:textfilecontent_test
>>>>>>> - ind-def:textfilecontent54_test
>>>>>>> - ind-def:xmlfilecontent_test
>>>>>>>
>>>>>>> ====================================================
>>>>>>> Matt Hansbury
>>>>>>> G022 - Information Assurance Industry Collaboration The MITRE
>>>>>> Corporation
>>>>>>> [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].
>>>>
>>>> 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: Community Call - 8/10/2011

Gunnar Engelbach
Actually, I disagree with the starting premise.  Redirection is one
implementation methodology we use in software to affect a change in
which subsystem an application is addressing, but I don't think
redirection by itself is the intent of an OVAL check.

What should be the intent is whether or not the 32-bit and/or 64-bit
version of a DLL is vulnerable to a known exploit.  Or if a 32-bit
and/or 64-bit registry value puts a piece of software in a non-compliant
state.

Redirection is just one method of answering those questions.  Another
would be to run the 32-bit rules in a 32-bit interpreter and then run
the 64-bit rules in a 64-bit interpreter and combine the results.  By
not making the flag specifically about redirection tool builders have
more leeway on how to address the intent of the rule without explicitly
having to add redirection to their interpreters.

But while we're at it 64 --> 32 is not the only valid redirection.  32
--> 64 is also valid.  So for your #2 there are actually 3 possible
states and your chart is missing a column for the bit-level of the
application doing the assessment.



On 8/11/2011 6:15 PM, [hidden email] wrote:

> Let's see if we can agree on some base premises, because I think we're not that far apart.
>
> 1)  We want to be able to toggle redirection on or off when scanning 64 bit systems.
> 2)  There are only two possible states, redirected, and not redirected.
>
> If we can all agree on that, then we need to figure out how, in OVAL, to best to state "If on a 64 bit system, look at the redirected view".
>
> To me, a behavior called "os redirection" and values of "none" and "32bit" make sense, and "32 bit" redirection on a 32 bit version of Windows simply does nothing.
>
> The below table pretty much sums it up (if it's not mangled in e-mail formatting)
>
> OS     Behavior     Redirection that occurs during scan
> -----  ------------   -------------------------------------------
> 32     32bit              none
> 32     none              none
> 64     32bit              32 (redirected)
> 64     none              none
>
> Anything more than that, in my opinion, is overly complex.
>
> Actually, rather than trying to make the terminology make sense in a 32 bit environment, it might make more sense to just document the behavior as only having an effect on 64 bit versions of windows.
>
> Ken
>
> -----Original Message-----
> From: Gunnar Engelbach [mailto:[hidden email]]
> Sent: Thursday, August 11, 2011 4:32 PM
> To: [hidden email]
> Subject: Re: [OVAL-DEVELOPER-LIST] Community Call - 8/10/2011
>
> On 8/11/2011 4:42 PM, [hidden email] wrote:
>>>> Except that it presumes that a 64-bit OS will only ever get assessed by a 64-bit application.
>>>> But it's entirely possible to do it from a 32-bit application, which is also an important consideration for remote agentless assessments.
>>
>> How does it presume that? It very clearly states that the content either wants no re-direction, or 32 bit redirection. It's independent of the engine.
>
> Because it doesn't allow for 64-bit redirection, which is what a 32-bit interpreter would need to do if the rule was specific to the 64-bit subsystem.
>
> It also means that a rule with no tag is expected to apply whether it is applied on a 32 bit OS or a 64-bit OS -- whichever happens to be "native" on the machine where it is run.  Which, actually, I hope is the case.  But if that's reliably true then we can forget about the bitness flag and just run each rule twice on those systems that do redirection*.
>
> Also, what does it mean if the content is run on a system where 32-bit is the native system and it encounters a rule that specifies 32-bit redirection?
>
> Frankly, I don't think a content author should have to worry about redirection.  Her considerations should be
>    * Does this rule always apply?
>    * Does this rule only apply to 64-bit?
>    * Does this rule only apply to 32-bit?
>    * Or even possibly: Does this rule only apply to 32-bit and 64-bit but not any other time?
>
>
> * This also depends on your goals for the content.  Should the 32- and 64-bit system be treated independently, or should a single check fail if either or both subsystems fail?  The former is more explicit and aids management/remediation, the latter is less likely to give a false positive.
>
>>
>>>> My perspective is that a rule should be considered agnostic to
>>>> redirection unless there is a reason why that would be inaccurate, in which case the content author should have a way to indicate under which conditions the rule would be accurate.
>>
>> I'm not sure I understand what you mean by agnostic in this case. Can you please explain?
>
> Maybe "indifferent" or "universal" would be better terms.  Which I think is also what you are getting at with your "no redirection" case.
>
> That is to say that if a rule isn't explicitly tagged for redirection then the expectation is that is produces correct results no matter what platform it is run on or which subsystem on a 64-bit system it is run against.
>
>
>>
>> Thanks,
>> Ken
>>
>> -----Original Message-----
>> From: Gunnar Engelbach [mailto:[hidden email]]
>> Sent: Thursday, August 11, 2011 3:35 PM
>> To: [hidden email]
>> Subject: Re: [OVAL-DEVELOPER-LIST] Community Call - 8/10/2011
>>
>> Except that it presumes that a 64-bit OS will only ever get assessed by a 64-bit application.  But it's entirely possible to do it from a 32-bit application, which is also an important consideration for remote agentless assessments.
>>
>> My perspective is that a rule should be considered agnostic to redirection unless there is a reason why that would be inaccurate, in which case the content author should have a way to indicate under which conditions the rule would be accurate.
>>
>>
>> On 8/11/2011 4:05 PM, Kurt Dillard wrote:
>>> I agree Ken, well stated.
>>>
>>> -----Original Message-----
>>> From: [hidden email] [mailto:[hidden email]]
>>> Sent: Thursday, August 11, 2011 12:13 PM
>>> To: [hidden email]
>>> Subject: Re: [OVAL-DEVELOPER-LIST] Community Call - 8/10/2011
>>>
>>> I think we're making this overly complex. Perhaps the behavior should
>>> just be called "OS redirection", and the settings should be "32 bit" or "none".
>>> If Microsoft adds more redirection scenarios, we can add those to the
>>> enumeration as needed.
>>>
>>> Also, we didn't talk about what the collected item reports as the path/key.
>>> I think it should always be the full, non-redirected path. If the
>>> collected item contains the redirected path, then it makes it harder
>>> for consumers of the OVAL results to act on the information. If I'm a
>>> sys admin, and I've got a result file that states permissions are
>>> wrong, I'd much rather have the complete "wow64" path than the 32 bit
>>> path to work off of. This also removes the need for the additional entity item specifying "bitness".
>>>
>>> Lastly, I just want to champion one more time the idea that the
>>> default should be "os native" (or in my proposed alternative above,
>>> "none"). The OVAL spec has never mentioned anything about
>>> accommodating redirection, and so this is really the only choice
>>> that's backwards compatible with the spec, in my opinion.
>>>
>>> Ken
>>>
>>> -----Original Message-----
>>> From: Gunnar Engelbach [mailto:[hidden email]]
>>> Sent: Thursday, August 11, 2011 1:47 PM
>>> To: [hidden email]
>>> Subject: Re: [OVAL-DEVELOPER-LIST] Community Call - 8/10/2011
>>>
>>> Yeah, my examples were more of a tongue-in-cheek exaggeration.  I was
>>> just trying to make the point that 32/64 redirection is not about
>>> architecture and more like emulation.
>>>
>>> In a practical sense a rule author is not going to be concerned if
>>> Microsoft Excel is being run inside a Java virtual machine, but is it
>>> possible he might need to consider if it is being run in XP
>>> Compatibility Mode, XP Mode on Windows 7, or in a debugger?  Or to
>>> differentiate between a Windows-native version of a unix command vice one that is running in Cygwin?
>>>
>>> Outside of the name of the attribute and the documented intention for
>>> the scope of it, none of this makes any difference from what has been
>>> proposed, so I'll leave it at that.
>>>
>>>
>>>
>>> On 8/11/2011 2:12 PM, David Solin wrote:
>>>> Well, indeed those are all /emulators/. But an app running in an
>>>> emulator runs no risk of accidentally loading an incompatible
>>>> library, or doing anything else that would call for redirection. I'm
>>>> just wondering, how likely is it that Microsoft will introduce
>>>> another thing that is somewhere between emulation or virtualization,
>>>> and native execution, that will require similar attention.
>>>>
>>>> A 32-bit-app-on-64-bit-OS a bit of a unique case, I think.
>>>>
>>>> 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/11/2011 12:30 PM, Gunnar Engelbach wrote:
>>>>> On 8/11/2011 12:57 PM, David Solin wrote:
>>>>>> This redirection business only applies to "32-bit Windows on
>>>>>> 64-bit Windows" (i.e., WOW), it has nothing really to do with
>>>>>> processor architecture.
>>>>>>
>>>>>> There could be implications if Microsoft decided to emulate x86 at
>>>>>> the OS level by using redirection of the registry and filesystem,
>>>>>> but how likely does that seem? You cannot, for instance, run an
>>>>>> x86 application on Windows Phone or vice-versa...
>>>>>
>>>>> Certainly not as a native application, but via hardware emulation...
>>>>>
>>>>> http://www.amigaforever.com/system/
>>>>> http://mamedev.org/release.html
>>>>> http://www.emulator-zone.com/
>>>>> http://www.ccs64.com/
>>>>>
>>>>>
>>>>> OK, a more serious example:
>>>>>
>>>>> http://www.microsoft.com/download/en/details.aspx?displaylang=en&id
>>>>> =
>>>>> 9
>>>>> 263
>>>>>
>>>>>
>>>>> But at least accounting for Transmeta is no longer a concern.
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> 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/11/2011 11:48 AM, Shane Shaffer wrote:
>>>>>>> While we were on the call yesterday I was searching for other
>>>>>>> architectures on Windows 8, but ultimately doesn't it come down
>>>>>>> to whether or not there is redirection? There could be a dozen
>>>>>>> different true architectures of Windows, but unless you can
>>>>>>> install conventional
>>>>>>> 32 and 64 bit apps on a Windows 8 phone and you have redirection
>>>>>>> going on for each architecture, does it matter?
>>>>>>> Of course, we've had different architectures before - we had x64
>>>>>>> and
>>>>>>> ia64 variants of Windows. We didn't need to indicate a difference
>>>>>>> in those architectures because the registry and file systems
>>>>>>> behaved the same.
>>>>>>> Shane Shaffer
>>>>>>> G2, Inc.
>>>>>>> Technical Director, Security Automation [hidden email]
>>>>>>> <mailto:[hidden email]>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Aug 11, 2011 at 12:30 PM, Vladimir Giszpenc
>>>>>>> <[hidden email]<mailto:[hidden email]>>    wrote:
>>>>>>>
>>>>>>> Matt,
>>>>>>>
>>>>>>> Microsoft claims that Windows 8 will run on ARM 32 bit RISC
>>>>>>> architecture.
>>>>>>> http://www.microsoft.com/presspass/press/2011/jan11/01-05socsuppo
>>>>>>> r
>>>>>>> t
>>>>>>> .mspx
>>>>>>>
>>>>>>> NVIDIA is reportedly working on a 64 bit ARM architecture.
>>>>>>> http://www.brightsideofnews.com/news/2011/3/8/nvidia-project-denv
>>>>>>> e
>>>>>>> r
>>>>>>> -is-a-64- bit-arm-processor-architecture.aspx
>>>>>>> <http://www.brightsideofnews.com/news/2011/3/8/nvidia-project-den
>>>>>>> v e r-is-a-64-bit-arm-processor-architecture.aspx>
>>>>>>>
>>>>>>> This is the future I was referring to. It is certainly not yet
>>>>>>> here, but Windows 8 should come next year.
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Vladimir Giszpenc
>>>>>>> Armadillo Technical Lead
>>>>>>> DSCI Contractor Supporting
>>>>>>> U.S. Army CERDEC S&TCD CSIAD
>>>>>>> Tactical Network Protection Branch
>>>>>>> (732) 542-3113 x1328<tel:%28732%29%20542-3113%20x1328>
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Hansbury, Matt [mailto:[hidden email]
>>>>>>> <mailto:[hidden email]>]
>>>>>>>> Sent: Thursday, August 11, 2011 11:23 AM
>>>>>>>> To: [hidden email]
>>>>>>> <mailto:[hidden email]>
>>>>>>>> Subject: [OVAL-DEVELOPER-LIST] Community Call - 8/10/2011
>>>>>>>>
>>>>>>>> All,
>>>>>>>>
>>>>>>>> We had a very productive call yesterday and I would like to
>>>>>>> thank those of
>>>>>>> you
>>>>>>>> that were able to join. The call was attended by around 30
>>>>>>>> people,
>>>>>>> representing
>>>>>>>> about 15 different organizations.
>>>>>>>>
>>>>>>>> The call started with a brief review of the proposed plan to
>>>>>>> address the
>>>>>>>> uncertainty around assessment of different combination of
>>>>>>> "bitness" on 64
>>>>>>> bit
>>>>>>>> Windows architectures. The proposal included adding the following:
>>>>>>>>
>>>>>>>> 1. A new behavior (called 'target_architecture') for a subset of
>>>>>>> tests
>>>>>>> (the full list
>>>>>>>> is added below*) that will indicate the intended target
>>>>>>> architecture. The
>>>>>>> value
>>>>>>>> for this behavior will be an enumeration that allows for the
>>>>>>> following
>>>>>>> values:
>>>>>>>> a. 32_bit - Indicating an intent to test for 32-bit.
>>>>>>>> b. 64_bit - indicating an intent to test for 64-bit.
>>>>>>>> c. os_native - indicating an intent to test the native
>>>>>>> architecture of
>>>>>>> the target
>>>>>>>> system.
>>>>>>>> 2. A new OVAL Item entity to allow tools to indicate the
>>>>>>> architecture on
>>>>>>> which
>>>>>>>> the OVAL Item was found. This would also be added to OVAL States.
>>>>>>>>
>>>>>>>> The discussion around the proposal was mainly positive to the
>>>>>>> proposal and
>>>>>>> the
>>>>>>>> general consensus appeared to be that these changes were a
>>>>>>> positive step
>>>>>>> in
>>>>>>>> making the author's intent regarding 32 vs. 64 bit more clear
>>>>>>> and provide
>>>>>>> more
>>>>>>>> consistent results across tools. Specifically, the vendor
>>>>>>>> community
>>>>>>> seemed to
>>>>>>>> think that the tool changes were not overly burdensome to them
>>>>>>>> and
>>>>>>> generally
>>>>>>>> seemed to favor the changes.
>>>>>>>>
>>>>>>>> Additionally, content authors also seemed to believe that the
>>>>>>> proposed
>>>>>>> changes
>>>>>>>> would benefit the OVAL Language, and that with the proper
>>>>>>> default setting,
>>>>>>> the
>>>>>>>> burden of re-writing content would be minimal. With regards to
>>>>>>>> the
>>>>>>> proposed
>>>>>>>> default behavior value of '32_bit', it seems that, in general,
>>>>>>> folks were
>>>>>>> more
>>>>>>>> comfortable with using the 'os_native' value, as it more
>>>>>>>> accurately
>>>>>>> reflected the
>>>>>>>> disposition of their content.
>>>>>>>>
>>>>>>>> The group was also asked if there was a use case for adding the
>>>>>>> concept of
>>>>>>>> 'both' to the enumeration, meaning that a check would be
>>>>>>> targeted at both
>>>>>>> 32-
>>>>>>>> bit and 64-bit. No clear consensus was reached here, so the
>>>>>>>> current
>>>>>>> proposal
>>>>>>>> does not include this. Also, given that the enumeration could be
>>>>>>> expanded to
>>>>>>>> other architectures, the name of such a concept would likely be
>>>>>>> 'all', not
>>>>>>> 'both'.
>>>>>>>> If any other folks see a clear use case for this value, please
>>>>>>> let us
>>>>>>> know.
>>>>>>>>
>>>>>>>> Lastly, it was also brought up that the environment variable
>>>>>>> test may also
>>>>>>>> require this behavior. More research is required to determine if
>>>>>>> that is
>>>>>>> the case.
>>>>>>>>
>>>>>>>> As follow up to this call, the MITRE team is going to do the
>>>>>>> following:
>>>>>>>>
>>>>>>>> 1. Research the OVAL Repository to confirm the best value for
>>>>>>> the default
>>>>>>>> behavior value. (This would be highly recommended as well, for
>>>>>>> any other
>>>>>>>> content owners out there.) 2. Consider whether an 'all' behavior
>>>>>>> enumeration
>>>>>>>> value is required by any use cases.
>>>>>>>> 3. Begin implementation of the above proposal for inclusion in
>>>>>>> the OVAL
>>>>>>> 5.10
>>>>>>>> version.
>>>>>>>> 4. Consider whether the environment variable test needs to be
>>>>>>> included in
>>>>>>>> discussion.
>>>>>>>>
>>>>>>>> Also note that the MITRE team announced their intent to push
>>>>>>> back the OVAL
>>>>>>>> 5.10 version release by some amount of time to accommodate these
>>>>>>> changes.
>>>>>>>> A formal announcement regarding the new release date will be
>>>>>>> sent out soon
>>>>>>> to
>>>>>>>> confirm this.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Matt
>>>>>>>>
>>>>>>>>
>>>>>>>> * Affected Test:
>>>>>>>>
>>>>>>>> - win-def:file_test
>>>>>>>> - win-def:fileauditedpermissions_test
>>>>>>>> - win-def:fileauditedpermissions53_test
>>>>>>>> - win-def:fileeffectiverights_test
>>>>>>>> - win-def:fileeffectiverights53_test
>>>>>>>> - win-def:registry_test,
>>>>>>>> - win-def:regkeyauditedpermissions_test
>>>>>>>> - win-def:regkeyauditedpermissions53_test
>>>>>>>> - win-def:regkeyeffectiverights_test
>>>>>>>> - win-def:regkeyeffectiverights53_test
>>>>>>>> - ind-def:filehash_test
>>>>>>>> - ind-def:filehash58_test
>>>>>>>> - ind-def:textfilecontent_test
>>>>>>>> - ind-def:textfilecontent54_test
>>>>>>>> - ind-def:xmlfilecontent_test
>>>>>>>>
>>>>>>>> ====================================================
>>>>>>>> Matt Hansbury
>>>>>>>> G022 - Information Assurance Industry Collaboration The MITRE
>>>>>>> Corporation
>>>>>>>> [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].
>>>>>
>>>>> 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].
123