Re: [sacm] Hackathon Goals and Stretch Goals

Apologies for the multiple emails, but there may be opportunities via
individual networks as well.

On May 15, 2017 11:30 PM, "Tim Harrison" <timothy.harrison.0@gmail.com>
wrote:

> 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/SacmVulnerabilityAss
>>>> essmentScenario.  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
>>
>>