idnits 2.17.1 draft-ietf-sacm-requirements-16.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 15, 2017) is 2507 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-12 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: December 17, 2017 Pulse Secure 6 June 15, 2017 8 Security Automation and Continuous Monitoring (SACM) Requirements 9 draft-ietf-sacm-requirements-16 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 December 17, 2017. 35 Copyright Notice 37 Copyright (c) 2017 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 . . . . . . . . 14 61 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 62 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 64 5.1. Trust between Provider and Requestor . . . . . . . . . . 16 65 5.2. Privacy Considerations . . . . . . . . . . . . . . . . . 17 66 6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 17 67 6.1. -05 to -06 . . . . . . . . . . . . . . . . . . . . . . . 17 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 69 7.1. Normative References . . . . . . . . . . . . . . . . . . 18 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 security information (such as 77 posture information) while protecting user information as well as the 78 systems that store, process, and transmit this information. Security 79 threats can be detected in a number of ways. SACM's charter focuses 80 on how to collect and share this information based on use cases that 81 involve posture assessment 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 [RFC7632]. Also, 96 this document uses terminology defined in 97 [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 described in [RFC7632]. This section describes the requirements used 112 by SACM to assess and compare candidate data models, interfaces, and 113 protocols, to suit the SACM architecture. These requirements express 114 characteristics or features that a candidate protocol, information 115 model, or data model must be capable of offering to ensure security 116 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 target endpoint and/or the assets 132 on the target endpoints to asset classes. This enables 133 identification of the attributes needed to exchange information 134 pertaining to the target endpoint. 136 2. Attribute Definition: Define the attributes desired to be 137 collected from each target endpoint. For instance, organizations 138 will want to know what software is installed and its 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 [RFC7632]. 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 (SACM) extensions. SACM MUST allow 174 implementations to use their own extensions; either proprietary data 175 models, protocols or extensions to SACM data models or protocols 176 could be used though they are not considered to be SACM compliant. 178 1. The information model and programmatic interfaces (see G-012 for 179 one example) MUST support the ability to add new operations 180 while maintaining backwards compatibility. SACM-defined 181 transport protocols MUST have extensibility to allow them to 182 transport operations that are defined in the future. 184 2. The query language MUST allow for general inquiries, as well as 185 expression of specific attributes or relationships between 186 attributes to follow; the retrieval of specific information 187 based on an event, or on a continuous basis; and the ability to 188 retrieve specific pieces of information, specific types or 189 classes of information, or the entirety of available 190 information. 192 3. The information model MUST accommodate the interoperable 193 addition of new data types and/or schemas. 195 G-002 Interoperability: The data models, protocols, and transports 196 must be specified with enough details to ensure interoperability. 198 G-003 Scalability: SACM needs to support a broad set of deployment 199 scenarios. The data models, protocols, and transports MUST be 200 scalable unless they are specifically defined to apply to a special- 201 purpose scenario, such as constrained devices. A SACM transport 202 protocol standard SHOULD include a section on scalability 203 considerations that addresses the number of endpoints and amount of 204 information to which it can reasonably be expected to scale. 205 Scalability must be addressed to support: 207 * Large datagrams: It is possible that the size of posture 208 assessment information can vary from a single assessment that is 209 small in size to a very large datagram or a very large set of 210 assessments (up to multiple gigabytes in size). 212 * Large number of datagrams per second: A deployment may involve 213 many rapid or simultaneous events that require processing, 214 generating many datagrams per second. 216 * Large number of providers and consumers: A deployment may consist 217 of a very large number of endpoints requesting and/or producing 218 posture assessment information. 220 * Large number of target endpoints: A deployment may be managing 221 information of a very large number of target endpoints. 223 G-004 Versatility: The data model, protocols, and transports MUST be 224 suitably specified to enable implementations to fit into different 225 deployment models and scenarios, including considerations for 226 implementations of data models and transports operating in 227 constrained environments. Separate solutions may be necessary to 228 meet the needs of specific deployment models and scenarios. 230 G-005 Information Extensibility: Non-standard (implementation- 231 specific) attributes MUST be supported. A method SHOULD be defined 232 for preventing collisions from occurring in the naming of all 233 attributes independent of their source. For interoperability and 234 scope boundary, the information model MUST define the mandatory set 235 of attributes. 237 G-006 Data Integrity: To protect the information being shared, SACM 238 components MUST protect the integrity and confidentiality of data in 239 transit (while information is being transferred between providers 240 and consumers, and through middle boxes and/or repositories) and 241 data at rest (for information stored on repositories and on 242 providers / consumers). Mechanisms for this protection are 243 unspecified but should include industry best practices such as 244 encrypted storage, encrypted transports, data checksums, etc. These 245 mechanisms are required to be available (i.e. all data-handling 246 components must support them), but are not required to be used in 247 all cases. 249 G-007 Data Partitioning: A method for partitioning data MUST be 250 supported to accommodate considerations such as geographic, 251 regulatory, operational requirements, overlay boundaries, and 252 federation (where the data may be collected in multiple locations 253 and either centralized or kept in the local region). Where 254 replication of data is supported, it is required that methods exist 255 to prevent update loops. 257 G-008 Versioning and Backward Compatibility: Announcement and 258 negotiation of versions, inclusive of existing capabilities (such as 259 transport protocols, data models, specific attributes within data 260 models, standard attribute expression sets, etc.) MUST be 261 supported. Negotiation for both versioning and capabilities is 262 needed to accommodate future growth and ecosystems with mixed 263 capabilities. 265 G-009 Information Discovery: There MUST be mechanisms for components 266 to discover what information is available across the ecosystem (i.e. 267 a method for cataloging data available in the ecosystem and 268 advertising it to consumers), where to go to get a specific piece of 269 that information (i.e. which provider has the information), and what 270 schemas are in use for organizing the information. For example, 271 providing a method by which a node can locate the advertised 272 information so that consumers are not required to have a priori 273 knowledge to find available information. 275 G-010 Target Endpoint Discovery: SACM MUST define the means by which 276 target endpoints may be discovered. Use Case 2.1.2 describes the 277 need to discover endpoints and their composition. 279 G-011 Push and Pull Access: Three methods of data access MUST be 280 supported: a Pull model, a solicited Push model, and an unsolicited 281 Push models. All of the methods of data access MUST support the 282 ability for the initiator to filter the set of posture assessment 283 information to be delivered. Additionally, the provider of the 284 information MUST be able to filter the set of posture assessment 285 information based on the permissions of the recipient. This 286 requirement is driven by use cases 2.1.3, 2.1.4 and 2.1.5. 288 G-012 SACM Component Interface: The interfaces by which SACM 289 components communicate to share endpoint posture information MUST be 290 well defined. That is, the interface defines the data model, SACM 291 transport protocols, and network transport protocols to enable SACM 292 components to communicate. 294 G-013 Endpoint Location and Network Topology: The SACM architecture 295 and interfaces MUST allow for the target endpoint (network) location 296 and network topology to be modeled and understood. Where 297 appropriate, the data model and the interfaces SHOULD allow for 298 discovery of the target endpoint location or network topology or 299 both. 301 G-014 Target Endpoint Identity: The SACM architecture and interfaces 302 MUST support the ability of components to provide attributes that 303 can be used to compose an identity for a target endpoint. These 304 identities MAY be composed of attributes from one or more SACM 305 components. 307 G-015 Data Access Control: Methods of access control MUST be 308 supported to accommodate considerations such as geographic, 309 regulatory, operational and federations. Entities accessing or 310 publishing data MUST identify themselves and pass access policy. 312 2.2. Requirements for the Architecture 314 At the simplest abstraction, the SACM architecture represents the 315 core components and interfaces needed to perform the production and 316 consumption of posture assessment information. Requirements relating 317 to SACM's architecture include: 319 ARCH-001 Scalability: The architectural components MUST account for 320 a range of deployments, from very small sets of endpoints to very 321 large deployments. 323 ARCH-002 Flexibility: The architectural components MUST account for 324 different deployment scenarios where the architectural components 325 may be implemented, deployed, or used within a single application, 326 service, or network, or may comprise a federated system. 328 ARCH-003 Separation of Data and Management Functions: SACM MUST 329 define both the configuration and management of the SACM data models 330 and protocols used to transport and share posture assessment 331 information. 333 ARCH-004 Topology Flexibility: Both centralized and decentralized 334 (peer-to-peer) information exchange MUST be supported. Centralized 335 data exchange enables use of a common data format to bridge together 336 data exchange between diverse systems, and can leverage a virtual 337 data store that centralizes and offloads all data access, storage, 338 and maintenance to a dedicated resource. Decentralized data 339 exchange enables simplicity of sharing data between relatively 340 uniform systems, and between small numbers of systems, especially 341 within a single enterprise domain. The fact that a centralized or 342 decentralized deployment is used SHOULD be invisible to a consumer. 344 ARCH-005 Capability Negotiation: Announcement and negotiation of 345 functional capabilities (such as authentication protocols, 346 authorization schemes, data models, transport protocols, etc.) MUST 347 be supported, enabling a SACM component to make inquiries about the 348 capabilities of other components in the SACM ecosystem. 350 ARCH-006 Role-based Authorization: The SACM architecture MUST be 351 capable of effecting role-based authorization. Distinction of 352 endpoints capable of and authorized to provide or consume 353 information is required to address appropriate access controls. 355 ARCH-007 Context-based Authorization: The SACM architecture MUST be 356 capable of effecting context-based authorization. Different 357 policies (e.g. business, regulatory, etc.) might specify what data 358 may be exposed to, or shared by, consumers based on one or more 359 attributes of the consumer. The policy might specify that consumers 360 are required to share specific information either back to the system 361 or to administrators. 363 ARCH-008 Time Synchronization: Actions or decisions based on time- 364 sensitive data (such as user logon/logoff, endpoint connection/ 365 disconnection, endpoint behavior events, etc.) are all predicated on 366 a synchronized understanding of time. The SACM architecture MUST 367 provide a mechanism for all components to synchronize time. A 368 mechanism for detecting and reporting time discrepancies SHOULD be 369 provided by the architecture and reflected in the information model. 371 2.3. Requirements for the Information Model 373 The SACM information model represents the abstracted representation 374 for Posture Assessment information to be communicated. SACM data 375 models must adhere to and comply with the SACM information model. 376 The requirements for the SACM information model include: 378 IM-001 Extensible Attribute Vocabulary: The information model MUST 379 define a minimum set of attributes for communicating Posture 380 Information, to ensure interoperability between data models. 382 (Individual data models may define attributes beyond the mandatory- 383 to-implement minimum set.) The attributes should be defined with a 384 clear mechanism for extensibility to enable data models to adhere to 385 SACM's required attributes as well as allow for their own 386 extensions. The attribute vocabulary should be defined with a clear 387 mechanism for extensibility to enable future versions of the 388 information model to be interoperably expanded with new attributes. 390 IM-002 Posture Data Publication: The information model MUST allow 391 for the data to be provided by a SACM component either solicited or 392 unsolicited. No aspect of the information model should be dependent 393 upon or assume a push or pull model of publication. 395 IM-003 Data Model Negotiation: SACM's information model MUST allow 396 support for different data models, data model versions, and 397 different versions of the operations on the data models and 398 transport protocols. The SACM information model MUST include the 399 ability to discover and negotiate the use of a particular data model 400 or any data model. 402 IM-004 Data Model Identification: The information model MUST provide 403 a means to uniquely identify each data model uniquely. The 404 identifier MUST contain both an identifier of the data model and a 405 version indicator for the data model. The identifiers SHOULD be 406 decomposable so that a customer can query for any version of a 407 specific data model and compare returned values for older or newer 408 than a desired version. 410 IM-005 Data Lifetime Management: The information model MUST provide 411 a means to allow data models to include data lifetime management. 412 The information model must identify attributes that can allow data 413 models to, at minimum, identify the data's origination time and 414 expected time of next update or data longevity (how long should the 415 data be assumed to still be valid). 417 IM-006 Singularity and Modularity: The SACM information model MUST 418 be singular (i.e. there is only one information model, not multiple 419 alternative information models from which to choose) and MAY be 420 modular (a conjunction of several sub-components) for ease of 421 maintenance and extension. For example, endpoint identification 422 could be an independent sub-component of the information model, to 423 simplify updating of endpoint identification attributes. 425 2.4. Requirements for the Data Model 427 The SACM information model represents an abstraction for "what" 428 information can be communicated and "how" it is to be represented and 429 shared. It is expected that as applications may produce posture 430 assessment information, they may share it using a specific data 431 model. Similarly, applications consuming or requesting posture 432 assessment information, may require it be based on a specific data 433 model. Thus, while there may exist different data models and 434 schemas, they should adhere to the SACM information model and meet 435 the requirements defined in this section. 437 The specific requirements for candidate data models include: 439 DM-001 Element Association: A SACM Information Model consists of a 440 set of SACM Information Model elements. A SACM Data Model MUST be 441 derived from the SACM Information Model. A SACM Data Model consists 442 of a set of SACM Data Model elements. In this derivation, a SACM 443 Data Model element MAY map to one or more SACM Information Model 444 elements. In addition, a SACM Data Model MAY include additional 445 Data Model elements that are not associated with any SACM 446 Information Model elements. 448 DM-002 Data Model Structure: The data model can be structured either 449 as one single module or separated into modules and sub-modules that 450 allow for references between them. The data model structure MAY 451 reflect structure in the information model, but does not need to. 452 For example, the data model might use one module to define 453 endpoints, and that module might reference other modules that 454 describe the various assets associated with the endpoint. 455 Constraints and interfaces might further be defined to resolve or 456 tolerate ambiguity in the references (e.g. same IP address used in 457 two separate networks). 459 DM-003 Search Flexibility: The search interfaces and actions MUST 460 include the ability to start a search anywhere within a data model 461 structure, and the ability to search based on patterns ("wildcard 462 searches") as well as specific data elements. 464 DM-004 Full vs. Partial Updates: The data model SHOULD include the 465 ability to allow providers of data to provide the data as a whole, 466 or when updates occur. For example, a consumer can request a full 467 update on initial engagement, then request to receive deltas 468 (updates containing only the changes since the last update) on an 469 ongoing basis as new data is generated. 471 DM-005 Loose Coupling: The data model SHOULD allow for a loose 472 coupling between the provider and the consumer, such that the 473 consumer can request information without being required to request 474 it from a specific provider, and a provider can publish information 475 without having a specific consumer targeted to receive it. 477 DM-006 Data Cardinality: The data model MUST describe their 478 constraints (e.g. cardinality). As posture information and the 479 tasks for collection, aggregation, or evaluation, could comprise one 480 or more attributes, interfaces and actions MUST allow and account 481 for such cardinality as well as whether the attributes are 482 conditional, optional, or mandatory. 484 DM-007 Data Model Negotiation: The interfaces and actions in the 485 data model MUST include capability negotiation to enable discovery 486 of supported and available data types and schemas. 488 DM-008 Data Origin: The data model MUST include the ability for 489 consumers to identify the data origin (provider that collected the 490 data). 492 DM-009 Origination Time: The data model SHOULD allow the provider to 493 include the information's origination time. 495 DM-010 Data Generation: The data model MUST allow the provider to 496 include attributes defining how the data was generated (e.g. self- 497 reported, reported by aggregator, scan result, etc.). 499 DM-011 Data Source: The data model MUST allow the provider to 500 include attributes identifying the data source (target endpoint from 501 which the data was collected) - e.g. hostname, domain (DNS) name or 502 application name. 504 DM-012 Data Updates: The data model SHOULD allow the provider to 505 include attributes defining whether the information provided is a 506 delta, partial, or full set of information. 508 DM-013 Multiple Collectors: The data model MUST support the 509 collection of attributes by a variety of collectors, including 510 internal collectors, external collectors with an authenticated 511 relationship with the endpoint, and external collectors based on 512 network and other observers. 514 DM-014 Attribute Extensibility: Use Cases in the whole of Section 2 515 describe the need for an attribute dictionary. With SACM's scope 516 focused on posture assessment, the data model attribute collection 517 and aggregation MUST have a well-understood set of attributes 518 inclusive of their meaning or usage intent. The data model MUST 519 include all attributes defined in the information model and MAY 520 include additional attributes beyond those found in the information 521 model. Additional attributes MUST be defined in accordance with the 522 extensibility framework provided in the information model (see IM- 523 001). 525 DM-015 Solicited vs. Unsolicited Updates: The data model MUST enable 526 a provider to publish data either solicited (in response to a 527 request from a consumer) or unsolicited (as new data is generated, 528 without a request required). For example, an external collector can 529 publish data in response to a request by a consumer for information 530 about an endpoint, or can publish data as it observes new 531 information about an endpoint, without any specific consumer request 532 triggering the publication; a compliance-server provider may publish 533 endpoint posture information in response to a request from a 534 consumer (solicited), or it may publish posture information driven 535 by a change in the posture of the endpoint (unsolicited). 537 DM-016 Transport Agnostic: The data model MUST be transport 538 agnostic, to allow for the data operations to leverage the most 539 appropriate SACM transport protocol. 541 2.5. Requirements for Data Model Operations 543 Posture information data adhering to a data model must also provide 544 interfaces that include operations for access and production of the 545 data. Operations requirements are distinct from transport 546 requirements in that operations requirements are requirements on the 547 application performing requests and responses, whereas transport 548 requirements are requirements on the transport protocol carrying the 549 requests / responses. The specific requirements for such operations 550 include: 552 OP-001 Time Synchronization: Request and response operations MUST be 553 timestamped, and published information SHOULD capture time of 554 publication. Actions or decisions based on time-sensitive data 555 (such as user logon/logoff, endpoint connection/disconnection, 556 endpoint behavior events, etc.) are all predicated on a synchronized 557 understanding of time. A method for detecting and reporting time 558 discrepancies SHOULD be provided. 560 OP-002 Collection Abstraction: Collection is the act of a SACM 561 component gathering data from a target endpoint. The request for a 562 data item MUST include enough information to properly identify the 563 item to collect, but the request shall not be a command to directly 564 execute nor directly be applied as arguments to a command. The 565 purpose of this requirement is primarily to reduce the potential 566 attack vectors, but has the additional benefit of abstracting the 567 request for collection from the collection method, thereby allowing 568 more flexibility in how collection is implemented. 570 OP-003 Collection Composition: A collection request MAY be composed 571 of multiple collection requests (which yield collected values). The 572 desire for multiple values MUST be expressed as part of the 573 collection request, so that the aggregation can be resolved at the 574 point of collection without having to interact with the requestor. 575 This requirement should not be interpreted as preventing a collector 576 from providing attributes which were not part of the original 577 request. 579 OP-004 Attribute-based Query: A query operation is the act of 580 requesting data from a provider. Query operations SHOULD be based 581 on a set of attributes. Query operations MUST support both a query 582 for specific attributes and a query for all attributes. Use Case 583 2.1.2 describes the need for the data model to support a query 584 operation based on a set of attributes to facilitate collection of 585 information such as posture assessment, inventory (of endpoints or 586 endpoint components), and configuration checklist. 588 OP-005 Information-based Query with Filtering: The query operation 589 MUST support filtering. Use Case 2.1.3 describes the need for the 590 data model to support the means for the information to be collected 591 through a query mechanism. Furthermore, the query operation 592 requires filtering capabilities to allow for only a subset of 593 information to be retrieved. The query operation MAY be a 594 synchronous request or asynchronous request. 596 OP-006 Operation Scalability: The operation resulting from a query 597 operation MUST be able to handle the return and receipt of large 598 amounts of data. Use Cases 2.1.4 and 2.1.5 describe the need for 599 the data model to support scalability. For example, the query 600 operation may result in a very large set of attributes, as well as a 601 large set of targets. 603 OP-007 Data Abstraction: The data model MUST allow a SACM component 604 to communicate what data was used to construct the target endpoint's 605 identity, so other SACM components can determine whether they are 606 constructing an equivalent target endpoint (and its identity) and 607 whether they have confidence in that identity. SACM components 608 SHOULD have interfaces defined to transmit this data directly or to 609 refer to where the information can be retrieved. 611 OP-008 Provider Restriction: Request operations MUST include the 612 ability to restrict the data to be provided by a specific provider 613 or a provider with specific characteristics. Response operations 614 MUST include the ability to identify the provider that supplied the 615 response. For example, a SACM Consumer should be able to request 616 that all of the data come from a specific provider by identity (e.g. 617 Provider A) or from a Provider that is in a specific location (e.g. 618 in the Boston office). 620 2.6. Requirements for SACM Transport Protocols 622 The term SACM transfer protocol is intended to be distinguished from 623 underlying layer 3 and 4 protocols such as TCP/IP, operating at an 624 equivalent level as the hyperText transfer protocol (HTTP). The SACM 625 transfer protocol is focused on moving data and performing necessary 626 access control operations; it is agnostic to the data model 627 operations. 629 The requirements for SACM transport protocols include: 631 T-001 Multiple Transport Protocol Support: SACM transfer protocols 632 will vary depending on the deployment model that relies on different 633 transport layer requirements, different device capabilities, and 634 system configurations dealing with connectivity. 636 T-002 Data Integrity: SACM transfer protocols MUST be able to ensure 637 data integrity for data in transit. 639 T-003 Data Confidentiality: SACM transfer protocols MUST be able to 640 support data confidentiality. SACM transport protocols MUST ensure 641 data protection for data in transit (e.g. by encryption) to provide 642 confidentiality, integrity, and robustness against protocol-based 643 attacks. Note that while the transport MUST be able to support data 644 confidentiality, implementations MAY provide a configuration option 645 that enables and disables confidentiality in deployments. 646 Protection for data at rest is not in scope for transport protocols. 647 Data protection MAY be used for both privacy and non-privacy 648 scenarios. 650 T-004 Transport Protection: SACM transfer protocols MUST be capable 651 of supporting mutual authentication and replay protection. 653 T-005 Transport Reliability: SACM transfer protocols MUST provide 654 reliable delivery of data. This includes the ability to perform 655 fragmentation and reassembly, and to detect replays. The SACM 656 transfer may take advantage of reliability features in the network 657 transport; however, the network transport may be unreliable (e.g. 658 UDP), in which case the SACM transport running over the unreliable 659 network transport is responsible for ensuring reliability (i.e. by 660 provisions such as confirmations and re-transmits). 662 T-006 Transport Layer Requirements: Each SACM transfer protocol MUST 663 clearly specify the transport layer requirements it needs to operate 664 correctly. Examples of items that may need to be specified include 665 connectivity requirements, replay requirements, data link encryption 666 requirements, and/or channel binding requirements. These 667 requirements are needed in order for deployments to be done 668 correctly. 670 3. Acknowledgements 672 The authors would like to thank Barbara Fraser, Jim Bieda, and Adam 673 Montville for reviewing and contributing to this draft. In addition, 674 we recognize valuable comments and suggestions made by Jim Schaad and 675 Chris Inacio. 677 4. IANA Considerations 679 This memo includes no request to IANA. 681 5. Security Considerations 683 This document defines the requirements for SACM. As such, it is 684 expected that several data models, protocols, and transfer protocols 685 may be defined or reused from already existing standards. 687 To address security and privacy considerations, the data model, 688 protocols, and transports must consider authorization based on 689 consumer function and privileges, to only allow authorized consumers 690 and providers to access specific information being requested or 691 published. 693 To enable federation across multiple entities (such as across 694 organizational or geographic boundaries) authorization must also 695 extend to infrastructure elements themselves, such as central 696 controllers / brokers / data repositories. 698 In addition, authorization needs to extend to specific information or 699 resources available in the environment. In other words, 700 authorization is based on the subject (the information requestor), 701 the provider (the information responder), the object (the endpoint 702 the information is being requested on), and the attribute (what piece 703 of data is being requested). The method by which this authorization 704 is applied is unspecified. 706 SACM's charter focuses on the workflow orchestration and the sharing 707 of posture information for improving efficacy of security 708 applications such as compliance, configuration, assurance and other 709 threat and vulnerability reporting and remediation systems. While 710 the goal is to facilitate the flow of information securely, it is 711 important to note that participating endpoints may not be cooperative 712 or trustworthy. 714 5.1. Trust between Provider and Requestor 716 The information given from the provider to a requestor may come with 717 different levels of trustworthiness given the different potential 718 deployment scenarios and compromise either at the provider, the 719 requesting consumer, or devices that are involved in the transport 720 between the provider and requestor. This section will describe the 721 different considerations that may reduce the level of trustworthiness 722 of the information provided. 724 In the information transport flow, it is possible that some of the 725 devices may serve as proxies or brokers and as such, may be able to 726 observe the communications flowing between an information provider 727 and requestor. Without appropriate protections, it is possible for 728 these proxies and brokers to inject and affect man-in-the-middle 729 attacks. 731 It is common to, in general, distrust the network service provider, 732 unless the full hop by hop communications process flow is well 733 understood. As such, the posture information provider should protect 734 the posture information data it provides as well as the transport it 735 uses. Similarly, while there may be providers whose goal is to 736 openly share its information, there may also be providers whose 737 policy is to grant access to certain posture information based on its 738 business or regulatory policy. In those situations, a provider may 739 require full authentication and authorization of the requestor (or 740 set of requestors) and share only the authorized information to the 741 authenticated and authorized requestors. 743 A requestor beyond distrusting the network service provider, must 744 also account that the information received from the provider may have 745 been communicated through an undetermined network communications 746 system. That is, the posture information may have traversed through 747 many devices before reaching the requestor. SACM specifications 748 should provide the means for verifying data origin and data integrity 749 and at minimum, provide endpoint authentication and transport 750 integrity. 752 A requestor may require data freshness indications, both knowledge of 753 data origination as well as time of publication so that it can make 754 more informed decisions about the relevance of the data based on its 755 currency and/or age. 757 It is also important to note that endpoint assessment reports, 758 especially as they may be provided by the target endpoint may pose 759 untrustworthy information. The considerations for this are described 760 in Section 8 of [RFC5209]. 762 The trustworthiness of the posture information given by the provider 763 to one or many requestors is dependent on several considerations. 764 Some of these include the requestor requiring: 766 o Full disclosure of the network topology path to the provider(s). 768 o Direct (peer to peer) communication with the provider. 770 o Authentication and authorization of the provider. 772 o Either or both confidentiality and integrity at the transport 773 layer. 775 o Either or both confidentiality and integrity at the data layer. 777 5.2. Privacy Considerations 779 SACM information may contain sensitive information about the target 780 endpoint as well as revealing identity information of the producer or 781 consumer of such information. Similarly, as part of the SACM 782 discovery mechanism, the advertised capabilities (and roles, e.g. 783 SACM components enabled) by the endpoint may be construed as private 784 information. 786 In addition to identity and SACM capabilities information disclosure, 787 the use of time stamps or other attributes that can be used as 788 identifiers especially as they are coupled with an identity can be 789 further used to determine a target endpoint or user's behavioral 790 patterns. Such attributes may also be deemed sensitive and may 791 required further protection or obfuscation to meet privacy concerns. 792 That is, there may be applications as well as business and regulatory 793 practices that require that aspects of such information be hidden 794 from any parties that do not need to know it. 796 Data confidentiality can provide some level of privacy but may fall 797 short where unecessary data is still transmitted. In those cases, 798 filtering requirements at the data model such as OP-005 must be 799 applied to ensure that such data is not disclosed. [RFC6973] 800 provides guidelines for which SACM protocols and information and data 801 models should follow. 803 6. Change Log 805 6.1. -05 to -06 807 Updated G-005 to clarify the MUST to allow non-standard extensions, 808 SHOULD avoid collisions and ensure interoperability. 810 Cleaned up and clarified IM-003, DM-001. 812 Cleaned up some of the OP-XXX and ARCH-XXX per Jim Schaad's comments. 814 Updated some of the text around Editor notes and removed all 'Editor 815 Note' comments 817 7. References 819 7.1. Normative References 821 [I-D.ietf-sacm-terminology] 822 Birkholz, H., Lu, J., Strassner, J., and N. Cam-Winget, 823 "Security Automation and Continuous Monitoring (SACM) 824 Terminology", draft-ietf-sacm-terminology-12 (work in 825 progress), March 2017. 827 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 828 Requirement Levels", BCP 14, RFC 2119, 829 DOI 10.17487/RFC2119, March 1997, 830 . 832 [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. 833 Tardo, "Network Endpoint Assessment (NEA): Overview and 834 Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008, 835 . 837 [RFC7632] Waltermire, D. and D. Harrington, "Endpoint Security 838 Posture Assessment: Enterprise Use Cases", RFC 7632, 839 DOI 10.17487/RFC7632, September 2015, 840 . 842 7.2. Informative References 844 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 845 Morris, J., Hansen, M., and R. Smith, "Privacy 846 Considerations for Internet Protocols", RFC 6973, 847 DOI 10.17487/RFC6973, July 2013, 848 . 850 Authors' Addresses 851 Nancy Cam-Winget 852 Cisco Systems 853 3550 Cisco Way 854 San Jose, CA 95134 855 US 857 Email: ncamwing@cisco.com 859 Lisa Lorenzin 860 Pulse Secure 861 2700 Zanker Rd., Suite 200 862 San Jose, CA 95134 863 US 865 Email: llorenzin@pulsesecure.net