idnits 2.17.1 draft-camwinget-sacm-requirements-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 8, 2014) is 3603 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 236, but no explicit reference was found in the text == Unused Reference: 'RFC5209' is defined on line 245, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-sacm-terminology-04 == Outdated reference: A later version (-10) exists of draft-ietf-sacm-use-cases-07 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SACM N. Cam-Winget 3 Internet-Draft Cisco Systems 4 Intended status: Informational June 8, 2014 5 Expires: December 10, 2014 7 Secure Automation and Continuous Monitoring (SACM) Requirements 8 draft-camwinget-sacm-requirements-04 10 Abstract 12 This document defines the scope and set of requirements for the 13 Secure Automation and Continuous Monitoring working group. The 14 requirements and scope are based on the agreed upon use cases. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on December 10, 2014. 33 Copyright Notice 35 Copyright (c) 2014 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2.1. General SACM requirements . . . . . . . . . . . . . . . . 2 53 2.2. Requirements based on Use Cases . . . . . . . . . . . . . 4 54 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 55 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 56 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 57 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 59 6.2. Informative References . . . . . . . . . . . . . . . . . 6 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 62 1. Introduction 64 Today's challenges of evolving threats and improved analytics to 65 address such threats highlight a need to automate the securing of 66 both information and the systems that store, process and transmit the 67 information. SACM's charter focuses on addressing some of these 68 challenges in a narrower scope by bounding the task to address use 69 cases that pertain to the posture assessment of endpoints. 71 This document focuses on describing the requirements for facilitating 72 the exchange of posture assessment information, in particular, for 73 the use cases as exemplified in [I-D.ietf-sacm-use-cases].Also, this 74 document uses terminology defined in [I-D.ietf-sacm-terminology]. 76 2. Requirements 78 This document defines requirements based on the SACM use cases 79 defined in [I-D.ietf-sacm-use-cases]. This section describes the 80 requirements used by SACM to assess and compare candidate information 81 models and protocols to suit the architecture. These requirements 82 express characteristics or features that a candidate protocol or data 83 model must be capable of offering so as to ensure security and 84 interoperability. 86 2.1. General SACM requirements 88 The use cases defined in [I-D.ietf-sacm-use-cases] apply to many 89 deployment scenarios. To ensure interoperability, scalability and 90 flexibility in any of these deployments, the following requirements 91 are defined for all use cases: 93 G-001 Extensibility: the data models, protocols and transports 94 defined by SACM must be extensible to allow support for non-standard 95 and future extensions. The transport protocol must support easily 96 adding new operations while maintaining backwards compatibility. 97 The query language must allow general inquiries as well as 98 expression of specific paths to follow; retrieval of specific 99 information based on an event, as well as on a continuous basis; and 100 the ability to retrieve specific pieces of information, specific 101 classes of information, and/or the entirety of available 102 information. The information model must accommodate the addition of 103 new data types and/or schemas in a backwards compatible fashion. 105 G-002 Interoperability: The data models, protocols and transports 106 must be specified with enough details and state machine to ensure 107 interoperability. 109 G-003 Scalability: The data models, protocols and transports must be 110 scalable. SACM must support a broad set of deployment scenarios. 111 As such, it is possible that the size or posture assessment 112 information can vary from a single assessment that is small in 113 (record or datagram) size to a very large datagram or a very large 114 set of assessments and must be addressed by the SACM specifications 115 defined. 117 G-004 Agility: The agility requirement is to ensure that the data 118 model, protocols, transports and its implementations are suitable to 119 fit in different deployment models and scenarios. Considerations 120 for the lightweight implementations of data models and transports is 121 required. Use cases, especially in the vulnerability assessment and 122 threat defense applications require time criticality in both 123 obtaining the information as well as consuming (e.g. parsing) the 124 data. 126 G-005 Transport variability: Different transports must be supported 127 to address different deployment and time constraints. Supporting 128 transports at the Layer 2, Layer 3 and higher application layers. 130 G-006 Extensibility: a method for expressing both standard and non- 131 standard (implementer-specific) data attributes while avoiding 132 collisions should be defined. For interoperability and scope 133 boundary, an explicit set of data attributes as mandatory to 134 implement should be defined and focused on Posture Assessment should 135 be described to allow for interoprability too. 137 G-007 Access Control: To address security and privacy 138 considerations, the data model, protocols and transport must 139 consider authorization based on roles to only allow authorized 140 requestors and publishers to access the information being requested 141 or published. 143 2.2. Requirements based on Use Cases 145 This section describes the requirements that may apply to information 146 models, data models, protocols or transports as identified by the use 147 cases in [I-D.ietf-sacm-use-cases] and referenced by the section 148 numbers from that draft. 150 REQ-001 Attribute Dictionary: Use Cases in the whole of Section 2 151 describe the need for an Attribute Dictionary. With SACM's scope 152 focused on Posture Assessment, the attribute collection and 153 aggregation must have a well understood set of attributes inclusive 154 of their meaning or usage intent. 156 REQ-002 Information Model: Use Case 2.1.1 describes the need for an 157 Information Model to drive content definition. As SACM endeavors to 158 reuse already existing standards which may have their own data 159 models defined by instantiating an information model, the data 160 models can be mapped to SACM's information model. See [RFC3444] for 161 a description and distinctions between an information and data 162 model. 164 REQ-003 Data Model to Protocol mapping: Use Case 2.1.1 describes the 165 need to instantiate a data model that can map to the SACM protocols 166 for posture content operations such as publication, query, change 167 detection and asynchronous notifications. 169 REQ-004 Endpoint Discovery: Use Case 2.1.2 describes the need to 170 discover endpoints and their composition. 172 REQ-005 Attribute based query: Use Case 2.1.2 describes the need for 173 the data model to support a query operation based on a set of 174 attributes to facilitate collection of information such as posture 175 assessment, inventory (of endpoints or endpoint components) and 176 configuration checklist. . 178 REQ-006 Information based query with filtering: Use Case 2.1.3 179 describes the need for the data model to support the means for the 180 information to be collected through a query mechanism. Furthermore, 181 the query operation requires filtering capabilities to allow for 182 only a subset of information to be retrieved. The query operation 183 may be a synchronous request or asynchronous request. 185 REQ-007 Asynchronous publication, updates or change modifications 186 with filtering: Use Cases 2.1.3, 2.1.4 and 2.1.5 describe the need 187 for the data model to support the means for the information to be 188 published asynchronously. Similarly, the data model must support 189 the means for a requestor to obtain updates or change modifications 190 asynchronously. Like the query operation, these update 191 notifications can be set up with a filter to allow for only a subset 192 of posture assessment information to be obtained. 194 REQ-008 Data model scalability: Use Cases 2.1.4 and 2.1.5 describes 195 the need for the data model to support scalability. For example, 196 the query operation may result in a very large set of attributes as 197 well as a large set of targets. 199 REQ-009 Separation of Collection Request and Collection Action: the 200 data model must distinguish the means to request for a data item to 201 include enough information to properly identify the item to collect 202 but the request could be separate and distinct from the actual 203 method or process used to fulfill the request. 205 3. Acknowledgements 207 The authors would like to thank Barbara Fraser, Jim Bieda and Adam 208 Montville for reviewing and contributing to this draft. 210 4. IANA Considerations 212 This memo includes no request to IANA. 214 5. Security Considerations 216 This document defines the requirements for SACM. As such, it is 217 expected that several data models, protocols and transports may be 218 defined or reused from already existing standards. This section will 219 highlight security considerations that may apply to SACM based on the 220 architecture and standards applied in SACM. 222 6. References 224 6.1. Normative References 226 [I-D.ietf-sacm-terminology] 227 Waltermire, D., Montville, A., Harrington, D., and N. Cam- 228 Winget, "Terminology for Security Assessment", draft-ietf- 229 sacm-terminology-04 (work in progress), May 2014. 231 [I-D.ietf-sacm-use-cases] 232 Waltermire, D. and D. Harrington, "Endpoint Security 233 Posture Assessment - Enterprise Use Cases", draft-ietf- 234 sacm-use-cases-07 (work in progress), April 2014. 236 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 237 Requirement Levels", BCP 14, RFC 2119, March 1997. 239 6.2. Informative References 241 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 242 Information Models and Data Models", RFC 3444, January 243 2003. 245 [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. 246 Tardo, "Network Endpoint Assessment (NEA): Overview and 247 Requirements", RFC 5209, June 2008. 249 Author's Address 251 Nancy Cam-Winget 252 Cisco Systems 253 3550 Cisco Way 254 San Jose, CA 95134 255 US 257 Email: ncamwing@cisco.com