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: 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.