Re: [sacm] FOR REVIEW: IM Merge - Abstract and Introduction

["Haynes, Dan" <[e-mail]>]

Hi Adam,

A few comments inline below.

Thanks,

Danny

From: Adam Montville [mailto:[e-mail]]
Sent: Friday, April 08, 2016 5:58 PM
To: Haynes, Dan <[e-mail]>
Cc: [e-mail]
Subject: Re: [sacm] FOR REVIEW: IM Merge - Abstract and Introduction


On Apr 8, 2016, at 1:53 PM, Haynes, Dan <[e-mail]<mailto:[e-mail]>> wrote:

With that said, can the “Abstract” and “1. Introduction” of [3] replace the “Abstract” and “1. Introduction” of WG IM [2]?

As contributor.

I think the abstract replacement is sane.  Some clarification on why we care only about data in motion and not as much about data at rest might be required.  I’m fine with focusing on data in motion, provided the expectation that any data at rest does not violate the relationships between information as established by the information model.  This might be handled well by slightly altering the last sentence in the first paragraph of the introduction to something like: “It is expected that information elements, and the relationships between them, expressed in this document are retained when fit into data models for data at rest.”  (Or something like that.)

[danny]: I see. I think  the main point with respect to data in motion vs. data at rest is that we primarily care about getting information from one SACM Component to another.  How it is stored in a Repository could be left for an implementer to decide.  With that said, you are right.  Things like relationships need to be retained somehow or at least re-constructible in the event that data including relationships must be provided in response to a query to the Repository.  Do you think it is worth calling out that the relationships can either be preserved directly in the data model or in some other way that allows them to be reconstructed at a later time (which may provide more flexibility)?  If both of these are covered by “retained” or this flexibility is not needed, I am fine with just using what you have proposed.

The changes in the introduction seem significant, and I like the brevity of the proposed replacement.  It appears that you’ve dropped the “Problem Statement”, “Referring to An Endpoint”, and “Dealing with Uncertainty” subsections of the introduction.  Was this done because these topics are treated elsewhere?

[danny]: When merging the text from the IMs, we were focused on making the WG IM as clear and concise as possible.  That is, what is the minimal text necessary to: (1) allow readers to understand what types of information we are trying to model, (2) what structures are available to model this information, and (3) the actual information elements that we think are necessary for SACM.  As a result, if the text didn’t seem critical to reaching this objective, we did not include it in the merged text.  Do you feel that this text is absolutely critical to include in the WG IM?  The main driver behind this is that the current WG IM is already very long :).

It seems that you’ve also become more specific when talking about the tasks supported by the information model.  The current introduction speaks to things like “endpoint characterization” and the proposed introduction speaks to things like “target endpoint characterization”.  Was the qualifying word “target” chosen for a particular reason?

[danny]: We added the “target” qualifier because it was more specific to the tasks being supported by the IM and better aligned with the terminology document.

I ask, because in my mind “target endpoints” are the subject of an assessment process, but we need to deal with endpoints outside of such processes.  Configuration assessment or vulnerability assessment will have “target endpoints” to examine, but an endpoint management capability doesn’t really have “target endpoints”, because it is concerned with all endpoints (use of the qualifier “target” implies a subset of the whole).

[danny]: Using the current definition of “target endpoint", wouldn’t an endpoint under the “endpoint management capability” be considered an “endpoint of interest” and as a result a “target endpoint”?
My recommended change to the proposed introduction is to change “target endpoint” to “endpoint”.

Again, all of these comments are made with my contributor hat on.

Kind regards,

Adam