idnits 2.17.1 draft-ietf-sacm-requirements-03.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (January 2, 2015) is 3402 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 545, but no explicit reference was found in the text == Unused Reference: 'RFC3444' is defined on line 554, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-sacm-terminology-05 == Outdated reference: A later version (-10) exists of draft-ietf-sacm-use-cases-07 Summary: 0 errors (**), 0 flaws (~~), 6 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 L. Lorenzin 5 Expires: July 6, 2015 Pulse Secure 6 January 2, 2015 8 Secure Automation and Continuous Monitoring (SACM) Requirements 9 draft-ietf-sacm-requirements-03 11 Abstract 13 This document defines the scope and set of requirements for the 14 Secure Automation and Continuous Monitoring working group. The 15 requirements and scope are based on the agreed upon use cases. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on July 6, 2015. 34 Copyright Notice 36 Copyright (c) 2015 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2.1. Requirements for SACM . . . . . . . . . . . . . . . . . . 3 54 2.2. Requirements for the Architecture . . . . . . . . . . . . 5 55 2.3. Requirements for the Data Model . . . . . . . . . . . . . 6 56 2.4. Requirements for Transport Protocols . . . . . . . . . . 9 57 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 58 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 60 5.1. Trust between Provider and Requestor . . . . . . . . . . 10 61 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 62 6.1. Normative References . . . . . . . . . . . . . . . . . . 12 63 6.2. Informative References . . . . . . . . . . . . . . . . . 12 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 66 1. Introduction 68 Today's environment of rapidly-evolving security threats highlights 69 the need to automate the sharing of such information while protecting 70 user information as well as the systems that store, process, and 71 transmit this information. Security threats can be detected in a 72 number of ways. SACM's charter focuses on how to collect and share 73 this information based on use cases that involve posture assessment 74 of endpoints. 76 Scalable and sustainable collection, expression, and evaluation of 77 endpoint information is foundational to SACM's objectives. To secure 78 and defend a network one must reliably determine what devices are on 79 the network, how those devices are configured from a hardware 80 perspective, what software products are installed on those devices, 81 and how those products are configured. We need to be able to 82 determine, share, and use this information in a secure, timely, 83 consistent, and automated manner to perform endpoint posture 84 assessments. 86 This document focuses on describing the requirements for facilitating 87 the exchange of posture assessment information, in particular, for 88 the use cases as exemplified in [I-D.ietf-sacm-use-cases].Also, this 89 document uses terminology defined in [I-D.ietf-sacm-terminology]. 91 2. Requirements 93 This document defines requirements based on the SACM use cases 94 defined in [I-D.ietf-sacm-use-cases]. This section describes the 95 requirements used by SACM to assess and compare candidate data 96 models, their interfaces and protocols to suit the SACM architecture. 98 These requirements express characteristics or features that a 99 candidate protocol or data model must be capable of offering to 100 ensure security and interoperability. 102 In order to address the needs for determining, sharing and using 103 posture information, the following tasks should be considered: 105 1. Define the assets. This is what we want to know about an asset. 106 For instance, organizations will want to know what software is 107 installed and its many critical security attributes such as patch 108 level. 110 2. Resolve what assets actually compose an endpoint. This requires 111 populating the data elements and attributes needed to exchange 112 information pertaining to the assets composing an endpoint. 114 3. Determine the expected values for the data elements and 115 attributes that need to be evaluated against the actual collected 116 instances of asset data. This is how an organization can express 117 its policy for an acceptable data element or attribute value. A 118 system administrator can also identify specific data elements and 119 attributes that represent problems, such as vulnerabilities, that 120 need to be detected on an endpoint. 122 4. Evaluate the collected instances of the asset data against those 123 expressed in the policy. 125 5. Report the results of the evaluation. 127 2.1. Requirements for SACM 129 Many deployment scenarios can be instantiated to address the above 130 tasks and use cases defined in [I-D.ietf-sacm-use-cases]. To ensure 131 interoperability, scalability and flexibility in any of these 132 deployments, the following requirements are defined for proposed SACM 133 standards: 135 G-001 Solution Extensibility: The data models, protocols and 136 transports defined by SACM MUST be extensible to allow support for 137 non-standard and future extensions. 139 1. The transport protocol MUST support the ability to add new 140 operations while maintaining backwards compatibility. 142 2. The query language must allow general inquiries as well as 143 expression of specific paths to follow; retrieval of specific 144 information based on an event, as well as on a continuous basis; 145 and the ability to retrieve specific pieces of information, 146 specific types or classes of information, and/or the entirety of 147 available information. 149 3. The information model must accommodate the addition of new data 150 types and/or schemas in a backwards compatible fashion. 152 G-002 Interoperability: The data models, protocols and transports 153 must be specified with enough details to ensure interoperability. 155 G-003 Scalability: The data models, protocols and transports must be 156 scalable. SACM must support a broad set of deployment scenarios. 157 As such, it is possible that the size of posture assessment 158 information can vary from a single assessment that is small in 159 (record or datagram) size to a very large datagram or a very large 160 set of assessments. This must be defined by the SACM 161 specifications. 163 G-004 Agility: The agility requirement is to ensure that the data 164 model, protocols, and transports are suitably specified to enable 165 implementions to fit into the different deployment models and 166 scenarios. Considerations for lightweight implementations of data 167 models and transports is required. 169 G-005 Information Extensibility: A method for expressing both 170 standard and non-standard (implemention-specific) data attributes 171 while avoiding collisions SHOULD be defined. For interoperability 172 and scope boundary, an explicit set of data attributes MUST be 173 defined mandatory to implement. 175 G-006 Data Integrity: A method for ensuring data integrity MUST be 176 provided. This method is required to be available (i.e. all data- 177 handling components must support it), but is not required to be used 178 in all cases. 180 G-007 Data Isolation: A method for partitioning data MUST be 181 supported, to accommodate considerations such as geographic, 182 regulatory, overlay boundaries and federation, where an organization 183 may want to differentiate between information that can be shared 184 outside its own domain and information that cannot. As with the 185 requirement for data integrity, this method is required to be 186 available (i.e. all data-handling components must support it), but 187 is not required to be used in all cases. 189 G-008 Versioning and Backward Compatibility: Announcement and 190 negotiation of versions, inclusive of exisiting capabilities (such 191 as transport protocols, data models, specific attributes within data 192 models, standard attribute expression sets, etc.) MUST be 193 supported. Negotiation for both versioning and capability is needed 194 to accommodate future growth and ecosystems with mixed capabilities. 196 G-009 Discovery: There must be a mechanism for components to 197 discover what information is available across the ecosystem (i.e. a 198 method for cataloging data available in the ecosystem and 199 advertising it to consumers), and where to go to get a specific 200 piece of that information. For example, providing a method by which 201 a node can locate the advertised information so that consumers are 202 not required to have a priori knowledge to find available 203 information. 205 G-010 Endpoint Discovery: SACM MUST define the means by which 206 endpoints may be discovered. Use Case 2.1.2 describes the need to 207 discover endpoints and their composition. 209 G-011 Unsolicited publication, updates or change modifications with 210 filtering: Use Cases 2.1.3, 2.1.4 and 2.1.5 describe the need for 211 the data model to support the means for the information to be 212 published unsolicited. Similarly, the data model must support the 213 means for a requestor to obtain updates or change modifications 214 without constant querying (or polling). Like the query operation, 215 these update notifications can be set up with a filter to allow for 216 only a subset of posture assessment information to be obtained. 218 2.2. Requirements for the Architecture 220 At the simplest abstraction, the SACM architecture represents the 221 core components and interfaces needed to perform the production and 222 consumption of posture assessment information. Requirements relating 223 the SACM's architecture include: 225 ARCH-001 Scalability: The architectural components must account for 226 a range of deployments, from very small set of endpoints are used to 227 very large deployments. 229 ARCH-002 Agility: The architectural components must account for 230 different deployment scenarios where the architectural components 231 may be implemented, deployed or used within a single application, 232 service, network or may comprise a federated system. 234 ARCH-003 Separation of Data and Management functions: SACM must 235 define both the configuration and management of the SACM data models 236 and protocols used to transport and share posture assessment 237 information. 239 ARCH-004 Topology Flexibility: Both centralized and decentralized 240 (peer-to-peer) information exchange must be supported. Centralized 241 data exchange enables use of a common data format to bridge together 242 data exchange between diverse systems, and can leverage a virtual 243 data store that centralizes and offloads all data access, storage, 244 and maintenance to a dedicated resource. Decentralized data 245 exchange enables simplicity of sharing data between relatively 246 uniform systems, and between small numbers of systems, especially 247 within a single enterprise domain. 249 ARCH-005 Modularity: Announcement and negotiation of functional 250 capabilities (such as authentication protocols, authorization 251 schemes, data models, transport protocols, etc.) must be supported, 252 enabling a SACM component to make inquiries about the capabilities 253 of other components in the SACM ecosystem. 255 ARCH-006 Role based Authorization: The SACM architecture MUST be 256 capable of affecting role based authorization. Distinction of 257 endpoints capable and authorized to provide or consume information 258 is required to address appropriate access controls. 260 ARCH-007 Context based Authorization: The SACM architecture MUST be 261 capable of affecting a context based authorization. Different 262 policies (e.g. business, regulatory, etc) may specify what data may 263 be exposed or shared by particular consumers as well as how 264 consumers may be required to share the information. The context 265 defines the composite set of guidelines provided by policy for 266 affecting what posture data is allowed to be communicated from 267 providers to consumers. 269 2.3. Requirements for the Data Model 271 The SACM information model represents an abstraction for "what" 272 information can be communicated and "how" it is to be represented and 273 shared. 275 It is expected that as applications may produce Posture assessment 276 information, they may share it using a specific data model. 277 Similarly, applications consuming or requesting Posture Assessment 278 information, may require it be based on a specific data model. Thus, 279 while there may exist different data models and schemas, they should 280 adhere to a SACM information model that meets the requirements 281 defined in this section. 283 The specific requirements for candidate data models include: 285 IM-001 The data model MUST define the data attributes as objects 286 that MUST be uniquely referenced (e.g. endpoint, IP address, asset). 288 IM-002 The data model may be structured into modules and submodules 289 to allow for data references within a module. For example, an 290 endpoint may be defined as a module that references one or more 291 submodules that further describe the one or more assets. 292 Constraints and interfaces may further be defined to resolve or 293 tolerate ambiguity in the references (e.g. same IP address used in 294 two separate networks). 296 IM-003 The interfaces and actions in the data model MUST include 297 support for rootless searches and wildcard searches 299 IM-004 The search interfaces and actions MUST include the ability to 300 start a search anywhere within a data model structure. 302 IM-005 The data model SHOULD include management of the data, 303 including data lifetime management (longevity or expiration of 304 data). 306 IM-006 Ephemerality: The information model SHOULD include the 307 ability to allow providers of data to provide the data as a whole or 308 when updates occur. The data may be provided by a requestor either 309 solicited or unsolicited. 311 IM-007 The data model SHOULD allow for a loose coupling between the 312 provider and the requestor. 314 IM-008 The interfaces and actions in the data model MUST include the 315 ability to identify data from a specific provider. 317 IM-009 Data cardinality: The data model MUST describe their 318 constraints (e.g. cardinality). As Posture information and the 319 tasks for collection, aggregation or evaluation could comprise one 320 or more attributes, interfaces and actions must allow and account 321 for such cardinality as well as whether the attributes are 322 conditional, optional or mandatory. 324 IM-010 Data model negotiation: The interfaces and actions in the 325 information model MUST include capability negotiation to enable 326 discovery of supported and available data types and schemas. 328 IM-011 The data model SHOULD include the ability for providers to 329 identify the data origin. 331 IM-012 Synchronization: Request and response operations SHOULD be 332 timestamped, and published information SHOULD capture time of 333 publication. Actions or decisions based on time-sensitive data 334 (such as user logon/logoff, endpoint connection/disconnection, 335 endpoint behavior events, etc.) are all predicated on a synchronized 336 understanding of time. A method for detecting and reporting time 337 discrepancies SHOULD be provided. 339 IM-013 Collection separation: The request for a data item must 340 include enough information to properly identify the item to collect, 341 but the request shall not be a command to directly execute nor 342 directly be applied as arguments to a command. The purpose of this 343 requirement is primarily to reduce the potential attack vectors, but 344 has the additional benefit of abstracting the request for collection 345 from the collection method thereby allowing more flexibility in how 346 collection is implemented. 348 IM-014 Collection composition: A collection request can be composed 349 of multiple collection requests (which yield collected values). 350 This must be able to be expressed as part of the collection request 351 so that the aggregation can be resolved at the point of collection 352 without having to interact with the requester. 354 IM-015 Attribute based query: Use Case 2.1.2 describes the need for 355 the data model to support a query operation based on a set of 356 attributes to facilitate collection of information such as posture 357 assessment, inventory (of endpoints or endpoint components) and 358 configuration checklist. 360 IM-016 Information based query with filtering: Use Case 2.1.3 361 describes the need for the data model to support the means for the 362 information to be collected through a query mechanism. Furthermore, 363 the query operation requires filtering capabilities to allow for 364 only a subset of information to be retrieved. The query operation 365 MAY be a synchronous request or asynchronous request. 367 IM-017 Data model scalability: Use Cases 2.1.4 and 2.1.5 describes 368 the need for the data model to support scalability. For example, 369 the query operation may result in a very large set of attributes as 370 well as a large set of targets. 372 IM-018 Attribute Dictionary: Use Cases in the whole of Section 2 373 describe the need for an Attribute Dictionary. With SACM's scope 374 focused on Posture Assessment, the data model attribute collection 375 and aggregation MUST have a well understood set of attributes 376 inclusive of their meaning or usage intent. 378 IM-019 Transport Agnostic: the data model SHOULD be transport 379 agnostic, to allow for the data operations to leverage the most 380 appropriate transport Internet layer (e.g. Link Layer, TCP, UDP, 381 etc.). 383 IM-020 The data model SHOULD allow the provider to include the 384 information's origination time. 386 IM-021 The data model SHOULD allow the provider to include attributs 387 defining how the data was generated (e.g. self-reported, reported by 388 aggregator, scan result, etc.). 390 IM-022 The data model SHOULD allow the provider to include 391 attributes defining the location of the data source. 393 IM-023 The data model SHOULD allow the provider to include 394 attributes defining whether the information provided is a delta, 395 partial or full set of information. 397 2.4. Requirements for Transport Protocols 399 The requirements for transport protocols include: 401 T-001 Transport variability: Different transports must be supported 402 to address different deployment and time constraints. Supporting 403 transports MAY be at the data link layer, network transport layer or 404 the application layers. 406 T-002 Data Integrity: Transport protocols MUST be able to support 407 data integrity. 409 T-003 Data Confidentiality: Transport protocols MUST be able to 410 support data confidentiality. Transport protocols SHOULD ensure 411 data protection for data in transit by encryption to provide 412 confidentiality, integrity and robustness against protocol-based 413 attacks. Note that while the transport MUST be able to support data 414 confidentiality, implementations MAY choose to make confidentiality 415 optional. Protection for data at rest is not in scope for SACM. 416 Data protection MAY be used for both privacy and non-privacy 417 scenarios. 419 T-004 Transport protection: Transport protocols MUST be capable of 420 supporting mutual authentication and replay protection. 422 T-005 Transport reliability: Transport protocols MUST provide 423 reliable delivery of data. This includes the ability to perform 424 fragmentation and reassembly, and detect replays. 426 3. Acknowledgements 428 The authors would like to thank Barbara Fraser, Jim Bieda and Adam 429 Montville for reviewing and contributing to this draft. 431 4. IANA Considerations 433 This memo includes no request to IANA. 435 5. Security Considerations 437 This document defines the requirements for SACM. As such, it is 438 expected that several data models, protocols and transports may be 439 defined or reused from already existing standards. This section will 440 highlight security considerations that may apply to SACM based on the 441 architecture and standards applied in SACM. In particular, 442 highlights to security considerations that may apply to the SACM 443 reference architecture and standard data models and transports will 444 be discussed 446 To address security and privacy considerations, the data model, 447 protocols and transport must consider authorization based on consumer 448 function and privileges, to only allow authorized consumers and 449 providers to access specific information being requested or 450 published. 452 To enable federation across multiple entities (such as across 453 organizational or geographic boundaries) authorization must also 454 extend to infrastructure elements themselves, such as central 455 controllers / brokers / data repositories. 457 In addition, authorization needs to extend to specific information or 458 resources available in the environment. In other words, 459 authorization should be based on both subject (the information 460 requestor) and object (the information requested). The method by 461 which this authorization is applied is unspecified. 463 With SACM's charter focus on the sharing of posture information for 464 improving efficacy of security applications such as compliance, 465 configuration, assurance and other threat and vulnerability reporting 466 and remediation systems. While the goal is to facilitate the flow of 467 information securely, it is important to note that participating 468 endpoints may not be cooperative or trustworthy. 470 5.1. Trust between Provider and Requestor 472 The information given from the provider to a requestor may come with 473 different levels of trustworthiness given the different potential 474 deployment scenarios and compromise either at the provider, the 475 requestor or devices that are involved in the transport between the 476 provider and requestor. This section will describe the different 477 considerations that may reduce the level of trustworthiness of the 478 information provided. 480 In the information transport flow, it is possible that some of the 481 devices may serve as proxies or brokers and as such, may be able to 482 observe the communications flowing between an information provider 483 and requester. Without appropriate protections 485 It is common to, in general, distrust the network service provider, 486 unless the full hop by hop communications process flow is well 487 understood. As such, the posture information provider should protect 488 the posture information data it provides as well as the transport it 489 uses. Similarly, while there may be providers whose goal is to 490 openly share its information, there may also be providers whose 491 policy is to grant access to certain posture information based on its 492 business or regulatory policy. In those situations, a provider may 493 require full authentication and authorization of the requestor (or 494 set of requestors) and share only the authorized information to the 495 authenticated and authorized requestors. 497 A requestor beyond distrusting the network service provider, must 498 also account that the information recieved from the provider may have 499 been communicated through an undetermined network communications 500 system. That is, the posture information may have traversed through 501 many devices before reaching the requestor. As such, providing non- 502 repudiation in SACM is out of scope. However, SACM specifications 503 should provide the means for allowing non-repudiation possible and at 504 minimum, provide endpoint authentication and transport integrity. 506 A requestor may require data freshness indications, both knowledge of 507 data origination as well as time of publication so that it can make 508 more informed decisions about the relevance of the data based on its 509 currency and/or age. 511 It is also important to note that endpoint assessment reports, 512 especially as they may be provided by the target endpoint may pose 513 untrustworthy information. The considerations for this is described 514 in Section 8 of [RFC5209]. 516 The trustworthiness of the posture information given by the provider 517 to one or many requestors is dependent on several considerations. 518 Some of these include the requestor requiring: 520 o Full disclosure of the network topology path to the provider(s). 522 o Direct (peer to peer) communication with the provider. 524 o Authentication and authorization of the provider. 526 o Either or both confidentiality and integrity at the transport 527 layer. 529 o Either or both confidentiality and integrity at the data layer. 531 6. References 533 6.1. Normative References 535 [I-D.ietf-sacm-terminology] 536 Waltermire, D., Montville, A., Harrington, D., and N. Cam- 537 Winget, "Terminology for Security Assessment", draft-ietf- 538 sacm-terminology-05 (work in progress), August 2014. 540 [I-D.ietf-sacm-use-cases] 541 Waltermire, D. and D. Harrington, "Endpoint Security 542 Posture Assessment - Enterprise Use Cases", draft-ietf- 543 sacm-use-cases-07 (work in progress), April 2014. 545 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 546 Requirement Levels", BCP 14, RFC 2119, March 1997. 548 [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. 549 Tardo, "Network Endpoint Assessment (NEA): Overview and 550 Requirements", RFC 5209, June 2008. 552 6.2. Informative References 554 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 555 Information Models and Data Models", RFC 3444, January 556 2003. 558 Authors' Addresses 560 Nancy Cam-Winget 561 Cisco Systems 562 3550 Cisco Way 563 San Jose, CA 95134 564 US 566 Email: ncamwing@cisco.com 568 Lisa Lorenzin 569 Pulse Secure 570 2700 Zanker Rd., Suite 200 571 San Jose, CA 95134 572 US 574 Email: llorenzin@pulsesecure.net