Minutes for SACM at interim-2014-sacm-5

Meeting Minutes Security Automation and Continuous Monitoring (sacm) WG
Title Minutes for SACM at interim-2014-sacm-5
State Active
Other versions plain text
Last updated 2014-10-23

Meeting Minutes

SACM Virtual Interim Notes
The following is a consolidated overview of notes taken during the October 2014
SACM Virtual Interim.  Raw notes are included for informational purposes at the

All updates considered "resolved" or otherwise agreed upon should make their
way into submissions in support of work to be done during IETF 91.

Many thanks to Nancy Cam-Winget, Jim Bieda, and Lisa Lorenzin for providing
their notes from the session.

After going through agenda bashing and a review of late milestones, we had a
brief discussion about endpoint identity and whether that should be considered
a milestone.  It seems as though there may be some further discussion that
needs to happen.  At this point the concept of endpoint identity is implicit in
milestones and there has been a call to make this explicit.

We moved into the information model after that portion of the discussion where
we went through some discussion of issues previously sent to list. Some issues
were considered resolved, but need to be validated on the mailing list:

    1. Add sections as proposed by Cliff Kahn
       a. http://www.ietf.org/mail-archive/web/sacm/current/msg02103.html
    2. Graph model references in the information model draft
       a. Move section 5 of information model to appendix
       b. Rewrite section 6 to remove graph references
    3. UML diagram
       a. Upper part of diagram describes potential endpoint/attribute pairs
       b. Lower part (Endpoint Attribute Assertion) is prescriptive (MUST be

These updates should be submitted by the IETF 91 submission deadline of 10/27.

Other issues are still open to discussion.  Specifically:

    1. What is an endpoint?
    2. What is a unique identifier?
    3. Is there prior art for endpoint identification?
    4. We need flexibility for dynamic nature of endpoints

This can be a tricky secnario where even MAC addresses can be duplicated in
certain environments - essentially, many of the "identity handholds" we rely
upon in "traditional" environments may not suffice in novel enterprise
deployments.  This may warrant an additional type of SACM component that
handles endpoint identity and/or reconciliation.

For prior art with respect to endpoint identity see:

    - http://scap.nist.gov/specifications/ai/
    - http://csrc.nist.gov/publications/nistir/ir7693/NISTIR-7693.pdf

We also discussed the notion of assertion uncertainty.  Do we need to do
assertion checking based on provenance?  The idea is that we should strongly
consider providing points in the information/data models where we can record
provenance information, though not necessarily provide the methodology used to
determine levels of trust.

After the information model review we moved into Requirements review and
discussed the differences between current and prior drafts.  The Requirements
draft is somewhat lopsided where there are verbose requirements for most things
aside from the Information Model.  It was explictly noted that we need wider
reivew of the Requirements draft.

After the Requirements discussion we moved directly into Architecture
discussion.  We, again, discussed differences between the current and prior
drafts, and believe that there is one more iteration of the Architecture draft
before WGLC.  As with the Requirements draft, it was noted that we need wider
review of the Architecture draft as well.

The Way Forward is as follows for IETF 91:

    - 1st meeting: Charter review and editing feedback on updated drafts
    - 2nd meeting: Adopt docs and update milestones
    - Goals:
        - Finalize requirements draft for WGLC and submission to IESG
        - Close outstanding architecture issues and move to WGLC
        - Discuss the Information Model
        - Update milestones
        - Accept and discuss protocol proposals


Jim Bieda

SACM Summary Notes: 14 Oct 2014

*WG Status – Dan Romascanu
Late on milestone timeline
IETF Cutoff date for updated drafts: 27 Oct
Lisa:  Should the charter of the group should include milestone for “Identity”?
Dan:  Should be included in Info-Model and Requirements by reference
RESOLVED:  Need to reserve time for discussing new milestones at IETF-91.

*Information Model review – Lisa Lorenzin, Cliff Kahn
RESOLVED:  Add sections proposed by Cliff Kahn email
see:  http://www.ietf.org/mail-archive/web/sacm/current/msg02103.html
2.2 – What is an endpoint?  Unique identifier?
Prior art on endpoint ID?
see:  http://scap.nist.gov/specifications/ai/
see:  http://csrc.nist.gov/publications/nistir/ir7693/NISTIR-7693.pdf
Need flexibility to deal with dynamic nature of endpoints.
2.3 – Dealing with uncertainty –
Need to do assertion checking based on provenance?
Adam:  Don’t conflate info model with process to determine truth of assertions?
Cliff:  Need to record provenance along with the assertion.

RESOLVED:  Graph model references in the Info Model draft
Move Section 5 of Info Model draft to Appendix.
Rewrite section 6 to remove references to graph.  (May be an option for data

RESOLVED:  UML diagram
Upper part of diagram describes POTENTIAL endpoint Attribute Value Pairs. (MAY
be provided) Lower part (Endpoint Attribute Assertion) is prescriptive (MUST be

Dan:  Please complete IM update by the IETF-91 submission deadline.

*Requirements review – Nancy Cam-Winget
Discussed diffs vs. prior draft.
Need one more iteration of draft (perhaps in Info Model & Transport) before
we adopt.
  Security Considerations beyond data protection in transport?
Ira – remove the word “task” from SACM docs
RESOLVED:  One more iteration before WGLC.

*Architecture review – Nancy Cam-Winget
Discussed diffs vs. prior draft
RESOLVED:  One more iteration before WGLC.

*Way Forward – Dan Romascanu
By 27 Oct:  Updates for Reqs, IM, and Architecture drafts due
IETF 91:
1st meeting:  charter review &  editing feedback on docs
2nd meeting: adopt docs and update milestones
     Final Reqs doc for submission to IESG
     Close arch issues and do WGLC
     Discuss Information Model
     Update milestones
     Accept & discuss protocols proposals

Nancy Cam-Winget
SACM Interim Notes

Agenda bash
4 Call-in Users + Alan Lei, Cliff Kahn, Danny Haynes, Ira McDonald, Jarrett,
Jessica Fitzgerald-McKay, Jim Bieda, Josh Lubell, Kathleen Moriarty, Lisa
Lorenzin, Rob Walters, Scott Pope, Thomas Joy

We are behind on milestones: Dan and Adam will update milestones to discuss at
the IETF 91 face-to-face meeting.  We currently have a 9month delay based on
original milestones

Need at least one iteration on the Requirements draft, not quite ready for WGLC
Architecture draft was published and confirmed today
Late on Information Model as well
Submission cutoff is Monday the 27th so there’s still some time to get updates
Lisa asks Jan 2014 info: retrieving config and policy information but there’s
no mention for collecting identity. Dan asks if its because we took for granted
that when talking about posture, there’s the need for identity already? Lisa
believes it’s a huge handwave…needs to be more explicit.  Need to clearly
define identity Adam agrees; though in the milestone it doesn’t need to call
out every little thing.  Believe identity is implicit. Dan also feels that
unless something big is missing, or a separate document is needed for something
(like identity) then it doesn’t need to be called out explicitly or
wordsmithing the current charter.  But that may require a rechartering. Lisa
believes that if we can not define identity then we can not move forward and
accomplish our goal. Nancy comments Dan says if we’re not comfortable with the
text that’s in the charter, then we can modify the charter but that may set us
back as we’ll need to recharter. Would prefer that we work thru it in the
actual drafts that we standardize. Lisa doesn’t believe that its excluded in
the charter as it is implicit, but wants to make sure that the work is
identified and know where its going to be done.

Nancy points that its in the requirements draft….even tho the charter is
implicit Dan notes that we’re in agreement and new milestones are to be
updated. NOTE for Chairs:  reserve time for discussing new milestones in IETF 91

Lisa to drive Information Model discussion:
Update: no calls were scheduled so no progress on the info model.  Wants to
address the two questions submitted by Cliff to help move the draft forward. In
the virtual interim, the model was posted too recently so people didn’t have
much time to go thru it and wanted to solicit feedback. Cliff asks about
problem statement text to be added, he sent and email today subject “proposed
addition to problem statement of SACM Information Model”: How do you refer to
an endpoint? It may not have a unique identifier….a MAC address is not meant to
be a unique identifier. Information model has background to drive towards an
endpoint attribute assertion: attribute value pairs with semantics where some
endpoints have a certain set of attributes over a time interval; but it doesn’t
mean that the set provides a unique identifier to the endpoint. Lisa comments:
MAC address in a multi-tenant environment then a richer context is needed to
help better define the endpoint. Dan asks for clarification: the same MAC
address can show up in different geographic data….because of mobility? Lisa
comments reuse of MAC address, etc Dan: time and location context can be used
to better provide scenario Cliff: encourages review text defining endpoint
attribute assertion as its core to information model.  It needs refining but
its in the right direction Lisa asks if there’s prior art Adam notes that there
are efforts but they’re proprietary; one based on NIST that is similar to
what’s being proposed here.  NIST asset identification spec; Adam will send a
link for this.  Comments that there are dynamic behaviors that need to be
accounted for that didn’t exist in the “static” deployments (or old
enterprises) Cliff notes that we need to have agility, because it will have to
be dynamic Adam agrees that flexibility needs to be there for future growth
Discussion of where the identity reference exists between Cliff, Ira and Adam
Adam inferences of cross checking should be outside information model, but info
model needs to be concise to allow for the representation for the assertion
types Cliff clarifies: info model should not prescribe how to do the cross
check, the info model should provide abstraction for components to allow for
non-standard specific ways. Adam: if a given piece of data came from user vs.
hw land, observed or taken from the endpoint does need to be expressed.  We
want the data to be present in the info model, not necessarily the method Lisa:
sounds like we’re agreeing so we can move forward Cliff: next question of
whether the graph model should be in the draft or not Suggests that it be moved
out of normative text….it may be moved to an appendix No comments or objections
to move it out of normative to either a different draft or as an Appendix
Cliff: next question regarding the “Revised UML diagram of information model”
An endpoint assertion may contain a bunch of attributes but not all endpoints
will have the same attributes…so perhaps the UML diagram is not correct Cliff,
Nancy, Ira and Lisa discuss normative text as having a set of interoperable set
of attributes and set of containers.  For instance, an endpoint assertion would
be a container but the model can not dictate specific attribute value pairs
inside the container because of the different types of endpoint.  It should be
a “descriptive” list of attributes versus being “prescriptive” of the
attributes that should fall inside attributes or containers.

Requirements discussion:
Ira comments that the word “task” should not be used but either replace it with
component or function Nancy comments that we need to clean up Information Model
section and perhaps needing more in the transport. Dan asks what’s next?  Hope
that we get more review…. Nancy can get another update based on her own
comments and do cleanup as she sees fit Chris will provide feedback by end of
this week

Architecture discussion:
Nancy describes the updates, notes that she wants to incorporate feedback from
Jessica as well. Nancy would like to get feedback from the group by this Friday
so she can get another rev by the 27th

Dan remarks and shows updated milestones to get drafts submitted by 10/27 and
notes that by IETF 91 milestones need to be updated. Adam asks on confidence to
get the drafts done; Nancy suggests getting feedback; Lisa’s confident on
getting info model by 10/27 but needs feedback by next Wednesday. Discussions
on getting proposals, Dan notes that he’d like to see some but needs to be
submitted by 10/27.  Chris asks/notes that it may be hard to evaluate current
XMPP-Grid without solid requirements and architecture.  Dan notes that we have
some drafts in place to help so we can parallel process as requirements and
architecture is in place albeit solidifying.

Lisa Lorenzin
141014 SACM virtual interim
Submission cutoff is Monday 10/27 for IETF 91
Endpoint identity goes into requirements, information model
Implicit in submission milestones for retrieving configuration and policy
information, endpoint posture Proposed additions to problem statement of SACM
information model CK - not sure problem statement is where these should go -
both problems and requirements Content that was buried in previous draft,
seemed to deserve promoting and explicating One problem is how to refer to an
endpoint Identifying an endpoint - how to refer to an endpoint We won't always
be able to use a unique identifier to refer to an endpoint Not all will have
one, not all observers will know the identifier when they observe something
Profiler may observe that a certain MAC address is an iPhone running iOS That's
what Profilers do - it won't know from that - MAC address is by no means a
unique identifier This is still useful posture data, is the premise here We
need to be able to capture information like that in the information model My
claim here is that this observer should not have to go digging and try to
figure out what endpoint has this MAC address That could be the job of a
different SACM component Correlates different observations to figure out what's
going on with a certain endpoint Led to the idea that the information model had
already Idea of endpoint attribute assertion - collection of attributes A/V
pairs with semantics that the observer says that some endpoint that has all of
these attributes over some time interval Doesn't meant that the attributes are
sufficient to uniquely identify the endpoint Maybe in combination with other
things, some other endpoint can figure out what endpoint it was Referring to an
endpoint without always having a unique identifier Part of the information
modeling problem LL - if capturing information about an endpoint in a
multi-tenant cloud environment, might have multiple endpoints with same MAC
address Causes a need for context about the domain of the observation DR - same
MAC address can show up why? LL - reuse of MAC address across different
domains, or single MAC address in different domains DR - then time and location
context are useful CK - encourage people to take a look at the text on defining
endpoint attribute assertion Think it's very core to the proposed information
model Don't think it's cooked yet - think it needs refining, sort of in the
right direction Allows you to make assertions about an endpoint without knowing
uniquely what endpoints you're discussing LL - not familiar with this area -
would love prior art, anything we can point at AM - have been efforts, nothing
gained traction, proprietary NIST came out with asset identification spec
Doesn't describe what identifies an asset Up to the user using the spec to
decide what constitutes an identifier Think Dave would have more to say about
it Submission either before charter or shortly after charter - prior to
charter, doesn't exist at this point Will send out a link CK - I've talked
about some of this with Dave & Kim Their model was a central administration
model, each endpoint onboarded by central authority and given unique
identification in enterprise Great, but for BYOD, IoT, slew of endpoints where
that doesn't work Would be good to talk more with Dave May work well in certain
kinds of enterprises where everything is onboarded in centrally administered
way Want our scope to include BYOD and IoT kinds of endpoints, taking that as a
given AM - lot of these specs that exist today were made for datacenters,
well-understood deployments, not necessarily dynamic assets Asset
identification spec would allow for some of that dynamic behavior to be
accounted for Don't believe it went into anything like matching algorithms,
don't know how detailed we want to be If we know about something in our CMDB,
has synthetic identifier, this app has ID X Find information about a given
asset, how do we match those two? CK - did look at that spec, Dave pointed me
at it Want to keep some agility about this, see identification as not a thing
we can fix once and for all AM - absolutely agree with that - keep as much
flexibility in how we define expressions, better off we'll be in the long run
CK - other thing in this memo is about dealing with uncertainty In figure 1 of
the information model Internet-Draft, there's a dotted line across the middle
Everything above is the world we're describing, everything below is SACM
components The relationship between the two was not fully developed - needs to
be more fully developed One thing about that relationship - in many information
models, have certainty Model is modeling facts Here we don't have that, won't
necessarily be true Attacker may develop countermeasures to fool some of our
components Since SACM is a security component, behoove us to have tolerance for
those things Endpoint attribute assertions are assertions - not true or false
necessarily Can be cross-checked with each other An observer can assert
something, another can consume assertions and decide whether assertions agree
If so, gets more credence, if not, gets more concern - secondary reasoning Why
we need provenance - helps explain what provenance is for Being able to take
into account reputation of observer, whoever put information into information
model - are they reliable? They themselves are also an endpoint, could be out
of compliance or vulnerable Should think about using SACM to monitor SACM -
feeding into reputation That's just part of the uncertainty Network
observations are inferential - not 100% anyway Need corroborating / hedging Do
all of those considerations need to be captured in an information model, or
many of them?  This is a problem IM - NIST spec is IR, information report, not
an SP-800 standard - IR-7693 Its main Achilles heel is it presumes throughout
direct communication with endpoint All security appliances that observe, watch
traffic, it's useless for Don't have unique identity from concatenation of
identifiers, because they're not on the wire Has some applicability, by no
means the answer Sent a note to a TNC list in TCG a couple months back, should
take a look at this - we did, saw that it had pluses and minuses AM - comment
about dealing with uncertainty There are assertions, no facts - I like that See
the degree of certainty as being an issue Wondering whether cross-checking and
being able to infer against each other, meaning not clear Whether that belongs
in the information model or whether the information model should be relegated
to what needs to be done in order to assess posture Inferences and posture can
be done outside of that Wouldn't want to conflate too many functions inside the
information model LL - where else would we do it? AM - something outside of
that Information model represents assertions being made, information represents
assertions How we cross-check those assertions could be done outside of that CK
- clarify what I was trying to say Don't think the information model should
prescribe how you should cross-check Maybe SACM standards shouldn't Information
model should provide information that would allow components to do that in
vendor-specific ways In some of the TNC standards, observations get tagged with
method used, place to do that Self-reported vs. reported by observer, different
techniques, and also identity of source SACM component reporting information AM
- given piece of data, come from third-party agent or userland? Observed on
wire or taken from endpoint?  Things like that CK - yes - make sense to have
it? AM - want the data that would be used for cross-checking and inferring to
be present in the information model, not necessarily the method LL - absolutely
CK - talked last time about whether graph model should be in information model,
didn't reach a decision I make an argument that it shouldn’t be - two-part
argument One is a question of whether the parts of an endpoint should be
represented with separate identifiers If there's going to be a graph, how would
we use the graph? One YANG model of endpoint attached as metadata to an
identifier that denotes the endpoint Maybe not, maybe expressed with subgraph -
interesting question, distraction to tackle it now NCW - my recollection of the
previous call was that there was consensus that the graph model was not to be
the normative text in the information model LL - think that what Cliff is
recommending is that we remove it, even non-normative, as a distraction Didn't
belong in the information model - what wasn't clear was whether graph could be
example for how we could organize the information DR - how would this be
reflected in the information model draft? Completely out? CK - move section 5
to an appendix so we don't lose it, have available when working on data models
to consider Section 6 would need to be rewritten in a way that does not assume
a graph DR - that works for me LL - any objections? CK - UML diagram showing
that every endpoint attribute assertion has UML relationship with endpoint What
we'd like, but sort of not true Will have endpoint attribute assertions where
-if you assume by endpoint we mean something with a unique identifier Endpoint
attribute assertion doesn't have that Many of those A/V pairs refer to things
in upper half of diagram IP addresses, MAC addresses, hardware components,
software components, locations, unique endpoint identifier Almost all things in
upper half could appear Tried to make the diagram say that If we like that,
text also needs to change to say that too NCW - you can refer to the diagram as
an example I agree that the endpoint attribute assertion is just a collection
of attributes, not all assertions are alike CK - I think it needs to be more
than an example Need to have some normative attributes Is your point that it
needs to be extensible? NCW - needs to be extensible, but I thought in our
discussions an asset could be a physical thing or virtual thing Would find it
hard to put a single handle to an endpoint CK - agreed IM - I think what Cliff
is trying to say - kind of a hard idea to get across - not all endpoint
attribute assertions contain the same set of attribute value pairs Varies
wildly depending on whether virtual / physical, hardware chunks in endpoint
What's inside an endpoint attribute assertion that's used generally for
identity in the broadest sense is utterly contextual We've found that unique
identifier problem is a hard problem LL - think we need some normative set of
attributes, need extensibility as well NCW - we know we need something that
describes and endpoint assertion, that can be normative But the attributes are
not I don't think we can put normative "you must have one of" LL - I agree, but
I think there's value of defining a normative set of attributes so entities
that can use those can use them out of the box IM - only if it's in context -
attributes for software asset no overlap with hardware NCW - I would assume,
similar to what NetConf has done with YANG They have a set of containers and
attributes - for interoperability, MUST set of attributes from implementation
standpoint Assertion container, set of attributes, we have to decide which ones
are MUSTs What's contained within the endpoint assertion, don't' think we can
construe as normative CK - the diagram I drew yesterday says an endpoint
attribute assertion has one or more A/V pairs An A/V pair may refer to one of
the kinds of things in the upper half of the diagram, or it may not Will
certainly be some attribute values - quite precise With UML, easy to be
precise, consistent with what  you're saying Not trying to mandate that
particular attributes appear It may be that an A/V assertion that doesn't have
at least one of X is meaningless, but I'm hesitant to add normative text - have
restrictions without being sure we need them Seen that turn out to be a bad
idea in the past LL - think we need a descriptive list of attributes, not a
prescriptive list of attributes IM  - descriptions of attributes without having
prescriptive requirements that an endpoint attribute assertion bundle always
contain them CK - normative not only in syntax but in meaning LL - yes, that's
what I care about CK - were a little lax about that in things like RADIUS,
IF-MAP - has caused problems Won't be a closed set - will be extensible by IETF
and presumably by implementers as well TJ - in your diagram, you have
credential on the top Endpoint not always manageable to have a credential to
identify endpoints on the network Just one point CK - it shows that an endpoint
MAY have one - it's a star An endpoint has zero or more credentials TJ - that
sounds right Identifying an endpoint is a set of attributes that keep on
changing From an enterprise level, people have to do definition CK - attributes
change - agreed IM - they have a lifetime, too - not always the same as the
lifetime of the endpoint JB - just to be absolutely - stuff in upper parts of
diagram is descriptive of things you may have as A/V pairs provided to lower
half of diagram in endpoint attribute assertion, which must be there for any
endpoint LL - endpoint attribute assertion MUST be there, upper half is things
that MAY be in it LL - wraps up on information model DR - have 13 days until
the cutoff for submitting the Internet-Draft You basically need to complete the
work this week and the next week LL - yes - I do expect to have updated
information model draft submitted by deadline DR - should be draft-ietf-sacm LL
- yes, will rename it correctly Requirements NCW - don't have slides prepared
Based on text in information model draft, tried to elaborate more to highlight
need for scalability and so on Not happy with what's requirement on information
model For transport, not sure whether data protection was transport data
protection, or security considerations for interfaces, which include transport
More on architecture than requirements Would like to get your input and
feedback on that JB - want to know whether or not there should be a requirement
for security at a specific layer, or handle in architecture? NCW - for
requirements on architecture In section I added, trying to be consistent with
how we'd had it in general requirements All we had noted was data protection
Could speak to just data integrity, or confidentiality LL -  I thought we
agreed that we wanted both and they were separate requirements NCW - we did -
that's why I left requirement for data protection in general section, also
requirement in transport JB - do we want to say that function has to happen in
transport? LL - think that is necessary, but not the only place NCW - putting
requirement in transport means we have to address in transport layer JB - we
want to solve that in transport NCW - transport being one of the places we want
to solve that - yes DR - what next? Hoping more folks will read and provide
comments in the next week or so Facing the same cutoff for the 27th Wondering
whether a new iteration which is good enough for WGLC can be done NCW - I can
do the cleanup based on my own feedback, try to get it done by the 27th Hoping
to get more review, otherwise… DR - trying to figure out what happens between
now and IETF 91 Can do nothing and wait for comments to come Can do cleanup and
wait for new release without issuing last call Can issue last call, which may
not necessarily be the last last call Last call has capacity sometimes to
mobilize people who didn't pay close attention until then to read and provide
comments Discussion at IETF 91 CI - will commit to giving you feedback this
week - it's 11 pages Architecture Left the architectural figure as the main
figure New section is cut-n-paste of one of the appendices of information model
Given that we've now defined high-level components, Provider / Consumer /
Control Plane Had a hard time with comments about guidance Didn't include from
original text - function called out which was collection guidance capability
Didn't quite make sense to me, didn't bring it from information model Need to
sync with Dave Capability seemed like more of control function When read it
closer, seemed like producer or consumer that could go to collection or
evaluation Still functional components that act as producers or consumers LL -
think that's correct - collection guidance was a way for producers or consumers
to instruct other components on information needed NCW - removed that task
Called it a component, to flow better with taxonomy of this draft Component
that articulates guidance as producer or consumer Need to look at diagram to
make sure flow still makes sense Jess provided other diagrams, I had a hard
enough time trying to get this updated That I may show as better workflow
examples I'm hoping you guys will provide more feedback on this draft If I can
get the feedback from you guys by this Friday, may give me enough time to get
it in by the deadline Figures always give me a hard time, or IDNITS does Given
that I wanted to incorporate some of the feedback from Jess, I need about a
week LL - might talk to Aaron, he did magic with Cliff's figures NCW -
unfortunately Aaron is not focused on this anymore DM - instruction is to try
to do your best and complete by the deadline Probably good to go through at
least one more iteration before going to last call Have the best we can by
deadline, discuss it in Honolulu Questions or comments?