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" <athiasjerome@gmail.com> 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 <adam.w.montville@gmail.com>
> 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) <
>> david.waltermire@nist.gov> 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:sacm-bounces@ietf.org] *On Behalf Of *Adam
>>> Montville
>>> *Sent:* Tuesday, May 09, 2017 3:30 PM
>>> *To:* sacm@ietf.org
>>> *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 <
>>> adam.w.montville@gmail.com> 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
>> sacm@ietf.org
>> https://www.ietf.org/mailman/listinfo/sacm
>>
>
> _______________________________________________
> sacm mailing list
> sacm@ietf.org
> https://www.ietf.org/mailman/listinfo/sacm
>
>