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

From: "Haynes, Dan" <[email-masked]>
Date: Tue, 3 May 2016 13:24:21 +0000

Yeah, I only count four :) (although some are multi-part).  More below.

Thanks,

Danny

From: Adam Montville [mailto:[email-masked]]
Sent: Thursday, April 28, 2016 7:40 PM
To: Haynes, Dan <[email-masked]>
Cc: [email-masked]
Subject: Re: [sacm] FOR REVIEW: IM Merge - Abstract and Introduction

A few? ;-)

Right back at you.

On Apr 26, 2016, at 3:21 PM, Haynes, Dan <[email-masked]<mailto:[email-masked]>> wrote:

Hi Adam,

A few comments inline below.

Thanks,

Danny

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

On Apr 8, 2016, at 1:53 PM, Haynes, Dan <[email-masked]<mailto:[email-masked]>> 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.

This sounds like agreement, but I want to point out that the text I proposed was really intended to be a straw man.  If you want to stick with the text I’ve proposed I would not object, though others might.

[danny]: Yeah, I agree with you.  What do others think about this?

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 :).

No I do not.  I was trying to understand the reasoning behind the change.

[danny]: Thanks for the clarification.  In that case, we will keep the proposal as-is (i.e. removes the “problem statement”, “referring to an endpoint”, and “dealing with uncertainty” sections).

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.

This isn’t something I’m too hung up on, so if it makes sense to everyone else, that’s fine.  And see next comment.

[danny]: Ok, thanks for the clarification.  Does this make sense to everyone else?

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”?

I can see this perspective.  If I’m using the information model to organize characterization information and I’m just viewing that information, would it still be a “target” endpoint?  I suppose it’s the one I’m interested in, but I’m not sure it’s quite the same as “target” as used in the vulnerability assessment workflow.  Still, I’m not hung up on this, as long as we believe it’s clear to readers/implementers, etc.

[danny]: What do others think about this?  Do we want to leave it as-is?  Or, do we see a distinction between the two.  If we do see a distinction here, we may want to consider revising the definition of “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

---

From: "Haynes, Dan" <[email-masked]>
Date: Tue, 10 May 2016 10:00:53 +0000

Did others have thoughts on this thread?  I would like to get this one resolved by the end of the week.

Thanks,

Danny

From: sacm [mailto:[email-masked]] On Behalf Of Haynes, Dan
Sent: Tuesday, May 03, 2016 9:24 AM
To: Adam Montville <[email-masked]>
Cc: [email-masked]
Subject: Re: [sacm] FOR REVIEW: IM Merge - Abstract and Introduction

Thanks,

Danny

A few? ;-)

Right back at you.

Hi Adam,

Thanks,

Danny

As contributor.

Kind regards,

Adam

---

From: "Haynes, Dan" <[email-masked]>
Date: Fri, 13 May 2016 14:11:58 +0000

Since I haven’t heard any feedback on this, I plan to make the following changes as outlined below.

·         Update introduction per Adam’s comment to make it clear that there is an expectation that data-at-rest does not violate the relationships of information as defined in the IM.

·         Keep introduction proposal as-is (i.e. removes the “problem statement”, “referring to an endpoint”, and “dealing with uncertainty” sections).

·         Keep the “target” qualifier in front of things like “target endpoint discovery”, “target endpoint characterization”, etc.

·         Leave use of “target endpoint“ as-is for now.  If we want to re-consider this we can, but, I think we will have to think about the definition in the terminology document.

Thanks,

Danny

From: Haynes, Dan
Sent: Tuesday, May 10, 2016 6:01 AM
To: Haynes, Dan <[email-masked]>; Adam Montville <[email-masked]>
Cc: [email-masked]
Subject: RE: [sacm] FOR REVIEW: IM Merge - Abstract and Introduction

Thanks,

Danny

To: Adam Montville <[email-masked]<mailto:[email-masked]>>

Thanks,

Danny

A few? ;-)

Right back at you.

Hi Adam,

Thanks,

Danny

As contributor.

Kind regards,

Adam