Subject: [sacm] [sacmwg/draft-ietf-sacm-information-model] discuss IM/DM related questions (#68)

From: Danny Haynes <[email-masked]>
Date: Tue, 01 Nov 2016 09:33:57 -0700

There are many existing collection mechanisms and data models.  Does SACM need new data models? Or, does SACM just need to describe how an implementer can leverage these existing data models? Furthermore, does SACM need a single unifying data model or just a framework for communicating information expressed in any available data model?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/68

---

From: David Waltermire <[email-masked]>
Date: Tue, 01 Nov 2016 09:51:19 -0700

This is something that we should explore more. The alternative is to essentially remodel all of the existing data models. IMHO, remodeling the world of posture modelling is a non-starter. We will be at this forever, we will always be chasing what has been modeled within management protocols (e.g., MIB, Yang, etc), and we will likely end up with something that won’t get implemented in software products. In short, a remodeling approach does not scale.

Instead, we may be able to focus on characterizing the key subjects (e.g., endpoints, software, hardware, configuration settings) in a standardized way to provide a framework for expressing the subject of data provided by another model. This allows a consumer to query for this data in the same way, and determine if a piece of posture information is interesting or not. Understanding the payload is a different matter. We may want to think about a transcoding approach that would allow conversion of data between two different, but similar data models. This would allow a consumer to get the information it needs in a form it understands.

Thoughts?

Dave

From: Danny Haynes [mailto:[email-masked]]
Sent: Tuesday, November 01, 2016 12:34 PM
To: sacmwg/draft-ietf-sacm-information-model <[email-masked]>
Subject: [sacmwg/draft-ietf-sacm-information-model] discuss IM/DM related questions (#68)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub<https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/68>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AJaiaJqPreFxD9UOFzkQMROW_gumfBx1ks5q52n1gaJpZM4KmStl>.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/68#issuecomment-257621209

---

From: adammontville <[email-masked]>
Date: Wed, 02 Nov 2016 05:55:48 -0700

I hope that we find few, if any, who want to reinvent data models where they already exist.  A framework for relating data model elements to SACM Information Model elements seems warranted.  I like the idea of narrowing focus to what we need right now, although "configuration" is a huge domain (we can narrow that field as well).

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/68#issuecomment-257856208

---

From: Danny Haynes <[email-masked]>
Date: Thu, 03 Nov 2016 09:58:04 -0700

Yeah, I like the idea of pulling in existing data models.  Some that come to mind are: CIM (PowerShell, WMI, or SBLIM), YANG (via NETCONF), MIB (via SNMP), SCAP/OVAL/SWID (via NEA), and Apple Configuration Profiles (via Apple MDM Protocol).  Are there others that we might want to consider?

I think having a structure which can leverage these protocols and data models within SACM would be a great first step.  Once that is in place, I think the next step would be to focus on unifying the end user experience such that they have a common way to interact with all the different data models and protocols supported by SACM.  That is, the end users wouldn't necessarily need to know what protocols and data models are in use.  They would just say I want to assess X, Y, or Z and SACM would do it using whatever protocols and data models are available.  I believe this is where the mapping comes into play.  Anyways, it sounds like all the responses so far are fairly aligned with one another.  

Do others have thoughts on this?

Also, is this something we would like to discuss at IETF 97?  Or, should we just keep working this on the list for now?

Thanks,

Danny 

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/68#issuecomment-258204939

---

From: "Wolfkiel, Joseph L CIV DISA ID (US)" <[email-masked]>
Date: Thu, 3 Nov 2016 17:46:57 +0000

When we built the "device" model for the Network Defense data models, we did crosswalks between CIM, OVAL SC, and several vendor and government database schemas.  The crosswalks were helpful, but the debates on what data elements and relationships to keep or prune were probably even more helpful since they made us come to a common understanding of what data we needed and how we thought we would use it.

Joseph L. Wolfkiel
SCM Engineering Lead
DISA ID52
Fort Meade DISA Acquisiton Bldg Cube A4A58E
Work: (301) 225-8820
Gov Cell: (571) 814-8231
[email-masked]

-----Original Message-----
From: sacm [mailto:[email-masked]] On Behalf Of Danny Haynes
Sent: Thursday, November 03, 2016 12:58 PM
To: sacmwg/draft-ietf-sacm-information-model
Cc: Comment; sacm
Subject: [Non-DoD Source] Re: [sacm] [sacmwg/draft-ietf-sacm-information-model] discuss IM/DM related questions (#68)

All active links contained in this email were disabled. Please verify the identity of the sender, and confirm the authenticity of all links contained within the message prior to copying and pasting the address to a Web browser. 

________________________________

Thanks,

Danny 

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub < Caution-https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/68#issuecomment-258204939 > , or mute the thread < Caution-https://github.com/notifications/unsubscribe-auth/AKbE0S8r8YfjDIdiJIqBjmwfTFFlO_v1ks5q6hKcgaJpZM4KmStl > . <Caution-https://github.com/notifications/beacon/AKbE0Xs821h7SnaIB3IvBxhUos5RdkFuks5q6hKcgaJpZM4KmStl.gif>