Re: [sacm] Hackathon Goals and Stretch Goals

[Adam Montville <[e-mail]>]

Also, I've created a wiki page here:
https://trac.ietf.org/trac/sacm/wiki/SacmVulnerabilityAssessmentHackathon

At that page (version 4) I've put up a modified version of the user story
suggested earlier, hopefully making appropriate clarifications.

Kind regards,

Adam

On Tue, May 16, 2017 at 1: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:
>
>> Hello,
>>
>> the general story looks like a good fit. I am little uncertain about the
>> details regarding:
>>
>> >> 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.
>>
>> This seems to imply an iterative process, in which the Assessment
>> Results Repository first only stores the "current available information"
>> about software packages installed as software instances on the target
>> endpoint - and then enriches that with the assessment that this software
>> instance is vulnerable (has to be updated) or not. Is that correct?
>
>
>> This seems to merge the components "Assessment Results Repository",
>> which store the current "state of things are not compliant" and the
>> "Endpoint Repository", which stores the information (e.g. like a
>> configuration management system) in which stores information that
>> reflects what is currently installed on a target endpoint?
>>
>
> [AWM] Yes, I think the story could be clarified on this front. It
> shouldn't merge the two components we've agreed to keep separate. If the
> first sentence in your quoted text beging instead with "Collected software
> inventory will be stored in the Endpoint Repository..." I think that fixes
> some things.
>
>
>>
>> That's the only nit I have on the "story" :)
>>
>> 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?
>
>
>>
>> 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
>>
>