================================================ ================================================ IETF 92 SACM Session I (9:00 AM CDT - 11:30 CDT) March 23, 2015 Dallas, Texas, U.S.A Minute taker #1: Danny Haynes Minute taker #2: Nancy Cam-Winget Jabber scribe: Chris Inacio ================================================ Agenda Bashing (Dan Romascanu / Adam Montville) ================================================ [Dan Romascanu]: The information model discussion will take less time than allocated because there hasn't been any changes since the last virtual interim meeting. We can allocate the time to other discussions. It was noted that we have one transport protocol (XMPP-GRID), but, are not in good shape although we expect more to come. [Adam Montville]: Can we move the scope discussion after the use cases discussion as it may impact our other discussions today? (There were no objections so the agenda was updated accordingly.) [Dan Romascanu]: The agenda for Friday is still open for changes. It will include discussions by liaisons from the Open Group, ETSI, groups within ETSI, and 3GPP. ================================================ Working Group Status (Dan Romascanu / Adam Montville) ================================================ [Adam Montville]: The use cases draft is scheduled for a tele-chat for the IESG and is in progress. A few things will be updated. Dave will cover those in the use cases discussion. We are still not doing that great on milestones, but, I don't think that is a surprise to anyone here. Everything here is just left over from the last meeting. This week, I would like to talk with a bunch of people in order to get feedback on what our milestones should be and a reasonable schedule for those milestones. Then, on Friday, we will have a proposal for a new set that we can discuss. We will also have a scope discussion this morning which may impact some things, but, it should be good. [Dan Romascanu]: Any questions? (There were no questions) ================================================ Use Cases (Dave Waltermire) ================================================ [Dave Waltermire]: The use cases draft is currently going through the IESG review process. The latest changes weren't ready before the submission deadline for IETF 92, but, they will be submitted to the working group after this meeting. For this session, I have a version with tracked changes and would like to go through a few key items. The nature of Warren's changes were mostly editorial in nature, however, he did want the draft to mention that the data collected from an endpoint could be used by a malicious actor to know what endpoint to attack. This piece of feedback was addressed in the draft by adding some text to the security considerations section. This new text effectively describes an anti-use case. Is there any feedback on the proposed text? Any objections to the proposed text? [Merike Kaeo]: I like it as an initial start, but, would like to think through it a bit because I think being more elaborate may help readers. It is kind of generic, and it may be okay generic, but, I think seeing one or two more sentences would be good. [Dan Romascanu]: This document is in working group last call and these comments are from the Security Area directors. After feedback is considered, it will be sent to the IESG. [Kathleen Moriarty]: I have already had a ballot put on it and the IESG members have already had a week to review this. The next tele-chat is on April 9th. [Dan Romascanu]: Please make any changes available within the week so the IESG members don't get a different version with considerable changes. [Dave Waltermire]: Merike, what additional details would you like to see? [Merike Kaeo]: ??? [Chris Inacio]: I am concerned about the last sentence. Does it mean that in the architecture document that we should be describing how to armor a database on an endpoint box in the security considerations section? [Dave Waltermire]: I was thinking that we should say that you have the necessary access controls, etc. [Chris Inacio]: Physical security? Because if you can get your hands on the keyboard of the box, you win, right? So, where do you draw the line? [Dave Waltermire]: Physical security is outside of the scope of SACM. [Kathleen Moriarty]: Physical security is out of scope for the IETF. [Chris Inacio]: I don't disagree, but, what does it mean for that last sentence such that you kind of punt? That is my only concern. [Dave Waltermire]: Do you have suggestions on how we can revise the text? [Chris Inacio]: The security considerations get reviewed in the security directorate and it is not clear to me that this sentence, in this document, helps the security review or the implementation. It is not clear to me what it would imply if I was looking at those other documents as to what would be sufficient security. I'm just not sure about that last sentence that the security considerations of the documents must describe methods. After reading that last sentence, there is no reasonable response that you could be expected to make. If I am someone deploying that, I am not sure how that helps me. [Kathleen Moriarty]: Did this come from one of my comments? [Dave Waltermire]: No, it was from Warren. [Kathleen Moriarty]: This is more to help the working group so your later documents include this, but, I have made such changes, in other areas like routing and operations, to framework and use case documents to guide the working group and give them clues to what we would be looking for in subsequent documents. You are not going to go into detail, in a draft, on those points. You are just going to make high-level statements that talk about access control, authentication, etc. If it is not part of you protocol, you just want to make a statement that your infrastructure should be protected for the level of data that is on those systems and point out if there are privacy concerns or security concerns with compromise, could lead to reconnaissance, etc. There is tons of data that could be used for later attacks so it is really just to put those statements in. The value is not necessarily for those of us in the room, but, for people who are going to subsequently read these documents. So, some operator out there who doesn't know as much as in the room so they can be clued in that I need to protect the infrastructure because there are attacks on the infrastructure rather than the communications which is really what gets targeted. It is really a lot easier. [Jim Schaad]: I have problem with the term "anti-use case" because it may say that I don't want to implement any of this stuff to begin with, but, one of the things that I am wondering is can we include a few examples of types of attacks that we are looking at. For example, passive monitoring, database access, things like that so we have a list of attacks that we are thinking of that we need to look for when reviewing the other documents. [???]: What about "consideration" or "concern" instead of anti-use case? [Jim Schaad]: Much better. [Merike Kaeo]: Dave, I will help wordsmith something and that is exactly what I was thinking. Having something like this could be circumvented so that all the other documents can think through and maybe a few more sentences could help. [Dan Romascanu]: We adopted the model to use GitHub. We want to have this type of comment entered and then followed up on. I think it should be the job of the individual editors to track these issues. [Dave Waltermire]: Since the use cases document is so far along, I didn't think to put the issues in GitHub, but, I agree it may be useful to do it for IESG feedback. [Dan Romascanu]: I was thinking more in general for the other documents to capture the feedback which can then be worked through. It would be good for others to enter comments into the tracker as well. [Kathleen Moriarty]: Since there is a text change and there is a ballot on it, make sure that the revised text is sent to the security area review so that we can let the others know that more changes are coming. [Nancy Cam-Winget]: Just to clarify, do you want the issues in the IETF tracker or GitHub. [Dan Romascanu]: GitHub. ================================================ Scope Discussion (Adam Montville) ================================================ [Adam Montville]: As part of an Endpoint Identity Design Team (EID-DT) meeting, we wanted to talk about endpoint classes which led to wanting to have a scope discussion. The main focus of our charter is that we want to be able to collect and verify security configurations and need to develop a set of standards for endpoint posture assessment and transport protocols for the data. During the EID-DT meeting, we came up with four categories of devices: 1) Traditional (workstation, server, etc.) 2) Mobile (cell phone, tablet, etc.) 3) Network infrastructure (router, switch, etc.) 4) Constrained (ICS, IoT, etc.) In the EID-DT, we have been considering all of these things, but, would we want to pick a few of these on a first pass and then come back to the others. What do others think the scope should be? [Dave Waltermire]: We are not so much trying to exclude work, but, rather focus on a specific technology and try to limit our attention to what we work on as a way to advance the work more rapidly and pick up other things down the road as it makes sense to do so. [Adam Montville]: Yes, think of it more as increased focus. [Raj Patel]: I understand the need to focus the scope to get things done, but, I think it is critical that we work on ICS, etc. and tend to believe that we should not just limit scope based on these things. [Bob Moskowitz]: I think you are more thinking about prioritizing. When I see constrained, I work with vendors that see 30K of code space being a lot and getting to them to talk about security is challenging. It is going to be more of the coordinator of getting that data from the devices rather than the devices themselves. It will be interesting to see where this goes, but when I see this, a lot of flags go up for me. [Jessica Fitzgerald-McKay]: I think it is wise to focus on the least common denominator, but, want to focus on core enterprise use cases and the devices they support and then build out. I don't think constrained devices are on all enterprises so we want to focus on that and build extensibility into it to address these other use cases later. [Kathleen Moriarty]: I am concerned about constrained given others working in this area and their approaches are often very different. There are different languages, size requirements, etc. There are 5 different levels for IoT which level would we be working at. It might be good to do constrained devices separate and have a charter item added to address it after we do these other things. [Chris Inacio]: This is in response to Jessica's comment because I didn't understand what it meant. The other part is if we just say we are going to focus on Windows desktops and that makes up 80% of an enterprise, what does the data and the implication of collecting that data tell the potential end user of what you accomplished? How much of the attack surface have you covered? How do you express that? What is the end goal of SACM? [Adam Montville]: The end goal is to cover all of these categories of devices. [Chris Inacio]: How do you express what you accomplish if you narrow the scope and translate that into something for end users? [Adam Montville]: If we don't increase focus we may fail. [Jessica Fitzgerald-McKay]: Agree, we need to focus in order to narrow the attack space and accomplish things. We can safely say all enterprises have traditional endpoints and network infrastructure endpoints and start there to move the ball forward. [Raj Patel]: An enterprise could be an automobile assembly line and when you look at their IT infrastructure, there are lots of products and things are interconnected and I think here the work would be relevant. [Dave Waltermire]: I think we should focus on client/server environments, network infrastructure devices as far as assessing the software/hardware inventory of those devices and configuration information. If others are interested in these other spaces, are there volunteers to work and further that space because if we don't have that participation, we can't move that area forward. [Bob Moskowitz]: I second that we should focus on the enterprise use cases first. I have a lot of experience with constrained/IoT and they have different lifecycles. We should consider them later. [Chris Inacio]: To clarify, I know traditional systems are my Mac/PC on my desk, but, what about devices like a Xerox printer with a full PC in it although without a keyboard and monitor. I think that would be constrained device right. [???]: Phones on peoples' desks as well. [Chris]: I am saying it is a to-do later. I am just clarifying because a mobile phone is more of a constrained device than my printer with a full PC in it. [Dan Romascanu]: IP phones have the same configuration. [Nancy Cam-Winget]: It is not so much the devices, rather, the environment in which they are being used. Keep in mind that auto manufacturing and other automation there are still going to be hosts that have similar configurations. They have human interfaces, are still running Windows, you can have posture, but, the lifecycle is different. The process flow is different. [Chris Inacio]: I can't change the software on my printer so that is why I considered it constrained. [Nancy Cam-Winget]: Let's not use the word constrained, rather, the deployment scenarios, usage, and lifecycle flows that we are going after. In our charter, we were very explicit in that we are focusing on enterprise and even that is kind of fuzzy, but, maybe we need to tighten the scope of the use cases to make forward progress. The requirements have specific things around scalability, agility, etc. and these are things we need to check against. I am in IoT and can help review to make sure that, while we focus on the enterprise, we can extend to other deployment scenarios. [Bob Moskowitz]: You don't have to replace your printer, in your office, often, but, these vendors are coming out with new printers every year so they may be interested in that too, but, we put our scope to the enterprise and whether or not a printer is constrained, I think there are good definitions around something in that system is highly limited and just because it does not have a user interface does not fit any definition of constrained. [Chris Inacio]: So, it comes down to a practical question as we work on our endpoint model, is the printer out of scope? [Adam Montville]: I don't know the answer, but, how many people are interested in having this discussion? I would like to propose that we have a side meeting focused on this issue and report back on Friday. [Dan Romascanu]: What will be the output of this meeting? Does it impact the milestones, charter, etc.? What is the end game? [Adam Montville]: Define the four categories with definitions and examples and maybe some input on milestones and the charter. [Dan Romascanu]: There may be another process that we need to follow if we need to re-charter. [Kathleen Moriarty]: We can prioritize existing milestones without re-chartering. Make sure that we send the design meeting to the mailing list. [Dave Waltermire]: We want to get people to commit to doing some work and getting these things done. Submitting protocols, contributing to the information model, etc. I would like to see this reported on Friday and getting a list of people. ================================================ Information Model (Dave Waltermire) ================================================ [Dave Waltermire]: Due to constrains on other work, we did not have a lot of updates since the last virtual interim meeting, however, we have been doing a lot of work in the EID-DT and that is captured in the notes. We have also started to discuss some test cases focused on different types of devices, interactions, attributes, and other considerations for the different environments to help identify the attributes that we will want to request in the data models. It will also be used to filter out those attributes that we don't think are necessary. Last EID-DT meeting, we talked about one test case focused on the traditional client/server endpoint and the types of interactions and the identifying attributes that would be needed for endpoint identity. These test cases will be used to drive updates to the information model and drive the design team to a close. I would like to propose that we have an engineering meeting to talk through this. [Dan Romascanu]: To better define the scope for this week's work, we will want to define the list of test cases and a list of the minimal set of identifying attributes. We should make sure everything goes on the list. There has also been some discussion on the list about the identifying attributes and we should make sure to address those issues. [Dave Waltermire]: I think those issues have been specifically around software identification which is another identification scope and at a different level than endpoint identification. I think there was a proposal on the list to either create a new design team or expand the scope of the EID-DT. Do you have any thoughts on how we may proceed there? [Dan Romascanu]: No, that's fine. I am just trying to put this in the context of previous discussions that we had and we just may want to prioritize first on the identification of an endpoint and then the identification of software in a later phase. [Bob Moskowitz]: In listening to this discussion, TCG IF-MAP may be worth looking at and how they classify devices in terms of identity. [Dan Romascanu]: Can you send a pointer to the mailing list? [Bob]: Yes. [Dave Waltermire]: There are TCG members on the EID-DT that have mentioned IF-MAP. [Dan Romascanu]: If there is prior art somewhere else that we can just reuse, that is even better. ================================================ Requirements (Nancy Cam-Winget) ================================================ [Nancy Cam-Winget]: Show of hands, how many people read the latest version? [???]: How many changes? [Nancy Cam-Winget]: Text-wise not that much, but, I have re-arranged things. We are now up to version -04. From -02 to -03, the biggest substantive change was that I added a security considerations section. Adam gave lots of good feedback which was included in -04. I put some questions in response to Dan Romascanu's comments, but, also went ahead and put in some of the suggested changes in there. Besides that, I also went through and capitalized the MUSTs and SHOULDs where appropriate. Based on feedback, I clarified how the information model is more of the guideline for how we would propose data models and operations on data models, between -02 and -03, by changing the section from information model to data model. Some of the requirements were more for the information model itself versus the data model and some were a little bit of both so now in this revision you see requirements for both. The information model requirements are higher-level and the data model requirements are more for instantiation of the data models. Then, I separated the actual operations on the data itself into its own section. [Dan Romascanu]: Typically, the information model and data model occur in different phases so even if some of the requirements are repetitive, because the data model inherits some requirements from the information model, it is okay. [Nancy Cam-Winget]: I posed the question to you because there was some overlap between the two and I went ahead and made the changes anyways. I struggled whether to keep the operations separate or as part of the data model and it seemed like the interfaces either overlapped or not and that is why I ended up keeping the operations as its own separate section. Those were the main changes although you will see lots of relabeling, new section names, moving things around, etc., but, mostly the same. As part of the EID-DT meetings, there were some new requirements in the data model about the attributes that encompass an endpoint. [Dan Romascanu]: How far are we from working group last call? [Nancy Cam-Winget]: We are getting close. Part of me wants to force the issue by moving it to working group last call, but, the other part of me says that I reshuffled it enough that I should give more time to review. [Dan Romascanu]: Let's try to close any open issues. [Nancy Cam-Winget]: I don't think there is much more to do and I haven't received any more comments. [Dan Romascanu]: Let's give a couple of weeks to review and then move it to working group last call. [Kathleen Moriarty]: I agree with that. For those new to the IETF, if there are a lot of changes in the working group last call, we can always make the changes and do a second working group last call. ================================================ Architecture (Nancy Cam-Winget / Lisa Lorenzin) ================================================ [Nancy Cam-Winget]: In Section 2, the changes included trying to clarify the problem statement which ended up just being some editorial changes. In Section 3, in the architectural overview section, we discussed wanting to be very clear on the distinction between the two roles that the controller plays (1) the controller as a management function and (2) the controller as a controlling function for the data. We added text to make those clarifications. We talked about the roles and relabeled the diagrams so we now have "C" for Consumer and "Cr" for Controller. We now highlight roles for the management functions for the controller as well as things like authentication, authorization, doing discovery, and that there may be more than one data model and more than one transport as well as making the distinction of the controller from the data side. In Section 3.2, we added examples of protocols and interfaces, that already existed, that could be used. In Section 4, we had a lot of to-dos. We added definitions, examples, etc. We still need to make updates for collector interactions and the terminology section for the evaluator role. We also need to remove the to-dos and questions. We also tried to clarify and use control for management and broker for data. There is now a security considerations section. [Dan Romascanu]: Can I comment on the changes in the Figure 2 diagram? I believe that "C" for consumer is not consistent with "Cr" for controller in Figure 1. We just need to make sure it is consistent. [Lisa Lorenzin]: I didn't make any changes to Figure 2 except for "C" is for consumer and "Cr" is for controller. [Dan Romascanu]: But, in the other diagram, we called consumer "Cs". [Lisa Lorenzin]: Can you bring up Section 4.2.1.3? There is a to-do about examples. Should this section be removed or should it be filled in? [Dan Romascanu]: This section should be filled in with content. [Nancy Cam-Winget]: Correct. [Jessica Fitzgerald-McKay]: Why are you asking if it should be removed? [Dan Romascanu]: If we don't come up with examples, we will be stuck. [Nancy Cam-Winget]: If we are provided with examples, we can put them in. [Jessica Fitzgerald-McKay]: I am willing to write those examples and help Lisa with the changes. [Lisa Lorenzin]: I am willing to write the text, but, the working group think they should be included? [Dan Romascanu]: I believe so. [Lisa Lorenzin]: Is there consensus on Section 3 and 4? [Nancy Cam-Winget]: I think we need more review. We also need to respond to Jim's comments this week. Do you have time to do this? [Lisa Lorenzin]: Are the comments on GitHub? [Nancy Cam-Winget]: Jim's comments are on the mailing list (1/22). [Lisa Lorenzin]: Yes, I can. ================================================ Terminology (Adam Montville) ================================================ [Adam Montville]: There are three people that volunteered (Jarrett Lu, Merike Kaeo, and Brian Ford). We combined the SACM-defined terms and pre-defined terms. We reviewed the existing documents for terms and discrepancies and want to work with the draft editors to tighten up terminology and the use in drafts. [Dan Romascanu]: We should try to avoid defining terms which are supposed to be used in other parts. If we find a term that is not defined, we should work with the terminology team to define it. We may not make this document an RFC, but, it can be our reference. [Kathleen Moriarty]: I just wanted to make sure that we look at RFC4949 to make sure we are not re-inventing the wheel. [Jarrett Lu]: From the last interim meeting, I thought we agreed that if we were using a term in a draft that would be the only place that we use that term to just define it there, but, if other drafts share it, then we would define it in the terminology document? [Dan Romascanu]: That is correct. [Henk Birkholz]: While having terminology defined in individual documents, I do not mind having redundant terminology where you think you will find them - in the terminology draft. [Merike Kaeo]: We included RFC4949 and RFC5209 and I sent a comment to the working group. I am also changing the introduction to reflect that better. [Dan Romascanu]: Can we start using GitHub since we adopted it as a tracking tool? [Adam Montville]: Do people know how to add trackers to GitHub? [Dan Romascanu]: Can we get email messages to the list with issues? [Aziz Mohaisen]: Yes, we can do this right now although it wasn't originally considered. [Dave Waltermire]: Can Aziz make instructions for people in working group to use? [Adam Montville]: We should put the instructions on the wiki too. [Aziz Mohaisen]: Dan will need to confirm the email in order to be able to send to the list. ================================================ Protocols (Dan Romascanu) ================================================ [Dan Romascanu]: Is there an update on protocol submissions? [Nancy Cam-Winget]: We need to update XMPP-Grid. ================================================ Work Plan for this Week (Adam Montville) ================================================ The following meeting schedule was sent to the mailing list. All meetings were held in Terrace Room (on the Terrace Level): Tuesday 1300 - 1500 CDT (SACM Scope Part 1) 1730 - 1830 CDT (Endpoint ID Test Cases) Thursday 1740 - 1840 CDT (SACM Scope Part 2) ================================================ ================================================ IETF 92 SACM Session II (9:00 AM CDT - 11:30 CDT) March 27, 2015 Dallas, Texas, U.S.A Minute taker #1: Danny Haynes Minute taker #2: Dave Waltermire Jabber scribe: Chris Inacio ================================================ Agenda Bashing (Dan Romascanu / Adam Montville) ================================================ [Adam Montville] Given that we just had working sessions around the scope of SACM and the endpoint identity test case, the agenda will focus on that work rather than on updates of the working group documents. We will also not be having the discussion around the Open Group and SACM and ETSI M2M and SACM. [Chris Inacio]: Can we have the discussion around the work, from this week, be at the end? [Adam Montville]: That depends if the remote people that are presenting can join early. (This couldn’t be confirmed so the agenda wasn’t changed) ================================================ Work Report and Discussion (Adam Montville) ================================================ [Adam Montville]: The first discussion was focused around the prioritization of the work in SACM. We originally discussed basing this on classes of devices (traditional, network infrastructure, mobile, and constrained), however, after discussion, we agreed that basing on collection mechanisms would probably be the best way to do this and drive the information model to completion. We also had some discussion around state (e.g. configuration of an Apache server) versus behavior (e.g. running configuration of an Apache server) and decided that we should focus on checking the actual state of a piece of software, hardware, or configuration setting. We definitely need to drive the information model home so that we can start working on data models. We agreed that we needed the following models before we can move the information model to working group last call and the IESG. *Identifying an endpoint *Identifying hardware inventory *Identifying software inventory *Describing the available endpoint attributes for a given hardware or software item *Describing the observed value of an endpoint attribute for a given hardware or software item We also have this notion that we have a client on the endpoint that provides this data or we interact with a service that interacts with that client to get the data. This client is not necessarily a SACM component installed on the endpoint. [Dan Romascanu]: Do you see these models as separate deliverables or part of the information model? [Adam Montville]: I think my impression at this point is that these sub-models would be part of the information model or we could have separate models. [Dan Romascanu]: Are there any advantages or disadvantages to having separate models or a single comprehensive model? [Adam Montville]: I think that is yet to be determined. Does anyone have any opinions on this? [Jessica Fitzgerald-McKay]: I see a lot of value in breaking it down into smaller separate models. From what we described here, there are pieces that exist and we can pull in and standardize on. Others will require a lot of work for us. I think if we break it up into separate models, it will help us progress faster. [Jim Schaad]: I am trying to find out what you mean by describe endpoint attributes? Is it the set of attributes that could be on an endpoint? Or, is it the set of attributes that have to be on this endpoint at this date and time? [Adam Montville]: I would say both. [Kathleen Moriarty]: I just want to second Jessica because reusing existing work is going to help you tremendously especially for different device types. [Dave Waltermire]: I would also like to +1 what Jessica said and then address Jim's question. I think we really need two things: (1)A list of all the available attributes that we can collect and evaluate for a given endpoint whether or not they are defined or defaulted or whether or not that mechanism would work on a given endpoint because 9 times out of 10, we are not going to be interested in collecting the full information available on the endpoint we are generally going to be interested in some subset of attributes that are relevant to the organizations use so we need to be able to select from the menu of attributes that we want to collect and evaluate. (2)A method of representing the actual values that exist on the endpoint for those attributes. I think we really need both and both are two slightly different things. [Jim Schaad]: So, what you say about the values would be the last thing? [Dave Waltermire]: That's right. [Jim Schaad]: Is this a list of settings for which there will be observed values? [Dave Waltermire]: That is correct. [Chris Inacio]: No, we need to pop up a level. We should not try to figure out all the data that we could possibly care about, rather, we should understand that as the requirements are written and now, and as a way to possibly make progress, is to accept that there are lots of standards we care about (STIX/TAXII, IPFIX, OVAL, IODEF, etc.) and just focus on the key elements and identifiers for everything going from the endpoint to collector to the repository, from the query capability to the repository such that those things can operate on the data and know what data is available and that data can be in any of those formats unless we are trying to develop a common format which I don't think we should do. Whatever vendors have, let's support and work on interoperability layer that lets' them communicate. [Kathleen Moriarty]: By interoperability layer, there are translation engines that are used a lot. Is that what you mean? [Chris Inacio]: If you wanted a good product in the market, you would need to build that, but, I am not suggesting that we have to specify such a thing. [Kathleen Moriarty]: Okay. [Chris Inacio]: We need to be able to define enough of the information model and data model to be able to define the metadata to tie things together. [Kathleen Moriarty]: I think this is very hard. At EMC, we have to worry about storage and the most popular interface is a RESTful interface with DTMF CIM and SMIS. To put on other interfaces would be tough, Nancy is dealing with YANG modules, and the list goes on and on. This is really hard to support everything. [Dan Romascanu]: We should not forget that we are talking about the information model here which is higher level and protocol independent while the interoperability will be measured at the data model level with specific data model languages. [Kathleen Moriarty]: My point is that we are checking for completely different things. [Nancy Cam-Winget]: I think I agree with Chris. The information model is the abstraction of different types of information and operations and how it works. There will be many data models. Data models are another level of abstraction and it is up to the implementers and can be optimized. So, while I like the focus on these lists of things, I want to make sure that we focus on the abstraction to allow for the STIX, TAXII, etc. [Dave Waltermire]: I agree with all of this and I think this is some of what is meant by all this. We are not saying that we are going to enumerate how you check for minimum password length for Microsoft Windows or Red Hat Linux or all the other variations on that theme. How do we generalize a way to record and instantiate a model that would allow for some interoperability? I think that is what we are trying to talk about here both at an information model level and a data model level. [Chris Inacio]: I don't necessarily think we want to create interoperability at the data model. It is not clear to me that we need to define how to identify software/hardware inventory, etc. We need to understand that there are code points. We can have SWIDs, we can have CPEs we should have an information model and data model that allows the exchange of those data points between SACM components just allow different data models and how does that interoperate? How the implementer makes it interoperate is up to them. [Adam Montville]: We need to focus on higher level layers so that we can map between different data models. [Kathleen Moriarty]: Assuming you are pulling all data into one thing. There is data that comes from different sources where you need to bring it together to translate it all. I don't think we need a common language. Vendors have proprietary ways of doing things. How do we enable them? [Adam Montville]: That is the problem. We don't allow vendors to do this. [Kathleen Moriarty]: What about all routers are compliant? [Adam Montville]: That is above SACM. [Dave Waltermire]: You cannot correlate that across endpoints. We need to use different tools across endpoints and we end up with different results. That's why we need to define the endpoint identity work. [Nancy Cam-Winget]: Do you have an example? [Adam Montville]: There is an example on list by Joe Wolfkiel. [Nancy Cam-Winget]: ??? [Lorenzo Miniero]: This seems like an SNMP problem. We could just extend it to support security. [Kathleen Moriarty]: Is YANG the next SNMP? [Dan Romascanu]: You are really thinking of MIB modules in SMI. Working to transition from binary representation to XML representation. There are levels of data models and we need to define information models in a platform-agnostic manner across traditional, mobile, network infrastructure, IoT, etc. Basically, we need to focus on these information elements and we may decide that we may want to use SMI/MIB/SNMP. [Lorenzo Miniero]: ??? [Dan Romascanu]: There are agents collecting different elements. [Chris]: Let's see if I can reframe. Think of identity (endpoint, software, hardware, etc.) as a code-point that needs expert review for inclusion. Let's say CPE, SWID. What are the minimum things that we need? [Dan Romascanu]: In my model data formats and protocols are separate. [Chris]: We need model to create qualifications to decide if a data model fits in. Defining this at the information model layer is what we need to do then we are done. Move on. Determining sufficiently is what we need to do, rather, than trying to drive way to far down. [Adam Montville]: Agree, we need to address this in the data model. If some new data model comes in, we may need a mapping of the data model too. [Chris]: If a data model doesn't support everything, we don't have to do anything. It is up to the person with the data model to prove it addresses the IM. We don't need to go any further. [Adam Montville]: May need to in some cases. [Chris]: No. Don't go any further. [Dave Waltermire]: Agree with most, but, missing. Is that aligned with your thinking? [Chris]: No. Our information model tells us what data and what format so it can be acted on. [Dave Waltermire]: I don't understand. [Chris]: The data model could be CPE, OVAL, etc. and we just need to define the SACM layer. [Dave Waltermire]: Let's say we have "Office 1.2.3 Build 1" in CPE, "Java 1.2.3 Build 8" in SWID, and "Tool XYZ". Is that what we want to do? [Chris]: We are done with the data model when we can ask questions across enterprise, for all platforms, and get back an answer. [Adam Montville]: This all makes sense and we need to continue this discussion. ================================================ Terminology (Henk Birkholz) ================================================ [Henk Birkholz]: We are working on the terminology document to refactor it and get to consistency on terms across documents. We started with the terminology document taking from existing drafts, resolving between them, and making sure we have semantically precise terms. By redefining words, we may upset people, but, should get a good set of terms. I am trying to think like an end user and having consistency so people can learn about our work. [Adam Montville]: Any terms we should discuss now? [Henk Birkholz]: There was a contradiction in defining a SACM Component, role, and function. I don't think we want to open this now. [Merike Kaeo]: Henk did a lot of work on this. Four-and-a-half hours. It is more precise. We need to go over it, have a poll, and then if everyone agrees we will bring it to the group and get feedback then. [Jessica Fitzgerald-McKay]: If terminology document is something everyone should look at, we should send it to the list. [Henk Birkholz]: We still have more to do. We will send it out in a week. [Jessica Fitzgerald-McKay]: Okay, just pointing out that it would be good to get more eyes on it. [Merike Kaeo]: We will review next week and send it out after that. [Chris]: The draft document is on GitHub and you can follow along there. ================================================ SACM ETSI TC Cyber and SACM (Tony Rutkowski) ================================================ Tony went over what ETSI is and wanted to point out that TC CYBER is ETSI’s technical committee for cybersecurity. Tony went over the mapping of the different TC CYBER technical reports and how they relate to SACM. Tony also pointed out that ETSI’s deliverables are mostly informational technical reports rather than normative specifications. It was noted that that DTR/CYBER-001, DTR/CYBER-003, DTR/CYBER-007 were related to SACM in some way. DTR/CYBER-003 captures the twenty critical security controls that Tony Sager came up with. DTR/CYBER-004 tries to cover everything in security. DTR/CYBER-007 may have some a relationship to SACM depending on where it goes and DTR/CYBER-009 will depend on the extent that SACM uses STIX and TAXII. [Dan Romascanu]: In order to engage, we need to make these documents accessible to members of SACM. Then, we can determine what is and is not relevant in this work. [Tony Rutkowski]: I am working on understanding the STIX impact and a shared mapping between the different efforts. We are no longer playing the liaison game. ================================================ 3GPP SA3 and SACM (Tony Rutkowski) ================================================ Tony explained what the Third Generation Partnership Project (3GPP) is and how SA3, the Technical Committee on Security, meets often. Next, Tony explained how GSMA is the home of all the mobile network operators and how it works to establish industry consensus and requirements which are then submitted to the relevant standards development organizations. It was also noted that GSMA just merged with the Fraud and Security Group (FASG) and that the Security Assurance Group (SECAG) is expected to administer the Network Equipment Security Assurance Scheme (NESAS) based on 3GPP SECAM security requirements. [Tony Rutkowski]: All of the documents have a significant relationship to SACM. TR stands for technical report and TS stands for technical specification. TR 33.805 describes the methodologies for specifying network product security assurance and hardening requirements of 3GPP network products. TR 33.916 defines the complete Security Assurance Methodology (SECAM) evaluation process as well as the components that provide the expected security assurance. TR 33.806 applies SECAM to the MME product class. TS 33.116 provides an implementable specification for security assurance for 3GPP network products based on TR 33.806. I want to see what we can do to build bridges across organizations. [Dan Romascanu]: I think these documents are freely accessible? [Tony Rutkowski]: Yes. [Dan Romascanu]: I would like to have people volunteer to go through each document. [Dave Waltermire]: Are they large documents? [Tony Rutkowski]: Yes. [Dan Romascanu]: We want to have people go through them. [Nancy Cam-Winget]: I am not volunteering, but, you described four ETSI documents and four 3GPP documents. It seems like you might need to read the specification before the report. I am just wondering if you are going to have to read them all. [Dan Romascanu]: Any recommendations on the order for reading the documents? [Tony Rutkowski]: I tried to put them in an order that makes sense. If you want to understand the mobile infrastructure document, you will also want to review the overview document. [Kent Landfield]: TR 33.805? [Dave Waltermire]: I am interested in volunteering. [Dan Romascanu]: We need to find out how we can get SACM people access to the documents. [Tony Rutkowski]: Someone at NIST is involved. I will coordinate with Dave and will try to facilitate some comments regarding SWID. [Dave Waltermire]: Are there additional documents around the SWID work? [Tony Rutkowski]: Yes, I will enumerate that as well as a presentation with that and GSMA. I will update them. [Dave Waltermire]: I found the slides difficult to follow without notes. [Tony Rutkowski]: Doing SWIDs for mobile networks. People worked on a SWID-like effort back in the 1980's so SWID is really nothing new. ================================================ Milestone Update (Adam Montville) ================================================ The existing milestones were presented. *Oct 2013 - Initial submission of SACM Architecture I-D *Nov 2013 - Initial submission of SACM Information Model I-D *Jan 2014 - Initial submission of protocol and data format for retrieving configuration and policy information for driving data collection and analysis Internet-Draft *Jan 2014 - Initial submission of protocol and data format for collecting endpoint posture I-D *May 2014 - Submit SACM Architecture Internet-Draft to the IESG for consideration as Informational RFC *Sep 2014 - Submit protocol and data format for retrieving configuration and policy information for driving data collection and analysis Internet-Draft to the IESG for consideration as Proposed Standard *Sep 2014 - Submit protocol and data format for collecting endpoint posture Internet-Draft to the IESG for consideration as Proposed Standard Next, updated milestones, for the working group, were presented. [Kathleen Moriarty]: We can submit anything at any time. If things don't get submitted the working group will close. [Dave Waltermire]: We need help with the information model and have some notes from the EID-DT that need to get included. [Kathleen Moriarty]: I am the only one that gave feedback on the protocol. Others should read it and give feedback too. [Dave Waltermire]: We need content for Section 4 of the architecture document and I would like to help align it with the terminology work. I won't have more time on the information model. [Nancy Cam-Winget]: I am getting comments which is good. I think we are close. We really just need to address comments. [Dan Romascanu]: Maybe we can do it in May? [Nancy Cam-Winget]: I need to get things into GitHub. Any help with that would be great. [Dan Romascanu]: GitHub is not bad. [Adam Montville]: I am working to get things up there. [Nancy Cam-Winget]: I have a question about the process, can we just close issues? [Adam Montville]: You should comment on the issue and if no one responds, it is closed. [Lisa Lorenzin]: We could have the editor close the issue and have people just reopen it. [Jim Schaad]: You can use milestones to align issues with versions and you can use labels. [Nancy Cam-Winget]: We need to document this process. [Dave Waltermire]: We should take Jim's approach. [Nancy Cam-Winget]: It feels like there are major sections that need to be reworked in the architecture document. The comments from January need to be addressed. Section 4 needs work. [Dave Waltermire]: I can help with that. [Nancy Cam-Winget]: We need to get consensus around Section 4 and then we can rework Section 5. [Lisa Lorenzin]: I am busy until the end of April. [Dave Waltermire] We have the virtual interim meeting in May and June. What is the cutoff date for IETF 94? [Dan Romascanu]: Beginning of July so early June. [Lisa Lorenzin]: We need to find someone to help write Section 5. [Nancy Cam-Winget]: I can take a look at it while waiting to get comments on requirements. We need other feedback on the architecture document. [Kent Landfield]: Can we have everyone focus on one document? [Dan Romascanu]: I don't like this approach of serializing. [Kent Landfield]: Sometimes people are spread too thin to get anything done. [Dave Waltermire]: I would like to see working group last call for the information model, architecture, and requirements documents as an intermediary before submitting to the IESG. [Dan Romascanu]: The requirements will be the first. [Adam Montville]: Nancy, what do you think will need to slip? [Nancy Cam-Winget]: Only one protocol and no data models. I don't think we will be ready by September. More like November. [Kathleen Moriarty]: If you get a protocol submission, you might want to take it in while in the working group last call and can change things in another working group last call. I will also review them. We don't necessarily need to send it to IESG. If we don't get any submissions, we will close the working group. [Nancy Cam-Winget]: I don't see the information model being ready before November. [Juan Gonzalez]: I agree with Kent. What about requirements for the May virtual meeting, architecture for the June virtual meeting, and be set up good for July? [Dan Romascanu]: I don't want to serialize, but, I agree the requirements are a high priority. [Kathleen Moriarty]: SACM been around for two years and hasn't accomplished much. [Dave Waltermire]: We only have a couple of editors (Cliff, Dave, Nancy) and they are working on multiple documents (information model, architecture, etc.). Are there any volunteers? [Kathleen Moriarty]: Let's make sure to get people involved and get reviews in. [Adam Montville]: Dave's question around getting more people involved in editing documents. [Aziz Mohaisen]: Not sure, I will be able to commit time for another three weeks. [Lisa Lorenzin]: Please propose text rather than saying "please add text here". Based on this discussion, the following draft milestones will be sent to the list. *WGLC Requirements – May 2015 *WGLC Architecture – July 2015 *WGLC Information Model – November 2015 *Submit Requirements to IESG – July 2015 *Submit Architecture to IESG – September 2015 *Submit Information Model to IESG – January 2016 *Adopt at least one Protocol/Interface Submission(s) – Nov. 2015 *Adopt at least one Data Model Submission(s) – Nov. 2015 *Update WG Milestones (yes, this is a milestone) – Jan. 2016 *Submit Terminology to IESG (TBD)