Re: [sacm] Hackathon Goals and Stretch Goals

[Henk Birkholz <[e-mail]>]

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
>