Re: [sacm] Hackathon Goals and Stretch Goals

Jerome Athias <jerome.athias@protonmail.com> Tue, 23 May 2017 09:12 UTC

Return-Path: <jerome.athias@protonmail.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 3B7A412954D for <sacm@ietfa.amsl.com>; Tue, 23 May 2017 02:12:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.679
X-Spam-Level:
X-Spam-Status: No, score=-1.679 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, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=protonmail.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 mEa4wDFdXkLs for <sacm@ietfa.amsl.com>; Tue, 23 May 2017 02:12:32 -0700 (PDT)
Received: from mail2.protonmail.ch (mail2.protonmail.ch [185.70.40.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CD1C128D19 for <sacm@ietf.org>; Tue, 23 May 2017 02:12:31 -0700 (PDT)
Date: Tue, 23 May 2017 05:12:21 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1495530745; bh=YDwhsQCsHRQMsbfpTTF2qBjpt0o2UBCPkY8MTXlrs5M=; h=From:Cc:Reply-To:Subject:In-Reply-To:References:Feedback-ID:From; b=sxTohA9GP8FO2vHj8XSrBd3GkrSzO3p4KPM3axxPPaa37pzN8M1BffY2kWkOZxTjE DpspK4TtiLJmfGhMiOoIH3R7JX5Mb53moiOc23zHywZha/omP4JgaycY+5LXFcmLuR OQhIocxrZf6a2QprVxBVa1jVqbGW1nBylit6fWx0=
From: Jerome Athias <jerome.athias@protonmail.com>
Cc: "sacm@ietf.org" <sacm@ietf.org>
Reply-To: Jerome Athias <jerome.athias@protonmail.com>
Message-ID: <4l5d7I5AeUdBxiFcsusXjs5jItThZ8Gm23gU5afNFXpBUanJDttOlsMZZmlkgr-RejCyv5NFV6aupyFjf9I5hQrua81dHD20ecLFC-DaCBo=@protonmail.com>
In-Reply-To: <653be99c-7502-210d-ccd1-5dc5811b8cee@sit.fraunhofer.de>
References: <CACknUNUhqqdumk1wombsAha0TQS4O4dNpajUs2Ak4jWDWZHXaA@mail.gmail.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> <CAN40gStPGRW7P6m2m7QrO8awCuksjyQoga4QCD3BzFqa_GN26Q@mail.gmail.com> <DM5PR09MB1354F148919DE47F23F3F087A5F80@DM5PR09MB1354.namprd09.prod.outlook.com> <653be99c-7502-210d-ccd1-5dc5811b8cee@sit.fraunhofer.de>
Feedback-ID: 0pNaUpQyJcJ_FqKgvRh59kNH9tw1YU9Hb7-41TF1UFya4DA0ft6-ejYSrPjLLQWz-KcGUoHsZH8z6Hzy-ZW3EA==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="b1_7ad93ae64d6fc1d2445c5c83444ad8ff"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sacm/_4-pZ5WB92IxxFPbISSAIpbV1Wc>
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: Tue, 23 May 2017 09:12:36 -0000

So trying to add my 2c, under a PoC context

A) I do agree with Dan that Mappings would be needed (e.g. between the IEs and some XSD schemas, or interexchange format specifications, e.g. ARF, OVAL,... (XORCISM)) and so APIs or glue code can do the trick.
I agree that an SQL database can be used (it could be a central repository. One big unique database schema would be unwanted, however, it could be split (a la CAESARS Framework) (you would use UUIDs/GUIDs anyway) and orchestrated (a la IACD). This without the immediate need of an interexchange format.
Later on, when minimum required information element will be identified between 2 components, the format could be defined and optimized.
(a la IVIL: Intermediate Vulnerability Information Language)
This, when using an SQL base (so then the tables/objects with columns/attributes and relationships are defined), is really "just" a conversion of objects representation...
(It's not an approach as elegant as a purely defined Ontology but it makes it work while being interoperable)
(Note here that for near future adoption promotion of SWID, one should maybe jump into the OASIS CSAF new CVRF committee...)

B) Regarding code,
I am interested by the previous contribution offers.
I could contribute with some -components plugins- (methods?) and pointers to some other code/tools.
(Note that I'll try to update my XORCISM repo during the week-end)
Focusing mainly on Windows-based endpoints (because when it's too easy it's not fun):
I could provide:

1) VDI2VDD
PoC code that converts Microsoft Security Updates Information (VDI) into VDD (OVAL Definitions)
- This is currently work in progress, but ok for PoC
- This demonstrates (re)use of a VDD Repository information
(while this could be directly the CIS OVAL Repository [0], here i'm using 2))
- New insertion into 2) could Trigger*:
. ROLIE SDE use, Assessment
(out-of-scope note: here STIX v1 can be used for an OpenC2 COA (STIX v2 currently too limited) OR IODEF/MILE for sci;Vulnerability with NodeRole 26. assessment, etc. ...)

2) VDD Repository
- In the form of a "Data Model" as an SQL schema
https://github.com/athiasjerome/XORCISM/tree/master/MODELS/XOVAL

- PoC code that converts the CIS (XML) OVAL Repository information [0] into XOVAL (SQL) information
https://github.com/athiasjerome/XORCISM/blob/master/SOURCES/Import_oval/Program.cs

3) VDI Collection plugin/method
- PoC code that converts&imports NVD CVD database (XML) into a (SQL) VDI Repository 4)
https://github.com/athiasjerome/XORCISM/blob/master/SOURCES/Import_all/Program.cs
- Note: New insertion into 3) could Trigger* (with use of 6))

4) VDI Repository
https://github.com/athiasjerome/XORCISM/tree/master/MODELS/XVULNERABILITY

5) Endpoint Information Collection plugin/method
- PoC code that uses external tools for collecting Endpoints information
https://github.com/athiasjerome/XORCISM/blob/master/SOURCES/XProviderNmap/Engine.cs
- OVAL Community Tools (using OVAL Inventory Definitions) should be used, e.g. OVALdi
- One interesting simple candidate tool to use for Windows could be https://github.com/nccgroup/WMIcmd
- Other candidates for Collectors ... (API/glue with tools like BMC Remedy, or simple tools already listed by Adam, https://sourceforge.net/projects/teemip/ etc.)

6) Endpoint Information Repository
- SQL schema (small part of https://github.com/athiasjerome/XORCISM/tree/master/MODELS/XORCISMModel )
e.g. ARF schema

7) Assessment Results Repository
- SQL schema (small part of https://github.com/athiasjerome/XORCISM/tree/master/MODELS/XORCISMModel )

8) Vulnerability Assessors
- PoC code that uses external tools for collecting Assessment Results
https://github.com/athiasjerome/XORCISM/tree/master/SOURCES/XProviderNeXpose
https://github.com/athiasjerome/XORCISM/tree/master/SOURCES/XProviderQualys
...
It is important to note that Vulnerability Assessors will collect information useful to update the 6) Endpoint Repository information (e.g. new unknown endpoints, updated information (even if just update of the timestamps), etc.)

Then of course, because we want that automated and continuous, on top of that, an 'Orchestrator' with tasks/jobs scheduler, workflow (playbook) manager and profile manager would be needed.
https://github.com/athiasjerome/XORCISM/blob/master/SOURCES/XManagerService/Engine.cs

[0] https://oval.cisecurity.org

-------- Original Message --------
Subject: Re: [sacm] Hackathon Goals and Stretch Goals
Local Time: May 22, 2017 7:48 PM
UTC Time: May 22, 2017 4:48 PM
From: henk.birkholz@sit.fraunhofer.de
To: sacm@ietf.org

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:sacm-bounces@ietf.org] *On Behalf Of *Ira McDonald
> *Sent:* Friday, May 19, 2017 2:39 PM
> *To:* Adam Montville <adam.w.montville@gmail.com>; Ira McDonald
> <blueroofmusic@gmail.com>
> *Cc:* Henk Birkholz <henk.birkholz@sit.fraunhofer.de>; sacm@ietf.org
> *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
> <adam.w.montville@gmail.com <mailto: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
> <mailto: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
> <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
> <mailto:adam.w.montville@gmail.com>>; Waltermire, David A.
> > (Fed) <david.waltermire@nist.gov
> <mailto:david.waltermire@nist.gov>>; sacm@ietf.org
> <mailto: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>
> > <mailto: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>
> <mailto: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>
> > <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>
> <mailto: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>
> <mailto: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> <mailto:sacm@ietf.org
> <mailto:sacm@ietf.org>>
> > https://www.ietf.org/mailman/listinfo/sacm
> >
> >
> >
> > _______________________________________________
> > sacm mailing list
> > sacm@ietf.org <mailto:sacm@ietf.org>
> > https://www.ietf.org/mailman/listinfo/sacm
> >
>
> _______________________________________________
> sacm mailing list
> sacm@ietf.org <mailto:sacm@ietf.org>
> https://www.ietf.org/mailman/listinfo/sacm
>
>
> _______________________________________________
> 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