Re: [sacm] Hackathon Goals and Stretch Goals

[Adam Montville <[e-mail]>]

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
>