Security Automation and Continuous Monitoring (SACM) Requirements
Note: This ballot was opened for revision 16 and is now closed.
Comment (2017-06-21 for -16) Unknown
I spent a while trying to figure out how to ballot on this - I personally see value in requirements, use-cases and similar (informational) documents - they help newcomers to the technology understand how and why it is shaped as it is. This document is also (kind of) mentioned in the charter ("A document or documents describing the SACM Architecture. This will include protocol requirements and their associated use cases as well as a description ..." , and so I've decided on Yes However, there are still some comments / nits which should be addressed, including: Abstract: "The requirements and scope are based on the agreed upon use cases." -- what use cases / agreed upon by whom? (Missing ref). 1. Introduction "Today’s environment of rapidly-evolving security threats highlights the need to automate the sharing of security information (such as posture information) while protecting user information as well as the systems that store, process, and transmit this information." - "... user information as well as the systems" -> "user information and the systems" ? Not sure if this is better.... 2. Requirements I got somewhat lost in "A SACM transport protocol is one that runs on top of L3 protocols such as TCP/IP or L4 protocols such as HTTP, carries operations (requests / responses), and moves data." - perhaps "A SACM transport protocol is one that runs on top of L3 protocols (such as TCP/IP) or L4 protocols (such as HTTP), carries operations (requests / responses), and moves data." 3: "With the information model defining assets and attributes to facilitate the guidance, collection, and assessment of posture, these are some of the tasks that should be considered:" - the "With" and "these" feel unrelated. I'm not really sure how they are supposed to tie together, so I cannot suggest text. G-001 "2. The query language MUST allow for general inquiries, as well as expression of specific attributes or relationships between attributes to follow; the retrieval of specific information ..." -- I don't really understand the "to follow"; can it be struck? G-002 "Interoperability: The data models, protocols, and transports must be specified with enough details to ensure interoperability." -- I really don't understand the point of saying this - are you expecting that if you *didn't* say this that people would intentionally create models without enough detail? Is this just a "motherhood and apple pie" statement? G-006 "Mechanisms for this protection are unspecified but should include industry best practices such as encrypted storage, encrypted transports, data checksums, etc. " -- the list of best practices seems harmful; if you provide a list people will implicitly assume it is exhaustive, and industry best practices change over time. Also, what is a "data checksum"? I'm assuming you mean something "cryptographic checksums" or "secure hash" - a data checksum implies something like a simple CRC. I'd suggest just dropping the "such as..." list. IM-004 "Data Model Identification: The information model MUST provide a means to uniquely identify each data model uniquely." - you really really want this to be unique, don't you :-P 5.2. Privacy Considerations "In addition to identity and SACM capabilities information disclosure, the use of time stamps or other attributes that can be used as identifiers especially as they are coupled with an identity can be further used to determine a target endpoint or user’s behavioral patterns." -- this sentence could use some work. I agree with what it is trying to say, but it is long and confusing. Perhaps: "In addition to identity and SACM capabilities information disclosure, the use of time stamps (or other attributes that can be used as identifiers) could be further used to determine a target endpoint or user’s behavioral patterns." -- I *think* that that maintains the meaning, but is clearer. "Data confidentiality can provide some level of privacy but may fall short where unecessary data is still transmitted." - "unnecessary" (typo)
Kathleen Moriarty Former IESG member
Yes (for -16) Unknown
Adam Roach Former IESG member
No Objection (2017-06-21 for -16) Unknown
I see little value in spending RFC editor resources on publishing this document, but don't feel strongly enough about it to abstain. I would be happy to see this document declared as having been useful for the working group's internal purposes, and having already served the entirety of its purpose, not progressed to an RFC.
Alexey Melnikov Former IESG member
No Objection (2017-06-22 for -16) Unknown
I generally dislike "requirements" documents, as most WG are not going to check final protocol against requirements. However I can see that such documents can be sometimes useful. I have some specific comments on Section 2.6. It generally looks very confused on transport protocol versa transfer protocol, which I don't think are synonyms: 2.6. Requirements for SACM Transport Protocols I think you meant "Transfer Protocol" in the section title, as my understanding that "SACM transfer protocol" != "SACM transport protocol"? The term SACM transfer protocol is intended to be distinguished from underlying layer 3 and 4 protocols such as TCP/IP, operating at an equivalent level as the hyperText transfer protocol (HTTP). The SACM transfer protocol is focused on moving data and performing necessary access control operations; it is agnostic to the data model operations. The requirements for SACM transport protocols include: Again, do you mean "transfer protocol" here? (snip) T-003 Data Confidentiality: SACM transfer protocols MUST be able to support data confidentiality. SACM transport protocols MUST ensure Do you really mean "transport protocol" above? This will rule out both TCP and UDP. data protection for data in transit (e.g. by encryption) to provide confidentiality, integrity, and robustness against protocol-based attacks. Note that while the transport MUST be able to support data confidentiality, implementations MAY provide a configuration option that enables and disables confidentiality in deployments. Protection for data at rest is not in scope for transport protocols. Again, "transfer protocols"? Data protection MAY be used for both privacy and non-privacy scenarios.
Alia Atlas Former IESG member
No Objection (for -16) Unknown
Ben Campbell Former IESG member
(was Discuss) No Objection
No Objection (2017-08-01 for -17) Unknown
Thanks for addressing my DISCUSS position and other comments. I am clearing my DISCUSS under the expectation that an upcoming revision will include the changes that have been discussed in email. I am keeping the first comment below for posterity, but I don't expect any action on it. - I agree with the other abstain positions that the content in this draft doesn't seem to warrant publication as an RFC. I'm not going to abstain over it, since I think that sort of discussion should occur at charter or milestone adoption time.
Deborah Brungard Former IESG member
No Objection (for -16) Unknown
Eric Rescorla Former IESG member
No Objection (2017-06-20 for -16) Unknown
* Large datagrams: It is possible that the size of posture assessment information can vary from a single assessment that is small in size to a very large datagram or a very large set of assessments (up to multiple gigabytes in size). I would consider saying "message" here, because I usually think of "datagram" as ~= packet/IP datagram.
Spencer Dawkins Former IESG member
No Objection (2017-06-19 for -16) Unknown
I'm following along with Mirja's Abstain, although I'm balloting No Objection. I'm looking at T-005 Transport Reliability: SACM transfer protocols MUST provide reliable delivery of data. This includes the ability to perform fragmentation and reassembly, and to detect replays. The SACM transfer may take advantage of reliability features in the network transport; however, the network transport may be unreliable (e.g. UDP), in which case the SACM transport running over the unreliable network transport is responsible for ensuring reliability (i.e. by provisions such as confirmations and re-transmits). and wondering why you'd want to run SACM transfer protocols over UDP in the first place (and, assuming there's a fabulous reason to do that, why you wouldn't run those protocols over UDP in all cases). This is a No Objection position, but please recognize that these protocols would be simpler if they were running over TCP.
Alissa Cooper Former IESG member
Abstain (2017-06-21 for -16) Unknown
I too don't see the particular value of having this published as an RFC, but understand that the WG may view it differently. I offer the comments below for what they're worth. I think the document sows confusion in its use of the terms "transport protocol" and "transfer protocol." They appear to be used interchangeably (maybe? I'm not actually entirely sure), there seem to be claims that HTTP is a L4 transport protocol, and although the terms "SACM transport protocol" and "SACM transfer protocol" are used and vaguely defined in the draft, they are not defined in the terminology document. If this document goes forward it seems like an edit pass to clarify what is meant with these terms each time they are used, and their relationship to what we typically think of as a "transport protocol," is warranted. I would have thought target location information would be specifically called out in Section 5.2. I have not seen a response to the Gen-ART review.
Alvaro Retana Former IESG member
Abstain (2017-06-20 for -16) Unknown
I am ABSTAINing because I don't see publication value for this document given that the architecture and the information model are already done (or at least in an advanced state). I understand the interest of the WG to document the requirements as an RFC, so I won't stand in the way of publication. Having said that, if the original intent was for this document to be used as input for the development of the architecture, consider updating some of the text so that there's no mix of "timing": the text should probably read as if the architecture/information model don't exist yet; there are no references to them (which is good), but the text makes some mention of them... For example: Section 2 (Requirements) says that it "describes the requirements used by SACM to assess and compare candidate data models, interfaces, and protocols, to suit the SACM architecture." I'm guessing that "will be used", and that "by SACM" refers to the WG (SACM by itself is used extensively throughout). Note that the end says "to suit the architecture", which sounds like the architecture is a foregone conclusion and the requirements are just for the rest. Also in Section 2: "SACM defines an architecture and information model focused on addressing the needs for determining, sharing, and using posture information via Posture Information Providers and Posture Information Consumers mediated by a Controller." I didn't check, but this sounds like a quick description of the architecture and information model -- both of which would be developed based on this document.
Benoît Claise Former IESG member
(was No Objection) Abstain
Abstain (2017-06-27 for -16) Unknown
Hi Nancy, > Hi Benoit, > Thanks for the review and feedback. Please see further comments below: > > On 6/21/17, 4:00 AM, "Benoit Claise (bclaise)" <email@example.com> wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > - 3. The information model MUST accommodate the interoperable > addition of new data types and/or schemas. > > I guess that you want to say: The data model MUST ... > See RFC 3444 > [NCW] The group actually debated “information model” vs “data model” extensively and > decided on this language. > > - > Reading G-003, G-004, G-012, it seems like you want to be able to select your > "transport", with your own requirements. > > However, I guess that, practically, you'll select a data model and the > transport will be obvious. MIB module => UDP IFPIX information elemeents => > UDP/DTLS. Yeah, the specs say SCTP/TCP, but in practice ... YANG module, either > NETCONF => TCP/SSH or RESTCONF => HTTPS Not sure I believe into a single > transport to rules them all, where "them" is all the different data model > source of information. This was already my feedback during your previous > interim meeting (where I presented yangcatalog.org): your information model > draft is basically of a mix of elements already specified in IPFIX, YANG > module, MIB module. How do you consolidate all this? > [NCW] There will be data models that are only suitable for specific transfer models > and specific transport layers (ROLIE for example as a discovery lends itself better at > an HTTP and not so much in MIB). The Information model is meant to be a “raw” > definition of elements/attributes that can them be mapped into specific data models > (the group for instance is looking at SWID, others are looking at netconf) etc…. > > Same remark with "2.5 requirements for data model operations". > You select your data model and the data model operations are given/specified > already Let's say: IPFIX. From there you have a push mechanism only (as opposed > to pull). Let's say: YANG module. From there you select NETCONF or NETCONF, and > the operations are already specified. > [NCW] In essence, that is correct. > > - > The SACM information model MUST include the > ability to discover and negotiate the use of a particular data model > or any data model. > > What does it mean "negotiate"? > Either an end point supports a data model or it doesn't, no? > > Same remark for: > DM-007 Data Model Negotiation: The interfaces and actions in the > data model MUST include capability negotiation to enable discovery > of supported and available data types and schemas. > [NCW] In this context, “Negotiate” is the means by which two parties can agree on the data model to be used. > The “means” could be data model and/or transfer protocol specific….but the intent is to enable that thru > The abstraction to allow for that should be in the Information model definition. > > > > - Read the following one multiple times, and I still don't understand it: > IM-005 Data Lifetime Management: The information model MUST provide > a means to allow data models to include data lifetime management. > [NCW] It is really meant to be a means by which the consumer of the information can know when that data may be obsoleted (updated, changed or removed). What about trying to make the text clear(er)? > > > - > The SACM information model represents an abstraction for "what" > information can be communicated and "how" it is to be represented and > shared. > > Not sure it's aligned with RFC3444: > IM --> conceptual/abstract model > | for designers and operators > +----------+---------+ > | | | > DM DM DM --> concrete/detailed model > for implementors > > [NCW] We really have tried….if it isn’t clear, I am open to making it more so but > the resulting draft and definitions come from much debate and final agreement from the WG. What I considered to be an easy COMMENT turned out more complicated that I thought. I guess that we'll agree to disagree. I don't feel that this data model/information model discussion will be resolved to my OPS-view satisfaction. I can't support this document publication and I don't want to spend energy to try to convince people for this COMMENT Since I don't want to be in the way, I'll ABSTAIN. Regards, Benoit
Mirja Kühlewind Former IESG member
Abstain (2017-06-16 for -16) Unknown
I abstain because I don’t think there is a achievable value in publishing this document in the RFC series (for consumption outside the wg). However, I also don’t understand why there is a requirement to support multiple transport protocols, including potentially UDP. I don’t think this is worth a discuss on this document but if SACM plans to invent a new transport (over UDP) instead of just using TCP which seems more than appropriate, it needs a real justification for that (which is at least in this document not at all given)!
Suresh Krishnan Former IESG member
Abstain (2017-06-21 for -16) Unknown
I do see the value of writing up the requirements to guide further work in the WG, but I do not see that value of publishing them in a standalone RFC. I would have much preferred the requirements to be included in the other WG deliverables (as Alvaro and Terry have noted). I do respect the WG's intent to publish and I am abstaining to move out of the way.
Terry Manderson Former IESG member
Abstain (2017-06-20 for -16) Unknown
I am balloting ABSTAIN on this document as I don't see strong value in a set of requirements as a standalone document added to the RFC series. I appreciate it's an extension of the use-cases document and a WG milestone but it reads like the architecture and info model is already done (and indeed WG revisions of that work look mature). In which case I STRONGLY urge that the 10 pages of requirements be placed (as required) in appendices of the milestone documents (information-model, data-model, protocol/Interface, architecture etc). This maintains the rationale for the designs in question and aids the reader in comprehension of the work. That said, with ABSTAIN positions, I am not blocking publication of this document and I shall leave it to the responsible AD to adjudicate.