idnits 2.17.00 (12 Aug 2021) /tmp/idnits27657/draft-ietf-sacm-requirements-18.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC7632]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 107: '... MUST - indicates an absolute requi...' RFC 2119 keyword, line 109: '... MUST NOT - indicates something abs...' RFC 2119 keyword, line 111: '... SHOULD - indicates a strong recomm...' RFC 2119 keyword, line 113: '... SHOULD NOT - indicates a strong re...' RFC 2119 keyword, line 115: '... MAY - indicates a willingness to a...' (92 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 1, 2017) is 1747 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-13 Summary: 2 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: February 2, 2018 Pulse Secure 6 August 1, 2017 8 Security Automation and Continuous Monitoring (SACM) Requirements 9 draft-ietf-sacm-requirements-18 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 transfer protocols. The requirements and scope are based 16 on the agreed upon use cases ([RFC7632]). 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 February 2, 2018. 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 . . . . . . . . . 9 58 2.4. Requirements for the Data Model . . . . . . . . . . . . . 10 59 2.5. Requirements for Data Model Operations . . . . . . . . . 12 60 2.6. Requirements for SACM Transfer Protocols . . . . . . . . 14 61 3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 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. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 67 6.1. Normative References . . . . . . . . . . . . . . . . . . 18 68 6.2. Informative References . . . . . . . . . . . . . . . . . 18 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 71 1. Introduction 73 Today's environment of rapidly-evolving security threats highlights 74 the need to automate the sharing of security information (such as 75 posture information) while protecting user information and the 76 systems that store, process, and transmit this information. Security 77 threats can be detected in a number of ways. The Secure Automation 78 and Continuous Monitoring (SACM) charter focuses on how to collect 79 and share this information based on use cases that involve posture 80 assessment of endpoints. 82 Scalable and sustainable collection, expression, and evaluation of 83 endpoint information is foundational to SACM's objectives. To secure 84 and defend a network, one must reliably determine what devices are on 85 the network, how those devices are configured from a hardware 86 perspective, what software products are installed on those devices, 87 and how those products are configured. We need to be able to 88 determine, share, and use this information in a secure, timely, 89 consistent, and automated manner to perform endpoint posture 90 assessments. 92 This document focuses on describing the requirements for facilitating 93 the exchange of posture assessment information in the enterprise, in 94 particular, for the use cases as exemplified in [RFC7632]. As 95 proposals are evaluated for SACM standardization, their drafts are 96 expected to include a section that describe how they address each of 97 the enumerated requirements. 99 Also, this document uses terminology defined in 100 [I-D.ietf-sacm-terminology]. 102 1.1. Requirements Language 104 Use of each capitalized word within a sentence or phrase carries the 105 following meaning during the SACM WG's protocol selection process: 107 MUST - indicates an absolute requirement 109 MUST NOT - indicates something absolutely prohibited 111 SHOULD - indicates a strong recommendation of a desired result 113 SHOULD NOT - indicates a strong recommendation against a result 115 MAY - indicates a willingness to allow an optional outcome 117 When the words appear in lower case, their natural language meaning 118 is used. 120 2. Requirements 122 This document defines requirements based on the SACM use cases 123 described in [RFC7632]. This section describes the requirements used 124 by SACM to assess and compare candidate data models, interfaces, and 125 protocols. These requirements express characteristics or features 126 that a candidate protocol, information model, or data model must be 127 capable of offering to ensure security and interoperability. 129 Multiple data models, protocols, and transfers may be employed in a 130 SACM environment. A SACM transfer protocol is one that runs on top 131 of transport layer protocols such as TCP/IP or internet layer 132 protocols such as HTTP, carries operations (requests / responses), 133 and moves data. 135 SACM will define an architecture and information model focused on 136 addressing the needs for determining, sharing, and using posture 137 information via Posture Information Providers and Posture Information 138 Consumers securely. With the information model defining assets and 139 attributes to facilitate the guidance, collection, and assessment of 140 posture, tasks that should be considered include: 142 1. Asset Classification: Map the target endpoint and/or the assets 143 on the target endpoints to asset classes. This enables 144 identification of the attributes needed to exchange information 145 pertaining to the target endpoint. 147 2. Attribute Definition: Define the attributes desired to be 148 collected from each target endpoint. For instance, organizations 149 will want to know what software is installed and its critical 150 security attributes such as patch level. 152 3. Policy Definition: This is where an organization can express its 153 policy for acceptable or problematic values of an endpoint 154 attribute. The expected values of an endpoint attribute are 155 determined for later comparison against the actual endpoint 156 attribute values during the evaluation process. Expected values 157 may include both those values which are good as well as those 158 values which represent problems, such as vulnerabilities. The 159 organization can also specify the endpoint attributes that are to 160 be present for a given target endpoint. 162 4. Information Collection: Collect information (attribute values) 163 from the target endpoint to populate the endpoint data. 165 5. Endpoint Assessment: Evaluate the actual values of the endpoint 166 attributes against those expressed in the policy. (An evaluation 167 result may become additional endpoint data). 169 6. Result Reporting: Report the results of the evaluation for use by 170 other components. Examples of use of a report would be 171 additional evaluation, network enforcement, vulnerability 172 detection, and license management. 174 2.1. Requirements for SACM 176 Many deployment scenarios can be instantiated to address the above 177 tasks and use cases defined in [RFC7632]. To ensure 178 interoperability, scalability, and flexibility in any of these 179 deployments, the following requirements are defined for proposed SACM 180 standards: 182 G-001 Solution Extensibility: The information model, data models, 183 protocols, and transfers defined by SACM MUST be designed to allow 184 support for future (SACM) extensions. SACM MUST allow for both 185 standardized and proprietary extensions. 187 1. The information model and programmatic interfaces (see G-012 for 188 one example) MUST support the ability to add new operations 189 while maintaining backwards compatibility. SACM-defined 190 transfer protocols MUST have extensibility to allow them to 191 transfer operations that are defined in the future. 193 2. The query language MUST allow for general inquiries, as well as 194 expression of specific attributes or relationships between 195 attributes; the retrieval of specific information based on an 196 event, or on a continuous basis; and the ability to retrieve 197 specific pieces of information, specific types or classes of 198 information, or the entirety of available information. 200 3. The information model MUST accommodate the interoperable 201 addition of new data types and/or schemas. 203 G-002 Interoperability: The data models, protocols, and transpors 204 MUST be specified with enough details to ensure interoperability. 206 G-003 Scalability: SACM needs to support a broad set of deployment 207 scenarios. The data models, protocols, and transports has to be 208 scalable unless they are specifically defined to apply to a special- 209 purpose scenario, such as constrained devices. A SACM transfer 210 protocol standard SHOULD include a section on scalability 211 considerations that addresses the number of endpoints and amount of 212 information to which it can reasonably be expected to scale. 213 Scalability must be addressed to support: 215 * Large message: It is possible that the size of posture assessment 216 information can vary from a single assessment that is small in 217 size to a very large message or a very large set of assessments 218 (up to multiple gigabytes in size). 220 * Large number of messages per second: A deployment may involve 221 many rapid or simultaneous events that require processing, 222 generating many messages per second. 224 * Large number of providers and consumers: A deployment may consist 225 of a very large number of endpoints requesting and/or producing 226 posture assessment information. 228 * Large number of target endpoints: A deployment may be managing 229 information of a very large number of target endpoints. 231 G-004 Versatility: The data model, protocols, and transports must be 232 suitably specified to enable implementations to fit into different 233 deployment models and scenarios, including considerations for 234 implementations of data models and transports operating in 235 constrained environments. Separate solutions may be necessary to 236 meet the needs of specific deployment models and scenarios. 238 G-005 Information Extensibility: Non-standard (implementation- 239 specific) attributes MUST be supported. A method SHOULD be defined 240 for preventing collisions from occurring in the naming of all 241 attributes independent of their source. For interoperability and 242 scope boundary, the information model MUST define the mandatory set 243 of attributes. 245 G-006 Data Protection: To protect the information being shared, SACM 246 components MUST protect the integrity and confidentiality of data in 247 transit (end to end) and data at rest (as information is stored in 248 repositories). Mechanisms for this protection are unspecified but 249 should include industry best practices. These mechanisms are 250 required to be available (i.e. all data-handling components must 251 support them), but are not required to be used in all cases. 253 G-007 Data Partitioning: A method for partitioning data MUST be 254 supported to accommodate considerations such as geographic, 255 regulatory, operational requirements, overlay boundaries, and 256 federation (where the data may be collected in multiple locations 257 and either centralized or kept in the local region). Where 258 replication of data is supported, it is required that methods exist 259 to prevent update loops. 261 G-008 Versioning and Backward Compatibility: Announcement and 262 negotiation of versions, inclusive of existing capabilities (such as 263 transfer protocols, data models, specific attributes within data 264 models, standard attribute expression sets, etc.) MUST be 265 supported. Negotiation for both versioning and capabilities is 266 needed to accommodate future growth and ecosystems with mixed 267 capabilities. 269 G-009 Information Discovery: There MUST be mechanisms for components 270 to discover what information is available across the ecosystem (i.e. 271 a method for cataloging data available in the ecosystem and 272 advertising it to consumers), where to go to get a specific piece of 273 that information (i.e. which provider has the information), and what 274 schemas are in use for organizing the information. For example, 275 providing a method by which a node can locate the advertised 276 information so that consumers are not required to have a priori 277 knowledge to find available information. 279 G-010 Target Endpoint Discovery: SACM MUST define the means by which 280 target endpoints may be discovered. Use Case 2.1.2 describes the 281 need to discover endpoints and their composition. 283 G-011 Push and Pull Access: Three methods of data access MUST be 284 supported: a Pull model, a solicited Push model, and an unsolicited 285 Push models. All of the methods of data access MUST support the 286 ability for the initiator to filter the set of posture assessment 287 information to be delivered. Additionally, the provider of the 288 information MUST be able to filter the set of posture assessment 289 information based on the permissions of the recipient. This 290 requirement is driven by use cases 2.1.3, 2.1.4 and 2.1.5. 292 G-012 SACM Component Interface: The interfaces by which SACM 293 components communicate to share endpoint posture information MUST be 294 well defined. That is, the interface defines the data model, SACM 295 transfer protocols, and network transfer protocols to enable SACM 296 components to communicate. 298 G-013 Endpoint Location and Network Topology: The SACM architecture 299 and interfaces MUST allow for the target endpoint (network) location 300 and network topology to be modeled and understood. Where 301 appropriate, the data model and the interfaces SHOULD allow for 302 discovery of the target endpoint location or network topology or 303 both. 305 G-014 Target Endpoint Identity: The SACM architecture and interfaces 306 MUST support the ability of components to provide attributes that 307 can be used to compose an identity for a target endpoint. These 308 identities MAY be composed of attributes from one or more SACM 309 components. 311 G-015 Data Access Control: Methods of access control must be 312 supported to accommodate considerations such as geographic, 313 regulatory, operational and federations. Entities accessing or 314 publishing data MUST identify themselves and pass access policy. 316 2.2. Requirements for the Architecture 318 Following are the requirements for the SACM architecture: 320 ARCH-001 Component functions: At the simplest abstraction, the SACM 321 architecture MUST represent the core components and interfaces 322 needed to perform the production and consumption of posture 323 assessment information. 325 ARCH-002 Scalability: The architectural components MUST account for 326 a range of deployments, from very small sets of endpoints to very 327 large deployments. 329 ARCH-003 Flexibility: The architectural components MUST account for 330 different deployment scenarios where the architectural components 331 may be implemented, deployed, or used within a single application, 332 service, or network, or may comprise a federated system. 334 ARCH-004 Separation of Data and Management Functions: SACM MUST 335 define both the configuration and management of the SACM data models 336 and protocols used to transfer and share posture assessment 337 information. 339 ARCH-005 Topology Flexibility: Both centralized and decentralized 340 (peer-to-peer) information exchange MUST be supported. Centralized 341 data exchange enables use of a common data format to bridge together 342 data exchange between diverse systems, and can leverage a virtual 343 data store that centralizes and offloads all data access, storage, 344 and maintenance to a dedicated resource. Decentralized data 345 exchange enables simplicity of sharing data between relatively 346 uniform systems, and between small numbers of systems, especially 347 within a single enterprise domain. The fact that a centralized or 348 decentralized deployment is used SHOULD be invisible to a consumer. 349 However, there may be cases where the producer chooses to include 350 that information due to consumer preference 352 ARCH-006 Capability Negotiation: Announcement and negotiation of 353 functional capabilities (such as authentication protocols, 354 authorization schemes, data models, transfer protocols, etc.) MUST 355 be supported, enabling a SACM component to make inquiries about the 356 capabilities of other components in the SACM ecosystem. 358 ARCH-007 Role-based Authorization: The SACM architecture MUST be 359 capable of effecting role-based authorization. Distinction of 360 endpoints capable of and authorized to provide or consume 361 information is required to address appropriate access controls. 363 ARCH-008 Context-based Authorization: The SACM architecture MUST be 364 capable of effecting context-based authorization. Different 365 policies (e.g. business, regulatory, etc.) might specify what data 366 may be exposed to, or shared by, consumers based on one or more 367 attributes of the consumer. The policy might specify that consumers 368 are required to share specific information either back to the system 369 or to administrators. 371 ARCH-009 Time Synchronization: Actions or decisions based on time- 372 sensitive data (such as user logon/logoff, endpoint connection/ 373 disconnection, endpoint behavior events, etc.) are all predicated on 374 a synchronized understanding of time. The SACM architecture MUST 375 provide a mechanism for all components to synchronize time. A 376 mechanism for detecting and reporting time discrepancies SHOULD be 377 provided by the architecture and reflected in the information model. 379 2.3. Requirements for the Information Model 381 The SACM information model represents the abstracted representation 382 for Posture Assessment information to be communicated. SACM data 383 models must adhere to and comply with the SACM information model. 384 The requirements for the SACM information model include: 386 IM-001 Extensible Attribute Vocabulary: The information model MUST 387 define a minimum set of attributes for communicating Posture 388 Information, to ensure interoperability between data models. 389 (Individual data models may define attributes beyond the mandatory- 390 to-implement minimum set.) The attributes should be defined with a 391 clear mechanism for extensibility to enable data models to adhere to 392 SACM's required attributes as well as allow for their own 393 extensions. The attribute vocabulary should be defined with a clear 394 mechanism for extensibility to enable future versions of the 395 information model to be interoperably expanded with new attributes. 397 IM-002 Posture Data Publication: The information model MUST allow 398 for the data to be provided by a SACM component either solicited or 399 unsolicited. No aspect of the information model should be dependent 400 upon or assume a push or pull model of publication. 402 IM-003 Data Model Negotiation: SACM's information model MUST allow 403 support for different data models, data model versions, and 404 different versions of the operations on the data models and transfer 405 protocols. The SACM information model MUST include the ability to 406 discover and negotiate the use of a particular data model or any 407 data model. 409 IM-004 Data Model Identification: The information model MUST provide 410 a means to uniquely identify each data model. The identifier MUST 411 contain both an identifier of the data model and a version indicator 412 for the data model. The identifiers SHOULD be decomposable so that 413 a customer can query for any version of a specific data model and 414 compare returned values for older or newer than a desired version. 416 IM-005 Data Lifetime Management: The information model MUST provide 417 a means to allow data models to include data lifetime management. 418 The information model must identify attributes that can allow data 419 models to, at minimum, identify the data's origination time and 420 expected time of next update or data longevity (how long should the 421 data be assumed to still be valid). 423 IM-006 Singularity and Modularity: The SACM information model MUST 424 be singular (i.e. there is only one information model, not multiple 425 alternative information models from which to choose) and MAY be 426 modular (a conjunction of several sub-components) for ease of 427 maintenance and extension. For example, endpoint identification 428 could be an independent sub-component of the information model, to 429 simplify updating of endpoint identification attributes. 431 2.4. Requirements for the Data Model 433 The SACM information model represents an abstraction for "what" 434 information can be communicated and "how" it is to be represented and 435 shared. It is expected that as applications may produce posture 436 assessment information, they may share it using a specific data 437 model. Similarly, applications consuming or requesting posture 438 assessment information, may require it be based on a specific data 439 model. Thus, while there may exist different data models and 440 schemas, they should adhere to the SACM information model and meet 441 the requirements defined in this section. 443 The specific requirements for candidate data models include: 445 DM-001 Element Association: A SACM Information Model consists of a 446 set of SACM Information Model elements. A SACM Data Model MUST be 447 derived from the SACM Information Model. A SACM Data Model consists 448 of a set of SACM Data Model elements. In this derivation, a SACM 449 Data Model element MAY map to one or more SACM Information Model 450 elements. In addition, a SACM Data Model MAY include additional 451 Data Model elements that are not associated with any SACM 452 Information Model elements. 454 DM-002 Data Model Structure: The data model can be structured either 455 as one single module or separated into modules and sub-modules that 456 allow for references between them. The data model structure MAY 457 reflect structure in the information model, but does not need to. 458 For example, the data model might use one module to define 459 endpoints, and that module might reference other modules that 460 describe the various assets associated with the endpoint. 461 Constraints and interfaces might further be defined to resolve or 462 tolerate ambiguity in the references (e.g. same IP address used in 463 two separate networks). 465 DM-003 Search Flexibility: The search interfaces and actions MUST 466 include the ability to start a search anywhere within a data model 467 structure, and the ability to search based on patterns ("wildcard 468 searches") as well as specific data elements. 470 DM-004 Full vs. Partial Updates: The data model SHOULD include the 471 ability to allow providers of data to provide the data as a whole, 472 or when updates occur. For example, a consumer can request a full 473 update on initial engagement, then request to receive deltas 474 (updates containing only the changes since the last update) on an 475 ongoing basis as new data is generated. 477 DM-005 Loose Coupling: The data model SHOULD allow for a loose 478 coupling between the provider and the consumer, such that the 479 consumer can request information without being required to request 480 it from a specific provider, and a provider can publish information 481 without having a specific consumer targeted to receive it. 483 DM-006 Data Cardinality: The data model MUST describe their 484 constraints (e.g. cardinality). As posture information and the 485 tasks for collection, aggregation, or evaluation, could comprise one 486 or more attributes, interfaces and actions MUST allow and account 487 for such cardinality as well as whether the attributes are 488 conditional, optional, or mandatory. 490 DM-007 Data Model Negotiation: The interfaces and actions in the 491 data model MUST include capability negotiation to enable discovery 492 of supported and available data types and schemas. 494 DM-008 Data Origin: The data model MUST include the ability for 495 consumers to identify the data origin (provider that collected the 496 data). 498 DM-009 Origination Time: The data model SHOULD allow the provider to 499 include the information's origination time. 501 DM-010 Data Generation: The data model MUST allow the provider to 502 include attributes defining how the data was generated (e.g. self- 503 reported, reported by aggregator, scan result, etc.). 505 DM-011 Data Source: The data model MUST allow the provider to 506 include attributes identifying the data source (target endpoint from 507 which the data was collected) - e.g. hostname, domain (DNS) name or 508 application name. 510 DM-012 Data Updates: The data model SHOULD allow the provider to 511 include attributes defining whether the information provided is a 512 delta, partial, or full set of information. 514 DM-013 Multiple Collectors: The data model MUST support the 515 collection of attributes by a variety of collectors, including 516 internal collectors, external collectors with an authenticated 517 relationship with the endpoint, and external collectors based on 518 network and other observers. 520 DM-014 Attribute Extensibility: Use Cases in the whole of Section 2 521 describe the need for an attribute dictionary. With SACM's scope 522 focused on posture assessment, the data model attribute collection 523 and aggregation MUST have a well-understood set of attributes 524 inclusive of their meaning or usage intent. The data model MUST 525 include all attributes defined in the information model and MAY 526 include additional attributes beyond those found in the information 527 model. Additional attributes MUST be defined in accordance with the 528 extensibility framework provided in the information model (see IM- 529 001). 531 DM-015 Solicited vs. Unsolicited Updates: The data model MUST enable 532 a provider to publish data either solicited (in response to a 533 request from a consumer) or unsolicited (as new data is generated, 534 without a request required). For example, an external collector can 535 publish data in response to a request by a consumer for information 536 about an endpoint, or can publish data as it observes new 537 information about an endpoint, without any specific consumer request 538 triggering the publication; a compliance-server provider may publish 539 endpoint posture information in response to a request from a 540 consumer (solicited), or it may publish posture information driven 541 by a change in the posture of the endpoint (unsolicited). 543 DM-016 tTransfer Agnostic: The data model MUST be transfer agnostic, 544 to allow for the data operations to leverage the most appropriate 545 SACM transfer protocol. 547 2.5. Requirements for Data Model Operations 549 Posture information data adhering to a data model must also provide 550 interfaces that include operations for access and production of the 551 data. Operations requirements are distinct from transfer 552 requirements in that operations requirements are requirements on the 553 application performing requests and responses, whereas transfer 554 requirements are requirements on the transfer protocol carrying the 555 requests / responses. The specific requirements for such operations 556 include: 558 OP-001 Time Synchronization: Request and response operations MUST be 559 timestamped, and published information SHOULD capture time of 560 publication. Actions or decisions based on time-sensitive data 561 (such as user logon/logoff, endpoint connection/disconnection, 562 endpoint behavior events, etc.) are all predicated on a synchronized 563 understanding of time. A method for detecting and reporting time 564 discrepancies SHOULD be provided. 566 OP-002 Collection Abstraction: Collection is the act of a SACM 567 component gathering data from a target endpoint. The request for a 568 data item MUST include enough information to properly identify the 569 item to collect, but the request shall not be a command to directly 570 execute nor directly be applied as arguments to a command. The 571 purpose of this requirement is primarily to reduce the potential 572 attack vectors, but has the additional benefit of abstracting the 573 request for collection from the collection method, thereby allowing 574 more flexibility in how collection is implemented. 576 OP-003 Collection Composition: A collection request MAY be composed 577 of multiple collection requests (which yield collected values). The 578 desire for multiple values MUST be expressed as part of the 579 collection request, so that the aggregation can be resolved at the 580 point of collection without having to interact with the requestor. 581 This requirement should not be interpreted as preventing a collector 582 from providing attributes which were not part of the original 583 request. 585 OP-004 Attribute-based Query: A query operation is the act of 586 requesting data from a provider. Query operations SHOULD be based 587 on a set of attributes. Query operations MUST support both a query 588 for specific attributes and a query for all attributes. Use Case 589 2.1.2 describes the need for the data model to support a query 590 operation based on a set of attributes to facilitate collection of 591 information such as posture assessment, inventory (of endpoints or 592 endpoint components), and configuration checklist. 594 OP-005 Information-based Query with Filtering: The query operation 595 MUST support filtering. Use Case 2.1.3 describes the need for the 596 data model to support the means for the information to be collected 597 through a query mechanism. Furthermore, the query operation 598 requires filtering capabilities to allow for only a subset of 599 information to be retrieved. The query operation MAY be a 600 synchronous request or asynchronous request. 602 OP-006 Operation Scalability: The operation resulting from a query 603 operation MUST be able to handle the return and receipt of large 604 amounts of data. Use Cases 2.1.4 and 2.1.5 describe the need for 605 the data model to support scalability. For example, the query 606 operation may result in a very large set of attributes, as well as a 607 large set of targets. 609 OP-007 Data Abstraction: The data model MUST allow a SACM component 610 to communicate what data was used to construct the target endpoint's 611 identity, so other SACM components can determine whether they are 612 constructing an equivalent target endpoint (and its identity) and 613 whether they have confidence in that identity. SACM components 614 SHOULD have interfaces defined to transmit this data directly or to 615 refer to where the information can be retrieved. 617 OP-008 Provider Restriction: Request operations MUST include the 618 ability to restrict the data to be provided by a specific provider 619 or a provider with specific characteristics. Response operations 620 MUST include the ability to identify the provider that supplied the 621 response. For example, a SACM Consumer should be able to request 622 that all of the data come from a specific provider by identity (e.g. 623 Provider A) or from a Provider that is in a specific location (e.g. 624 in the Boston office). 626 2.6. Requirements for SACM Transfer Protocols 628 The term SACM transfer protocol is intended to be distinguished from 629 underlying transport and internet layer protocols such as TCP/IP or 630 operating at an equivalent level as the HTTP. The SACM transfer 631 protocol is focused on moving data and performing necessary access 632 control operations; it is agnostic to the data model operations. 634 The requirements for SACM transfer protocols include: 636 T-001 Multiple transfer Protocol Support: SACM transfer protocols 637 will vary depending on the deployment model that relies on different 638 transfer layer requirements, different device capabilities, and 639 system configurations dealing with connectivity. For example, where 640 posture attributes may be collected directly from an endpoint using 641 NEA's model [RFC5209], different transports may be defined to 642 collect them using PT-EAP [RFC7171] or PT-TLS [RFC6876] depending on 643 the deployment scenario. 645 T-002 Data Integrity: SACM transfer protocols MUST be able to ensure 646 data integrity for data in transit. 648 T-003 Data Confidentiality: SACM transfer protocols MUST be able to 649 support data confidentiality. SACM transfer protocols MUST ensure 650 data protection for data in transit (e.g. by encryption) to provide 651 confidentiality, integrity, and robustness against protocol-based 652 attacks. Note that while the transfer MUST be able to support data 653 confidentiality, implementations MAY provide a configuration option 654 that enables and disables confidentiality in deployments. 655 Protection for data at rest is not in scope for transfer protocols. 656 Data protection MAY be used for both privacy and non-privacy 657 scenarios. 659 T-004 Transfer Protection: SACM transfer protocols MUST be capable 660 of supporting mutual authentication and replay protection. 662 T-005 Transfer Reliability: SACM transfer protocols MUST provide 663 reliable delivery of data. This includes the ability to perform 664 fragmentation and reassembly, and to detect replays. The SACM 665 transfer may take advantage of reliability features in the network 666 transport; however, the network transport may be unreliable (e.g. 667 UDP), in which case the SACM transfer running over the unreliable 668 network transport is responsible for ensuring reliability (i.e. by 669 provisions such as confirmations and re-transmits). 671 T-006 Transfer Layer Requirements: Each SACM transfer protocol MUST 672 clearly specify the transport layer requirements it needs to operate 673 correctly. Examples of items that may need to be specified include 674 connectivity requirements, replay requirements, data link encryption 675 requirements, and/or channel binding requirements. These 676 requirements are needed in order for deployments to be done 677 correctly. 679 T-007 Transfer Protocol adoption: SACM SHOULD where reasonably 680 possible, leverage and use existing IETF transfer protocols versus 681 defining new ones. 683 3. Acknowledgments 685 The authors would like to thank Barbara Fraser, Jim Bieda, and Adam 686 Montville for reviewing and contributing to this draft. In addition, 687 we recognize valuable comments and suggestions made by Jim Schaad and 688 Chris Inacio. 690 4. IANA Considerations 692 This memo includes no request to IANA. 694 5. Security Considerations 696 This document defines the requirements for SACM. As such, it is 697 expected that several data models, protocols, and transfer protocols 698 may be defined or reused from already existing standards. 700 To address security and privacy considerations, the data model, 701 protocols, and transports must consider authorization based on 702 consumer function and privileges, to only allow authorized consumers 703 and providers to access specific information being requested or 704 published. 706 To enable federation across multiple entities (such as across 707 organizational or geographic boundaries) authorization must also 708 extend to infrastructure elements themselves, such as central 709 controllers / brokers / data repositories. 711 In addition, authorization needs to extend to specific information or 712 resources available in the environment. In other words, 713 authorization is based on the subject (the information requestor), 714 the provider (the information responder), the object (the endpoint 715 the information is being requested on), and the attribute (what piece 716 of data is being requested). The method by which this authorization 717 is applied is unspecified. 719 SACM's charter focuses on the workflow orchestration and the sharing 720 of posture information for improving efficacy of security 721 applications such as compliance, configuration, assurance and other 722 threat and vulnerability reporting and remediation systems. While 723 the goal is to facilitate the flow of information securely, it is 724 important to note that participating endpoints may not be cooperative 725 or trustworthy. 727 5.1. Trust between Provider and Requestor 729 The information given from the provider to a requestor may come with 730 different levels of trustworthiness given the different potential 731 deployment scenarios and compromise either at the provider, the 732 requesting consumer, or devices that are involved in the transfer 733 between the provider and requestor. This section will describe the 734 different considerations that may reduce the level of trustworthiness 735 of the information provided. 737 In the information transfer flow, it is possible that some of the 738 devices may serve as proxies or brokers and as such, may be able to 739 observe the communications flowing between an information provider 740 and requestor. Without appropriate protections, it is possible for 741 these proxies and brokers to inject and affect man-in-the-middle 742 attacks. 744 It is common to, in general, distrust the network service provider, 745 unless the full hop by hop communications process flow is well 746 understood. As such, the posture information provider should protect 747 the posture information data it provides as well as the transfer it 748 uses. Similarly, while there may be providers whose goal is to 749 openly share its information, there may also be providers whose 750 policy is to grant access to certain posture information based on its 751 business or regulatory policy. In those situations, a provider may 752 require full authentication and authorization of the requestor (or 753 set of requestors) and share only the authorized information to the 754 authenticated and authorized requestors. 756 A requestor beyond distrusting the network service provider, must 757 also account that the information received from the provider may have 758 been communicated through an undetermined network communications 759 system. That is, the posture information may have traversed through 760 many devices before reaching the requestor. SACM specifications 761 should provide the means for verifying data origin and data integrity 762 and at minimum, provide endpoint authentication and transfer 763 integrity. 765 A requestor may require data freshness indications, both knowledge of 766 data origination as well as time of publication so that it can make 767 more informed decisions about the relevance of the data based on its 768 currency and/or age. 770 It is also important to note that endpoint assessment reports, 771 especially as they may be provided by the target endpoint may pose 772 untrustworthy information. The considerations for this are described 773 in Section 8 of [RFC5209]. 775 The trustworthiness of the posture information given by the provider 776 to one or many requestors is dependent on several considerations. 777 Some of these include the requestor requiring: 779 o Full disclosure of the network topology path to the provider(s). 781 o Direct (peer to peer) communication with the provider. 783 o Authentication and authorization of the provider. 785 o Either or both confidentiality and integrity at the transfer 786 layer. 788 o Either or both confidentiality and integrity at the data layer. 790 5.2. Privacy Considerations 792 SACM information may contain sensitive information about the target 793 endpoint as well as revealing identity information of the producer or 794 consumer of such information. Similarly, as part of the SACM 795 discovery mechanism, the advertised capabilities (and roles, e.g. 796 SACM components enabled) by the endpoint may be construed as private 797 information. 799 In addition to identity and SACM capabilities information disclosure, 800 the use of time stamps (or other attributes that can be used as 801 identifiers) could be further used to determine a target endpoint or 802 user's behavioral patterns. Such attributes may also be deemed 803 sensitive and may required further protection or obfuscation to meet 804 privacy concerns. That is, there may be applications as well as 805 business and regulatory practices that require that aspects of such 806 information be hidden from any parties that do not need to know it. 808 Data confidentiality can provide some level of privacy but may fall 809 short where unnecessary data is still transmitted. In those cases, 810 filtering requirements at the data model such as OP-005 must be 811 applied to ensure that such data is not disclosed. [RFC6973] 812 provides guidelines for which SACM protocols and information and data 813 models should follow. 815 6. References 817 6.1. Normative References 819 [RFC7632] Waltermire, D. and D. Harrington, "Endpoint Security 820 Posture Assessment: Enterprise Use Cases", RFC 7632, 821 DOI 10.17487/RFC7632, September 2015, 822 . 824 6.2. Informative References 826 [I-D.ietf-sacm-terminology] 827 Birkholz, H., Lu, J., Strassner, J., and N. Cam-Winget, 828 "Security Automation and Continuous Monitoring (SACM) 829 Terminology", draft-ietf-sacm-terminology-13 (work in 830 progress), July 2017. 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 [RFC6876] Sangster, P., Cam-Winget, N., and J. Salowey, "A Posture 838 Transport Protocol over TLS (PT-TLS)", RFC 6876, 839 DOI 10.17487/RFC6876, February 2013, 840 . 842 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 843 Morris, J., Hansen, M., and R. Smith, "Privacy 844 Considerations for Internet Protocols", RFC 6973, 845 DOI 10.17487/RFC6973, July 2013, 846 . 848 [RFC7171] Cam-Winget, N. and P. Sangster, "PT-EAP: Posture Transport 849 (PT) Protocol for Extensible Authentication Protocol (EAP) 850 Tunnel Methods", RFC 7171, DOI 10.17487/RFC7171, May 2014, 851 . 853 Authors' Addresses 855 Nancy Cam-Winget 856 Cisco Systems 857 3550 Cisco Way 858 San Jose, CA 95134 859 US 861 Email: ncamwing@cisco.com 863 Lisa Lorenzin 864 Pulse Secure 865 2700 Zanker Rd., Suite 200 866 San Jose, CA 95134 867 US 869 Email: llorenzin@pulsesecure.net