Subject: [sacm] Title for SACM Use Cases Draft

From: Stephen Hanna <[email-masked]>
Date: Thu, 3 Oct 2013 19:42:32 +0000

Dave and Nancy were talking about the title for
the SACM Use Cases document. The old title was:

Analysis of Security Automation and Continuous Monitoring (SACM) Use Cases

The new title is:

Using Security Posture Assessment to Grant Access to Enterprise Network Resources

I prefer the old title. The new title implies
that the only purpose of this work is to
"Grant Access to Enterprise Network Resources".
There are many other purposes such as preparing
reports on endpoint policy compliance, finding
misconfigured endpoints so they can be fixed, etc.

Thanks,

Steve

---

From: <[email-masked]>
Date: Fri, 4 Oct 2013 00:41:47 +0000

I agree with Steve. I like the first one as the new title gives the wrong impression.

Kent Landfield
McAfee Labs
[email-masked]
+1.817.637.8026 

> On Oct 3, 2013, at 1:03 PM, "Stephen Hanna" <[email-masked]> wrote:
> 
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Fri, 4 Oct 2013 17:32:06 +0000

+1

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, October 03, 2013 8:42 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [sacm] Title for SACM Use Cases Draft

Kent Landfield
McAfee Labs

> Dave and Nancy were talking about the title for the SACM Use Cases 
> document. The old title was:
> 
> I prefer the old title. The new title implies that the only purpose of 
> this work is to "Grant Access to Enterprise Network Resources".
> There are many other purposes such as preparing reports on endpoint 
> policy compliance, finding misconfigured endpoints so they can be 
> fixed, etc.
> 
> Thanks,
> 
> Steve
> 
>

---

From: Gunnar Engelbach <[email-masked]>
Date: Fri, 04 Oct 2013 13:41:02 -0400

I'd like to hear from Dave and Nancy on their thinking about this, but I 
suspect the reason for the title change has more to do with the 
recognition that the current use cases document covers much more than 
use cases.

If that was the goal, then given the choice between change the document 
name and break it out into other documents, a title change is fine.

It's just that, as everybody who has responded so far has pointed out, 
SACM isn't focused just on network access.

Dave:  Apologies, but I've barely had time to do more than take a quick 
glance at your changes to the "use cases" document, so I can only give a 
broad opinion right now.

First:  All of the text in the document is good.  I expect on detailed 
examination to find some typos and maybe some quibbles with phrasing, 
but overall the current text is all good.

Second: The restructure of the document is a help

Third:  I'm still not seeing justification for much of the contents of 
the document, especially in the context of the SACM charter.  I've got a 
thought for inserting a new chapter 3 ahead of the current one that 
might help -- hopefully I can make some time by the start of next week 
to flesh that out.

---

From: "Whitlock, Stephen" <[email-masked]>
Date: Fri, 4 Oct 2013 18:07:44 +0000

+1 on keeping them in one document.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Gunnar Engelbach
Sent: Friday, October 04, 2013 10:41 AM
To: Stephen Hanna
Cc: [email-masked]
Subject: Re: [sacm] Title for SACM Use Cases Draft

I'd like to hear from Dave and Nancy on their thinking about this, but I suspect the reason for the title change has more to do with the recognition that the current use cases document covers much more than use cases.

If that was the goal, then given the choice between change the document name and break it out into other documents, a title change is fine.

It's just that, as everybody who has responded so far has pointed out, SACM isn't focused just on network access.

---

From: Adam Montville <[email-masked]>
Date: Fri, 4 Oct 2013 19:33:26 +0000

It would be great to see as much response to use-case-specific discussions as there is to titling and formatting :-)

Unfortunately, as many of you have probably already seen, David Waltermire is essentially out-of-pocket during the USG shutdown, and I'm not sure when he might be popping back up here.

In light of this, it might be good for David Harrington, or someone else, to pick up editing of the Use Case document.  Any thoughts on this?

Adam

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Whitlock, Stephen
> Sent: Friday, October 04, 2013 11:08 AM
> To: Gunnar Engelbach; Stephen Hanna
> Cc: [email-masked]
> suspect the reason for the title change has more to do with the recognition
> that the current use cases document covers much more than use cases.
> 
> examination to find some typos and maybe some quibbles with phrasing, but
> overall the current text is all good.
> 
> Third:  I'm still not seeing justification for much of the contents of the
> document, especially in the context of the SACM charter.  I've got a thought
> for inserting a new chapter 3 ahead of the current one that might help --
> hopefully I can make some time by the start of next week to flesh that out.
> 
> 
> 
> 
> ...

. . .

---

From: "ietfdbh" <[email-masked]>
Date: Fri, 4 Oct 2013 22:21:48 -0400

Hi,

OK with me.
We need some consensus on the content before editing can occur ...
Discussions of use cases would be very helpful.

I'll try to get the latest sources from DM, or work from the latest I have.

David Harrington
[email-masked]
+1-603-828-1401

> Adam Montville
> Sent: Friday, October 04, 2013 3:33 PM
> To: Whitlock, Stephen; Gunnar Engelbach; Stephen Hanna
> Cc: [email-masked]
> It would be great to see as much response to use-case-specific discussions
as
> there is to titling and formatting :-)
> 
> Unfortunately, as many of you have probably already seen, David Waltermire
> is essentially out-of-pocket during the USG shutdown, and I'm not sure
when
> he might be popping back up here.
> 
> In light of this, it might be good for David Harrington, or someone else,
to pick
> up editing of the Use Case document.  Any thoughts on this?
> 
> Adam
> 
> 
> 
> > Gunnar Engelbach
recognition
> > Third:  I'm still not seeing justification for much of the contents of
the

---

From: "ietfdbh" <[email-masked]>
Date: Sat, 5 Oct 2013 07:36:48 -0400

Hi Adam,

Did David ask you to request that others pick up the pen for the use cases
doc?
I will call David to discuss whether he needs me to take the pen, and to get
his latest sources.

-- out of pocket --
People operating in IETF contribute as individuals.
I have been operating out-of-pocket all the time I have been editing for
sacm. Many contribute to IETF out-of-pocket.
The fact that David is operating out-of-pocket during the US govt shutdown
shouldn't really make a difference to his IETF editing capabilities.
I would think that with the US govt shutdown, David might have MORE time to
edit the documents.

-- ietf88 --
I do think the govt shutdown, and David's out-of-pocket situation, could
impact David's attendance at the next meeting.
I know from Tim Polk's experience with a previous shutdown that NIST
employees are bound by a set of rules about what they are allowed to finance
on their own, or to accept as "gifts" to cover IETF meeting expenses.
I do not expect to attend the next meeting; I would have difficulty
justifying the out-of-pocket costs.
Following the recommended IETF approach, we should stimulate ML discussion
and update the document prior to the deadline.
I think David and I (and the chairs) can do that, and David and I can
prepare "status" slides for the meeting, and participate remotely.

-- use cases document --
David has been driving the discussions with the intention of updating the
document.
We changed the structure and content significantly from the -00- revision.
We want WG reaction to the changes, and the next revision will bring the
document closer to WG consensus preferences.
I have been deliberately letting David drive the discussions, track the
needed changes, and edit the next revision.
We have gotten some good feedback on the list.
I have also been tracking the discussions and proposed changes, in case I
needed to pick up the pen.
I have the xml2rfc sources for the -00- revision; I don't know if David has
a more updated, unpublished revision of XML source.

I am of the impression that WG consensus is to remove the functional
capabilities analysis from the use cases doc.
Some of the analysis might be more appropriate for the requirements doc.

David Harrington
[email-masked]
+1-603-828-1401

as
when
to pick
recognition
the

---

From: "ietfdbh" <[email-masked]>
Date: Sat, 5 Oct 2013 08:57:29 -0400

Hi,

I agree with recent comments that SACM deals with more than just access
decisions.
In July, there was discussion of the scope of the work, and particularly the
scope of the use-cases document.
WG consensus was to limit the document to UC1; UC2 and UC3 were removed from
THIS use cases document.
See http://www.ietf.org/mail-archive/web/sacm/current/msg01265.html
WG consensus was also to limit the scope to Enterprises.

The title was changed to reflect that the content was only for "Endpoint
Posture Assessment" related to Enterprise resources.
The old title " Analysis of Security Automation and Continuous Monitoring
(SACM) Use  Cases" is misleading in that it covers far more scope than
enterprise-specific Endpoint Posture Assessment use cases.
So we changed it to:
"Using Security Posture Assessment to Grant Access to Enterprise Network
Resources"

We are using posture from RFC5209:
" Posture - Configuration and/or status of hardware or software on an
      endpoint as it pertains to an organization's security policy."
"Our" posture is specific to security policy; there may be other "posture
assessments" that are not specific to security policy, such as asset
management policies, or regulatory compliance policies, or network
management policies set by departments other than the security policy
department. 
WG consensus seems to be we do not want to talk too much about asset
management (or other scopes of policy-based management) because asset
management is not part of SACM; it is referenced by SACM. SACM scope is
about assessing relative to security policy.

I therefore suggest "Endpoint Security Posture Assessment - Enterprise Use
Cases"

David Harrington
[email-masked]
+1-603-828-1401

> Sent: Friday, October 04, 2013 1:41 PM
> To: Stephen Hanna
> Cc: [email-masked]

---

From: "ietfdbh" <[email-masked]>
Date: Sat, 5 Oct 2013 09:44:15 -0400

Hi Gunnar,

Can you be more specific about what content you do not see as justified
vis-à-vis the charter?
Are you talking about section 4, as others are?

The deadline for publication of a revision is 10-21.
I don't know if I'll have any delay in getting the latest sources from Dave
W.
If you want something inserted into the document, you should send your
proposed addition to the list asap, so we can pick it apart ;-) and try to
reach a consensus on adding it well in advance of deadline.
Can you share a quick strawman before fleshing out the details?

David Harrington
[email-masked]
+1-603-828-1401

---

From: Gunnar Engelbach <[email-masked]>
Date: Sat, 05 Oct 2013 13:36:51 -0400

> Are you talking about section 4, as others are?

I don't have a problem with any of the text in the document.  I suspect 
that it all is stuff that is needed, but that suspicion is born of my 
experience in this area -- somebody else reading these could just as 
easily disagree.  Starting at the charter and working down through the 
documents I'm just not seeing anything that justifies the inclusion of 
anything that is talked about.

Early talks about the structure of the use cases document did a better 
job of that, so my thought was to insert a new section between 2 and 3 
that expands on the two items in the charter describing what this 
working group will define:

"1. A set of standards to enable assessment of endpoint posture. This 
area of focus provides for necessary language and data format 
specifications.
.
.
.
2. A set of standards for interacting with repositories of content 
related to assessment of endpoint posture"

And you're right, suspense is nigh, and I probably won't get a change 
very soon to flesh this out as much as I'd like, so let me put down what 
I can right now while I have a few moments.

3. Usage Examples
   3.1 Endpoint Assessment
   [The current section 3 is a good start on this, but it's worth trying 
to push examples out toward the edge cases, such as the one I sent a 
couple months back -- Steve Hanna mentioned three more good examples]

   3.2 Repository Interaction
     3.2.1 Retrieve materials necessary to perform categorization of an 
asset (such as determine its CPE)
     3.2.2 Retrieve all materials necessary to complete an automated 
assessment to determine the level of compliance of a Windows 7 x64 
desktop machine with HIPAA regulations.
     3.2.2 Retrieve materials necessary to perform evaluation of all 
potential vulnerabilities for iOS identified since some date that can 
yield unauthorized remote access or privilege escalation.
     3.2.3 Retrieve human audience non-automated content associated with 
HIPAA compliance (such as the current HIPAA regulation, security 
training videos, etc).
     3.2.4 Register with repository for immediate notification of new 
security vulnerability content that match a selection filter (Filter 
terms could include OSs, applications, severity rating, automated 
check/vulnerability announcement, original content source, content 
author rating, etc)

Each of the examples given in section 3 can then include a summary of 
needs which then drive requirements.  But as you pointed out that will 
likely have a lot of duplication.  So, either:

1) Each section only lists those needs not already identified
2) The needs are listed in section 4 with a reference back to which 
example or architectural detail justifies its existence.

The drawback, of course, is that we can't possibly think of everything 
right now, but I still feel a lot more comfortable that we are focused 
correctly and headed toward a feasible real-world solution if we make an 
effort to do so.  These examples don't need to be long, involved, and 
detailed, but they do need to cover as broad a scope as fits within the 
charter and be detailed enough that an experienced person can infer 
needs from.  This also gives us a potential opportunity to see if any of 
these needs are divergent or mutually exclusive and therefore have an 
opportunity to annotate scenarios that we don't expect SACM to be able 
to address.

---

From: Adam Montville <[email-masked]>
Date: Mon, 7 Oct 2013 15:52:47 +0000

> From: ietfdbh [mailto:[email-masked]]
> Sent: Saturday, October 05, 2013 4:37 AM
> To: Adam Montville; [email-masked]; Waltermire, David A.
> Cc: [email-masked]
> Subject: RE: [sacm] Title for SACM Use Cases Draft
> 
> Hi Adam,
> 
[AWM] 
No, but I've been unable to reach him.  It seems that the contact information I have for David is NIST-related.  In an effort to keep things moving forward, I made the suggestion.

> I would think that with the US govt shutdown, David might have MORE time
> to edit the documents.
[AWM] 
I agree.  However, I also recognize that most people I know in the IETF would not be participating were it not for the funding of their employer.  I believe Dave is in this situation in terms of attendance, which you address below.

> employees are bound by a set of rules about what they are allowed to
> finance on their own, or to accept as "gifts" to cover IETF meeting expenses.
> I do not expect to attend the next meeting; I would have difficulty justifying
> the out-of-pocket costs.
> Following the recommended IETF approach, we should stimulate ML
> discussion and update the document prior to the deadline.
> I think David and I (and the chairs) can do that, and David and I can prepare
> "status" slides for the meeting, and participate remotely.
[AWM] 
This sounds reasonable.

> I have been deliberately letting David drive the discussions, track the needed
> changes, and edit the next revision.
> I have the xml2rfc sources for the -00- revision; I don't know if David has a
> more updated, unpublished revision of XML source.
[AWM] 
I have no idea about updated sources.

> > From: [email-masked] [mailto:[email-masked]] On Behalf
> > Of Adam Montville
> > Unfortunately, as many of you have probably already seen, David
> > Waltermire is essentially out-of-pocket during the USG shutdown, and
> > I'm not sure
> when
> > > From: [email-masked] [mailto:[email-masked]] On
> Behalf
> > Of
> > > Whitlock, Stephen
> > > From: [email-masked] [mailto:[email-masked]] On
> Behalf
> > Of
> > > Gunnar Engelbach
> > > I'd like to hear from Dave and Nancy on their thinking about this,
> > > but I suspect the reason for the title change has more to do with
> > > the
> recognition
> > > If that was the goal, then given the choice between change the
> > > document name and break it out into other documents, a title change is
> fine.
> > >
> > > Dave:  Apologies, but I've barely had time to do more than take a
> > > quick glance at your changes to the "use cases" document, so I can
> > > only give a broad opinion right now.
> > >
> > > First:  All of the text in the document is good.  I expect on
> > > detailed examination to find some typos and maybe some quibbles with
> > > phrasing,
> > but
> > > for inserting a new chapter 3 ahead of the current one that might
> > > help
> --
> > > hopefully I can make some time by the start of next week to flesh
> > > that
> out.
> > >
> > >
> > >
> > >
> > > > I prefer the old title. The new title implies that the only
> > > > purpose of this work is to "Grant Access to Enterprise Network
> Resources".
> > > > There are many other purposes such as preparing reports on
> > > > endpoint policy compliance, finding misconfigured endpoints so
> > > > they can be fixed, etc.
> > > >
> > > > Thanks,
> > > >
> > > > Steve
> > > >
> > > >

. . .