idnits 2.17.1 draft-ietf-sacm-requirements-11.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 (November 3, 2015) is 3096 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-16) exists of draft-ietf-sacm-terminology-08 Summary: 0 errors (**), 0 flaws (~~), 2 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: May 6, 2016 Pulse Secure 6 November 3, 2015 8 Secure Automation and Continuous Monitoring (SACM) Requirements 9 draft-ietf-sacm-requirements-11 11 Abstract 13 This document defines the scope and set of requirements for the 14 Secure Automation and Continuous Monitoring (SACM) architecture, data 15 model and transport protocols. The requirements and scope are based 16 on the agreed upon use cases. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on May 6, 2016. 35 Copyright Notice 37 Copyright (c) 2015 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 54 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.1. Requirements for SACM . . . . . . . . . . . . . . . . . . 4 56 2.2. Requirements for the Architecture . . . . . . . . . . . . 7 57 2.3. Requirements for the Information Model . . . . . . . . . 8 58 2.4. Requirements for the Data Model . . . . . . . . . . . . . 9 59 2.5. Requirements for Data Model Operations . . . . . . . . . 12 60 2.6. Requirements for SACM Transport Protocols . . . . . . . . 13 61 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 62 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 64 5.1. Trust between Provider and Requestor . . . . . . . . . . 15 65 5.2. Privacy Considerations . . . . . . . . . . . . . . . . . 17 66 6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 17 67 6.1. -05 to -06 . . . . . . . . . . . . . . . . . . . . . . . 17 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 69 7.1. Normative References . . . . . . . . . . . . . . . . . . 17 70 7.2. Informative References . . . . . . . . . . . . . . . . . 18 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 73 1. Introduction 75 Today's environment of rapidly-evolving security threats highlights 76 the need to automate the sharing of such information while protecting 77 user information as well as the systems that store, process, and 78 transmit this information. Security threats can be detected in a 79 number of ways. SACM's charter focuses on how to collect and share 80 this information based on use cases that involve posture assessment 81 of endpoints. 83 Scalable and sustainable collection, expression, and evaluation of 84 endpoint information is foundational to SACM's objectives. To secure 85 and defend a network, one must reliably determine what devices are on 86 the network, how those devices are configured from a hardware 87 perspective, what software products are installed on those devices, 88 and how those products are configured. We need to be able to 89 determine, share, and use this information in a secure, timely, 90 consistent, and automated manner to perform endpoint posture 91 assessments. 93 This document focuses on describing the requirements for facilitating 94 the exchange of posture assessment information in the enterprise, in 95 particular, for the use cases as exemplified in 96 [I-D.ietf-sacm-use-cases]. Also, this document uses terminology 97 defined in [I-D.ietf-sacm-terminology]. 99 1.1. Requirements Language 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in RFC 2119 [RFC2119]. 105 When the words appear in lower case, their natural language meaning 106 is used. 108 2. Requirements 110 This document defines requirements based on the SACM use cases 111 defined in [I-D.ietf-sacm-use-cases]. This section describes the 112 requirements used by SACM to assess and compare candidate data 113 models, interfaces, and protocols, to suit the SACM architecture. 114 These requirements express characteristics or features that a 115 candidate protocol or data model must be capable of offering to 116 ensure security and interoperability. 118 Multiple data models, protocols, and transports may be employed in a 119 SACM environment. A SACM transport protocol is one that runs on top 120 of L3 protocols such as TCP/IP or L4 protocols such as HTTP, carries 121 operations (requests / responses), and moves data. 123 SACM defines an architecture and information model focused on 124 addressing the needs for determining, sharing, and using posture 125 information via Posture Information Providers and Posture Information 126 Consumers mediated by a Controller. With the information model 127 defining assets and attributes to facilitate the guidance, 128 collection, and assessment of posture, these are some of the tasks 129 that should be considered: 131 1. Asset Classification: Map the assets on the target endpoints to 132 asset classes. This enables identification of the attributes 133 needed to exchange information pertaining to the target endpoint. 135 2. Attribute Definition: Define the attributes desired to be 136 collected from each target endpoint. This is what we want to 137 know about a target endpoint. For instance, organizations will 138 want to know what software is installed and its many critical 139 security attributes such as patch level. 141 3. Policy Definition: This is where an organization can express its 142 policy for acceptable or problematic values of an endpoint 143 attribute. The expected values of an endpoint attribute are 144 determined for later comparison against the actual endpoint 145 attribute values during the evaluation process. Expected values 146 may include both those values which are good as well as those 147 values which represent problems, such as vulnerabilities. The 148 organization can also specify the endpoint attributes that are to 149 be present for a given target endpoint. 151 4. Information Collection: Collect information (attribute values) 152 from the target endpoint to populate the endpoint data. 154 5. Endpoint Assessment: Evaluate the actual values of the endpoint 155 attributes against those expressed in the policy. (An evaluation 156 result may become additional endpoint data). 158 6. Result Reporting: Report the results of the evaluation for use by 159 other components. Examples of use of a report would be 160 additional evaluation, network enforcement, vulnerability 161 detection, and license management. 163 2.1. Requirements for SACM 165 Many deployment scenarios can be instantiated to address the above 166 tasks and use cases defined in [I-D.ietf-sacm-use-cases]. To ensure 167 interoperability, scalability, and flexibility in any of these 168 deployments, the following requirements are defined for proposed SACM 169 standards: 171 G-001 Solution Extensibility: The information model, data models, 172 protocols, and transports defined by SACM MUST be designed to allow 173 support for future extensions, including both standard and 174 proprietary transport protocols and data models. 176 1. The information model and interfaces MUST support the ability to 177 add new operations while maintaining backwards compatibility. 178 SACM-defined transport protocols MUST have extensibility to 179 allow them to transport operations that are defined in the 180 future. 182 2. The query language MUST allow for general inquiries, as well as 183 expression of specific attributes or relationships between 184 attributes to follow; the retrieval of specific information 185 based on an event, or on a continuous basis; and the ability to 186 retrieve specific pieces of information, specific types or 187 classes of information, or the entirety of available 188 information. 190 3. The information model MUST accommodate the interoperable 191 addition of new data types and/or schemas. 193 G-002 Interoperability: The data models, protocols, and transports 194 must be specified with enough details to ensure interoperability. 196 G-003 Scalability: SACM needs to support a broad set of deployment 197 scenarios. The data models, protocols, and transports MUST be 198 scalable unless they are specifically defined to apply to a special- 199 purpose scenario, such as constrained devices. A SACM transport 200 protocol standard SHOULD include a section on scalability 201 considerations that addresses the number of endpoints and amount of 202 information to which it can reasonably be expected to scale. 203 Scalability must be addressed to support: 205 * Large datagrams: It is possible that the size of posture 206 assessment information can vary from a single assessment that is 207 small in size to a very large datagram or a very large set of 208 assessments (up to multiple gigabytes in size). 210 * Large number of providers and consumers: A deployment may consist 211 of a very large number of endpoints requesting and/or producing 212 posture assessment information. 214 * Large number of target endpoints: A deployment may be managing 215 information of a very large number of target endpoints. 217 G-004 Agility: The data model, protocols, and transports MUST be 218 suitably specified to enable implementations to fit into different 219 deployment models and scenarios, including considerations for 220 implementations of data models and transports operating in 221 constrained environments. 223 G-005 Information Extensibility: Non-standard (implementation- 224 specific) attributes MUST be supported. A method SHOULD be defined 225 for preventing collisions from occurring in the naming of all 226 attributes independent of their source. For interoperability and 227 scope boundary, the information model MUST define the mandatory set 228 of attributes. The set of attributes defined by the information 229 model MUST be well defined. 231 G-006 Data Integrity: To protect the information being shared, SACM 232 components MUST protect the integrity and confidentiality of data in 233 transit (while information is being transferred between providers 234 and consumers, and through proxies and/or repositories) and data at 235 rest (for information stored on repositories and on providers / 236 consumers). Mechanisms for this protection are unspecified but 237 should include industry best practices such as encrypted storage, 238 encrypted transports, data checksums, etc. These mechanisms are 239 required to be available (i.e. all data-handling components must 240 support them), but are not required to be used in all cases. 242 G-007 Data Partitioning: A method for partitioning data MUST be 243 supported to accommodate considerations such as geographic, 244 regulatory, operational requirements, overlay boundaries, and 245 federation (where the data may be collected in multiple locations 246 and either centralized or kept in the local region). Where 247 replication of data is supported, it is required that methods exist 248 to prevent update loops. 250 G-008 Versioning and Backward Compatibility: Announcement and 251 negotiation of versions, inclusive of existing capabilities (such as 252 transport protocols, data models, specific attributes within data 253 models, standard attribute expression sets, etc.) MUST be 254 supported. Negotiation for both versioning and capability is needed 255 to accommodate future growth and ecosystems with mixed capabilities. 257 G-009 Information Discovery: There MUST be mechanisms for components 258 to discover what information is available across the ecosystem (i.e. 259 a method for cataloging data available in the ecosystem and 260 advertising it to consumers), where to go to get a specific piece of 261 that information (i.e. which provider has the information), and what 262 schemas are in use for organizing the information. For example, 263 providing a method by which a node can locate the advertised 264 information so that consumers are not required to have a priori 265 knowledge to find available information. 267 G-010 Target Endpoint Discovery: SACM MUST define the means by which 268 target endpoints may be discovered. Use Case 2.1.2 describes the 269 need to discover endpoints and their composition. 271 G-011 Push and Pull Access: Three methods of data access MUST be 272 supported: the standard Pull model as well as solicited and 273 unsolicited Push models. All of the methods of data access MUST 274 support the ability for the initiator to filter the set of posture 275 assessment information to be delivered. Additionally, the provider 276 of the information MUST be able to filter the set of posture 277 assessment information based on the permissions of the recipient. 278 This requirement is driven by use cases 2.1.3, 2.1.4 and 2.1.5. 280 G-012 Device Interface: The interfaces by which SACM components 281 communicate to share endpoint posture information MUST be well 282 defined. That is, the interface defines the data model, SACM 283 transport protocols, and network transport protocols to enable SACM 284 components to communicate. [Revised per our 6/29 conversation - 285 does this work? -LL] 287 G-013 Endpoint Location and Network Topology: The SACM architecture 288 and interfaces MUST allow for the target endpoint (network) location 289 and network topology to be modeled and understood. Where 290 appropriate, the data model and the interfaces SHOULD allow for 291 discovery of the target endpoint location or network topology or 292 both. 294 G-014 Target Endpoint Identity: The SACM architecture and interfaces 295 MUST support the ability of components to provide attributes that 296 can be used to compose an identity for a target endpoint. These 297 identities MAY be composed of attributes from one or more SACM 298 components. 300 G-015 Data Access Control: Methods of access control MUST be 301 supported to accommodate considerations such as geographic, 302 regulatory, operational and federations. Entities accessing or 303 publishing data MUST identify themselves and pass access policy. 305 2.2. Requirements for the Architecture 307 At the simplest abstraction, the SACM architecture represents the 308 core components and interfaces needed to perform the production and 309 consumption of posture assessment information. Requirements relating 310 to SACM's architecture include: 312 ARCH-001 Scalability: The architectural components MUST account for 313 a range of deployments, from very small sets of endpoints to very 314 large deployments. 316 ARCH-002 Flexibility: The architectural components MUST account for 317 different deployment scenarios where the architectural components 318 may be implemented, deployed, or used within a single application, 319 service, or network, or may comprise a federated system. 321 ARCH-003 Separation of Data and Management Functions: SACM MUST 322 define both the configuration and management of the SACM data models 323 and protocols used to transport and share posture assessment 324 information. 326 ARCH-004 Topology Flexibility: Both centralized and decentralized 327 (peer-to-peer) information exchange MUST be supported. Centralized 328 data exchange enables use of a common data format to bridge together 329 data exchange between diverse systems, and can leverage a virtual 330 data store that centralizes and offloads all data access, storage, 331 and maintenance to a dedicated resource. Decentralized data 332 exchange enables simplicity of sharing data between relatively 333 uniform systems, and between small numbers of systems, especially 334 within a single enterprise domain. The fact that a centralized or 335 decentralized deployment is used SHOULD be invisible to a consumer. 337 ARCH-005 Capability Negotiation: Announcement and negotiation of 338 functional capabilities (such as authentication protocols, 339 authorization schemes, data models, transport protocols, etc.) must 340 be supported, enabling a SACM component to make inquiries about the 341 capabilities of other components in the SACM ecosystem. 343 ARCH-006 Role-based Authorization: The SACM architecture MUST be 344 capable of effecting role-based authorization. Distinction of 345 endpoints capable of and authorized to provide or consume 346 information is required to address appropriate access controls. 348 ARCH-007 Context-based Authorization: The SACM architecture MUST be 349 capable of effecting context-based authorization. Different 350 policies (e.g. business, regulatory, etc.) might specify what data 351 may be exposed to, or shared by, consumers based on one or more 352 attributes of the consumer. The policy might specify that consumers 353 are required to share specific information either back to the system 354 or to administrators. 356 ARCH-008 Time Synchronization: Actions or decisions based on time- 357 sensitive data (such as user logon/logoff, endpoint connection/ 358 disconnection, endpoint behavior events, etc.) are all predicated on 359 a synchronized understanding of time. The SACM architecture MUST 360 provide a mechanism for all components to synchronize time. A 361 mechanism for detecting and reporting time discrepancies SHOULD be 362 provided by the architecture and reflected in the information model. 364 2.3. Requirements for the Information Model 366 The SACM information model represents the abstracted representation 367 for Posture Assessment information to be communicated. SACM data 368 models must adhere to and comply with the SACM information model. 369 The requirements for the SACM information model include: 371 IM-001 Extensible Attribute Vocabulary: The information model MUST 372 define a minimum set of attributes for communicating Posture 373 Information, to ensure interoperability between data models. 374 (Individual data models may define attributes beyond the mandatory- 375 to-implement minimum set.) The attributes should be defined with a 376 clear mechanism for extensibility to enable data models to adhere to 377 SACM's required attributes as well as allow for their own 378 extensions. The attribute vocabulary should be defined with a clear 379 mechanism for extensibility to enable future versions of the 380 information model to be interoperably expanded with new attributes. 382 IM-002 Posture Data Publication: The information model MUST allow 383 for the data to be provided by a SACM component either solicited or 384 unsolicited. No aspect of the information model should be dependent 385 upon or assume a push (unsolicited) or pull (solicited) model of 386 publication. 388 IM-003 Data Model Negotiation: SACM's information model MUST allow 389 support for different data models, data model versions, and 390 different versions of the operations (and network layer transport). 391 The SACM information model MUST include the ability to discover and 392 negotiate the use of a particular data model or any data model. 394 IM-004 Data Model Identification: The information model MUST provide 395 a means to uniquely identify each data model uniquely. The 396 identifier MUST contain both an identifier of the data model and a 397 version indicator for the data model. The identifiers SHOULD be 398 decomposable so that a customer can query for any version of a 399 specific data model and compare returned values for older or newer 400 than a desired version. 402 IM-005 Data Lifetime Management: The information model MUST provide 403 a means to allow data models to include data lifetime management. 404 The information model must identify attributes that can allow data 405 models to, at minimum, identify the data's origination time and 406 expected time of next update or data longevity (how long should the 407 data be assumed to still be valid). 409 IM-006 Singularity and Modularity: The SACM information model MUST 410 be singular (i.e. there is only one information model, not multiple 411 alternative information models from which to choose) and MAY be 412 modular (a conjunction of several sub-components) for ease of 413 maintenance and extension. For example, endpoint identification 414 could be an independent sub-component of the information model, to 415 simplify updating of endpoint identification attributes. 417 2.4. Requirements for the Data Model 419 The SACM information model represents an abstraction for "what" 420 information can be communicated and "how" it is to be represented and 421 shared. It is expected that as applications may produce posture 422 assessment information, they may share it using a specific data 423 model. Similarly, applications consuming or requesting posture 424 assessment information, may require it be based on a specific data 425 model. Thus, while there may exist different data models and 426 schemas, they should adhere to the SACM information model and meet 427 the requirements defined in this section. 429 The specific requirements for candidate data models include: 431 DM-001 Element Association: The data model MUST contain a data model 432 element for each information model element (e.g. endpoint, IP 433 address, asset). In other words, for every item in the information 434 model, there must be an item in the data model. The data model can 435 also include elements that do not exist in the information model. 437 DM-002 Data Model Structure: The data model can be structured either 438 as one single module or separated into modules and sub-modules that 439 allow for references between them. The data model structure MAY 440 reflect structure in the information model, but does not need to. 441 For example, the data model might use one module to define 442 endpoints, and that module might reference other modules that 443 describe the various assets associated with the endpoint. 444 Constraints and interfaces might further be defined to resolve or 445 tolerate ambiguity in the references (e.g. same IP address used in 446 two separate networks). 448 DM-003 Search Flexibility: The search interfaces and actions MUST 449 include the ability to start a search anywhere within a data model 450 structure, and the ability to search based on patterns ("wildcard 451 searches") as well as specific data elements. 453 DM-004 Full vs. Partial Updates: The data model SHOULD include the 454 ability to allow providers of data to provide the data as a whole, 455 or when updates occur. For example, a consumer can request a full 456 update on initial engagement, then request to receive deltas 457 (updates containing only the changes since the last update) on an 458 ongoing basis as new data is generated. 460 DM-005 Loose Coupling: The data model SHOULD allow for a loose 461 coupling between the provider and the consumer, such that the 462 consumer can request information without being required to request 463 it from a specific provider, and a provider can publish information 464 without having a specific consumer targeted to receive it. 466 DM-006 Data Cardinality: The data model MUST describe their 467 constraints (e.g. cardinality). As posture information and the 468 tasks for collection, aggregation, or evaluation, could comprise one 469 or more attributes, interfaces and actions MUST allow and account 470 for such cardinality as well as whether the attributes are 471 conditional, optional, or mandatory. 473 DM-007 Data Model Negotiation: The interfaces and actions in the 474 data model MUST include capability negotiation to enable discovery 475 of supported and available data types and schemas. 477 DM-008 Data Origin: The data model MUST include the ability for 478 consumers to identify the data origin (provider that collected the 479 data). 481 DM-009 Origination Time: The data model SHOULD allow the provider to 482 include the information's origination time. 484 DM-010 Data Generation: The data model MUST allow the provider to 485 include attributes defining how the data was generated (e.g. self- 486 reported, reported by aggregator, scan result, etc.). 488 DM-011 Data Source: The data model MUST allow the provider to 489 include attributes defining the data source (target endpoint from 490 which the data was collected) - e.g. hostname, domain (DNS) name or 491 application name. 493 DM-012 Data Updates: The data model SHOULD allow the provider to 494 include attributes defining whether the information provided is a 495 delta, partial, or full set of information. 497 DM-013 Multiple Collectors: The data model MUST support the 498 collection of attributes by a variety of collectors, including 499 internal collectors, external collectors with an authenticated 500 relationship with the endpoint, and external collectors based on 501 network and other observers. 503 DM-014 Attribute Extensibility: Use Cases in the whole of Section 2 504 describe the need for an attribute dictionary. With SACM's scope 505 focused on posture assessment, the data model attribute collection 506 and aggregation MUST have a well-understood set of attributes 507 inclusive of their meaning or usage intent. The data model MUST 508 include all attributes defined in the information model and MAY 509 include additional attributes beyond those found in the information 510 model. Additional attributes MUST be defined in accordance with the 511 extensibility framework provided in the information model. 513 DM-015 Solicited vs. Unsolicited Updates: The data model MUST enable 514 a provider to publish data either solicited (in response to a 515 request from a consumer) or unsolicited (as new data is generated, 516 without a request required). For example, an external collector can 517 publish data in response to a request by a consumer for information 518 about an endpoint, or can publish data as it observes new 519 information about an endpoint, without any specific consumer request 520 triggering the publication; a compliance-server provider may publish 521 endpoint posture information in response to a request from a 522 consumer (solicited), or it may publish posture information driven 523 by a change in the posture of the endpoint (unsolicited). 525 DM-016 Transport Agnostic: The data model MUST be transport 526 agnostic, to allow for the data operations to leverage the most 527 appropriate SACM transport protocol. 529 2.5. Requirements for Data Model Operations 531 Posture information data adhering to a data model must also provide 532 interfaces that include operations for access and production of the 533 data. Operations requirements are distinct from transport 534 requirements in that operations requirements are requirements on the 535 application performing requests and responses, whereas transport 536 requirements are requirements on the transport protocol carrying the 537 requests / responses. The specific requirements for such operations 538 include: 540 OP-001 Time Synchronization: Request and response operations MUST be 541 timestamped, and published information SHOULD capture time of 542 publication. Actions or decisions based on time-sensitive data 543 (such as user logon/logoff, endpoint connection/disconnection, 544 endpoint behavior events, etc.) are all predicated on a synchronized 545 understanding of time. A method for detecting and reporting time 546 discrepancies SHOULD be provided. 548 OP-002 Collection Abstraction: Collection is the act of a SACM 549 component gathering data from a target endpoint. The request for a 550 data item MUST include enough information to properly identify the 551 item to collect, but the request shall not be a command to directly 552 execute nor directly be applied as arguments to a command. The 553 purpose of this requirement is primarily to reduce the potential 554 attack vectors, but has the additional benefit of abstracting the 555 request for collection from the collection method, thereby allowing 556 more flexibility in how collection is implemented. 558 OP-003 Collection Composition: A collection request MAY be composed 559 of multiple collection requests (which yield collected values). The 560 desire for multiple values MUST be expressed as part of the 561 collection request, so that the aggregation can be resolved at the 562 point of collection without having to interact with the requestor. 563 This requirement SHOULD NOT be interpreted as preventing a collector 564 from providing attributes which were not part of the original 565 request. 567 OP-004 Attribute-based Query: A query operation is the act of 568 requesting data from a provider. Query operations SHOULD be based 569 on a set of attributes. Query operations MUST support both a query 570 for specific attributes and a query for all attributes. Use Case 571 2.1.2 describes the need for the data model to support a query 572 operation based on a set of attributes to facilitate collection of 573 information such as posture assessment, inventory (of endpoints or 574 endpoint components), and configuration checklist. 576 OP-005 Information-based Query with Filtering: The query operation 577 MUST support filtering. Use Case 2.1.3 describes the need for the 578 data model to support the means for the information to be collected 579 through a query mechanism. Furthermore, the query operation 580 requires filtering capabilities to allow for only a subset of 581 information to be retrieved. The query operation MAY be a 582 synchronous request or asynchronous request. 584 OP-006 Data Model Scalability: The operation resulting from a query 585 operation MUST be able to handle the return and receipt of large 586 amounts of data. Use Cases 2.1.4 and 2.1.5 describes the need for 587 the data model to support scalability. For example, the query 588 operation may result in a very large set of attributes, as well as a 589 large set of targets. 591 OP-007 Data Abstraction: The data model MUST allow a SACM component 592 to communicate what data was used to construct the target endpoint's 593 identity, so other SACM components can determine whether they are 594 constructing an equivalent target endpoint (and their identity) and 595 whether they have confidence in that identity. SACM components 596 SHOULD have interfaces defined to transmit this data directly or to 597 refer to where the information can be retrieved. 599 OP-008 Provider Restriction: Request operations MUST include the 600 ability to restrict the data to be provided by a specific provider 601 or a provider with specific characteristics. Response operations 602 MUST include the ability to identify the provider that supplied the 603 response. For example, a SACM Consumer should be able to request 604 that all of the data come from a specific provider by identity (e.g. 605 Provider A) or from a Provider that is in a specific location (e.g. 606 in the Boston office). 608 2.6. Requirements for SACM Transport Protocols 610 The term transport protocol is frequently overloaded. The term SACM 611 transport protocol is intended to be distinguished from underlying 612 layer 3 and 4 protocols such as TCP/IP and TLS. However, it is 613 possible that a layer 3 or 4 protocol may be used as a SACM transport 614 protocol, either alone or as part of a SACM transport protocol (i.e. 615 using HTTP over TLS with XML as the content). The SACM transport 616 protocol is focused on moving data and performing necessary access 617 control operations; it is agnostic to the data model operations. 619 The requirements for SACM transport protocols include: 621 T-001 Multiple Transport Protocol Support: SACM transport protocols 622 MUST support different network transport protocols in a deployment 623 to support different transport layer requirements, different device 624 capabilities, and system configurations dealing with connectivity. 626 T-002 Data Integrity: SACM transport protocols MUST be able to 627 ensure data integrity for data in transit. 629 T-003 Data Confidentiality: SACM transport protocols MUST be able to 630 support data confidentiality. SACM transport protocols MUST ensure 631 data protection for data in transit (e.g. by encryption) to provide 632 confidentiality, integrity, and robustness against protocol-based 633 attacks. Note that while the transport MUST be able to support data 634 confidentiality, implementations MAY choose to make confidentiality 635 optional. Protection for data at rest is not in scope for transport 636 protocols. Data protection MAY be used for both privacy and non- 637 privacy scenarios. 639 T-004 Transport Protection: SACM transport protocols MUST be capable 640 of supporting mutual authentication and replay protection. 642 T-005 Transport Reliability: SACM transport protocols MUST provide 643 reliable delivery of data. This includes the ability to perform 644 fragmentation and reassembly, and to detect replays. 646 T-006 Transport Layer Requirements: Each SACM transport protocol 647 MUST clearly specify the transport layer requirements it needs to 648 operate correctly. Examples of items that may need to be specified 649 include connectivity requirements, replay requirements, data link 650 encryption requirements, and/or channel binding requirements. These 651 requirements are needed in order for deployments to be done 652 correctly. For example, a proxy server between UDP and TCP can 653 provide a connection that correctly fulfills the connectivity and 654 replay requirements as well as data link requirements (through the 655 use of TLS and DTLS) but would be unable to provide a channel 656 binding requirement, as that implies there is no MITM to look at the 657 data. 659 3. Acknowledgements 661 The authors would like to thank Barbara Fraser, Jim Bieda, and Adam 662 Montville for reviewing and contributing to this draft. In addition, 663 we recognize valuable comments and suggestions made by Jim Schaad and 664 Chris Inacio. 666 4. IANA Considerations 668 This memo includes no request to IANA. 670 5. Security Considerations 672 This document defines the requirements for SACM. As such, it is 673 expected that several data models, protocols, and transports may be 674 defined or reused from already existing standards. This section will 675 highlight security considerations that may apply to SACM based on the 676 architecture and standards applied in SACM. In particular, 677 highlights to security considerations that may apply to the SACM 678 reference architecture and standard data models and transports will 679 be discussed. 681 To address security and privacy considerations, the data model, 682 protocols, and transports must consider authorization based on 683 consumer function and privileges, to only allow authorized consumers 684 and providers to access specific information being requested or 685 published. 687 To enable federation across multiple entities (such as across 688 organizational or geographic boundaries) authorization must also 689 extend to infrastructure elements themselves, such as central 690 controllers / brokers / data repositories. 692 In addition, authorization needs to extend to specific information or 693 resources available in the environment. In other words, 694 authorization is based on the subject (the information requestor), 695 the provider (the information responder), the object (the endpoint 696 the information is being requested on), and the attribute (what piece 697 of data is being requested). The method by which this authorization 698 is applied is unspecified. 700 SACM's charter focuses on the sharing of posture information for 701 improving efficacy of security applications such as compliance, 702 configuration, assurance and other threat and vulnerability reporting 703 and remediation systems. While the goal is to facilitate the flow of 704 information securely, it is important to note that participating 705 endpoints may not be cooperative or trustworthy. 707 5.1. Trust between Provider and Requestor 709 The information given from the provider to a requestor may come with 710 different levels of trustworthiness given the different potential 711 deployment scenarios and compromise either at the provider, the 712 requesting consumer, or devices that are involved in the transport 713 between the provider and requestor. This section will describe the 714 different considerations that may reduce the level of trustworthiness 715 of the information provided. 717 In the information transport flow, it is possible that some of the 718 devices may serve as proxies or brokers and as such, may be able to 719 observe the communications flowing between an information provider 720 and requestor. Without appropriate protections, it is possible for 721 these proxies and brokers to inject and affect man-in-the-middle 722 attacks. 724 It is common to, in general, distrust the network service provider, 725 unless the full hop by hop communications process flow is well 726 understood. As such, the posture information provider should protect 727 the posture information data it provides as well as the transport it 728 uses. Similarly, while there may be providers whose goal is to 729 openly share its information, there may also be providers whose 730 policy is to grant access to certain posture information based on its 731 business or regulatory policy. In those situations, a provider may 732 require full authentication and authorization of the requestor (or 733 set of requestors) and share only the authorized information to the 734 authenticated and authorized requestors. 736 A requestor beyond distrusting the network service provider, must 737 also account that the information received from the provider may have 738 been communicated through an undetermined network communications 739 system. That is, the posture information may have traversed through 740 many devices before reaching the requestor. SACM specifications 741 should provide the means for verifying data origin and data integrity 742 and at minimum, provide endpoint authentication and transport 743 integrity. 745 A requestor may require data freshness indications, both knowledge of 746 data origination as well as time of publication so that it can make 747 more informed decisions about the relevance of the data based on its 748 currency and/or age. 750 It is also important to note that endpoint assessment reports, 751 especially as they may be provided by the target endpoint may pose 752 untrustworthy information. The considerations for this is described 753 in Section 8 of [RFC5209]. 755 The trustworthiness of the posture information given by the provider 756 to one or many requestors is dependent on several considerations. 757 Some of these include the requestor requiring: 759 o Full disclosure of the network topology path to the provider(s). 761 o Direct (peer to peer) communication with the provider. 763 o Authentication and authorization of the provider. 765 o Either or both confidentiality and integrity at the transport 766 layer. 768 o Either or both confidentiality and integrity at the data layer. 770 5.2. Privacy Considerations 772 SACM information may contain sensitive information about the target 773 endpoint as well as revealing identity information of the producer or 774 consumer of such information. Similarly, as part of the SACM 775 discovery mechanism, the advertised capabilities (and roles, e.g. 776 SACM components enabled) by the endpoint may be construed as private 777 information. There may be applications as well as business and 778 regulatory practicess that require that aspects of such information 779 be hidden from any parties that do not need to know it. 781 Data confidentiality can provide some level of privacy but may fall 782 short where unecessary data is still transmitted. In those cases, 783 filtering requirements at the data model such as OP-005 must be 784 applied to ensure that such data is not disclosed. [RFC6973] 785 provides guidelines for which SACM protocols and information and data 786 models should follow. 788 6. Change Log 790 6.1. -05 to -06 792 Updated G-005 to clarify the MUST to allow non-standard extensions, 793 SHOULD avoid collisions and ensure interoperability. 795 Cleaned up and clarified IM-003, DM-001. 797 Cleaned up some of the OP-XXX and ARCH-XXX per Jim Schaad's comments. 799 Updated some of the text around Editor notes and removed all 'Editor 800 Note' comments 802 7. References 804 7.1. Normative References 806 [I-D.ietf-sacm-terminology] 807 Birkholz, H., "Secure Automation and Continuous Monitoring 808 (SACM) Terminology", draft-ietf-sacm-terminology-08 (work 809 in progress), October 2015. 811 [I-D.ietf-sacm-use-cases] 812 Waltermire, D. and D. Harrington, "Endpoint Security 813 Posture Assessment - Enterprise Use Cases", draft-ietf- 814 sacm-use-cases-10 (work in progress), July 2015. 816 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 817 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 818 RFC2119, March 1997, 819 . 821 [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. 822 Tardo, "Network Endpoint Assessment (NEA): Overview and 823 Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008, 824 . 826 7.2. Informative References 828 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 829 Morris, J., Hansen, M., and R. Smith, "Privacy 830 Considerations for Internet Protocols", RFC 6973, DOI 831 10.17487/RFC6973, July 2013, 832 . 834 Authors' Addresses 836 Nancy Cam-Winget 837 Cisco Systems 838 3550 Cisco Way 839 San Jose, CA 95134 840 US 842 Email: ncamwing@cisco.com 844 Lisa Lorenzin 845 Pulse Secure 846 2700 Zanker Rd., Suite 200 847 San Jose, CA 95134 848 US 850 Email: llorenzin@pulsesecure.net