Re: [sacm] Hackathon Goals and Stretch Goals

["Waltermire, David A. (Fed)" <[e-mail]>]

Kathleen,

Thanks for clarifying the participation model for the Hackathon. The fact that it is open to anyone is important.

As for Tim's email, which CTF event in Prague are you referring to?

I found one hosted by Accenture tomorrow, but I am not aware of one around the time of the IETF.

Regards,
Dave

> -----Original Message-----
> From: Kathleen Moriarty [mailto:[e-mail]]
> Sent: Tuesday, May 16, 2017 10:58 AM
> To: Waltermire, David A. (Fed) <[e-mail]>
> Cc: Tim Harrison <[e-mail]>; Jerome Athias
> <[e-mail]>; [e-mail]; Adam Montville
> <[e-mail]>
> Subject: Re: [sacm] Hackathon Goals and Stretch Goals
> 
> Hi,
> 
> Just a couple of points.  If some of you are near enough to Prague and
> wanted to attend the Hackathon, but not the IETF, that is not a problem and
> signup is separate from the IETF registration.  The Hackathon is free to attend
> and open to the public.
> 
> David, I think Tim was just suggesting that people who attend the capture
> the flag event (in Prague), may also be interested in attending the
> Hackathon, so recruiting there could be fruitful.
> 
> Best regards,
> Kathleen
> 
> On Tue, May 16, 2017 at 9:11 AM, Waltermire, David A. (Fed)
> <[e-mail]> wrote:
> > Tim,
> >
> >
> >
> > The Hackathon is more like an interop event than a Capture the Flag
> > (CTF) event. According to the IETF website “IETF Hackathons encourage
> > developers to collaborate and develop utilities, ideas, sample code
> > and solutions that show practical implementations of IETF standards.”
> > [1] What we are planning to do would be to collaboratively develop one
> > or more solutions within the scope of SACM that address the user story.
> >
> >
> >
> > We need volunteers to bring running code to address an aspect of this
> > project. For example, we are bringing 1) a ROLIE implementation that
> > can serve as a Vulnerability Detection Data Repository, and 2)
> > software with a bundled SWID tag and CoSWID tag to be installed on a
> system.
> >
> >
> >
> > Regards,
> >
> > Dave
> >
> >
> >
> > [1] https://www.ietf.org/hackathon/
> >
> >
> >
> > From: Tim Harrison [mailto:[e-mail]]
> > Sent: Monday, May 15, 2017 11:31 PM
> > To: Jerome Athias <[e-mail]>
> > Cc: [e-mail]; Adam Montville <[e-mail]>;
> > Waltermire, David A. (Fed) <[e-mail]>
> >
> >
> > Subject: Re: [sacm] Hackathon Goals and Stretch Goals
> >
> >
> >
> > Just a passing thought, but one might recruit candidates at a known
> > convention and/or via a Kaizen Capture the Flag (CTF) event -
> > https://kaizen-ctf.com/
> >
> >
> >
> > Cheers,
> >
> > Tim
> >
> >
> >
> > On May 15, 2017 11:14 PM, "Jerome Athias" <[e-mail]>
> wrote:
> >
> > 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]>
> > 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]> 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]] On Behalf Of Adam Montville
> > Sent: Tuesday, May 09, 2017 3:30 PM
> > To: [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]>
> > 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]
> > 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
> >
> 
> 
> 
> --
> 
> Best regards,
> Kathleen