Validate Hackathon (100) Scope

[adammontville]

Use this issue to discuss the anticipated scope of the hackathon. During the last hackathon, we essentially had two tables working separately. Both efforts were successful, and then during the SACM session at IETF 99 there was in-room support for merging the two efforts in a continuation for the IETF 100 hackathon.

That's what this scope issue is about - what do you believe the scope of this hackathon effort ought to be? Be as precise as possible, be open and accepting in the discussion.

[adammontville]

Now that the draft charter has been posted (see https://mailarchive.ietf.org/arch/msg/sacm/O1GxmdrJrWRLA5xpEE0RP4PgWw0), we can expect the charter discussion to progress. In the meantime, it would be good to start considering how this hackathon effort may be impacted by the proposed charter.

Please opine here.

[sacm]

It's probably too late, but the verbiage " 4. Compare actual element values to expected element values" has always bugged me. Usually the comparison is to make a compliance or vulnerability judgement, so you're generally either comparing the actual element values to element values that indicate known vulnerable states, or that indicate when elements are in or out of compliance with a policy. Neither of those operations really address "expected element values". Sometimes, for an inventory use case, the elements are just collected and evaluated to determine which additional elements must be collected and evaluated to inform a vulnerability or compliance evaluation. I suppose my specific objection is the use of the word "expected." Could you use "acceptable" or "policy compliant" instead? That said, firming up the charter is a pretty basic group function that is overdue for this effort. I applaud your action in trying to get it done. Joseph L. Wolfkiel SCM Engineering Lead DISA ID52 Fort Meade DISA Acquisiton Bldg Cube A4A58E Work: (301) 225-8820 Gov Cell: (571) 814-8231 Joseph.L.Wolfkiel.civ@mail.mil

…

-----Original Message----- From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of adammontville Sent: Thursday, September 14, 2017 11:54 AM To: sacmwg/vulnerability-scenario <vulnerability-scenario@noreply.github.com> Cc: Subscribed <subscribed@noreply.github.com> Subject: [Non-DoD Source] Re: [sacm] [sacmwg/vulnerability-scenario] Validate Hackathon (100) Scope (#30) 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.

________________________________ Now that the draft charter has been posted (see Caution-https://mailarchive.ietf.org/arch/msg/sacm/O1GxmdrJrWRLA5xpEE0RP4PgWw0 < Caution-https://mailarchive.ietf.org/arch/msg/sacm/O1GxmdrJrWRLA5xpEE0RP4PgWw0 > ), we can expect the charter discussion to progress. In the meantime, it would be good to start considering how this hackathon effort may be impacted by the proposed charter. Please opine here. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub < Caution-#30 (comment) > , or mute the thread < Caution-https://github.com/notifications/unsubscribe-auth/AKbE0XIBK7fTVDg9S2f_Pj2d0f54Mc8iks5siUwbgaJpZM4PUoUD > . <Caution-https://github.com/notifications/beacon/AKbE0Ye0GiY_Inkpz7yy8OJZ7_Y0vJFNks5siUwbgaJpZM4PUoUD.gif>

[henkbirkholz]

Hello, thank you for catching that. the revised YANG datatstore draft refers to "intended", IIRC. But - this is from a management perspective, not from a security pov. In consequence, (also, if not to late), referencing the intended metadata origin type, illustrating the difference (if any - I am pretty certain there is a subtle one) would be nice to have - and deciding on (if there is - and I am rathee certain there is) the equivalence of CC'ish "policy compliant" and "expected collection results" should be done. It is not bad if it is too late here, we can consolidate/resolve this in the terminology document at any time. Viele Grüße, Henk p.s. sry 4 my radio silence. I was absent rather unexpected for a while.

…

On September 14, 2017 8:16:49 PM GMT+02:00, sacm ***@***.***> wrote: It's probably too late, but the verbiage " 4. Compare actual element values to expected element values" has always bugged me. Usually the comparison is to make a compliance or vulnerability judgement, so you're generally either comparing the actual element values to element values that indicate known vulnerable states, or that indicate when elements are in or out of compliance with a policy. Neither of those operations really address "expected element values". Sometimes, for an inventory use case, the elements are just collected and evaluated to determine which additional elements must be collected and evaluated to inform a vulnerability or compliance evaluation. I suppose my specific objection is the use of the word "expected." Could you use "acceptable" or "policy compliant" instead? That said, firming up the charter is a pretty basic group function that is overdue for this effort. I applaud your action in trying to get it done. Joseph L. Wolfkiel SCM Engineering Lead DISA ID52 Fort Meade DISA Acquisiton Bldg Cube A4A58E Work: (301) 225-8820 Gov Cell: (571) 814-8231 ***@***.*** -----Original Message----- From: sacm ***@***.*** On Behalf Of adammontville Sent: Thursday, September 14, 2017 11:54 AM To: sacmwg/vulnerability-scenario ***@***.***> Cc: Subscribed ***@***.***> Subject: [Non-DoD Source] Re: [sacm] [sacmwg/vulnerability-scenario] Validate Hackathon (100) Scope (#30) 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. ________________________________ Now that the draft charter has been posted (see Caution-https://mailarchive.ietf.org/arch/msg/sacm/O1GxmdrJrWRLA5xpEE0RP4PgWw0 < Caution-https://mailarchive.ietf.org/arch/msg/sacm/O1GxmdrJrWRLA5xpEE0RP4PgWw0 > ), we can expect the charter discussion to progress. In the meantime, it would be good to start considering how this hackathon effort may be impacted by the proposed charter. Please opine here. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub < Caution-#30 (comment) > , or mute the thread < Caution-https://github.com/notifications/unsubscribe-auth/AKbE0XIBK7fTVDg9S2f_Pj2d0f54Mc8iks5siUwbgaJpZM4PUoUD > . <Caution-https://github.com/notifications/beacon/AKbE0Ye0GiY_Inkpz7yy8OJZ7_Y0vJFNks5siUwbgaJpZM4PUoUD.gif> -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: #30 (comment)

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

[adammontville]

Joe, thanks for this comment. I've posted a note on the charter thread for yours. Henk, I'm not sure what you were suggesting in your comment, so if you have specific replacement text to propose for the charter, please comment directly in that thread.

[adammontville]

@henkbirkholz @djhaynes @wmunyan @david-waltermire-nist @strongX509 @canb227

Now that the charter discussion is in a reasonably stable place, we're getting the band back together to arrive at a mutually agreeable scope for hackathon 100. At the conclusion of hackathon 99, I put together this notional diagram as a straw man to get our conversation started: https://raw.githubusercontent.com/sacmwg/vulnerability-scenario/master/ietf_hackathon/graphics/hackathon_deployment_combined.png

Dave and Stephen believe that 99 gave them enough to go on for crafting an evaluation language (outstanding!). For 100, I would propose that our desired outcome would be enough information/experience to have enough to go on for coming up with orchestration and collection guidance.

Please provide your thoughts on scope for 100 on this thread, so that the conversation is reflected in GitHub on the appropriate issue (or simply respond in GitHub directly).

[adammontville]

During 2017-10-05 meeting we talked about the high-level scope for 100 being, roughly, the following:

• Confirm broker exists - @henkbirkholz can you please confirm this? (see Confirm broker exists #32 )
• We need docs on broker interface - @henkbirkholz can you please provide this (or provide code we can try to auto-gen docs)? (see Document xmpp-grid broker interface(s) #33 )
• We need to build the CIS-CAT interface to xmpp-grid - @wmunyan will have this once the above are confirmed/done
• We need to build the StrongTNC interface to xmpp-grid - @strongX509 Are you planning to participate? If not, we need someone to help with this.

[adammontville]

I was able to get in touch with Andreas ( @strongX509 ). If there is a desire for a StrongTNC-xmpp-grid interface he's interested in working on it (I'm paraphrasing a bit). Then, what remains is ensuring the broker exists (I think this confirms it, but I would like @henkbirkholz to confirm for certain), and getting that xmpp-grid interface documentation in order.

@wmunyan @strongX509 @henkbirkholz : If any of you have ways to break down tasks, feel free to add them to our TODO column (there are already a couple of placeholders there).

[adammontville]

Upon our discussion today, we declared our scope as being defined well enough for us to make progress. Thanks to all who contributed to the discussion here and during the meeting today.