Re: [sacm] Hackathon Goals and Stretch Goals

[Jessica Fitzgerald-McKay <[e-mail]>]

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