Re: [sacm] Hackathon Goals and Stretch Goals

[Adam Montville <[e-mail]>]

Ira, thank you for sharing your opinion. I am perfectly fine making such a
declaration, but I would like others to chime in also. I know at least one
other who believes doing this would be a good idea, but I'm not sure about
any sort of consensus on the issue at this point.

To your other points, I agree completely - this is proof-of-concept work,
not finished product. So, it can be an ugly, but instructional, solution.

Adam

On Fri, May 19, 2017 at 1:39 PM Ira McDonald <[e-mail]>
wrote:

> Hi Adam,
>
> Chiming in below on one point raised in this Hackathon goals conversation.
>
> Cheers,
> - Ira
>
>
> On Tue, May 16, 2017 at 2:47 PM, Adam Montville <
> [e-mail]> wrote:
>
>> Hi Henk. I'll try inline.
>>
>> On Tue, May 16, 2017 at 11:04 AM Henk Birkholz <
>> [e-mail]> wrote:
>>
> <...snip...>
>>
>
>>> Also, I noticed conflicting notions about how important it is to prepare
>>> a message format to convey information between components. While it
>>> might not be as critical as "having actual component code to work with",
>>> interoperability is key. And if we would agree on a preliminary data
>>> structure (probably derived from the current IM), before we start the
>>> hackathon, we could save some time during the f2f on-site. It's probably
>>> a low hanging fruit also, as I am not talking about every IE to be
>>> conveyed, but about the general message structure ("the container") and
>>> the corresponding encoding for data in motion.
>>>
>>
>> [AWM] There are differing perspectives on this front. Yes, having a
>> common structure could be useful, but it may not be necessary for the
>> purposes of this effort. This effort is somewhat different from others that
>> I've heard of, in that we are not implementing a solution as much as we are
>> discovering one. I do expect that we will discover the structures we need
>> as we develop the solution. What do others think about this? Do we need to
>> have this information up front, or is it something we can discover as we go?
>>
>
> <ira> For message wire format for the Hackathon, please consider taking
> the SACM
> Information Model verbatim and using that XSD for XML wire format.
> Efficiency is
> totally irrelevant.  So is elegance.  You're trying to do a proof of
> concept.  Defining
> the Hackathon wire format interactively in the room is a time waster idea,
> IMO.
>
>>
>>
>>>
>>> Thoughts?
>>>
>>>
>>> Viele Grüße,
>>>
>>> Henk
>>>
>>>
>>>
>>>
>>> On 05/16/2017 05:12 PM, Haynes, Dan wrote:
>>> > Seems like a reasonable story to focus around, for the hackathon, to
>>> me.
>>> >
>>> >
>>> >
>>> > Thanks,
>>> >
>>> > Danny
>>> >
>>> >
>>> >
>>> > *From:*sacm [mailto:[e-mail]] *On Behalf Of *Jerome
>>> Athias
>>> > *Sent:* Monday, May 15, 2017 11:12 PM
>>> > *To:* Adam Montville <[e-mail]>; Waltermire, David
>>> A.
>>> > (Fed) <[e-mail]>; [e-mail]
>>> > *Subject:* Re: [sacm] Hackathon Goals and Stretch Goals
>>> >
>>> >
>>> >
>>> > I think it's a good idea too.
>>> >
>>> > I don't know who is supposed to participate to this hackathon?
>>> >
>>> > Potentially you could market it by capitalizing on real known events,
>>> > (without trolling) let's say "new critical vulnerability", "for
>>> > preventing ransomware" "FictitousCorp needs to Respond quickly and have
>>> > a system to Identify and Protect its endpoints..."
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > On Tue, 16 May 2017 at 00:30, Adam Montville <
>>> [e-mail]
>>> > <mailto:[e-mail]>> wrote:
>>> >
>>> >     I think that's a good idea. How do folks feel about this story? Is
>>> >     it lacking anything? Is it too specific? What would you change
>>> about
>>> >     it if you could?
>>> >
>>> >
>>> >
>>> >     On Mon, May 15, 2017 at 12:57 PM Waltermire, David A. (Fed)
>>> >     <[e-mail] <mailto:[e-mail]>>
>>> wrote:
>>> >
>>> >         I was thinking that it would be useful to have a user story to
>>> >         implement against for the Hackathon. How about something like
>>> >         the following that maps to our goals:
>>> >
>>> >
>>> >
>>> >         A vendor identifies a vulnerability in their software product.
>>> >         They produce a new version of their software and publish a
>>> >         vulnerability bulletin that indicates customers should upgrade
>>> >         to the new version to address the vulnerability. The product
>>> >         versions have both a SWID tag and a CoSWID tag. As a customer
>>> of
>>> >         this vendor that uses the affected products, we need to build a
>>> >         vulnerability assessment system that is capable of detecting
>>> >         what version of the software is installed and determine if that
>>> >         version is vulnerable using the vendor provided information.
>>> The
>>> >         Collector will be capable of gathering software inventory
>>> >         information from one or more target endpoints by:
>>> >
>>> >
>>> >
>>> >         1)      Requesting software inventory information for the
>>> >         affected software based on an ad-hoc request.
>>> >
>>> >         2)      Reporting the software inventory as software changes
>>> occur
>>> >
>>> >
>>> >
>>> >         Collected software inventory information will be stored in the
>>> >         Assessment Results Repository and will be compared to
>>> >         vulnerability detection data retrieved from the Vulnerability
>>> >         Detection Data Repository. The vulnerability detection data
>>> will
>>> >         be derived from the vendor provided information in some useful
>>> >         way to be determined by the Vulnerability Assessor.
>>> >
>>> >
>>> >
>>> >         How does this look?
>>> >
>>> >
>>> >
>>> >         Regards,
>>> >
>>> >         Dave
>>> >
>>> >
>>> >
>>> >         *From:*sacm [mailto:[e-mail]
>>> >         <mailto:[e-mail]>] *On Behalf Of *Adam Montville
>>> >         *Sent:* Tuesday, May 09, 2017 3:30 PM
>>> >         *To:* [e-mail] <mailto:[e-mail]>
>>> >         *Subject:* Re: [sacm] Hackathon Goals and Stretch Goals
>>> >
>>> >
>>> >
>>> >         All:
>>> >
>>> >
>>> >
>>> >         This week Dave and I have had an opportunity to discuss these a
>>> >         bit further. We've come up with the following set of goals and
>>> >         outcomes:
>>> >
>>> >
>>> >
>>> >         GOAL: Running code demonstrating the communication needs
>>> between
>>> >         identified components as they pertain to the on-request
>>> >         collection case through the scenario, where that case is
>>> >         described
>>> >         at
>>> https://trac.ietf.org/trac/sacm/wiki/SacmVulnerabilityAssessmentScenario
>>> .
>>> >         OUTCOME: We will have specific understanding of components'
>>> >         boundaries and the necessary information flows (including
>>> >         information being communicated) between them.
>>> >
>>> >
>>> >
>>> >         GOAL: Leverage existing collected data in a data repository.
>>> >         OUTCOME: Demonstrate that previously collected data can be
>>> >         reused to support vulnerability assessment
>>> >
>>> >
>>> >
>>> >         GOAL: Running code to extend that base case to include a
>>> >         mechanism capable of monitoring a given set of endpoint
>>> >         attributes for change. OUTCOME: We will have specific
>>> >         understanding of additional architectural considerations for
>>> >         handling monitoring vs. on-request collection, as well as any
>>> >         additional information flows required.
>>> >
>>> >
>>> >
>>> >         Does anyone care to bash these goal-ouctome pairs in the
>>> context
>>> >         of our hackathon plans?  If so, please do so over the next day
>>> >         or two, otherwise these will become the stated goals for our
>>> >         hackathon.
>>> >
>>> >
>>> >
>>> >         Kind regards,
>>> >
>>> >
>>> >
>>> >         Adam
>>> >
>>> >
>>> >
>>> >         On Tue, May 2, 2017 at 4:40 PM Adam Montville
>>> >         <[e-mail] <mailto:[e-mail]
>>> >>
>>> >         wrote:
>>> >
>>> >             All:
>>> >
>>> >
>>> >
>>> >             Last week Dave sent a list of milestones to the list. The
>>> >             first of which was for the WG to define some goals for the
>>> >             IETF 99 hackathon. I can see at least one primary goal with
>>> >             at least one stretch goal. The primary goal is to have
>>> >             running code demonstrating the basic/ideal case through our
>>> >             vulnerability scenario, where a new vulnerability is
>>> >             discovered and we need to reach out all the way to the
>>> >             endpoint to determine whether it is in fact vulnerable. A
>>> >             stretch goal might be to have running code demonstrating a
>>> >             "monitor for this vulnerability from now on" capability
>>> (I'm
>>> >             sure I'm not stating that as well as I could).
>>> >
>>> >
>>> >
>>> >             Does anyone have additional goals? Or, are there better
>>> ways
>>> >             to state these particular goals (there probably are)?
>>> >
>>> >
>>> >
>>> >             Kind regards,
>>> >
>>> >
>>> >
>>> >             Adam
>>> >
>>> >     _______________________________________________
>>> >     sacm mailing list
>>> >     [e-mail] <mailto:[e-mail]>
>>> >     https://www.ietf.org/mailman/listinfo/sacm
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > sacm mailing list
>>> > [e-mail]
>>> > https://www.ietf.org/mailman/listinfo/sacm
>>> >
>>>
>>> _______________________________________________
>>> sacm mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/sacm
>>>
>>
>> _______________________________________________
>> sacm mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/sacm
>>
>>