Subject: [sacm] Berlin Meeting

From: Adam Montville <[email-masked]>
Date: Wed, 3 Jul 2013 16:51:54 +0000

All:

While we are not yet an official WG, I'd like to try to get our ducks in a row and progress as though we are a WG.  I see some important dates have passed, and that some are upcoming (http://www.ietf.org/meeting/cutoff-dates-2013.html#IETF87).

Notably:

* 2013-07-05 (this Friday): Final agenda published
* 2013-07-15: Internet Draft submission cut-off (for all drafts, including -00)
* 2013-07-17: Draft WG agendas due by UTC 24:00

Given the milestones listed in our charter, it seems that our agenda should contain a healthy dose of use case an discussion and possibly some requirements discussion.

Proposed (loose) Agenda:

* Note well + agenda bashing
* Charter and Milestone Review
* Use Case Discussion
    * Review of list
    * Presentation on latest draft (if update submitted)
* Requirements discussion (time permitting)
* Administravia (new-WG-related stuff)

Are there relevant drafts that we want to discuss in Berlin and can be submitted before the 15 July deadline?  At present, the following "related documents" show up on our Documents page (http://datatracker.ietf.org/wg/sacm/):

* draft-booth-sacm-vuln-model-02
* draft-waltermire-sacm-architecture-00
* draft-waltermire-sacm-use-cases-04

I'm looking forward to seeing you in Berlin!

Regards,

Adam

This message and attachments may contain confidential information.  If it appears that this message was sent to you by mistake, any retention, dissemination, distribution or copying of this message and attachments is strictly prohibited.  Please notify the sender immediately and permanently delete the message and any attachments.

---

From: Sean Turner <[email-masked]>
Date: Wed, 03 Jul 2013 23:53:54 -0400

On 7/3/13 12:51 PM, Adam Montville wrote:
> All:
>
> While we are not yet an official WG, I'd like to try to get our ducks in
> a row and progress as though we are a WG.  I see some important dates
> have passed, and that some are upcoming
> (http://www.ietf.org/meeting/cutoff-dates-2013.html#IETF87).
>
> Notably:
>
> Given the milestones listed in our charter, it seems that our agenda
> should contain a healthy dose of use case an discussion and possibly
> some requirements discussion.
>
> Proposed (loose) Agenda:
>

If it's chartered, then we can skip the charter review - it won't be up 
for discussion because it'll be approved ;)

Normally, I'd suggest that sessions avoid summaries of the existing 
drafts.  Participants (used this word on purpose) should read the drafts 
*before* they come to the session.  I'd actually like presenters to ask 
before they start who has read their draft ;)

But, being that this would be the first ever session it's probably okay 
to present what's in them.  In the future, though we can push the work 
forward and get to the point by only talking about open issues.

> Are there relevant drafts that we want to discuss in Berlin and can be
> submitted before the 15 July deadline?  At present, the following
> "related documents" show up on our Documents page
> (http://datatracker.ietf.org/wg/sacm/):
>

Ideally, all of these drafts would be updated before the meeting (hint) ;)

> This message and attachments may contain confidential information. If it
> appears that this message was sent to you by mistake, any retention,
> dissemination, distribution or copying of this message and attachments
> is strictly prohibited. Please notify the sender immediately and
> permanently delete the message and any attachments.
>
>
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm
>

---

From: Adam Montville <[email-masked]>
Date: Fri, 5 Jul 2013 19:43:45 +0000

NOTE: Please ignore the confidentiality notice at the bottom of this e-mail (and others) - it is added after I hit "send" and will be removed for IETF correspondence sometime in the next week or two.

> -----Original Message-----
> From: Sean Turner [mailto:[email-masked]]
> Sent: Wednesday, July 03, 2013 8:53 PM
> To: Adam Montville
> Cc: [email-masked]
> Subject: Re: [sacm] Berlin Meeting
> 
> > While we are not yet an official WG, I'd like to try to get our ducks
> > in a row and progress as though we are a WG.  I see some important
> > dates have passed, and that some are upcoming
> If it's chartered, then we can skip the charter review - it won't be up for
> discussion because it'll be approved ;)

Fair enough.  Consider the two stricken from the proposed agenda.

> 
> Normally, I'd suggest that sessions avoid summaries of the existing drafts.
> Participants (used this word on purpose) should read the drafts
> *before* they come to the session.  I'd actually like presenters to ask before
> they start who has read their draft ;)
> 
> But, being that this would be the first ever session it's probably okay to
> present what's in them.  In the future, though we can push the work forward
> and get to the point by only talking about open issues.

I would encourage everyone to read ahead even for this first session and would anticipate review of these to be minimal and only for those who may not otherwise have heard about SACM work before Berlin.

> Ideally, all of these drafts would be updated before the meeting (hint) ;)

I am unsure as to the state of the vulnerability model and the architecture document.  I know that David Harrington has been working on trimming up the use case document.

On that note, he has asked on several occasions for some more concrete use case examples, but I haven't really seen many provided.  It would be good for this community to throw a few out there.  Remember that use cases don't need to be comprehensive with respect to the requirements.  They should exemplify.

If there are use cases treated elsewhere, but to which access is limited (i.e. other organizations have published similar use cases but the documents aren't free), then I suggest that we summarize them here without simply referencing that work.

> > This message and attachments may contain confidential information. If
> > it appears that this message was sent to you by mistake, any
> > retention, dissemination, distribution or copying of this message and
> > attachments is strictly prohibited. Please notify the sender
> > immediately and permanently delete the message and any attachments.
> >
> >
> ...

---

From: Stephen Hanna <[email-masked]>
Date: Fri, 5 Jul 2013 20:39:53 +0000

I have a few comments and questions on the SACM Use Cases
document. Since Adam has encouraged us to discuss it and
offer our thoughts, I'll do so now.

First, I recall that we previously agreed to focus our
work on UC1 only for now. Our current draft charter
seems to reflect that agreement, which is good! So I
suggest that UC2 and UC3 be removed from the use case
document before it becomes a Working Group document.

Second, I often find it's helpful to have specific
examples in use cases to make them concrete. After all,
people want to solve specific problems with our systems.
And this can keep us grounded.

For example, we could add an example for UC1 that
says:

In order to meet compliance requirements and ensure that
corporate finance information is not revealed improperly,
all computers in the finance department of Example
Corporation are required to run only software contained
on an approved list and to be configured to download and
install software patches every night. Each computer is
checked to make sure it complies with this policy whenever
it connects to the network and at least once a day
thereafter. As part of this daily compliance check,
the SACM protocols are used to assess the posture of
each computer and report on its compliance with policy.
Handling of non-compliant endpoints is not part of
the SACM architecture.

What do people think? Do you like having such examples?
If so, I can write a few more such as one where
suspicious endpoint behavior (like contacting a known
command and control server) triggers a compliance check.
Or one dealing with user-owned (BYOD) devices. These
examples may translate into sub-cases of UC1 or we
may decide to break out UC1 into several use cases.
Other examples could include pulling up a report to
see which endpoints have a particular version of
software that has just been discovered to have a
particular vulnerability. Or which endpoints have
*ever* had that software, since the vulnerability
might have been exploited before we learned of it.

I'm glad we're getting a bit more specific here.
That seems appropriate for a use case document!

BTW, I see that the charter calls for the use cases
to go into the Architecture document. OK by me! But
let's start with use cases before we spend too much
time talking about architecture. Best to fully
understand the problem before we design the solution!

And yes, I know that may of us probably think we have
a clear idea of the problem already. The issue is
that until we've written down the problem description
in excruciating detail with examples and agreed upon
it, we probably all have different understandings of
exactly what the problem is. That's normal.

Thanks,

Steve

---

From: "ietfdbh" <[email-masked]>
Date: Fri, 5 Jul 2013 19:16:30 -0400

>  I know that David Harrington has been working on trimming up
> the use case document.
> 
> On that note, he has asked on several occasions for some more concrete use
> case examples, but I haven't really seen many provided.  It would be good
> for this community to throw a few out there.  Remember that use cases
> don't need to be comprehensive with respect to the requirements.  They
> should exemplify.

Remember that the IETF mantra is "rough consensus and running code" - the
IETF focuses on a bottom-up approach; we like to look at what has been
implemented in products or open source, etc. and try to reach consensus on
the good common functionality across multiple  examples of existing "running
code".
What we have so far seems be a lot of 50,000 foot abstractions and promises
of what the industry will be able to do with what we produce.
It reminds me of vaporware marketing ...

It would be really good to get some examples of "running code" as use cases.
For example, "we ship an application that controls user access to the
network, and we use the IETF NEA protocol to gather data, using this
information model, and this method of assessment. Implementer feedback has
shown these aspects of the specification to be problematic in certain
environments for these reasons;  customer feedback on deployment of this
approach has been successful in these environments, but less successful in
these other environments because ...."

Or "we have running code for an IPS implementation, in shipping product, and
here is text that describes the information model and method of assessing
abnormal user behavior,  and this method for establishing policy about
acceptable variation from normal, and have found that it works well." (UC3)

Or, "we have running code in an open source library for continuously
monitoring router security configuration. We find that the standards are
inadequate in expressing information for this aspect of router
configuration, and we had to supplement the standards with our own
proprietary data model to add this functionality to our monitoring."

We have gotten a number of pointers to work done elsewhere, but it is
usually to other standards organizations' specifications. 
Well, if other SDOs have already written specifications in this space, then
why do we need to do anything in the IETF? The IETF doesn't do
rubber-stamping of other organizations' specifications.
It would be good to get internet-drafts that describes the specifications of
other fora that have addressed these issues, and - most importantly - the
field experience of implementations/deployments of those other approaches.
So if you think we should consider a DMTF information model, or 3GPP
information model, or NIST/MITRE information model, then it really should be
submitted to the IETF, in an Internet-draft, under IETF IPR rules, and
giving change control to the IETF, so we can consider the proposal as input
to an IETF design.
If you think we should consider such specifications because you have
implemented or deployed them and think they work well, then write an ID that
discusses your implementation/deployment experience with those other
specifications.

> 
> If there are use cases treated elsewhere, but to which access is limited
(i.e.
> other organizations have published similar use cases but the documents
> aren't free), then I suggest that we summarize them here without simply
> referencing that work.
> 

And, as always, we welcome text that you propose we add to the use-cases
document (or other documents).

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

---

From: Stephen Hanna <[email-masked]>
Date: Sat, 6 Jul 2013 00:29:42 +0000

> It would be really good to get some examples of "running

OK, Dave. I'll bite and send some info on running code that
uses open standards for endpoint assessment. I expect that
others will also, after they return from their holiday weekend.

Dozens of products (open source and commercial) and
thousands of customers (millions of users) have done
endpoint assessment using the TNC/NEA standards.
Customers typically use these standards to solve
problems like the ones described in RFC 5209 (the
NEA Requirements spec). Those problems are very
similar to the ones described for SACM but we seem
to be adding a bit more by wanting to have a
standard compliance language and some reporting.
Maybe also the ability to assess devices that don't
have NEA support built in, which TNC can sort of
support via the IF-MAP and CESP specs (although
some aspects of that are underspecified right now).

SCAP has standards for a standard compliance language
and some reporting but they don't seem to have any
actual protocols for endpoint assessment.

Now you probably want more hard facts. Which products
support the TNC standards? Which customers are using
them? What are they doing with them?

TCG has a certification program for products that
have implemented the TNC/NEA specs. The list of
certified products is here:

https://www.trustedcomputinggroup.org/certification/tnc_certified_products_list

And this page has links to case studies that document
actual customers who have happily implemented this:

https://www.trustedcomputinggroup.org/solutions/network_access_and_identity

The SCAP Validation Program is here:

http://scap.nist.gov/validation/

For a list of validated products, go here:

http://nvd.nist.gov/scapproducts.cfm

I don't have links to case studies from customers
who are using the SCAP standards. I'm sure that
some of the SCAP experts on this list can provide
links.

I don't want to toot my own horn but since you asked
for first-hand experience, I will say that Juniper
has been shipping products that conform to the TNC
standards for the last eight years and those standards
work pretty darn well! Not perfect and more is needed
but they are a good starting point. For my ideas on
how the TNC/NEA standards can be used for SACM and
what more is needed, see this draft:

http://datatracker.ietf.org/doc/draft-hanna-sacm-assessment-protocols

I guess I'd better update that draft to wake it
from its dormancy and bring it up to date. Will do.

You asked why IETF needs to be involved if there are
already standards in this area. As described in my
I-D linked to above, the TNC/NEA standards don't
provide a rich enough language for policy checks.
SCAP can provide that and fits nicely with the TNC
protocols. For one idea on how to fit those specs
together, see this Public Review draft (not final):

http://www.trustedcomputinggroup.org/resources/tnc_scap_messages_for_ifm

Obviously, that document would need more work to
be ready. And many of the SCAP documents aren't
really open standards, at least in my view. And
we need a way to handle endpoints that don't support
the TNC/NEA protocols. TCG has some solutions in
that area (IF-MAP and CESP) but I would never claim
that TCG has the answer to everything. IETF brings
together an unparalleled group of experts who will
make the SACM specs much better than what went in.

Like you, I'm allergic to "meta-architectural
frameworks", as Radia Perlman calls them. Let's
get specific!

Please respond to the other email I sent today on
use cases. Let's get that document nailed down to
some specific problems that real customers have.
Then we can move on to creating standards that
solve those problems, preferably by starting with
standards that have been used for years in the
real world so that we know what their flaws are
and we can fix them!

Thanks,

Steve

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> ietfdbh
> Sent: Friday, July 05, 2013 7:17 PM
> To: 'Adam Montville'; 'Sean Turner'
> Cc: [email-masked]

---

From: "ietfdbh" <[email-masked]>
Date: Sat, 6 Jul 2013 08:58:01 -0400

Thank you Steve.
Specific examples seem very helpful in understanding the scope of the
problem, so we can better focus on the scope of the possible solution(s).
Comments inline ...

> Stephen Hanna
> Sent: Friday, July 05, 2013 4:40 PM
> To: [email-masked]
> Subject: [sacm] SACM Use Cases
> 
> I have a few comments and questions on the SACM Use Cases document.
> Since Adam has encouraged us to discuss it and offer our thoughts, I'll do
so
> now.
> 
> First, I recall that we previously agreed to focus our work on UC1 only
for
> now. Our current draft charter seems to reflect that agreement, which is
> good! So I suggest that UC2 and UC3 be removed from the use case

I can do that if there is consensus.
Anybody disagree strongly with removing these sections, and focusing solely
on UC1 in this document?

We can re-title this document "Using Security Posture Assessment to Grant
Access to Network Resources"
Comments?
Anybody want to develop documents for use cases for UC2 and UC3?
(everything can be merged/broken out differently later if desired.)

> 
> Second, I often find it's helpful to have specific examples in use cases
to
> make them concrete. After all, people want to solve specific problems with
> our systems.

I definitely agree with this.

> In order to meet compliance requirements and ensure that corporate
> finance information is not revealed improperly, all computers in the
finance
> department of Example Corporation are required to run only software
> contained on an approved list and to be configured to download and install
> software patches every night. Each computer is checked to make sure it
> complies with this policy whenever it connects to the network and at least
> once a day thereafter. As part of this daily compliance check, the SACM
> protocols are used to assess the posture of each computer and report on
its
> compliance with policy.

Added the example to the UC draft.

> Handling of non-compliant endpoints is not part of the SACM architecture.

I left this part out; it didn't seem appropriate for the UC document.
Maybe it belongs in the charter or the arch doc?

> If so, I can write a few more such as one where suspicious endpoint
behavior
> (like contacting a known command and control server) triggers a compliance
> check.
> Or one dealing with user-owned (BYOD) devices. These examples may
> translate into sub-cases of UC1 or we may decide to break out UC1 into
> several use cases.
> Other examples could include pulling up a report to see which endpoints
> have a particular version of software that has just been discovered to
have a
> *ever* had that software, since the vulnerability might have been
exploited
> before we learned of it.

I would gladly add such examples to the UC doc.
Can you please write them up for inclusion?

> That seems appropriate for a use case document!

+1

> 
> BTW, I see that the charter calls for the use cases to go into the
Architecture
> document. OK by me! But let's start with use cases before we spend too
> much time talking about architecture. Best to fully understand the problem
> before we design the solution!

+1

> 
> And yes, I know that may of us probably think we have a clear idea of the
> problem already. The issue is that until we've written down the problem
> description in excruciating detail with examples and agreed upon it, we
> probably all have different understandings of exactly what the problem is.
> That's normal.

Agreed. I don't know about the excruciating detail, but at least some
concrete examples of the problem(s) we're trying to solve seems called for,
to help us all get on the same page.
In addition, having some concrete examples of use cases will help others,
such as the IESG, to better understand the nature of the problems we want to
work on, and to narrow down what types of functionality and information
models might benefit from standardization. 

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

---

From: Adam Montville <[email-masked]>
Date: Tue, 9 Jul 2013 11:27:00 +0000

> Sent: Saturday, July 06, 2013 5:58 AM
> To: 'Stephen Hanna'; [email-masked]
> Subject: Re: [sacm] SACM Use Cases
> 
> Thank you Steve.
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> > Of Stephen Hanna
> > now. Our current draft charter seems to reflect that agreement, which
> > is good! So I suggest that UC2 and UC3 be removed from the use case

I would not have any objection to removing these use cases from the document, but do have a concern about "forgetting" them over time.  While we have agreed to be focused on the first use case, I do not see why we cannot include a brief "epic" or "scenario" level description of the other use cases and simply explicitly state that we are focused on the first use case, which would subsequently be discussed in detail. 

> > make them concrete. After all, people want to solve specific problems
> > with our systems.
> > contained on an approved list and to be configured to download and
> > install software patches every night. Each computer is checked to make
> > sure it complies with this policy whenever it connects to the network
> > and at least once a day thereafter. As part of this daily compliance
> > check, the SACM protocols are used to assess the posture of each
> > computer and report on
> its
> > compliance with policy.
> 

I would not be surprised if many in this community have these or similar examples in mind when reading these documents.  That said, I'd like to be as helpful as possible for newcomers to our problem domain, so I have no objection to including such examples.  My concern is that we end up building something that is too constrained for other valid examples, so we may have to watch for that.

> > (like contacting a known command and control server) triggers a
> > compliance check.
> > Other examples could include pulling up a report to see which
> > endpoints have a particular version of software that has just been
> > discovered to
> have a

Steve, if you need help with some of these (for the sake of time, I know you don't need "help" considering the examples), let me know and I'll write a couple (just be specific about which ones you'd like me to write).

For that matter, I would encourage others on the list to look at the detailed examples that have been provided and to submit, perhaps as a reply to this thread, your own examples.  The more examples we have, the better abstractions we'll be able to see, and thus a better architecture should be achievable.

> > That seems appropriate for a use case document!

+1, but let's not go overboard either :-)  We should have enough example to enable careful readers to build an abstract model in their minds, so as to yield an effective overall architecture...

> > much time talking about architecture. Best to fully understand the
> > problem before we design the solution!
> 
> +1

+1

> 
> >
> > And yes, I know that may of us probably think we have a clear idea of
> > the problem already. The issue is that until we've written down the
> > problem description in excruciating detail with examples and agreed
> > upon it, we probably all have different understandings of exactly what the
> problem is.
> > That's normal.
> 
> such as the IESG, to better understand the nature of the problems we want
> to work on, and to narrow down what types of functionality and information

---

From: Adam Montville <[email-masked]>
Date: Mon, 15 Jul 2013 18:58:43 +0000

Stealing unabashedly from Brian Trammel's awesome example over on the MILE list...

If you'd like a slot to talk at the SACM WG meeting in Berlin, please let us know at [email-masked] by end of day tomorrow!  

Topics for discussion include any document or topic covered by the recently approved charter (http://datatracker.ietf.org/wg/sacma/charter/). Priority will be given to working-group drafts and discussion of significant progress on previously presented documents.

The meeting will take place in Tiergarten 1/2 on Friday, August 7, 11:20-12:20 CEST.

Regards,

Adam

> Adam Montville
> Sent: Friday, July 05, 2013 12:44 PM
> To: Sean Turner
> Cc: [email-masked]
> NOTE: Please ignore the confidentiality notice at the bottom of this e-mail
> (and others) - it is added after I hit "send" and will be removed for IETF
> correspondence sometime in the next week or two.
> 
> 
> > > While we are not yet an official WG, I'd like to try to get our
> > > ducks in a row and progress as though we are a WG.  I see some
> > > important dates have passed, and that some are upcoming
> > If it's chartered, then we can skip the charter review - it won't be
> > up for discussion because it'll be approved ;)
> 
> > *before* they come to the session.  I'd actually like presenters to
> > ask before they start who has read their draft ;)
> >
> > But, being that this would be the first ever session it's probably
> > okay to present what's in them.  In the future, though we can push the
> > work forward and get to the point by only talking about open issues.
> 
> I would encourage everyone to read ahead even for this first session and
> would anticipate review of these to be minimal and only for those who may
> not otherwise have heard about SACM work before Berlin.
> 
> >
> > > * Use Case Discussion
> > >      * Review of list
> > > Are there relevant drafts that we want to discuss in Berlin and can
> > > be submitted before the 15 July deadline?  At present, the following
> I am unsure as to the state of the vulnerability model and the architecture
> document.  I know that David Harrington has been working on trimming up
> the use case document.
> 
> If there are use cases treated elsewhere, but to which access is limited (i.e.
> > > This message and attachments may contain confidential information.
> > > If it appears that this message was sent to you by mistake, any
> > > retention, dissemination, distribution or copying of this message
> > > and attachments is strictly prohibited. Please notify the sender
> dissemination, distribution or copying of this message and attachments is
> strictly prohibited.  Please notify the sender immediately and permanently
> delete the message and any attachments.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 15 Jul 2013 19:04:25 +0000

> The meeting will take place in Tiergarten 1/2 on Friday, August 7,

Actually we have a second one hour slot scheduled 12:30-13:30. We may decide to go without a break and finish earlier if so it happens, but we can plan for two hours. 

Regards,

Dan

> Sent: Monday, July 15, 2013 9:59 PM
> To: Adam Montville; Sean Turner
> Cc: [email-masked]
> If you'd like a slot to talk at the SACM WG meeting in Berlin, please
> let us know at [email-masked] by end of day tomorrow!
> 
> Topics for discussion include any document or topic covered by the
> recently approved charter
> (http://datatracker.ietf.org/wg/sacma/charter/). Priority will be given
> to working-group drafts and discussion of significant progress on
> previously presented documents.
> 
> > Of Adam Montville
> > NOTE: Please ignore the confidentiality notice at the bottom of this
> > e-mail (and others) - it is added after I hit "send" and will be
> > removed for IETF correspondence sometime in the next week or two.
> >
> >
> > > > Given the milestones listed in our charter, it seems that our
> > > > agenda should contain a healthy dose of use case an discussion and
> > > > possibly some requirements discussion.
> > > >
> > > > Proposed (loose) Agenda:
> > > >
> drafts.
> > > okay to present what's in them.  In the future, though we can push
> > > the work forward and get to the point by only talking about open
> issues.
> >
> > I would encourage everyone to read ahead even for this first session
> > and would anticipate review of these to be minimal and only for those
> > who may not otherwise have heard about SACM work before Berlin.
> >
> > >
> > > > * Use Case Discussion
> > > >      * Review of list
> > > > Are there relevant drafts that we want to discuss in Berlin and
> > > > can be submitted before the 15 July deadline?  At present, the
> > > > following "related documents" show up on our Documents page
> > I am unsure as to the state of the vulnerability model and the
> > architecture document.  I know that David Harrington has been working
> > on trimming up the use case document.
> >
> > On that note, he has asked on several occasions for some more concrete
> > use case examples, but I haven't really seen many provided.  It would
> > be good for this community to throw a few out there.  Remember that
> > use cases don't need to be comprehensive with respect to the
> > requirements.  They should exemplify.
> >
> > aren't free), then I suggest that we summarize them here without
> > simply referencing that work.
> >
> >
> > >
> it appears that this message was sent to you by mistake, any retention,

---

From: Sean Turner <[email-masked]>
Date: Mon, 15 Jul 2013 16:57:50 -0400

> Topics for discussion include any document or topic covered by the recently approved charter (http://datatracker.ietf.org/wg/sacma/charter/). Priority will be given to working-group drafts and disc…

https://datatracker.ietf.org/wg/sacm/charter/ ;)