SACM @ IETF 101 (London) Thursday 22 March 2018, 09:30 - 12:00 GMT/UTC Location: Richmond/Chelsea/Tower =================================== (remote participation via meetecho) 1. Administrative and Agenda Bashing (Chairs, 5 min) ========== Note Well, Note Takers, Jabber Scribes, Agenda Bashing No Agenda bash. The chairs provided a summary of the WG. Q: (Inacio) To the WG ... How many people have read the terminology? [Not many] Q: How many are willing to review the terminology draft. A: About 6 or 7 Sincere thanks were extended to Kathleen Moriarty as the outgoing AD. 2. WG Status (Chairs) ========== Charter Update https://datatracker.ietf.org/doc/draft-ietf-sacm-terminology/ Status: SWIMA is in the queue now;, terminology draft is still in the works team meeting weekly resolving ~30 issues documented (Henk notes there are more undocumented) 3. Hackathon Update (Montville/Munyan) ============== https://github.com/CISecurity/Integration Munyan presented on the SACM activities during the Hackathon. Frank: (on slide 2) Why did you include so many methods of collection? Was it to test that the architecture would work for collection? A: Trying to see if system characteristics can be collected from different sources and published over XMPP. Frank: Interested in the IPFix aspect. Nancy: XMPP-grid shows teh agility of the XMPP-grid in carrying information. SACM doesn't have to use all of this felxibility. Shariff: Doesn't assume the agent is on the endpoint. A: The solution is flexible to no require an agent on the endpoint, but in the hackathon we had one. Henk: This is why we have so many data acquisition methods. At some point they get to the "collector", which then communicates with XMPP grid. We can use interfaces that already exist on the endpoint. Chris: At the hackaton, many questions about which XEPs to use came up. Which were used? A: Slide 6 provides a list of XEPs. Ad Hoc commands: allows the orchestrator to invoke commands [couldn't keep up with the talk track on what each XEP does.] Hope to continue hackathon efforts to keep refining the approach. 4. Software Inventory Message and Attributes for PA-TNC (Fitzgerald-McKay) ========== https://datatracker.ietf.org/doc/draft-ietf-sacm-nea-swima-patnc/ No questions or comments on the status. 5. Endpoint Compliance Profile (Fitzgerald-McKay) ============ https://datatracker.ietf.org/doc/draft-ietf-sacm-ecp/ Shariff: We are looking at the orchestrator pulling data from the repository. Jess: Asset inventory should not be seperate from security. Shariff: We care about coverage issues, and not finding a device indicates a security problem. Jess: External security tools are evaluators. Shariff: a remediation box is missing on the ECP diagram slide. Jess: a remediation capability is an examplke of an evaluator. Shariff: On the left of the diagram we are concerned with threats, and on the right we care about the remedy. Jess: We need help on adding yang-push to the draft, which was requested by the WG. Eric Voit: I will help along with my colleague. Next steps: UPdate draft. 6. Concise Software Identifiers (Waltermire) https://datatracker.ietf.org/doc/draft-ietf-sacm-coswid/ Waltermire provided an overview of the changes made in the -03/-04/-05 revisions of draft-ietf-sacm-coswid. Q: (Frank Xia): In this draft you use CBOR as the wire format. Do all formats in SACM use CBOR. A: (Waltermire): This draft and the choice to use CBOR only covers this the SWID representation. There is an XML and CBOR format. Comment: (Henk): The freely availible XSD from ISO has curious features. Comment: (Sharrif Mansour): If an organization uses the ISO version of SWD A: (Waltermire): If an organization is using both CBOR and XML, there would be new tooling required. A: (Mansour): To avoid complexity. Can SWID clearly define which version is vulnerable to CVE A: (Waltermire): This is a use case of NIST with the National Vulnerability Database A: (Waltermire): SWID vs. CoSWID will use different containers. Signatures won't be compatible. The data will be interchangable. I've published a tool to convert. A: (Mansour): This complexity detracts from adoption. Per slide 5: Q: (Waltermire): Are there any concerns with removing Appendix B (firmware extension) and creating a seperate draft to allow syncroninization with SUIT? [no objections voiced] Q: (Waltermire): Should it be a WG document [various discussion with chair] A: (Waltermire): It will be posted as individual draft. Per slide 7: Q: (Mansour): I sit on the OWASP board to help. This seems to be at a higher layer, have you considered BDD that has domain specific language that has an english-like expressions; there are a few orgs looking at these. They may be able to address the inventory level W: Roman: are we talking about creating an agnostic mapping of SACM to let them go to CBOR or JSON W: would be 2 drafts: xpath to cbor/JSON and 2nd for Roman: benefit to survey what is out there and get help from other working group but not in scope for SACM W: need something @SACM and looking around and not found a good solution, but can get input if others exist Henk: there is Yang CBOR draft that has Xpath expression, its not a complete set of what's needed, but can be a reference W: want more than a reference, but something that can fit needs Henk: there could be something and have expertise W: what to do? Karen: start a draft and see where it goes and find roadblocks W: will add text as appropriate and then will try to look at separate drafts to address gaps Notes on BDD Frameworks and the DSL Language (Gherkin) http://jbehave.org/ https://automationpanda.com/tag/bdd/ Per slide 8: Q: (Waltermire) Are there any concern with taking the described actions? [none voiced] Next Steps: Document updated in next month. Then ready for WGLC with pieces removed for individual draft as discussed above. 7. ROLIE Core and ROLIE Software Descriptor (Banghart) ============ https://datatracker.ietf.org/doc/draft-ietf-sacm-rolie-softwaredescriptor/ Stephen thanked the WG for their help with getting RFC8322 published. slide "media type / format questions" incorrectly references application/swid2015+xml 8. Security Automation and Continuous Monitoring (SACM) Architecture (Montville/Munyan) https://datatracker.ietf.org/doc/draft-mandm-sacm-architecture/ Montville introduced another SACM architecture draft, draft-mandm-sacm-architecture, Q: (slide 3) What does "at odds" mean? A: (nancy) These architectures are an instantiation of a SACM architecture, not THE SACM architecture. A: (Jess): XMPP and ECP are solving different aspects of the "SACM problem". XMPP-grid was moved to MILE since it solved problems there. XMPP grid can solve SACM issues. We need an architure that defined a SACM solution that addresses all of the problems we are facing. Bret: At the lightning round, Mathew from Matrix.org might be interesting here. Matrix has some adoption and may be worth looking at. Shariff: Some needs use pub/sub, many developers use REST instead of XMPP. Comment: (Waltermire): The posture manager consolidates what is being tasked of the end-points. This was an early use cases. It is easy to overload the endpoint if too many nodes ask it questions. A few things concern me about these diagrams. I could see hundreds of different devices asking questions of the endpoint. How do we address that in the architecture? A: (Montville): Not sure if this applies in all use cases. A: (Shariff): We are also concerned about this situation. We are adding a lot of logic into the orchestrator to prevent this situation. A: (Montville): Agreed, for an organization of your size with millions of end-points, this is a concern. It might not apply fot all organizations. Dave Cricland: XEP-115 can support a design pattern that address endpoint issues. Adam: Just because the endpoints are on the same network, it doesn';t mean that they all need to communicate directly with each other. We need to sort out what should be able to communictae with what. Karen (as chair): How do we move forward with an architecture document? Dave Cricland: There are existing technical solutions at the protocol level to many of the problems we are discussing. Jess: Much of this is the same as ECP with the extra XMPP information being the big difference. Perhaps work can be done on ECP to address this gap? Henk: The previous architecture had a workflow, but this does not. Its difficult to proceed without understanding the workflow. I don't know how to build this solution. This architecture show where we are today, but doesn't provide guidance on how to assemble a solution. Shariff: A solution might be just one box. The data model is a challenge regarding how devices comminicate with each other. [didn't get the conversation with the chairs about how to move forward with the architecture. May need to go back tot he recording.] 9. YANG subscribed notifications via SACM Statements (Birkholz) https://datatracker.ietf.org/doc/draft-birkholz-sacm-yang-content/ Henk: I needs to understand the architecture to figure out how to update this draft. A bunch of work has been done (e.g., container, yang models, CoMI, etc.) We also need to figure out how to combine multiple collection methods. Once the architecture and collections are better understood, we can update this draft. 10. Data Model of Network Infrastructure Device (Xia/Lin/Dong/Zheng) - Control Plane Security - Management Plane Security Baseline - Data Plane Security Baseline - Infrastructure Layer Security Baseline https://datatracker.ietf.org/doc/draft-dong-sacm-nid-cp-security-baseline/ https://datatracker.ietf.org/doc/draft-lin-sacm-nid-mp-security-baseline/ https://datatracker.ietf.org/doc/draft-xia-sacm-nid-dp-security-baseline/ https://datatracker.ietf.org/doc/draft-dong-sacm-nid-infra-security-baseline/ Stephen: Thank you for doing what the WG asked by investigating what might be provided by other existing yang models. Do you plan to coninue this investigation? Frank: Thanks. We have completed our investigation. Stephen: Not sure it makes sense to integrate tightly with the rest of SACM. Publish in support of the yang community. Chris (as chair): How many non-Huawei have read this document? A: two (Henk,Stephen). Clarifying: non-huawei software vendors?, A:zero Frank: We believe other vendors will have interest. Karen (as chair): (echoed Stephen's last statement.) Kathleen: (Referring to the overview slide) Lawful interception interface, can you tell me about that? That might cause some controversy Frank: Some of the content is taken directly from the Huawei whitepaper, not all of it needs to be standarized Kathleen: Thanks, just trying to save you some headaches. Karen: 5 minutes to discuss where the group is going. I think we've had a productive meeting, one question, do we need a virutal interim. Hum if you want one. (a number of people hum). Alright, we will schedule an interim meeting. Dave: Can we schedule the iterim to not conflict with RSA Nancy: We could do a face2face at RSA Adam: We will be at RSA, but sacm would be second priority Jess: If there is a meeting at RSA can there be a remote option? Karen (Chair): Yes there will be a remote option if we go down that path. Bret: RSA is a bad time to schedule things for people that work with vendors. Kathleen: Anyone planning to promote this work at RSA? (Adam M raises hand) RSA would be a great place to socialize this kind of work, the people there would care about this. Bret: (Agrees with kathleen) We have a PR problem, we need to figure out how we're going to socialize this stuff. Trying to talk to people about YANG modules doesnt work. We need elevator pitches to share with people. I go around and talk to CTOs at each booth and socialize ideas with them. We need some packaged ideas and pitches that we can share with people, that would be helpful. Shariff: We would love to help (as board member of O???). We have a number of meetings where we present information. Anyone can present work at some of these, it could be a great place to socialize some of this work. Karen: Virutal iterim and a meeting at RSA, will communicate to list. 10. Way Forward - (Chairs/WG) ================================================ Sherif Mansour's Notes on SACM Connection between the Orchstrator and Repository this allows the org to switch tools (security assessment tools) without having to perform additional dependencies, as long as the orchstrator send the data to the repository in a standardised format then it is fine. Consider the use of BDD Frameworks and the DSL Language (Gherkin), for simplicity and ease of adoption, above the various layers of formats underneath SACM - Recommend that for the Orchstrator and Reposirory for easier analysis. Plenty of work has been done on BDD frameworks in the QA and software engineering world that there is plenty of code/mapping already built http://jbehave.org/ https://automationpanda.com/tag/bdd/ Feedback on Terminology 1) Do we distinguish between the different types of findings? Example Vulnerability/config vs. coverage vs. Control weakness/deficiency vs.a change in security context (breaks security design) Why? Those have different resolver vs. owner groups. Example a weakness in a security tool allowed the exflirtation of data x from asset y. The resolver is the owner of the security tool even though the owner of the asset is someone else. 2) Does it take into account ephemeral host (assets/workloads) that are based on an image. Need to map a vulnerability to an image, the specific date/image version (since vulnerabilitys can be discovered post assessment, and its important to do that mapping post assessment.) Secondly to map the runing workloads to the image, and the image to findings. Finally to map the resolution to distinguish between owners of an image (those that need to apply a fix) and workload owner those that need to use the latest image. 3) Objects: Mapping a threat (or attack vector) to a finding to a fix (remedy/patch) Resolver vs. Owner Reference data (Asset Inventory/Identities/NVD Repo) GRC/Standards/Policies/Procedures - to findings Use cases: As a security team we would like a standardised model to map a threat to a finding to impacted assets and finally to a remedy(a fix), in order for us to effectvely assess, evaluate and remediate security findings. Other use cased TBD - writing them up Feedback of Architecture, focused too much of the how vs. the What. A simplified data model to show the end to end mapping and use cases would be helpful And a implementation architectre should come after various itternations of design. SACM Statement architecture - Signle sheet music Example of simplified evaluation: https://www.newswire.com/news/t-e-n-announces-2017-ise-north-america-award-winners-20061755 (search for VxSx). =================================================