Do u copy? On Thu, Sep 21, 2017 at 4:23 PM, Jerome Athias <jerome.athias@protonmail.com> wrote: > Hi > > Why not using a "military communication way" or alpha/bravo/tango/Charlie control tower way? Roger that? 5/5... + SAML like info > > 2c > > On Wed, Sep 20, 2017 at 8:49 PM, Wilson, Bryan L CIV USN SPAWARSYSCEN LANT SC (US) <bryan.l.wilson.civ@mail.mil> wrote: > >> 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/qO52Bxu6V4pf9?domain=oval.mitre.org](https://protect-us.mimecast.com/s/VAq3B5uqobrhV?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/qO52Bxu6V4pf9?domain=oval.mitre.org](https://protect-us.mimecast.com/s/VAq3B5uqobrhV?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: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> >> >> ############################################################################################################ >> >> -----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 truealse 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/4QN8BZiqEkVsg](https://protect-us.mimecast.com/s/5JNQBkugRAKho) > >> >> CIS Email Icons 01_23-02 < [https://protect-us.mimecast.com/s/dqpZB0SMrvGhm?domain=facebook.com](https://protect-us.mimecast.com/s/g5GpBbUlm6Qh9?domain=facebook.com) > CIS Email Icons 01_23-03 < [https://protect-us.mimecast.com/s/DzeKBdIoNGwfE?domain=twitter.com](https://protect-us.mimecast.com/s/oXpwBdfQWr7uW?domain=twitter.com) > CIS Email Icons 01_23-04 < [https://protect-us.mimecast.com/s/8JNOBeuonaLfQ?domain=youtube.com](https://protect-us.mimecast.com/s/ANWLBgUXEgQC7?domain=youtube.com) > CIS Email Icons 01_23-05 < [https://protect-us.mimecast.com/s/QQ5EBNiNk6xTD?domain=linkedin.com](https://protect-us.mimecast.com/s/3RvDBzfeRbKI5?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 Monitoring<[https://protect-us.mimecast.com/s/xNdEBKUJp8xUX](https://protect-us.mimecast.com/s/qO52Bxu6wmOtJ)> < [https://protect-us.mimecast.com/s/MdebBKUQgz5un?domain=jovalcm.com](https://protect-us.mimecast.com/s/4QN8BZiqx1Xhz?domain=jovalcm.com) > >> >> Facebook< [https://protect-us.mimecast.com/s/O5JXBwU2Nr7CJ](https://protect-us.mimecast.com/s/dqpZB0SMzNdUG)> < [https://protect-us.mimecast.com/s/9XN9B0fqX6as7?domain=facebook.com](https://protect-us.mimecast.com/s/DzeKBdIovlphG?domain=facebook.com) > Linkedin< [https://protect-us.mimecast.com/s/lNpeBgULZNDfN](https://protect-us.mimecast.com/s/8JNOBeuoMEghr)> < [https://protect-us.mimecast.com/s/zN8gBwUEqo5fg?domain=linkedin.com](https://protect-us.mimecast.com/s/QQ5EBNiN9K3c4?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/rxg6BOud3nRfk](https://protect-us.mimecast.com/s/xNdEBKUJVmGUp) < [https://protect-us.mimecast.com/s/xNdEBKUJp8xUX](https://protect-us.mimecast.com/s/qO52Bxu6wmOtJ) > > < [https://protect-us.mimecast.com/s/MdebBKUQgz5un?domain=jovalcm.com](https://protect-us.mimecast.com/s/4QN8BZiqx1Xhz?domain=jovalcm.com) < [https://protect-us.mimecast.com/s/MdebBKUQgz5un?domain=jovalcm.com](https://protect-us.mimecast.com/s/4QN8BZiqx1Xhz?domain=jovalcm.com) > > >> >> Facebook< [https://protect-us.mimecast.com/s/Zp8VBDIA7JkuG](https://protect-us.mimecast.com/s/MdebBKUQxELuY) < [https://protect-us.mimecast.com/s/O5JXBwU2Nr7CJ](https://protect-us.mimecast.com/s/dqpZB0SMzNdUG) > > < [https://protect-us.mimecast.com/s/9XN9B0fqX6as7?domain=facebook.com](https://protect-us.mimecast.com/s/DzeKBdIovlphG?domain=facebook.com) < [https://protect-us.mimecast.com/s/9XN9B0fqX6as7?domain=facebook.com](https://protect-us.mimecast.com/s/DzeKBdIovlphG?domain=facebook.com) > > Linkedin<[https://protect-us.mimecast.com/s/mmJWBAc089qfK](https://protect-us.mimecast.com/s/O5JXBwU2wJRtn) < [https://protect-us.mimecast.com/s/lNpeBgULZNDfN](https://protect-us.mimecast.com/s/8JNOBeuoMEghr) > > < [https://protect-us.mimecast.com/s/zN8gBwUEqo5fg?domain=linkedin.com](https://protect-us.mimecast.com/s/QQ5EBNiN9K3c4?domain=linkedin.com) < [https://protect-us.mimecast.com/s/zN8gBwUEqo5fg?domain=linkedin.com](https://protect-us.mimecast.com/s/QQ5EBNiN9K3c4?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.