Re: [sacm] Hackathon Goals and Stretch Goals

Ira McDonald <blueroofmusic@gmail.com> Fri, 19 May 2017 18:39 UTC

Return-Path: <blueroofmusic@gmail.com>
X-Original-To: sacm@ietfa.amsl.com
Delivered-To: sacm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 197D11292CE for <sacm@ietfa.amsl.com>; Fri, 19 May 2017 11:39:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level:
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0IZKbnuiSETz for <sacm@ietfa.amsl.com>; Fri, 19 May 2017 11:39:41 -0700 (PDT)
Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7478B1273B1 for <sacm@ietf.org>; Fri, 19 May 2017 11:39:41 -0700 (PDT)
Received: by mail-qk0-x233.google.com with SMTP id a72so67965884qkj.2 for <sacm@ietf.org>; Fri, 19 May 2017 11:39:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7u4q9oc0N5daoN8fFlmfOx6YVRYunER4BUErVs2syi8=; b=Def80hFeCAfpxqQmEgOO8uBB6/cLml2mQHgi50gnu5H1vjSUkVTyflP9Sp5z9u74j9 IOmYk3+RQigQlWrorDv437u4ww1RgRx1xFJw9lJPzjJzSetAzWBXzfQL3Jk7H1H5xwCp dER7BQ+OArGRlKv3Aejw0jZhdL47XHgwkXh07OBJr/KzvPB9gVGNo38JEqJFyAQAGW0k a+ypLTVXvN/wWVE2NPiJm0DHnTaEuiQcacSZDNwFF3mdtbuaATZyGOL65jieNhMwm94z zD2bBPGj7JSqmY0OM24FzkYwD3O6cF9eqR8dBMwu4bQMlQ/RtesmImOdnq80pgkOs4ul 0new==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7u4q9oc0N5daoN8fFlmfOx6YVRYunER4BUErVs2syi8=; b=SqijeAV6Ss7brj/v+IVLs0yCf0ilAazn3dkClrEiCAPtE1Ga7/mCFHrl9A7NDeATb8 TLXq8p+lJSpOUigi+08m/9m3AOrLqak1WtMrvr42G7PvaUSXicOb3tqFiOt9hJazBuZA lELakZMrD/cgr+TnMwb0Xx8AjSbSz2VL0m8Rj1ZYOJsPcfCA/MepG639qTJWHP4zRRyU i55OB3Gy0IuhWKUOKF6UpGsi+oOMW3Y0oiz3ShszuEkuq41P7uwMlh8u1wsIh9sgfMZU i02F6YVsgCAhAVymkMmNDvkFaB0Bvh4mndynThyrWMqNFvck9YGo1SMLEVlMxO9Cf9Bw PuKg==
X-Gm-Message-State: AODbwcBLUzYNJiAQu+zbkTJXlD16Xe3G+CUzOALvs2MVLce7+ILRRDqW e+QPNBzfaYgR+N/enYG5oo4O/RwyFA==
X-Received: by 10.55.138.1 with SMTP id m1mr10726917qkd.270.1495219180568; Fri, 19 May 2017 11:39:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.85.99 with HTTP; Fri, 19 May 2017 11:39:20 -0700 (PDT)
In-Reply-To: <CACknUNU-kuGMi8Oass_JT+3CvpAgbm8PAb1_KDTwM6D2X1o-JQ@mail.gmail.com>
References: <CACknUNUhqqdumk1wombsAha0TQS4O4dNpajUs2Ak4jWDWZHXaA@mail.gmail.com> <CACknUNUQ_sgw46GsU8LoOq1puEyo8DUnJ4599h0GE=+Nc2Hxow@mail.gmail.com> <MWHPR09MB1440A80762DE455376735978F0E10@MWHPR09MB1440.namprd09.prod.outlook.com> <CACknUNUA0YH5EXQrPJHMWqfp=PZcVc_FpeTR0T9SmRMsteSvhw@mail.gmail.com> <CAA=AuEf_7A4ObvoiGHHzhtzNTS2B3Wxiz+WcBjwc8dqh4z7h2g@mail.gmail.com> <DM5PR09MB1354402E944E81A585B279D1A5E60@DM5PR09MB1354.namprd09.prod.outlook.com> <90838fdd-07be-fdf8-300f-614425d360ec@sit.fraunhofer.de> <CACknUNU-kuGMi8Oass_JT+3CvpAgbm8PAb1_KDTwM6D2X1o-JQ@mail.gmail.com>
From: Ira McDonald <blueroofmusic@gmail.com>
Date: Fri, 19 May 2017 14:39:20 -0400
Message-ID: <CAN40gStPGRW7P6m2m7QrO8awCuksjyQoga4QCD3BzFqa_GN26Q@mail.gmail.com>
To: Adam Montville <adam.w.montville@gmail.com>, Ira McDonald <blueroofmusic@gmail.com>
Cc: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, "sacm@ietf.org" <sacm@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c072ace1e8a66054fe4d8a9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sacm/UFxeENl5eCVR1MbgWlCyvxjWXuE>
Subject: Re: [sacm] Hackathon Goals and Stretch Goals
X-BeenThere: sacm@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SACM WG mail list <sacm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sacm>, <mailto:sacm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sacm/>
List-Post: <mailto:sacm@ietf.org>
List-Help: <mailto:sacm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sacm>, <mailto:sacm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 May 2017 18:39:44 -0000

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 <adam.w.montville@gmail.com>
wrote:

> Hi Henk. I'll try inline.
>
> On Tue, May 16, 2017 at 11:04 AM Henk Birkholz <
> henk.birkholz@sit.fraunhofer.de> 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:sacm-bounces@ietf.org] *On Behalf Of *Jerome Athias
>> > *Sent:* Monday, May 15, 2017 11:12 PM
>> > *To:* Adam Montville <adam.w.montville@gmail.com>; Waltermire, David A.
>> > (Fed) <david.waltermire@nist.gov>; sacm@ietf.org
>> > *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 <
>> adam.w.montville@gmail.com
>> > <mailto: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 <mailto: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
>> >         <mailto:sacm-bounces@ietf.org>] *On Behalf Of *Adam Montville
>> >         *Sent:* Tuesday, May 09, 2017 3:30 PM
>> >         *To:* sacm@ietf.org <mailto: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 <mailto: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 <mailto:sacm@ietf.org>
>> >     https://www.ietf.org/mailman/listinfo/sacm
>> >
>> >
>> >
>> > _______________________________________________
>> > 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
>>
>
> _______________________________________________
> sacm mailing list
> sacm@ietf.org
> https://www.ietf.org/mailman/listinfo/sacm
>
>