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