discuss IM/DM related questions #68
Comments
|
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:notifications@github.com] 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? — |
|
“Does SACM need new data models? Or, does SACM just need to describe how an implementer can leverage these existing data models?” From these two questions it seems to me that the best course of action is option 2, there exists such a wealth of data models that it would be a waste of resources to try to recreate that work. If at some point we stumble across some niche information that doesn’t have an adequate expression, then we could look into extension or creating of a data model. “Does SACM need a single unifying data model or just a framework for communicating information expressed in any available data model?” I again personally think that the second option is optimal. If we can construct the web that ties together all of these data models, we’ll end up doing less work and creating something that people will be more likely to use. The more modular and extensible the SACM solution is the longer it’ll provide value. I think that my view on these questions puts me in-line with Dave’s transcoding approach. We need a way of wrapping or describing information such that we are not responsible for creating the data model itself, but only identifying it. The terms “enveloping” and “translation” have been tossed around, we should look into that direction. Stephen From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of David Waltermire 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:notifications@github.com] 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? — — |
|
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). |
|
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 |
|
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 -----Original Message----- 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. 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 — |
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?
The text was updated successfully, but these errors were encountered: