Hi OVAL developers,

The two accesstoken/userright-related OVAL tests are slightly ambiguous about how to behave in the case where there are no rights assigned to a principal (in the case of the accesstoken_object), or no users with the specified right (in the case of the userright_object).

In the case of accesstoken_object, assuming the principal exists, should there be an item with all the rights set to 0?  Or should the oval-res:object be flagged “does not exist”?

In the case of userright_object, should there be an item with a userright entity flagged “does not exist”?  Or should the oval-res:object be flagged “does not exist”?

In addition to making a determination for clarification in the next version of OVAL, we should determine whether any existing content (e.g., USGCB, STIG) is specifically designed for one implementation or the other.

Best regards,
—David Solin

David A. Solin
Co-Founder, Research & Technology
solin@jovalcm.com mailto:solin@jovalcm.com
https://protect-us.mimecast.com/s/VAq3B5uVQDXIv?domain=jovalcm.com
  https://protect-us.mimecast.com/s/5JNQBkuZ9DJc8?domain=facebook.com https://protect-us.mimecast.com/s/g5GpBbUeM29ux?domain=linkedin.com

David,

I still need to research the accesstoken test but regarding the userright test:

I believe if a user right has "NO ONE" assigned to it the OVAL-Results should look like this:

                          <win-sc:userright_item id="7" status="exists">
                                <win-sc:userright>SE_REMOTE_SHUTDOWN_NAME</win-sc:userright>
                                <win-sc:trustee_name status="does not exist"></win-sc:trustee_name>
                                <win-sc:trustee_sid status="does not exist"></win-sc:trustee_sid>
                          </win-sc:userright_item>

Let me know what your thoughts are.

Bryan Wilson
SPAWAR Systems Center Atlantic

-----Original Message-----
From: OVAL_Developer [mailto:oval_developer-bounces@lists.cisecurity.org] On Behalf Of David Solin
Sent: Thursday, August 31, 2017 3:42 PM
To: OVAL Developer List
Subject: [Non-DoD Source] [OVAL DEVELOPER] Implementation issue for win-def:accesstoken_object (and win-def:userright_object)

All active links contained in this email were disabled. Please verify the identity of the sender, and confirm the authenticity of all links contained within the message prior to copying and pasting the address to a Web browser.

Hi OVAL developers,

The two accesstoken/userright-related OVAL tests are slightly ambiguous about how to behave in the case where there are no rights assigned to a principal (in the case of the accesstoken_object), or no users with the specified right (in the case of the userright_object).

In the case of accesstoken_object, assuming the principal exists, should there be an item with all the rights set to 0?  Or should the oval-res:object be flagged “does not exist”?

In the case of userright_object, should there be an item with a userright entity flagged “does not exist”?  Or should the oval-res:object be flagged “does not exist”?

In addition to making a determination for clarification in the next version of OVAL, we should determine whether any existing content (e.g., USGCB, STIG) is specifically designed for one implementation or the other.

Best regards,
—David Solin

David A. Solin
Co-Founder, Research & Technology
solin@jovalcm.com < Caution-mailto:solin@jovalcm.com >

Joval Continuous Monitoringhttps://protect-us.mimecast.com/s/MdebBKUKkQdhw  < https://protect-us.mimecast.com/s/O5JXBwUDn2lse?domain=jovalcm.com >

Facebookhttps://protect-us.mimecast.com/s/9XN9B0fEgqxTZ  < https://protect-us.mimecast.com/s/lNpeBgUknLVUe?domain=facebook.com >  Linkedinhttps://protect-us.mimecast.com/s/zN8gBwUxJEbCz  < https://protect-us.mimecast.com/s/rxg6BOu7OdMTv?domain=linkedin.com >

I would agree with David S. for the User Rights collections.  The intent of that test is to collect those trustees to whom the right has been granted.  If no trustees are granted the right, no items would be collected and the flag would be “does not exist”.

In terms of the Access Token collections, there could be 2 scenarios:  First, if the trustee_name exists, but has no rights granted, an item would be collected, the flag would be “exists” and all of the child elements would be set to “0”/false.  If the trustee itself doesn’t exist, which could be possible considering it’s the trustee_name and not the trustee_sid, a non-existant trustee would result in a flag of “does not exist”.

Cheers,
-Bill M.

Bill Munyan
Technical Product Executive; Security Controls & Automation
31 Tech Valley Drive
East Greenbush, NY 12061

william.munyan@cisecurity.orgmailto:william.munyan@cisecurity.org
518 880-0690
518 466-1160 (cell)
[CIS_WEB_Logo_Type_RGB_Flat]https://www.cisecurity.org/
[CIS Email Icons 01_23-02] https://www.facebook.com/CenterforIntSec    [CIS Email Icons 01_23-03] https://twitter.com/CISecurity    [CIS Email Icons 01_23-04] https://www.youtube.com/user/TheCISecurity    [CIS Email Icons 01_23-05] https://www.linkedin.com/company/the-center-for-internet-security

From: OVAL_Developer [mailto:oval_developer-bounces@lists.cisecurity.org] On Behalf Of David Solin
Sent: Tuesday, September 5, 2017 6:35 PM
To: OVAL Developer List oval_developer@lists.cisecurity.org
Subject: Re: [OVAL DEVELOPER] [Non-DoD Source] Implementation issue for win-def:accesstoken_object (and win-def:userright_object)

Actually… I personally think in this case the more traditionally “OVAL” approach would be to say the corresponding oval-sc:object/@flag=“does not exist”.

When I wrote this question last Thursday, I had the idea that the item could have multiple trustee_name/trustee_sid entities, but in reality those are specified in the schema as singleton entities for the item.  Therefore, since the design for the object is to have one item result for each trustee with the right, it makes intuitive sense that if no trustees have the right, there would be no items.  If there are no items, the oval-sc:object/@flag would have to be set to “does not exist”.  Of course, clearly the right exists in the abstract — it’s a member of an enumeration, after all.

The accesstoken_object/item is a little bit different.  An OVAL interpreter has to create synthetic entities indicating the absence of each right that a principal does not have.  It seems strange to go from a case of having maybe one right being set to “1” with the other 44 rights being set to “0”, to suddenly saying the object doesn’t exist at all if the principal has none of the rights assigned.

So, those are my opinions on how these objects should work, from the perspective of an interpreter developer.  But I think it would be most instructive to learn what the NIST certification program’s assumptions were, as well as the assumptions made by other content authors who have used these tests.

Best regards,
—David Solin

David A. Solin
Co-Founder, Research & Technology
solin@jovalcm.commailto:solin@jovalcm.com
[Joval Continuous Monitoring]http://jovalcm.com
[Facebook] https://www.facebook.com/jovalcm [Linkedin] https://www.linkedin.com/company/joval-continuous-monitoring

On Sep 5, 2017, at 2:51 PM, Jerome Athias <jerome.athias@protonmail.commailto:jerome.athias@protonmail.com> wrote:

Sounds like clearer and unambiguous, if files/packets size is not an issue

On Tue, Sep 5, 2017 at 10:45 PM, Wilson, Bryan L CIV USN SPAWARSYSCEN LANT SC (US) <bryan.l.wilson.civ@mail.milmailto:bryan.l.wilson.civ@mail.mil> wrote:
David,

I still need to research the accesstoken test but regarding the userright test:

I believe if a user right has "NO ONE" assigned to it the OVAL-Results should look like this:

<win-sc:userright_item id="7" status="exists">
win-sc:userrightSE_REMOTE_SHUTDOWN_NAME</win-sc:userright>
<win-sc:trustee_name status="does not exist"></win-sc:trustee_name>
<win-sc:trustee_sid status="does not exist"></win-sc:trustee_sid>
</win-sc:userright_item>

Let me know what your thoughts are.

Bryan Wilson
SPAWAR Systems Center Atlantic

-----Original Message-----
From: OVAL_Developer [mailto:oval_developer-bounces@lists.cisecurity.org] On Behalf Of David Solin
Sent: Thursday, August 31, 2017 3:42 PM
To: OVAL Developer List
Subject: [Non-DoD Source] [OVAL DEVELOPER] Implementation issue for win-def:accesstoken_object (and win-def:userright_object)

All active links contained in this email were disabled. Please verify the identity of the sender, and confirm the authenticity of all links contained within the message prior to copying and pasting the address to a Web browser.

Hi OVAL developers,

The two accesstoken/userright-related OVAL tests are slightly ambiguous about how to behave in the case where there are no rights assigned to a principal (in the case of the accesstoken_object), or no users with the specified right (in the case of the userright_object).

In the case of accesstoken_object, assuming the principal exists, should there be an item with all the rights set to 0? Or should the oval-res:object be flagged "does not exist"?

In the case of userright_object, should there be an item with a userright entity flagged "does not exist"? Or should the oval-res:object be flagged "does not exist"?

In addition to making a determination for clarification in the next version of OVAL, we should determine whether any existing content (e.g., USGCB, STIG) is specifically designed for one implementation or the other.

Best regards,
—David Solin

David A. Solin
Co-Founder, Research & Technology
solin@jovalcm.commailto:solin@jovalcm.com < Caution-mailto:solin@jovalcm.com >

Joval Continuous Monitoring<Caution-http://download.jovalcm.com/assets/jovalcm.color.225.pngCaution-http://download.jovalcm.com/assets/jovalcm.color.225.png> < http://jovalcm.comhttp://jovalcm.com >

Facebook< Caution-http://download.jovalcm.com/assets/fb.rounded.pngCaution-http://download.jovalcm.com/assets/fb.rounded.png> < https://www.facebook.com/jovalcmhttps://www.facebook.com/jovalcm > Linkedin<Caution-http://download.jovalcm.com/assets/li.rounded.pngCaution-http://download.jovalcm.com/assets/li.rounded.png> < https://www.linkedin.com/company/joval-continuous-monitoringhttps://www.linkedin.com/company/joval-continuous-monitoring >

.....
This message and attachments may contain confidential information. If it appears that this message was sent to you by mistake, any retention, dissemination, distribution or copying of this message and attachments is strictly prohibited. Please notify the sender immediately and permanently delete the message and any attachments.

Good Morning OVAL Dev Team,

The SCAP 1.2 Validation Program includes testing for the OVAL
accesstoken_test and the expected behavior is to produce
accesstoken_item(s) which include all the entities
(seassignprimarytokenprivilege, seauditprivilege, etc.) with true\false
values. This behavior is in line with William and David’s explanations.

Regarding the userright_item(s), I also agree with their interpretation.
Currently this test is not tested by the SCAP 1.2 Validation Program (since
this test was created in OVAL 5.11), but it will be tested in the upcoming
SCAP 1.3 Program. It will be great if the clarification will be included in
the OVAL documentation.

Respectfully,

_Dragos.

From: OVAL_Developer [mailto:oval_developer-bounces@lists.cisecurity.org] *On
Behalf Of *William Munyan
Sent: Wednesday, September 06, 2017 2:15 PM
To: David Solin solin@jovalcm.com; OVAL Developer List <
oval_developer@lists.cisecurity.org>
Subject: Re: [OVAL DEVELOPER] [Non-DoD Source] Implementation issue for
win-def:accesstoken_object (and win-def:userright_object)

I would agree with David S. for the User Rights collections.  The intent of
that test is to collect those trustees to whom the right has been granted.
If no trustees are granted the right, no items would be collected and the
flag would be “does not exist”.

In terms of the Access Token collections, there could be 2 scenarios:
First, if the trustee_name exists, but has no rights granted, an item would
be collected, the flag would be “exists” and all of the child elements
would be set to “0”/false.  If the trustee itself doesn’t exist, which could
be possible considering it’s the trustee_name and not the trustee_sid, a
non-existant trustee would result in a flag of “does not exist”.

Cheers,

-Bill M.

Bill Munyan

Technical Product Executive; Security Controls & Automation

31 Tech Valley Drive

East Greenbush, NY 12061

william.munyan@cisecurity.org

518 880-0690

518 466-1160 (cell)

[image: CIS_WEB_Logo_Type_RGB_Flat] https://www.cisecurity.org/

                       [image: CIS Email Icons 01_23-02]

https://protect-us.mimecast.com/s/GWe0BOc61oEh3?domain=facebook.com    [image: CIS Email Icons
01_23-03] https://protect-us.mimecast.com/s/Y1DdB4IzNORs5?domain=twitter.com  [image: CIS Email Icons
01_23-04] https://protect-us.mimecast.com/s/K2N6BpUE1qgHK?domain=youtube.com    [image: CIS Email
Icons 01_23-05]
https://protect-us.mimecast.com/s/enpmBaIGRq1Fx?domain=linkedin.com

From: OVAL_Developer [mailto:oval_developer-bounces@lists.cisecurity.org
oval_developer-bounces@lists.cisecurity.org] *On Behalf Of *David Solin
Sent: Tuesday, September 5, 2017 6:35 PM
To: OVAL Developer List oval_developer@lists.cisecurity.org
Subject: Re: [OVAL DEVELOPER] [Non-DoD Source] Implementation issue for
win-def:accesstoken_object (and win-def:userright_object)

Actually… I personally think in this case the more traditionally “OVAL”
approach would be to say the corresponding oval-sc:object/@flag=“does not
exist”.

When I wrote this question last Thursday, I had the idea that the item
could have multiple trustee_name/trustee_sid entities, but in reality those
are specified in the schema as singleton entities for the item.  Therefore,
since the design for the object is to have one item result for each trustee
with the right, it makes intuitive sense that if no trustees have the
right, there would be no items.  If there are no items, the
oval-sc:object/@flag would have to be set to “does not exist”.  Of course,
clearly the right exists in the abstract — it’s a member of an enumeration,
after all.

The accesstoken_object/item is a little bit different.  An OVAL interpreter
has to create synthetic entities indicating the absence of each right that
a principal does not have.  It seems strange to go from a case of having
maybe one right being set to “1” with the other 44 rights being set to “0”,
to suddenly saying the object doesn’t exist at all if the principal has
none of the rights assigned.

So, those are my opinions on how these objects should work, from the
perspective of an interpreter developer.  But I think it would be most
instructive to learn what the NIST certification program’s assumptions
were, as well as the assumptions made by other content authors who have
used these tests.

Best regards,

—David Solin

David A. Solin
Co-Founder, Research & Technology
solin@jovalcm.com

[image: Joval Continuous Monitoring] https://protect-us.mimecast.com/s/WD4qBoTwROkcJ?domain=jovalcm.com

[image: Facebook]  https://protect-us.mimecast.com/s/0JwqBQuk1bDFe?domain=facebook.com[image: Linkedin]
https://protect-us.mimecast.com/s/wX47BGf31VGio?domain=linkedin.com

On Sep 5, 2017, at 2:51 PM, Jerome Athias jerome.athias@protonmail.com
wrote:

Sounds like clearer and unambiguous, if files/packets size is not an issue

On Tue, Sep 5, 2017 at 10:45 PM, Wilson, Bryan L CIV USN SPAWARSYSCEN LANT
SC (US) bryan.l.wilson.civ@mail.mil wrote:

David,

I still need to research the accesstoken test but regarding the userright
test:

I believe if a user right has "NO ONE" assigned to it the OVAL-Results
should look like this:

<win-sc:userright_item id="7" status="exists">
win-sc:userrightSE_REMOTE_SHUTDOWN_NAME</win-sc:userright>
<win-sc:trustee_name status="does not exist"></win-sc:trustee_name>
<win-sc:trustee_sid status="does not exist"></win-sc:trustee_sid>
</win-sc:userright_item>

Let me know what your thoughts are.

Bryan Wilson
SPAWAR Systems Center Atlantic

-----Original Message-----
From: OVAL_Developer [mailto:oval_developer-bounces@lists.cisecurity.org
oval_developer-bounces@lists.cisecurity.org] On Behalf Of David Solin
Sent: Thursday, August 31, 2017 3:42 PM
To: OVAL Developer List
Subject: [Non-DoD Source] [OVAL DEVELOPER] Implementation issue for
win-def:accesstoken_object (and win-def:userright_object)

All active links contained in this email were disabled. Please verify the
identity of the sender, and confirm the authenticity of all links contained
within the message prior to copying and pasting the address to a Web
browser.

Hi OVAL developers,

The two accesstoken/userright-related OVAL tests are slightly ambiguous
about how to behave in the case where there are no rights assigned to a
principal (in the case of the accesstoken_object), or no users with the
specified right (in the case of the userright_object).

In the case of accesstoken_object, assuming the principal exists, should
there be an item with all the rights set to 0? Or should the
oval-res:object be flagged "does not exist"?

In the case of userright_object, should there be an item with a userright
entity flagged "does not exist"? Or should the oval-res:object be flagged
"does not exist"?

In addition to making a determination for clarification in the next version
of OVAL, we should determine whether any existing content (e.g., USGCB,
STIG) is specifically designed for one implementation or the other.

Best regards,
—David Solin

David A. Solin
Co-Founder, Research & Technology
solin@jovalcm.com < Caution-mailto:solin@jovalcm.com solin@jovalcm.com >

Joval Continuous Monitoring<
https://protect-us.mimecast.com/s/arplBLhNRgrUR> <
https://protect-us.mimecast.com/s/WD4qBoTwROkcJ?domain=jovalcm.com
https://protect-us.mimecast.com/s/WD4qBoTwROkcJ?domain=jovalcm.com >

Facebook< https://protect-us.mimecast.com/s/271dB9Hb265ho> <
https://protect-us.mimecast.com/s/0JwqBQuk1bDFe?domain=facebook.com
https://protect-us.mimecast.com/s/0JwqBQuk1bDFe?domain=facebook.com > Linkedin<
https://protect-us.mimecast.com/s/6RNxBLfrKv6So> <
https://protect-us.mimecast.com/s/wX47BGf31VGio?domain=linkedin.com
https://protect-us.mimecast.com/s/wX47BGf31VGio?domain=linkedin.com >

.....

This message and attachments may contain confidential information. If it
appears that this message was sent to you by mistake, any retention,
dissemination, distribution or copying of this message and attachments is
strictly prohibited. Please notify the sender immediately and permanently
delete the message and any attachments.

SPAWAR would like to present an updated response to add to this discussion.  There is a lot of info here, please also look at the bottom of the email for examples of how certain content would / should report....

The OVAL spec's require that we flag an object as 'complete' if, when we query the target system for a system characteristic containing the object element(s), we get a positive response from the system.  We create an item, if when we query the system for those elements found in the object we find a system element matching the object requirements.

For example, in the case of a file_item, if we query the system for a file with a given filepath and that file exists on the system, we would create an item.  Clearly, the path and filename exist, so those elements would be populated in the item.  However, according to the schema, all other item elements are allowed to 'not exist' in the item.  The item elements that were 'required' by the object exist and are reported.  This is consistent with the guidance in sections "5.2.2.1 flag Usage" and "5.2.4.5.2 Status" of the 5.11 (2014) spec's.

SPAWAR contends that in the 'userRight' case, we should follow the same process.  If the portion of the item that is required by the userRight object exists, then we should create an item and the userright element in that item should be populated with the name of that userright.  If there are other item elements that do not exist, then they should not be populated and should be listed as 'does not exist.'  Apparently, on a healthy Windows system, a given userright can have zero of more sids associated with it.  The content author should construct an existence check and userright state to check the item(s) from there.

In general, if there is something on the system that satisfies the object elements, we create an item....  even if the item is otherwise 'empty.'  To vary from this would be to make the 'existence' check fluid or variable depending on the object type.  I think that would be a bad idea.

Finally, to complete our response.  The following 2 examples show content containing an invalid userright name vs content containing a valid userright name which's corresponding user right is set to no one. As defined, the userright entity is a finite list of valid user right names.  If the content author enters a userright name that is invalid, the resulting object will report "does not exist" and notes each entity as "not collected".  That is shown in example 1 to follow.  Example 2 shows how a user right with no one assigned should be handled based on SPAWAR's feedback above and previous emails.  As can be seen, the item has a status of "exists."  This is because data was successfully gathered and the result was an empty list.  This is another argument in regards to an item being created if data is successfully gathered even if that result is an empty list because no one is assigned that user right.

############################################################################################################
Example 1.  Content defines an invalid user right.  SCC will report a warning to the  error log and the OVAL results will show that the item does not exist.

<userright_object id="oval:mil.ssclant.oval.test:obj:1" version="1" comment="Example 1"
	xmlns="https://protect-us.mimecast.com/s/0JwqBQua6YKh7?domain=oval.mitre.org">
	<userright>SE_AUDinvalidfIT_NAME</userright>
</userright_object

Example 1 Results:
<win-sc:userright_item status="does not exist" id="1">
<win-sc:userright status="not collected"></win-sc:userright>
<win-sc:trustee_name status="not collected"></win-sc:trustee_name>
<win-sc:trustee_sid status="not collected"></win-sc:trustee_sid>
</win-sc:userright_item>

############################################################################################################
Example 2: Content defines a valid user right name is given which has no one assigned to that user right.

<userright_object id="oval:mil.ssclant.oval.test:obj:2" version="1" comment="Example 2"
	xmlns="https://protect-us.mimecast.com/s/0JwqBQua6YKh7?domain=oval.mitre.org">
	<userright>SE_REMOTE_SHUTDOWN_NAME</userright>
</userright_object>

Example 2 Results:
<win-sc:userright_item status="exists" id="2">
win-sc:userrightSE_REMOTE_SHUTDOWN_NAME</win-sc:userright>
<win-sc:trustee_name status="does not exist"></win-sc:trustee_name>
<win-sc:trustee_sid status="does not exist"></win-sc:trustee_sid>
</win-sc:userright_item>

############################################################################################################

-----Original Message-----
From: OVAL_Developer [mailto:oval_developer-bounces@lists.cisecurity.org] On Behalf Of Dragos Prisaca
Sent: Monday, September 11, 2017 9:36 AM
To: William Munyan; David Solin; OVAL Developer List
Subject: Re: [OVAL DEVELOPER] [Non-DoD Source] Implementation issue for win-def:accesstoken_object (and win-def:userright_object)

All active links contained in this email were disabled. Please verify the identity of the sender, and confirm the authenticity of all links contained within the message prior to copying and pasting the address to a Web browser.

Good Morning OVAL Dev Team,

The SCAP 1.2 Validation Program includes testing for the OVAL accesstoken_test and the expected behavior is to produce  accesstoken_item(s) which include all the entities (seassignprimarytokenprivilege, seauditprivilege, etc.) with true\false values. This behavior is in line with William and David’s explanations.

Regarding the userright_item(s), I also agree with their interpretation. Currently this test is not tested by the SCAP 1.2 Validation Program (since this test was created in OVAL 5.11), but it will be tested in the upcoming SCAP 1.3 Program. It will be great if the clarification will be included in the OVAL documentation.

Respectfully,

_Dragos.

From: OVAL_Developer [Caution-mailto:oval_developer-bounces@lists.cisecurity.org < Caution-mailto:oval_developer-bounces@lists.cisecurity.org > ] On Behalf Of William Munyan
Sent: Wednesday, September 06, 2017 2:15 PM
To: David Solin <solin@jovalcm.com < Caution-mailto:solin@jovalcm.com > >; OVAL Developer List <oval_developer@lists.cisecurity.org < Caution-mailto:oval_developer@lists.cisecurity.org > >
Subject: Re: [OVAL DEVELOPER] [Non-DoD Source] Implementation issue for win-def:accesstoken_object (and win-def:userright_object)

I would agree with David S. for the User Rights collections.  The intent of that test is to collect those trustees to whom the right has been granted.  If no trustees are granted the right, no items would be collected and the flag would be “does not exist”.

In terms of the Access Token collections, there could be 2 scenarios:  First, if the trustee_name exists, but has no rights granted, an item would be collected, the flag would be “exists” and all of the child elements would be set to “0”/false.  If the trustee itself doesn’t exist, which could be possible considering it’s the trustee_name and not the trustee_sid, a non-existant trustee would result in a flag of “does not exist”.

Cheers,

-Bill M.

Bill Munyan

Technical Product Executive; Security Controls & Automation

31 Tech Valley Drive

East Greenbush, NY 12061

william.munyan@cisecurity.org < Caution-mailto:william.munyan@cisecurity.org >

518 880-0690

518 466-1160 (cell)

CIS_WEB_Logo_Type_RGB_Flat < https://protect-us.mimecast.com/s/wX47BGfOX6rUw >

                       CIS Email Icons 01_23-02 < https://protect-us.mimecast.com/s/arplBLhVE83TL?domain=facebook.com >     CIS Email Icons 01_23-03 < https://protect-us.mimecast.com/s/271dB9HARmGs3?domain=twitter.com >    CIS Email Icons 01_23-04 < https://protect-us.mimecast.com/s/6RNxBLfVexaTl?domain=youtube.com >     CIS Email Icons 01_23-05 < https://protect-us.mimecast.com/s/NVeJBWs4Q8Xfl?domain=linkedin.com > 

From: OVAL_Developer [Caution-mailto:oval_developer-bounces@lists.cisecurity.org < Caution-mailto:oval_developer-bounces@lists.cisecurity.org > ] On Behalf Of David Solin
Sent: Tuesday, September 5, 2017 6:35 PM
To: OVAL Developer List <oval_developer@lists.cisecurity.org < Caution-mailto:oval_developer@lists.cisecurity.org > >
Subject: Re: [OVAL DEVELOPER] [Non-DoD Source] Implementation issue for win-def:accesstoken_object (and win-def:userright_object)

Actually… I personally think in this case the more traditionally “OVAL” approach would be to say the corresponding oval-sc:object/@flag=“does not exist”.

When I wrote this question last Thursday, I had the idea that the item could have multiple trustee_name/trustee_sid entities, but in reality those are specified in the schema as singleton entities for the item.  Therefore, since the design for the object is to have one item result for each trustee with the right, it makes intuitive sense that if no trustees have the right, there would be no items.  If there are no items, the oval-sc:object/@flag would have to be set to “does not exist”.  Of course, clearly the right exists in the abstract — it’s a member of an enumeration, after all.

The accesstoken_object/item is a little bit different.  An OVAL interpreter has to create synthetic entities indicating the absence of each right that a principal does not have.  It seems strange to go from a case of having maybe one right being set to “1” with the other 44 rights being set to “0”, to suddenly saying the object doesn’t exist at all if the principal has none of the rights assigned.

So, those are my opinions on how these objects should work, from the perspective of an interpreter developer.  But I think it would be most instructive to learn what the NIST certification program’s assumptions were, as well as the assumptions made by other content authors who have used these tests.

Best regards,

—David Solin

David A. Solin
Co-Founder, Research & Technology
solin@jovalcm.com < Caution-mailto:solin@jovalcm.com >

Joval Continuous Monitoringhttps://protect-us.mimecast.com/s/bApzBYuk9Dqhq  < https://protect-us.mimecast.com/s/Jqe2BmSwGYLTb?domain=jovalcm.com >

Facebookhttps://protect-us.mimecast.com/s/X8d4B3ImVJXh2  < https://protect-us.mimecast.com/s/7GXMBYfRnA5iv?domain=facebook.com >  Linkedinhttps://protect-us.mimecast.com/s/EJReB8uWpE9Um  < https://protect-us.mimecast.com/s/RKg5BJUpQEoc6?domain=linkedin.com >

On Sep 5, 2017, at 2:51 PM, Jerome Athias <jerome.athias@protonmail.com < Caution-mailto:jerome.athias@protonmail.com > > wrote:

 

Sounds like clearer and unambiguous, if files/packets size is not an issue 

 

 

On Tue, Sep 5, 2017 at 10:45 PM, Wilson, Bryan L CIV USN SPAWARSYSCEN LANT SC (US) <bryan.l.wilson.civ@mail.mil < Caution-mailto:bryan.l.wilson.civ@mail.mil > > wrote:

	David, 
	
	I still need to research the accesstoken test but regarding the userright test: 
	
	I believe if a user right has "NO ONE" assigned to it the OVAL-Results should look like this: 
	
	<win-sc:userright_item id="7" status="exists"> 
	<win-sc:userright>SE_REMOTE_SHUTDOWN_NAME</win-sc:userright> 
	<win-sc:trustee_name status="does not exist"></win-sc:trustee_name> 
	<win-sc:trustee_sid status="does not exist"></win-sc:trustee_sid> 
	</win-sc:userright_item> 
	
	Let me know what your thoughts are. 
	
	Bryan Wilson 
	SPAWAR Systems Center Atlantic 
	
	-----Original Message----- 
	From: OVAL_Developer [Caution-mailto:oval_developer-bounces@lists.cisecurity.org < Caution-mailto:oval_developer-bounces@lists.cisecurity.org > ] On Behalf Of David Solin 
	Sent: Thursday, August 31, 2017 3:42 PM 
	To: OVAL Developer List 
	Subject: [Non-DoD Source] [OVAL DEVELOPER] Implementation issue for win-def:accesstoken_object (and win-def:userright_object) 
	
	All active links contained in this email were disabled. Please verify the identity of the sender, and confirm the authenticity of all links contained within the message prior to copying and pasting the address to a Web browser. 
	
	
	________________________________ 
	
	
	
	Hi OVAL developers, 
	
	The two accesstoken/userright-related OVAL tests are slightly ambiguous about how to behave in the case where there are no rights assigned to a principal (in the case of the accesstoken_object), or no users with the specified right (in the case of the userright_object). 
	
	In the case of accesstoken_object, assuming the principal exists, should there be an item with all the rights set to 0? Or should the oval-res:object be flagged "does not exist"? 
	
	In the case of userright_object, should there be an item with a userright entity flagged "does not exist"? Or should the oval-res:object be flagged "does not exist"? 
	
	In addition to making a determination for clarification in the next version of OVAL, we should determine whether any existing content (e.g., USGCB, STIG) is specifically designed for one implementation or the other. 
	
	Best regards, 
	—David Solin 
	
	
	David A. Solin 
	Co-Founder, Research & Technology 
	solin@jovalcm.com < Caution-mailto:solin@jovalcm.com >  < Caution-Caution-mailto:solin@jovalcm.com < Caution-mailto:solin@jovalcm.com >  > 
	
	Joval Continuous Monitoring<https://protect-us.mimecast.com/s/vlqXBpTnNxofz < https://protect-us.mimecast.com/s/bApzBYuk9Dqhq > > < https://protect-us.mimecast.com/s/Jqe2BmSwGYLTb?domain=jovalcm.com < https://protect-us.mimecast.com/s/Jqe2BmSwGYLTb?domain=jovalcm.com >  > 
	
	Facebook< https://protect-us.mimecast.com/s/nKa0BqUdeLrCk < https://protect-us.mimecast.com/s/X8d4B3ImVJXh2 > > < https://protect-us.mimecast.com/s/7GXMBYfRnA5iv?domain=facebook.com < https://protect-us.mimecast.com/s/7GXMBYfRnA5iv?domain=facebook.com >  > Linkedin<https://protect-us.mimecast.com/s/1db4BMUpNYKcn < https://protect-us.mimecast.com/s/EJReB8uWpE9Um > > < https://protect-us.mimecast.com/s/RKg5BJUpQEoc6?domain=linkedin.com < https://protect-us.mimecast.com/s/RKg5BJUpQEoc6?domain=linkedin.com >  > 

.....

This message and attachments may contain confidential information. If it appears that this message was sent to you by mistake, any retention, dissemination, distribution or copying of this message and attachments is strictly prohibited. Please notify the sender immediately and permanently delete the message and any attachments.