Re: [sacm] Hackathon Goals and Stretch Goals

[Adam Montville <[e-mail]>]

Thanks, Jess.
On Tue, May 30, 2017 at 9:43 AM Jessica Fitzgerald-McKay <[e-mail]>
wrote:

> We've been collaborating with Andreas Steffens on a SWIMA collector that
> operates well with strongSwan's NEA implementation. We hope to bring both
> SWIMA and strongSwan to the Hackathon.
>
> On Thu, May 25, 2017 at 9:06 AM, Adam Montville <
> [e-mail]> wrote:
>
>> I'm viewing the problem essentially in two parts. 1) we need to
>> understand the information we need between each component to inform the
>> information model, then 2) we will need to figure out how to best represent
>> that information. Solidifying the information model seems like the latter,
>> which cannot really be done without first understanding the former. To me,
>> the hackathon should be first focused on the former - learning more about
>> the information we really need - before it gets too far along.
>>
>> This is not to say that we will not be able to address both! Instead, I
>> am suggesting that we, in earnest, start focusing on the first part of this
>> problem, and then hopefully get to the second part of the problem.
>>
>> We have three distinct goals. We have a user story. Now we need a team to
>> come together and start working even before we get to Prague, so that we
>> can make some real progress. There is not very much time left...
>>
>> Bill and I are committed. I believe Dave and Stephen are committed. Henk,
>> I think, is committed also. Who else is interested in participating? And,
>> how do we want to start running this? We can set up a code repo in GitHub
>> so we have a place to track work items, issues, etc.  Being committed to
>> the effort requires becoming and remaining engaged in an ongoing work
>> effort.
>>
>> Kind regards,
>>
>> Adam
>>
>> On Tue, May 23, 2017 at 12:02 PM Nancy Cam-Winget (ncamwing) <
>> [e-mail]> wrote:
>>
>>> Hi all,
>>>
>>> Trying to catch up on the thread….I would agree with Ira and Henk’s
>>> comments/suggestion that we should be working towards a SACM goal.  That
>>> is, SACM has been working on solidifying an IM and the IM elements which
>>> are a MUST to implement….that way we enable the interoperability across the
>>> heterogeneity of the information available.
>>>
>>> I think there are going to be modules (or “glue”) needed to enable the
>>> current DB’s/repositories and their interfaces to be able to expose their
>>> available data in an (SACM) interoperable flow.
>>>
>>> If Henk can provide this, then we can focus on the mappings to get the
>>> interop underway then….
>>>
>>>         Nancy
>>>
>>> On 5/22/17, 9:48 AM, "sacm on behalf of Henk Birkholz" <
>>> [e-mail] on behalf of [e-mail]>
>>> wrote:
>>>
>>>     Hello all,
>>>
>>>     I totally agree that the method employed in Collection Tasks should
>>> not
>>>     use the inter-component mechanism/format of distributing SACM
>>> content with.
>>>
>>>     E.g. if there is a SWID repository that is a database (there are open
>>>     but not commonly or currently used examples for data base schemas in
>>>     regard to the outdated 2009 version of SWID, as far as I know), of
>>>     course an SQL query is used to collect them. In this example the
>>>     acquisition method employed by a Collector is simply an SQL used by
>>> that
>>>     data base. We SHOULD NOT build an alternative way to convey that
>>>     information!
>>>
>>>     Same goes for Attributes via IF-M to address Danny's example.
>>>
>>>     Now, looking downstream, the information queried has to be composed
>>> into
>>>     an actual tag. Most likely, a DB about tags will store the most
>>>     important items to query tags in tables (e.g. tag_id, entity_id,
>>>     package_name, version, etc.) and also the complete XML blob (if it
>>> fits
>>>     into a DB value, they can be large if stored in native XML). This is
>>> the
>>>     way that the only open source example that I actually personally
>>> know of
>>>     does it, at least.
>>>
>>>     If you finally have that tag (re-composed or queried en'blob)
>>> collected
>>>     and it is about a vulnerable software package that is currently
>>>     installed as software instances on target endpoints, how to convey
>>> that
>>>     information to other downstream components is the interesting point
>>>     here: Partial, or as a byte blob, or mapped to IE, at least in a way
>>>     that is not surprising to any SACM component in general.
>>>
>>>     If we do not use a common message encoding and msg structure (data
>>>     model) here (may it even be so preliminary that we just learn to use
>>> sth
>>>     else), how should interop with further components work? I was under
>>> the
>>>     impression that is the point of the IM?
>>>
>>>     If nobody has the time to do this (which might be the only
>>> concern?), I
>>>     can whip up an example using XSD and CDDL, and even YANG for YANG
>>> event
>>>     notification, if I find more than one or two consecutive hours...
>>>
>>>     Viele Grüße,
>>>
>>>     Henk
>>>
>>>
>>>     On 05/22/2017 04:16 PM, Haynes, Dan wrote:
>>>     > It’s probably also worth pointing out that if we are using existing
>>>     > protocols such as NEA, it may not make sense to directly change the
>>>     > fields in its over-the-wire format to match the SACM IM (e.g.
>>>     > communications between endpoint and server), rather, provide a
>>> mapping.
>>>     > Then, when the server receives the data, it can use the mapping to
>>> store
>>>     > the data in the repository such that it aligns with the data
>>> described
>>>     > in the IM. This approach will likely be required when we want to
>>>     > leverage existing protocols where we may not have the ability to
>>> change
>>>     > them (e.g. Apple MDM and Configuration Profiles, Windows PowerShell
>>>     > Desired State Configuration, etc.). With all that said, the
>>> explicit
>>>     > approach may be more desirable when we are developing our own
>>> protocols
>>>     > or have significant influence and support to change existing
>>> protocols.
>>>     > I guess I am just trying to say we probably want to support both
>>>     > approaches :).
>>>     >
>>>     >
>>>     >
>>>     > Thanks,
>>>     >
>>>     > Danny
>>>     >
>>>     >
>>>     >
>>>     > *From:*sacm [mailto:[e-mail]] *On Behalf Of *Ira
>>> McDonald
>>>     > *Sent:* Friday, May 19, 2017 2:39 PM
>>>     > *To:* Adam Montville <[e-mail]>; Ira McDonald
>>>     > <[e-mail]>
>>>     > *Cc:* Henk Birkholz <[e-mail]>;
>>> [e-mail]
>>>     > *Subject:* Re: [sacm] Hackathon Goals and Stretch Goals
>>>     >
>>>     >
>>>     >
>>>     > 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
>>>     > <[e-mail] <mailto:[e-mail]>>
>>> wrote:
>>>     >
>>>     >     Hi Henk. I'll try inline.
>>>     >
>>>     >     On Tue, May 16, 2017 at 11:04 AM Henk Birkholz
>>>     >     <[e-mail]
>>>     >     <mailto:[e-mail]>> 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:[e-mail]
>>>     >         <mailto:[e-mail]>] *On Behalf Of *Jerome
>>> Athias
>>>     >         > *Sent:* Monday, May 15, 2017 11:12 PM
>>>     >         > *To:* Adam Montville <[e-mail]
>>>     >         <mailto:[e-mail]>>; Waltermire, David A.
>>>     >         > (Fed) <[e-mail]
>>>     >         <mailto:[e-mail]>>; [e-mail]
>>>     >         <mailto:[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]>
>>>     >         > <mailto:[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]>
>>>     >         <mailto:[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]>
>>>     >         >         <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]>
>>>     >         <mailto:[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]>
>>>     >         <mailto:[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]> <mailto:
>>> [e-mail]
>>>     >         <mailto:[e-mail]>>
>>>     >         >     https://www.ietf.org/mailman/listinfo/sacm
>>>     >         >
>>>     >         >
>>>     >         >
>>>     >         > _______________________________________________
>>>     >         > sacm mailing list
>>>     >         > [e-mail] <mailto:[e-mail]>
>>>     >         > https://www.ietf.org/mailman/listinfo/sacm
>>>     >         >
>>>     >
>>>     >         _______________________________________________
>>>     >         sacm mailing list
>>>     >         [e-mail] <mailto:[e-mail]>
>>>     >         https://www.ietf.org/mailman/listinfo/sacm
>>>     >
>>>     >
>>>     >     _______________________________________________
>>>     >     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
>>>
>>>
>>> _______________________________________________
>>> sacm mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/sacm
>>>
>>
>> _______________________________________________
>> sacm mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/sacm
>>
>>
>