SACM BOF
Notes from IETF 86 Meeting

SACM BOF met in Orlando, Florida, USA on March 14, 2013
from 1300 EDT (1700 GMT) to 1500 EDT (1900 GMT)

Kathleen Moriarty and Dan Romascanu chaired the session.

Steve Hanna took these notes. The contents of the slides
are not reproduced here since those have been archived and
are available online. Instead, the focus of these minutes
is mainly on the discussion that took place during the BOF.

Last names are only used only the first time that a
speaker appears in the notes. After that point, only
the speaker's first name is used. This works fine
because no two speakers had the same first name, including
those who made comments and asked questions.

1. Note Well, Note Takers, Jabber Scribes, Agenda Bashing - 5 min

Steve Hanna and Eliot Lear volunteered to take notes.
Eric Rescorla was Jabber Scribe. And we're on MEETECHO.

Dan reviewed the Note Well and Agenda. Here's the Agenda:

1. Note Well, Note Takers, Jabber Scribes, Agenda Bashing - 5 min
2. SACM Use Cases - David Waltermire, Adam Montville - 30 min
3. SACM Architecture - David Waltermire - 25 min
4. Solutions Contributions - Brief
5. Scope and Charter Discussion - 20 min
6. BOF Questions - 10 min

Dan explained that this is the second and final SACM BOF.
We have spent the time since our first BOF working on
refining our use cases and charter.  We'll focus this
meeting on discussing use cases and requirements and
scope and charter. At the end of this meeting, we'll
discuss some key questions that will help our Area
Director decide whether to charter the WG.

Dan explained that no new solutions have been proposed
since IETF 85 so item 4 (Solutions Contributions) will
just quickly point to solutions presented at the last BOF.

2. SACM Use Cases - David Waltermire, Adam Montville - 30 min
http://www.ietf.org/id/draft-waltermire-sacm-use-cases-04.txt

Adam described the changes to the use case document
since IETF 85. At the end of his presentation, he asked
the following questions:

1. Are the updated use cases sufficiently narrow?

2. Are the updated use cases aligned with draft charter?

3. Thoughts around renaming "Asset Management" to
"Asset Scoping"?

Dave Waltermire said that there has been consensus
on the list that only use case 1 should be in scope.
That's why our charter and architecture focus only
on use case 1.

Allan Thompson asked if use case 1 is before or after
connection to the network. Adam said either. Allan asked
to have this stated clearly in the document. This is
part of requirements.

Allan said that use cases 2 and 3 are broader
than only posture. If we were going to do those,
he'd ask why we're only focusing on posture
assessment.

Mike Boyle said he's OK with focusing on use
case 1. He asked why we can't include sensors
on the network that measure endpoint posture.
Dave said that he has an open question on this
in the next presentation. Mike agreed to defer
his question until the next presentation.

3. SACM Architecture - David Waltermire - 25 min
http://www.ietf.org/id/draft-waltermire-sacm-architecture-00.txt

Dave explained that he's going to present on
his proposed architecture for SACM. Dave asked
how many people have read this spec. About 15
people raised their hands.

Dave said we want to leverage existing IETF and
international standards as much as possible
and keep the architecture as simple as possible.
He showed the main diagram from the architecture.

Dave reviewed the Data Flows in the architecture:

DF1: Content Retrieval
DF2: Collection Tasking
DF3: Collected Data Publication
DF4: Collected Data Query

Dave then reviewed the Components:

Sensor
Controller
Evaluator
Data Storage
Content Repository

He explained that there are three kinds of Sensors:
Network-Oriented Sensors, External Endpoint-Oriented
Sensors, and Integrated/Installed Endpoint-Oriented
Sensors. A Network-Oriented Sensors observes network
traffic sent to and from endpoints and makes
inferences about endpoint posture based on that traffic.
An External Endpoint-Oriented Sensor is a component
external to the endpoint that uses authenticated or
unauthenticated APIs and protocols to gather data about
the endpoint's posture. An Integrated/Installed Endpoint-
Oriented Sensor is software and/or hardware installed on
or built into the endpoint that supplies data about the
endpoint's posture.

Each of these components may have multiple instances
in any given system.

Dave described the information gathered by the Sensor
in the current architecture and scope:

Endpoint Identity
Posture attributes
Provenance data
Entailment information

Eliot Lear asked if the Content Repositories hold
"data that drives collection policies", as stated
on the slides, or hold the policies themselves.
Dave said it's the latter (the policies).

Eliot asked some clarifying questions about the
relationship between the Evaluator and Controller.
Dave explained that the Evaluator is responsible
for analysis. The Controller is responsible for
collecting the data needed, as requested by the
Evaluator.

Allan Thomson asked if there might be several
Controllers talking to a single Sensor. Dave
said yes. What about multiple Evaluators
talking to a single Controller? Yes. All of
the relationships are many-to-many. Allan asked
that this be described in the requirements and
then in the architecture.

Dave asked some questions.

A. Are network-oriented sensors in scope?

Mike said yes, I think they should be. We're
mainly working on the protocols for Sensors
to talk to Controllers and other components.

Steve Hanna asked if we're still thinking that
this would only be limited to the information
types listed above. Dave said yes. Steve said
"Then I think network-oriented sensors are OK".

Chris Inazio asked for concrete examples of
network-oriented sensors vs. external endpoint-
oriented sensors. Dave gave some examples.
The main difference is that external endpoint-
oriented sensors would use APIs or protocols
to actively gather data whereas network-oriented
sensors just passively observe network traffic.
Chris said then we should use the terms active
and passive.

Kent Landfield asked what we mean by network-oriented
sensor. Dave explained that he means a sensor
that just observes network traffic passively.

Kent asked whether we would gather data on the
posture of network infrastructure devices like
routers and firewalls. Dave said yes. Those are
all endpoints.

Mike said network-oriented sensors can gather
behavioral information that's useful in assessing
endpoint posture. For example, a device that claimed
to be a printer might be doing things that indicate
it's not a printer. That should be included. It's
probably the same protocol. Chris agreed.

Eliot said that network-oriented sensors
gather huge amounts of data that needs to
be condensed down quite a bit to be useful.

Adam said that network-oriented sensors
are mainly useful for discovery. They're
not reliable in determining endpoint
configuration. And we should also include
assessing the posture of the Sensors.

Allan said looking at behavior goes beyond what's
traditionally considered posture. And behavior needs
to be assessed over a long time scale. Looking at
behavior is a much harder problem. Kent said that
he does not think behavior should be in scope.

Someone who didn't give his name asked if the
draft includes virtual machines. If so, there
will be endpoints inside endpoints. Dave said
that he thinks virtual machines should be in
scope, although they may not be called out
specifically in the drafts today.

Mike said he doesn't think we should define
a syntax for behavior. He just wants to
point out that they may use the same
protocols.

Dave asked for a hum for those who think that
network-oriented sensors should be in scope.
Kent stopped the hum and asked if behavioral
information would be included in the information.
Dave said yes. Kent said then the crucial question
we should be asking is whether behavioral
information is in scope.

Steve said Dave's answer seems to differ from
the one he gave earlier: that the information
gathered by network-oriented sensors would be
limited to the information types listed above.
Dave said he doesn't think behavioral information
like browsing porn would be included in the list
of data to be gathered. Chris said he thinks
that a network-oriented sensor could gather
data that allows it to decide that an endpoint
is a web server. Steve asked whether knowing
whether an endpoint is a web server is on the
list of data to be gathered in Dave's slides.
He asked which of the pieces of data on Dave's
slides a network-oriented sensor could provide.
Dave said maybe endpoint identity. Steve said
maybe operating system type and version. Dave
said maybe something about application inventory.

Chris said there are products available that
can determine not only which operating system
an endpoint is running but also which patches,
just by observing network traffic. Steve expressed
some doubt about the reliability of such observations.

Dan pointed out that we don't need to settle
this today. There are many other things that
need to be decided today at this BOF.

Mike said that it's good to include network
oriented sensors because they provide a
different, independent perspective on
endpoint posture.

Allan said that there are two parts to assessing
behavior: what kind of device is it and whether
it is doing something anomalous. Which of these
is in scope? Dave said neither is in scope now.

Dave suggested that we take this to the list.

Kent said that he thinks that Controllers should
definitely be able to manage other Controllers
and Controllers should be able to manage content
repositories or data storage. Both should be in
scope. Dave asked Kent to post that to the list.

Dave and Dan asked people to please send comments
to the email list on these and other topics.

4. Solutions Contributions

Dan explained that no solutions have been
presented since our first BOF. He gave links
to the drafts that were presented last time:

http://datatracker.ietf.org/doc/draft-booth-sacm-vuln-model/
http://datatracker.ietf.org/doc/draft-davidson-sacm-asr/
http://datatracker.ietf.org/doc/draft-hanna-sacm-assessment-protocols/
http://datatracker.ietf.org/doc/draft-montville-sacm-asset-identification/
http://datatracker.ietf.org/doc/draft-waltermire-content-repository/

Dan said these solutions may not be adopted by
the WG. They're just starting points. Some may
be adopted, some merged with others, and some
not adopted at all.

5. Scope and Charter Discussion - 20 min

Dan put a copy of our draft charter up on the screen.
However, he pointed out that this is only preliminary.

Our AD needs to be convinced that we have a clear and
focused problem statement, some reasonable draft solutions,
and a solid charter. We'll refine the charter and then
the IESG and IAB will review and revise the charter.
Then the whole IETF will review and propose revisions.
The IESG will revise and eventually (we hope) approve.
So we shouldn't focus on the exact wording of the charter
today.

Dan read the following text out of the charter:

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

These are the problems we're trying to solve.
So we're focused on Use Case 1 in our use cases
document and only two out of the four arrows
in the architecture. Let's focus our discussion
on that. The language "one or a set of standards"
is carefully chosen. In the IETF, we prefer to
have just one solution to a given problem but
we can have more than one if there's a very good
reason to have more than one.

Barbara Fraser said that we don't clearly define
what we mean by "endpoint". Dave said that we
define this in the use cases document, using the
same definition as RFC 5209.

Eliot asked what standards we think we can reuse.
Dave said that we'll be working that out in the WG,
probably putting it into the architecture document.
Dan said we may need a taxonomy document that lists
and evaluates the standards available.

Carsten Bormann asked where we refer to RFC 5209.
Someone pointed out that's in the first paragraph
of the charter. Carsten asked for more definitions
for other terms: content, etc. Instead of using
purely abstract terms, it would be good to relate
terms to concrete, existing terms.

[Stopped playback here, at 12:00 in video4.ogv]

Hannes Tschofenig asked where the assessment
protocols will run. Will they run directly to
the endpoint? If so, where will they terminate
on the other side? Dave said that we need to narrow
that down but in many cases, assessment will be
done by network access systems like NAC and VPN.

Allan said we should say who's allowed to assess
endpoints. Can endpoints assess other endpoints?
And do you really need to have a content repository
and open data storage? Kent said yes. We have years
of experience with SCAP that shows it's not enough
to just have open data formats. We also need open
protocols so that it's easy to distribute content.
And we can't have 100 different protocols for this.
We need international standards. Dan said please
don't use the word "we" unless you mean the IETF.
And please use IETF processes and rules.

Eliot said what goes into the content repository?
The policies or the assessment results? Kent said
he's thinking about the policies but it could also
include the assessment results. Dave said there
are many things to consider, such as rate of change.
We may want different repositories for different
kinds of data. And to answer Allan's original
question, there's no requirement to have a content
repository but it might be a good idea. Allan
clarified that he didn't mean to say that we need
or don't need a content repository. He just wants
to understand that requirements first before we
decide what the solution is.

Hannes provided some suggested language for the
deliverables in the charter. I'd say "A standards-
track document to define a protocol for retrieving
configuration information and policy. And also a
standards-track document specifying communications
protocols and data formats for retrieving (not
assessing) endpoint posture." Like in NEA, you
also have information sent from an endpoint to
a AAA server or some such thing. It's similar.
And one more thing. Put the requirements in
the architecture document or maybe in a separate
document altogether because the architecture
drives the requirements, generally.

Steve said this work is complementary to NEA.
It takes NEA to the next step. NEA provides
protocols for assessment but not the rest of
this context: where do you put the assessments
after you gather the assessments, how do you
trigger the assessments, and where do you get
the policies. This is nice complementary work
and yet this work doesn't require the use of
NEA. There are plenty of endpoints out there
that don't have a NEA client on them and this
work can handle the assessment of those endpoints.

Mike said that for #2, the protocol for
interacting with the repositories, the
network-based sensors can contribute to
that. They bring an independent view of
what's going on and a real-time view.

Dorothy Gellert said we should have the ability
to update the charter to add a taxonomy document.
Dan said that's a good suggestion. We can do
that when it's time to wordsmith the charter.

Barbara asked what this has to do with MILE.
Doesn't MILE or the extensions to MILE cover
all of this, since we're just moving data
around?

Kathleen said there are two related efforts
in MILE. The ROLIE draft could be generalized
to be a RESTful repository access protocol.
And SCI could extend MILE in patterned ways.
That extension work could be done here or
elsewhere and referenced in MILE. Dave agreed
and added that SACM data might be exchanged
in MILE protocols.

Nancy Cam-Winget said that the requirements
should be separated from the use cases. And
we should do a survey. Further, we should be
clear about the relationship to MILE and NEA.

Barry Leiba said that we should probably say
in the charter how this work relates to NEA
and MILE. Dan agreed.

6. BOF Questions - 10 min

A. Should IETF take-up the work described by
   the Scope and Charter? (yes, no, no opinion)

Dan asked for a hum on this question, clarifying
that this means should we create a Working Group
in this area, understanding that the charter
will need and get more work.

There were lots of hums for yes, no hums for no,
and a few hums for no opinion. No answer in Jabber.

B. Indicate your intent to actively contribute
   to this work in IETF. (yes, no, no opinion)

Dan asked for a show of hands on this, explaining
that he means to include writing documents,
writing code, participating in prototyping,
proof of concept, interoperability testing,
providing comments and reviews that will help
progress the documents, and any combination
of those.

There were 12 hands for yes and 1 in Jabber.

Sean Turner said he's generally happy with
the way this went. We'll take this to the
list and judge consensus there.

The full Meetecho recording (synchronized video, audio, slides and jabber room) of the SACM WG session at IETF 86 is available at the following URL:
http://ietf86.conf.meetecho.com/index.php/Recorded_Sessions#SACM