Minutes IETF98: sacm
minutes-98-sacm-00

SACM WG session minutes at IETF 98
==================================
Morning Session 1
Thursday, 30 March @ 9:00
Zurich A
2.5 hours (150 minutes)

Summary:

We discussed in detail one, "base case" path through our vulnerabilty
assessment scenario - a scenario which is being documented here:
https://trac.ietf.org/trac/sacm/wiki/SacmVulnerabilityAssessmentScenario.

Henk provided an overview of recent changes to our COSWID and Terminology
drafts.

We concluded with our "way forward" discussion. Roughly, our way forward is to
begin working toward the hackathon session at IETF 99. To achieve this, several
folks stuck around after the session to discuss the scope of that effort and
required planning.  Two leaders for the work effort have been identified (Adam
and David).  We intend to hold regular informal meetings between now and IETF
99 to ensure a successful outcome.

1. Logistics, note takers, status
=================================
slides: https://www.ietf.org/proceedings/98/slides/slides-98-sacm-chair-00.pdf
presenters: chairs -- Adam Montville and Karen O'Donoghue

The chairs provided an status update on the activity and documents of the WG.

Comment (Henk Birkholz): Is Danny (Haynes) on-site?
A: No

2. Vulnerabiltiy scenario working discussion
=================================================================
slides:
https://www.ietf.org/proceedings/98/slides/slides-98-sacm-vulnerability-scenario-discussion-00.pdf
presenter: Dave Waltermire reference:
https://trac.ietf.org/trac/sacm/wiki/SacmVulnerabilityAssessmentScenario

Per Slide 5:
Q: (Dave Waltermire) Are there any questions about these vulnerabilities
scenarios A: (Jessica Fitzgerald-McKay) What is the vulnerability detection
data A: (Jessica Fitzgerald-McKay) It is the information required to detect a
vulnerability A: () The data comes from the end-point. A: () No like OVAL data
A: (Jessica Fitzgerald-McKay) Are we assuming OVAL data A: (Adam Monville) No
A: (Jessica Fitzgerald-McKay) You would be comparing the data from the
end-point repository with the vulnerability repository A: (Henk Birkholz) View
this as guidance on how to acquire this data; not what data it is A: (Jessica
Fitzgerald-McKay) I think this is the "what" A: (Dave Waltermire) This is about
the vulnerability state? A: (Jessica Fitzgerald-McKay) Yes, on the how.

Per Slide 7:
Q: (Adam Montville): Is the vulnerability assessor talk to the repository or
talking directly to the collector? A: (Jessica Fitzgerald-McKay): I could see
an implementer combining the collector and end-point repository into one.  If
we're treating them as functional components I'm not sure we need to be that
specific. A: (Dave Waltermire): We want this architecture to be de-composable. 
If we treat the end-point repository as a proxy, we might be making things too
complicated. It might be simpler to treat the end-point repository as a data
store. A: (Adam Montville): Agreed.

Q: (Dave Waltermire) Are there any concerns with separating the end-point
repository and the collector being the component responsible for collection? A:
<no response>

Comment: (Adam Montville): The "results repository" will now go into the
"end-point repository.

Per Slide 8:
Q (Dave Waltermire): Is it the right decisions to combine repositories?
A: (Henk Birkholz): In general there should be no issue with splitting
repositories as long as they have distinct functions.  It depends on the nature
of the components.  If the work-flow is clear, everything can go into a single
repository if you define what is split/combined. A: (Adam Montville): To
clarify, are you making an argument for being more explicit about the
repositories A: (Henk Birkholz): Yes, there is a need to be explicit on what
data is in scope; and this has already been done.  If you can't differentiate
then they are the same component. A: (Dave Waltermire): Are you arguing for
splitting components? A: (Henk Birkholz): I favor defining components clearly.
A: (Jessica Fitzgerald-McKay): I think Henk means to keep them separate from
the architecture point of view (Henk agrees).  I'd endorse keeping them
separate.  We (US DOD) would likely keep them separate on our network but
others might choose not to do that.

Per Slide 9:
Q: (Adam Montville and Dave Waltermire): Is the collection task clearly
defined?  Was there a stepped missed? A: (Jessica Fitzgerald-McKay): Is this
defined in the information model?  Is that the goal? A: (Adam Montville):
Eventually. A: (Jessica Fitzgerald-McKay): At a high-level this seems adequate.
 The specifics should be in the information model. A: (Dave Waltermire): This
text is trying to clarify the input/output

Per Slide 11:
Comment: (Henk Birkholz): The term access control could be interpreted as
storage authorization.  The access control permeates all of the previous tasks.
A: (Dave Waltermire): I think that these tasks are not well aligned with the
storage task.  Issues of retention or authorization need to be considered. 
Perhaps we need to only cover what data is stored and where it is stored. A:
(Merike Kaeo): There is also how do you store the data -- what guarantees need
to be provided?

Per Slide 12:
Q: (Jessica Fitzgerald-McKay): Are these tasks granular enough to cover all
querying scenarios beyond the expected data push.  Maybe we need more detail in
the collection task. A: (Dave Waltermire): Back to slide 9, how do you
recommend the break-down of collection? A: (Jessica Fitzgerald-McKay): There
might be certain end-point features that when they change, they would get
pushed. A: (Dave Waltermire): Are you saying that certain attributes need to be
collected continuously; and certain attributes need to be sent ad hoc (perhaps
when they changed). A: (Jessica Fitzgerald-McKay): Yes.  Perhaps what should be
collected and pushed be document as a best practice. A: (Merike Kaeo): I'm
considering the practicality of this guidance.  Initially a baseline set of
information gets collected.  I also want to see when something do NOT occur. 
Why or what would I want to query.  I'd want the devices to tell me when
something has changed. A: (Dave Waltermire): Yes. A: (Merike Kaeo): The
decision of what to push and when adds complexity.  What is a scenario for when
you'd want to ask about more information from a device. A: (Dave Waltermire):
Knowing the software and hardware load are useful to a variety of business
processes ... A: (Kent Watson): In NETCONF there is a YANG push to change
notification.  The WG might want to examine these drafts and bring their
requirements to the drafts. A: (Jared Lu) It appears is a difference between
collecting (and the ways it can be triggered) and monitoring (which is alarming
on what got collected). A: (Jessica Fitzgerald-McKay): Perhaps continuously
collecting the data is "pre-task". A: (Dave Waltermire): It question appears to
be whether the collection task is distinct from a monitoring tasks.  I struggle
with the distinction. A: (Jared Lu): Collection is a state update in the
repository.  Knowing something happened is the monitoring. A: (Dave
Waltermire): Isn't this the same underlying mechanism? A: (Adam Montville):
Maybe not.  The mechanisms might be different. A: (Dave Waltermire): One
command might be to "collect and bring it back"; "collect and let me know when
it changes"; or "collect at this interval".  It won't be request-response in
each of these commands.  Should these be different tasks? A: (Jessica
Fitzgerald-McKay): It might be useful to clarify for the information model. A:
(Glen Wiley): When I look at critical control from CIS, monitoring is an active
task.  Collection doesn't imply immediate action.  Monitoring might involve
collection but it usually means there is a human or automated action.

Per Slide 13:
Comment: (Henk Birkholz): Most of the definitions for target end-point
characterization might not belong in the terminology draft.  Perhaps adding to
the wiki might make sense.

Per Slide 16
Q: (Dave Waltermire): Per the "Green box", do we need a task for this?
A: (Bill Munyan): The end-point repository has significant functionality.  The
data might go into different repositories. A: (David Waltermire) A: (Adam
Montville): The diagram could use clarity in the characterization process. A:
(Jared Lu) Characterization is analytics -- you've collected enough to abstract
insights.  Given the sequence, it either happens in the storage or after it
gets in the repository. A: (Dave Waltermire): Or by an offline process. 
Perhaps information from the enterprise.  It could be input into the
evaluation. A: (Adam Montville): This might not be constrained solely to the
vulnerability scenario. A: (Dave Waltermire): It sounds like we need more
discussion on the topic.

Per Slide 17:
Q: (Joe Salowey): What are the specifics about the query mechanism?
A: (Dave Waltermire): Give me everything you have about a device?  What is your
going in position for what vulnerabilities need to be assessed. A: (Joe
Salowey): You can end up down the path that the vulnerability assessor keeps a
separate repository of the NVD.

Q: (Dave Waltermire): What other information elements would be need to the
query mechanism of the VDD repository? A: (Roman Danyliw): The ability to query
for all vulnerabilities affecting a particular OS or configuration. A: (Adam
Montville): We may not need to go into the details as this is a first pass
through the content. A: (Joe Salowey): I'm happy to clarify my use cases
off-line A: (Karen O'Donoghue) The purpose of this conversation is to clear
road-blocks to clarify the information model. A: (Henk Birkholz): The severity
score surprised me. A: (Roman Danyliw): It's CVSS.

Per Slide 18:
Q: (Dave Waltermire): Do we want to discuss the IEs exchanged between the
Vulnerability Assessor and End Point Repository? A: (Adam Montville): Yes. A:
(Dave Waltermire): How would we enumerate these IEs. A: (Roman Danyliw):
Recommend we seed the conversation with candidate IEs to the mailing list; and
have others add to it. A: (Dave Waltermire): Determining the minimally viable
set would help. A: (Roman Danyliw): +1.  We should enumerate the candidate IEs
and tag each one as required or optional. A: (Jessica Fitzgerald-McKay): I'll
post the question to the list

Per Slide 21:
Q: (Dave Waltermire): Who would be interested in proof of concept
implementations to represent the work-flows.  Maybe at the Hack-a-Thon? A:
(Henk Birkholz): I've coordinated with the yang pub-sub draft authors. A:
(Stephen Banghart): To clarify is that code is related to yang-push. A: (Henk
Birkholz): The yang notification activity is independent. A: (Stephen
Banghart): To those knowledge on yang-push, are there implementations?  Is it
open source? A: (Kent Watson): Cisco has one.  I don't know of if it is open
source.

Q: (Dave Waltermire): Can we track who is willing to contribute to a future
Hack-a-Thon? A: (Karen O'Donoghue): Perhaps we can decompose the interest and
inquire on the mailing list.

3. CoSWID
=========
slides: [used, but not uploaded]
presenter: Henk Birkholz
drafts: draft-ietf-sacm-coswid-01

Birkholz updated the WG on the status of CoSWID draft
(draft-ietf-sacm-coswid-01).

4. Terminology
==============
slides: [used, but not uploaded]
presenters: Henk Birkholz
drafts: draft-ietf-sacm-terminology-12

Birkholz updated the WG on the status of SACM terminology draft
(draft-ietf-sacm-terminology-12).

Comment: (David Waltermire): I'd want to keep parity with the ISO SWID tags. 
Extensions might break that.  I was hoping to expose similar extension points. 
We need to provide text where there is parity and where there is not. A: (Henk
Birkholz): Agreed.  We want to better define extension points.  The first
decision is where to put them if they deviate from ISO SWID XSD.

Per "Termininology Milestones"
Comment: (Bob Moskowitz): Improved terminology always helps.  In SACM there are
objects that are things, processes, etc.  Identity in particular needs to be
clearer.  SACM needs both identity and identifiers. Comment: (Joe Salowey): We
might not be able to agree on terms across WGs.  Perhaps we just need to
distinguish on the context.  Unifying terminology may be difficult. Comment:
(Tony ): Concur on not needing to unify terminology.  Point to them by
reference. Comment: (Kathleen Moriarty): Resolving these issues shouldn't hold
up any specific WG. Comment: (Karen O'Donoghue): Coordinating and recognizing
terminology across groups should be a lightweight effort.  It shouldn't be a
detailed effort to resolve specific differences.  Doing it on another mailing
list would be helpful

5. Way Forward Discussion
=========================
presenters: chairs -- Adam Montville and Karen O'Donoghue

Karen O'Donoghue noted that next steps include:
** the WG hosting several interim/design team meetings before IETF 99
** discussion scoping what could be done at the Hack-a-thon

Q: (Karen O'Donoghue): How many people would be interested in participating in
the Hack-o-Thon? A: ~5 people. A: (David Waltermire): We should advertise.