Minutes for SACM at interim-2014-sacm-4
Security Automation and Continuous Monitoring
||Minutes for SACM at interim-2014-sacm-4
SACM Virtual Meeting Meeting
Wednesday, September 10, 2014, 12-2 PM EDT
1 logistics, note takers
2 WG Status
3 SACM Information Model
4 SACM Architecture
5 SACM Requirements
6 XMPP Grid Protocol
7 Way Forward
Participants: Josh Lubell, Dan Romascanu, Brant Cheikes, Charles Schmidt, Danny
Haynes, Gunmar, Cliff Kahn, Brian Ford, Thomas Joy, Lisa Lorenzin, Matt
Hansbury, Nancy Cam-Winget, Takeshi Takahashi, Dave Waltermire, Jim Bieda, Ira
McDonald, Jarrett Lu, Adam Montville, Kathleen Moriarty, Jessica
Fitzgerald-McKay, "Call-in User 6", Henk Birkholz, Dave Misell, Atul
1. Josh Lubell, Brian Ford taking notes (Big Thanks!)
2. WG Status
Nancy - didn't have time to update Architecture. Suggest spending more time on
Informational Model during this meeting. Question to group: Should we cite XMPP
references in the SACM spec or in the XMPP Grid Protocol spec?
Dan R - WG status: use case document on way to IESG. Any IPR that needs to be
disclosed? If so, please disclose. Protocol and Info Model milestones have
slipped. Since Toronto meeting, Architecture and Info Model behind "way
3. SACM Information Model
Lisa L - this doc is a merger of work from TNC and from Waltermire/Watson.
Limited scope to info model. Moved out-of-scope items to appendices, which
should be moved to other docs as appropriate (e.g., Architecture, terminology,
Dan R - What is the scope of the info model?
Nancy - Described in Problem Statement (sec. 2 of document). Info model
describes abstractly components and interfaces. We have a problem statement
that is a scope of work. We have use cases. The solution we envision in the
arch doc is composed of 1 or more protocols and one or more data models.
The scope of the information model is to describe the structure of the
information carried to realize the assessment.
Dan R - Info model should be an abstraction of data model
Lisa - sound good. Should be incorporated into document. [walk-through of
Fig. 1 from document. Lisa/Nancy discussed extensibility of relationships. Is
the model flexible enough?]
Gunnar - Is there any mechanism for attribution.
Nancy - There needs to be agility to provide for different relationships
Discussion about the agility of the information model.
Cliff - Required use of ASCII art and need to fit it all on a single page
forced me to leave stuff out of the diagram.
Dan R - This diagram needs to be consistent with the architecture.
Lisa - Good point. Some work needs to be done on Architecture to make
consistent. In the mean time, the simple diagram in the Architecture document
Dan - agree
Lisa - looking for feedback on whether new elements or new characteristics for
additional elements needed
Dan - how does the Graph Model (5) related to the Info model (4)
Lisa - sect 4 is about organization. Sec 5 is about enumeration
Dan R - We may want to talk about the graph representation as an appendix or
separate document that explains the usage of the more complex structures. I
dont think we need to list all the elements, instances and attributes and
representing them through the graph model. Maybe we need an example or two.
Im still fighting whether graph model belongs here as an appendix or a
Jim Bieda - Graph model seems like an implementation choice. Is it a should or
a must or an option.
Lisa - Open question?
Jim - there is an opportunity to work this for the next call and meeting.
Dave W - if we don't use graph notation in this document, then what should be
Dan R - maybe UML. Also, maybe section 6 should be merged into section 5.
Lisa - Looking for helping writing section 6 without graph terminology.
Lisa ? Appendix C is material that should be considered for inclusion into the
arch and use case docs.
Section E discussion ? Where does this belong??
Ira - Section E discussion on endpoint attributes
Is this implementation guidance or best practice?
Dan - Do we need to spend time on other documents??
Lisa ? We are done with content here.
The editors have worked on this combined info model outside of the WG because
having more people involved became unwieldy. They are looking for input. Lots
of work still to be done. Does anyone want to join the weekly calls?
Dan - There are a few key questions, big questions which run through
discussions like: what do we do with graph models ? what do we do with work
flow ? 4-6 big questions. I propose staring a thread for each big question on
the mailing list.
5. SACM Requirements
Nancy - made minor fixes to old document. Partitioned "agility" requirement
into multiple, more granular requirements (12-16). This was discussed at the
face-to-face. Added sec. 2.3 (Requirements for the Info Model)
Lisa - I think we have consensus that operations and workflow are not part of
the info model.
Ira - there should be a "requirements for the architecture" section. Also,
don't like "General SACM requrements" as a title.
Lisa - Disagree with latter. There are requirements that are part of the SACM
problem space but don't apply specifically to use cases, info model, etc.
Lisa - how about "SACM Requirements" instead?
Ira - that's fine
Dave W - some of the "general" requirements look like they belong in more
Nancy - please send your feedback to the mailing list.
Dave W - if requirements to be renumbered, should retain old number until
documents that reference the Reqts doc are updated.
Nancy - should XMPP terminology definitions stay in the Grid Protocol draft, or
should they go in the Terminology doc? [consensus to keep as is for now]
7. Way forward
Dan R - We have opportunity for another interim before the Honolulu meeting.
Suggest having one in early-to-mid October. Propose Reqts, Arch and Info Model
docs be updated beginning of October prior to the Interim.
Dave W - I'm not available week of 10/6 or week of 10/13, but please proceed
Dan R - Question to editors: should next versions of the Info Model and
Architecture docs be SACM WG items? Means content has to conform to IETF rules
and processes. But document doesn't have to be stable to be a WG item. Call for
consensus to be issued to mailing list.