idnits 2.17.1 draft-ietf-sacm-requirements-13.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 (March 17, 2016) is 2956 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-16) exists of draft-ietf-sacm-terminology-08 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SACM N. Cam-Winget 3 Internet-Draft Cisco Systems 4 Intended status: Informational L. Lorenzin 5 Expires: September 18, 2016 Pulse Secure 6 March 17, 2016 8 Security Automation and Continuous Monitoring (SACM) Requirements 9 draft-ietf-sacm-requirements-13 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 September 18, 2016. 35 Copyright Notice 37 Copyright (c) 2016 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 54 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.1. Requirements for SACM . . . . . . . . . . . . . . . . . . 4 56 2.2. Requirements for the Architecture . . . . . . . . . . . . 7 57 2.3. Requirements for the Information Model . . . . . . . . . 8 58 2.4. Requirements for the Data Model . . . . . . . . . . . . . 9 59 2.5. Requirements for Data Model Operations . . . . . . . . . 12 60 2.6. Requirements for SACM Transport Protocols . . . . . . . . 13 61 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 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 defined 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. This is what we want to 138 know about a target endpoint. For instance, organizations will 139 want to know what software is installed and its critical security 140 attributes such as patch level. 142 3. Policy Definition: This is where an organization can express its 143 policy for acceptable or problematic values of an endpoint 144 attribute. The expected values of an endpoint attribute are 145 determined for later comparison against the actual endpoint 146 attribute values during the evaluation process. Expected values 147 may include both those values which are good as well as those 148 values which represent problems, such as vulnerabilities. The 149 organization can also specify the endpoint attributes that are to 150 be present for a given target endpoint. 152 4. Information Collection: Collect information (attribute values) 153 from the target endpoint to populate the endpoint data. 155 5. Endpoint Assessment: Evaluate the actual values of the endpoint 156 attributes against those expressed in the policy. (An evaluation 157 result may become additional endpoint data). 159 6. Result Reporting: Report the results of the evaluation for use by 160 other components. Examples of use of a report would be 161 additional evaluation, network enforcement, vulnerability 162 detection, and license management. 164 2.1. Requirements for SACM 166 Many deployment scenarios can be instantiated to address the above 167 tasks and use cases defined in [RFC7632]. To ensure 168 interoperability, scalability, and flexibility in any of these 169 deployments, the following requirements are defined for proposed SACM 170 standards: 172 G-001 Solution Extensibility: The information model, data models, 173 protocols, and transports defined by SACM MUST be designed to allow 174 support for future (SACM) extensions. SACM MUST allow 175 implementations to use their own extensions; either proprietary data 176 models, protocols or extensions to SACM data models or protocols 177 could be used though they are not considered to be SACM compliant. 179 1. The information model and programmatic interfaces (see G-012 for 180 one example) MUST support the ability to add new operations 181 while maintaining backwards compatibility. SACM-defined 182 transport protocols MUST have extensibility to allow them to 183 transport operations that are defined in the future. 185 2. The query language MUST allow for general inquiries, as well as 186 expression of specific attributes or relationships between 187 attributes to follow; the retrieval of specific information 188 based on an event, or on a continuous basis; and the ability to 189 retrieve specific pieces of information, specific types or 190 classes of information, or the entirety of available 191 information. 193 3. The information model MUST accommodate the interoperable 194 addition of new data types and/or schemas. 196 G-002 Interoperability: The data models, protocols, and transports 197 must be specified with enough details to ensure interoperability. 199 G-003 Scalability: SACM needs to support a broad set of deployment 200 scenarios. The data models, protocols, and transports MUST be 201 scalable unless they are specifically defined to apply to a special- 202 purpose scenario, such as constrained devices. A SACM transport 203 protocol standard SHOULD include a section on scalability 204 considerations that addresses the number of endpoints and amount of 205 information to which it can reasonably be expected to scale. 206 Scalability must be addressed to support: 208 * Large datagrams: It is possible that the size of posture 209 assessment information can vary from a single assessment that is 210 small in size to a very large datagram or a very large set of 211 assessments (up to multiple gigabytes in size). 213 * Large number of datagrams per second: A deployment may involve 214 many rapid or simultaneous events that require processing, 215 generating many datagrams per second. 217 * Large number of providers and consumers: A deployment may consist 218 of a very large number of endpoints requesting and/or producing 219 posture assessment information. 221 * Large number of target endpoints: A deployment may be managing 222 information of a very large number of target endpoints. 224 G-004 Versatility: The data model, protocols, and transports MUST be 225 suitably specified to enable implementations to fit into different 226 deployment models and scenarios, including considerations for 227 implementations of data models and transports operating in 228 constrained environments. 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 proxies and/or repositories) and data at 241 rest (for information stored on repositories and on providers / 242 consumers). Mechanisms for this protection are unspecified but 243 should include industry best practices such as encrypted storage, 244 encrypted transports, data checksums, etc. These mechanisms are 245 required to be available (i.e. all data-handling components must 246 support them), but are not required to be used in all cases. 248 G-007 Data Partitioning: A method for partitioning data MUST be 249 supported to accommodate considerations such as geographic, 250 regulatory, operational requirements, overlay boundaries, and 251 federation (where the data may be collected in multiple locations 252 and either centralized or kept in the local region). Where 253 replication of data is supported, it is required that methods exist 254 to prevent update loops. 256 G-008 Versioning and Backward Compatibility: Announcement and 257 negotiation of versions, inclusive of existing capabilities (such as 258 transport protocols, data models, specific attributes within data 259 models, standard attribute expression sets, etc.) MUST be 260 supported. Negotiation for both versioning and capabilities is 261 needed to accommodate future growth and ecosystems with mixed 262 capabilities. 264 G-009 Information Discovery: There MUST be mechanisms for components 265 to discover what information is available across the ecosystem (i.e. 266 a method for cataloging data available in the ecosystem and 267 advertising it to consumers), where to go to get a specific piece of 268 that information (i.e. which provider has the information), and what 269 schemas are in use for organizing the information. For example, 270 providing a method by which a node can locate the advertised 271 information so that consumers are not required to have a priori 272 knowledge to find available information. 274 G-010 Target Endpoint Discovery: SACM MUST define the means by which 275 target endpoints may be discovered. Use Case 2.1.2 describes the 276 need to discover endpoints and their composition. 278 G-011 Push and Pull Access: Three methods of data access MUST be 279 supported: a Pull model, a solicited Push model, and an unsolicited 280 Push models. All of the methods of data access MUST support the 281 ability for the initiator to filter the set of posture assessment 282 information to be delivered. Additionally, the provider of the 283 information MUST be able to filter the set of posture assessment 284 information based on the permissions of the recipient. This 285 requirement is driven by use cases 2.1.3, 2.1.4 and 2.1.5. 287 G-012 SACM Component Interface: The interfaces by which SACM 288 components communicate to share endpoint posture information MUST be 289 well defined. That is, the interface defines the data model, SACM 290 transport protocols, and network transport protocols to enable SACM 291 components to communicate. 293 G-013 Endpoint Location and Network Topology: The SACM architecture 294 and interfaces MUST allow for the target endpoint (network) location 295 and network topology to be modeled and understood. Where 296 appropriate, the data model and the interfaces SHOULD allow for 297 discovery of the target endpoint location or network topology or 298 both. 300 G-014 Target Endpoint Identity: The SACM architecture and interfaces 301 MUST support the ability of components to provide attributes that 302 can be used to compose an identity for a target endpoint. These 303 identities MAY be composed of attributes from one or more SACM 304 components. 306 G-015 Data Access Control: Methods of access control MUST be 307 supported to accommodate considerations such as geographic, 308 regulatory, operational and federations. Entities accessing or 309 publishing data MUST identify themselves and pass access policy. 311 2.2. Requirements for the Architecture 313 At the simplest abstraction, the SACM architecture represents the 314 core components and interfaces needed to perform the production and 315 consumption of posture assessment information. Requirements relating 316 to SACM's architecture include: 318 ARCH-001 Scalability: The architectural components MUST account for 319 a range of deployments, from very small sets of endpoints to very 320 large deployments. 322 ARCH-002 Flexibility: The architectural components MUST account for 323 different deployment scenarios where the architectural components 324 may be implemented, deployed, or used within a single application, 325 service, or network, or may comprise a federated system. 327 ARCH-003 Separation of Data and Management Functions: SACM MUST 328 define both the configuration and management of the SACM data models 329 and protocols used to transport and share posture assessment 330 information. 332 ARCH-004 Topology Flexibility: Both centralized and decentralized 333 (peer-to-peer) information exchange MUST be supported. Centralized 334 data exchange enables use of a common data format to bridge together 335 data exchange between diverse systems, and can leverage a virtual 336 data store that centralizes and offloads all data access, storage, 337 and maintenance to a dedicated resource. Decentralized data 338 exchange enables simplicity of sharing data between relatively 339 uniform systems, and between small numbers of systems, especially 340 within a single enterprise domain. The fact that a centralized or 341 decentralized deployment is used SHOULD be invisible to a consumer. 343 ARCH-005 Capability Negotiation: Announcement and negotiation of 344 functional capabilities (such as authentication protocols, 345 authorization schemes, data models, transport protocols, etc.) MUST 346 be supported, enabling a SACM component to make inquiries about the 347 capabilities of other components in the SACM ecosystem. 349 ARCH-006 Role-based Authorization: The SACM architecture MUST be 350 capable of effecting role-based authorization. Distinction of 351 endpoints capable of and authorized to provide or consume 352 information is required to address appropriate access controls. 354 ARCH-007 Context-based Authorization: The SACM architecture MUST be 355 capable of effecting context-based authorization. Different 356 policies (e.g. business, regulatory, etc.) might specify what data 357 may be exposed to, or shared by, consumers based on one or more 358 attributes of the consumer. The policy might specify that consumers 359 are required to share specific information either back to the system 360 or to administrators. 362 ARCH-008 Time Synchronization: Actions or decisions based on time- 363 sensitive data (such as user logon/logoff, endpoint connection/ 364 disconnection, endpoint behavior events, etc.) are all predicated on 365 a synchronized understanding of time. The SACM architecture MUST 366 provide a mechanism for all components to synchronize time. A 367 mechanism for detecting and reporting time discrepancies SHOULD be 368 provided by the architecture and reflected in the information model. 370 2.3. Requirements for the Information Model 372 The SACM information model represents the abstracted representation 373 for Posture Assessment information to be communicated. SACM data 374 models must adhere to and comply with the SACM information model. 375 The requirements for the SACM information model include: 377 IM-001 Extensible Attribute Vocabulary: The information model MUST 378 define a minimum set of attributes for communicating Posture 379 Information, to ensure interoperability between data models. 380 (Individual data models may define attributes beyond the mandatory- 381 to-implement minimum set.) The attributes should be defined with a 382 clear mechanism for extensibility to enable data models to adhere to 383 SACM's required attributes as well as allow for their own 384 extensions. The attribute vocabulary should be defined with a clear 385 mechanism for extensibility to enable future versions of the 386 information model to be interoperably expanded with new attributes. 388 IM-002 Posture Data Publication: The information model MUST allow 389 for the data to be provided by a SACM component either solicited or 390 unsolicited. No aspect of the information model should be dependent 391 upon or assume a push or pull model of publication. 393 IM-003 Data Model Negotiation: SACM's information model MUST allow 394 support for different data models, data model versions, and 395 different versions of the operations on the data models and 396 transport protocols. The SACM information model MUST include the 397 ability to discover and negotiate the use of a particular data model 398 or any data model. 400 IM-004 Data Model Identification: The information model MUST provide 401 a means to uniquely identify each data model uniquely. The 402 identifier MUST contain both an identifier of the data model and a 403 version indicator for the data model. The identifiers SHOULD be 404 decomposable so that a customer can query for any version of a 405 specific data model and compare returned values for older or newer 406 than a desired version. 408 IM-005 Data Lifetime Management: The information model MUST provide 409 a means to allow data models to include data lifetime management. 410 The information model must identify attributes that can allow data 411 models to, at minimum, identify the data's origination time and 412 expected time of next update or data longevity (how long should the 413 data be assumed to still be valid). 415 IM-006 Singularity and Modularity: The SACM information model MUST 416 be singular (i.e. there is only one information model, not multiple 417 alternative information models from which to choose) and MAY be 418 modular (a conjunction of several sub-components) for ease of 419 maintenance and extension. For example, endpoint identification 420 could be an independent sub-component of the information model, to 421 simplify updating of endpoint identification attributes. 423 2.4. Requirements for the Data Model 425 The SACM information model represents an abstraction for "what" 426 information can be communicated and "how" it is to be represented and 427 shared. It is expected that as applications may produce posture 428 assessment information, they may share it using a specific data 429 model. Similarly, applications consuming or requesting posture 430 assessment information, may require it be based on a specific data 431 model. Thus, while there may exist different data models and 432 schemas, they should adhere to the SACM information model and meet 433 the requirements defined in this section. 435 The specific requirements for candidate data models include: 437 DM-001 Element Association: The data model MUST contain a data model 438 element for each information model element (e.g. endpoint, IP 439 address, asset). In other words, for every item in the information 440 model, there must be an item in the data model. The data model can 441 also include elements that do not exist in the information model. 443 DM-002 Data Model Structure: The data model can be structured either 444 as one single module or separated into modules and sub-modules that 445 allow for references between them. The data model structure MAY 446 reflect structure in the information model, but does not need to. 447 For example, the data model might use one module to define 448 endpoints, and that module might reference other modules that 449 describe the various assets associated with the endpoint. 450 Constraints and interfaces might further be defined to resolve or 451 tolerate ambiguity in the references (e.g. same IP address used in 452 two separate networks). 454 DM-003 Search Flexibility: The search interfaces and actions MUST 455 include the ability to start a search anywhere within a data model 456 structure, and the ability to search based on patterns ("wildcard 457 searches") as well as specific data elements. 459 DM-004 Full vs. Partial Updates: The data model SHOULD include the 460 ability to allow providers of data to provide the data as a whole, 461 or when updates occur. For example, a consumer can request a full 462 update on initial engagement, then request to receive deltas 463 (updates containing only the changes since the last update) on an 464 ongoing basis as new data is generated. 466 DM-005 Loose Coupling: The data model SHOULD allow for a loose 467 coupling between the provider and the consumer, such that the 468 consumer can request information without being required to request 469 it from a specific provider, and a provider can publish information 470 without having a specific consumer targeted to receive it. 472 DM-006 Data Cardinality: The data model MUST describe their 473 constraints (e.g. cardinality). As posture information and the 474 tasks for collection, aggregation, or evaluation, could comprise one 475 or more attributes, interfaces and actions MUST allow and account 476 for such cardinality as well as whether the attributes are 477 conditional, optional, or mandatory. 479 DM-007 Data Model Negotiation: The interfaces and actions in the 480 data model MUST include capability negotiation to enable discovery 481 of supported and available data types and schemas. 483 DM-008 Data Origin: The data model MUST include the ability for 484 consumers to identify the data origin (provider that collected the 485 data). 487 DM-009 Origination Time: The data model SHOULD allow the provider to 488 include the information's origination time. 490 DM-010 Data Generation: The data model MUST allow the provider to 491 include attributes defining how the data was generated (e.g. self- 492 reported, reported by aggregator, scan result, etc.). 494 DM-011 Data Source: The data model MUST allow the provider to 495 include attributes identifying the data source (target endpoint from 496 which the data was collected) - e.g. hostname, domain (DNS) name or 497 application name. 499 DM-012 Data Updates: The data model SHOULD allow the provider to 500 include attributes defining whether the information provided is a 501 delta, partial, or full set of information. 503 DM-013 Multiple Collectors: The data model MUST support the 504 collection of attributes by a variety of collectors, including 505 internal collectors, external collectors with an authenticated 506 relationship with the endpoint, and external collectors based on 507 network and other observers. 509 DM-014 Attribute Extensibility: Use Cases in the whole of Section 2 510 describe the need for an attribute dictionary. With SACM's scope 511 focused on posture assessment, the data model attribute collection 512 and aggregation MUST have a well-understood set of attributes 513 inclusive of their meaning or usage intent. The data model MUST 514 include all attributes defined in the information model and MAY 515 include additional attributes beyond those found in the information 516 model. Additional attributes MUST be defined in accordance with the 517 extensibility framework provided in the information model (see IM- 518 001). 520 DM-015 Solicited vs. Unsolicited Updates: The data model MUST enable 521 a provider to publish data either solicited (in response to a 522 request from a consumer) or unsolicited (as new data is generated, 523 without a request required). For example, an external collector can 524 publish data in response to a request by a consumer for information 525 about an endpoint, or can publish data as it observes new 526 information about an endpoint, without any specific consumer request 527 triggering the publication; a compliance-server provider may publish 528 endpoint posture information in response to a request from a 529 consumer (solicited), or it may publish posture information driven 530 by a change in the posture of the endpoint (unsolicited). 532 DM-016 Transport Agnostic: The data model MUST be transport 533 agnostic, to allow for the data operations to leverage the most 534 appropriate SACM transport protocol. 536 2.5. Requirements for Data Model Operations 538 Posture information data adhering to a data model must also provide 539 interfaces that include operations for access and production of the 540 data. Operations requirements are distinct from transport 541 requirements in that operations requirements are requirements on the 542 application performing requests and responses, whereas transport 543 requirements are requirements on the transport protocol carrying the 544 requests / responses. The specific requirements for such operations 545 include: 547 OP-001 Time Synchronization: Request and response operations MUST be 548 timestamped, and published information SHOULD capture time of 549 publication. Actions or decisions based on time-sensitive data 550 (such as user logon/logoff, endpoint connection/disconnection, 551 endpoint behavior events, etc.) are all predicated on a synchronized 552 understanding of time. A method for detecting and reporting time 553 discrepancies SHOULD be provided. 555 OP-002 Collection Abstraction: Collection is the act of a SACM 556 component gathering data from a target endpoint. The request for a 557 data item MUST include enough information to properly identify the 558 item to collect, but the request shall not be a command to directly 559 execute nor directly be applied as arguments to a command. The 560 purpose of this requirement is primarily to reduce the potential 561 attack vectors, but has the additional benefit of abstracting the 562 request for collection from the collection method, thereby allowing 563 more flexibility in how collection is implemented. 565 OP-003 Collection Composition: A collection request MAY be composed 566 of multiple collection requests (which yield collected values). The 567 desire for multiple values MUST be expressed as part of the 568 collection request, so that the aggregation can be resolved at the 569 point of collection without having to interact with the requestor. 570 This requirement should not be interpreted as preventing a collector 571 from providing attributes which were not part of the original 572 request. 574 OP-004 Attribute-based Query: A query operation is the act of 575 requesting data from a provider. Query operations SHOULD be based 576 on a set of attributes. Query operations MUST support both a query 577 for specific attributes and a query for all attributes. Use Case 578 2.1.2 describes the need for the data model to support a query 579 operation based on a set of attributes to facilitate collection of 580 information such as posture assessment, inventory (of endpoints or 581 endpoint components), and configuration checklist. 583 OP-005 Information-based Query with Filtering: The query operation 584 MUST support filtering. Use Case 2.1.3 describes the need for the 585 data model to support the means for the information to be collected 586 through a query mechanism. Furthermore, the query operation 587 requires filtering capabilities to allow for only a subset of 588 information to be retrieved. The query operation MAY be a 589 synchronous request or asynchronous request. 591 OP-006 Operation Scalability: The operation resulting from a query 592 operation MUST be able to handle the return and receipt of large 593 amounts of data. Use Cases 2.1.4 and 2.1.5 describe the need for 594 the data model to support scalability. For example, the query 595 operation may result in a very large set of attributes, as well as a 596 large set of targets. 598 OP-007 Data Abstraction: The data model MUST allow a SACM component 599 to communicate what data was used to construct the target endpoint's 600 identity, so other SACM components can determine whether they are 601 constructing an equivalent target endpoint (and its identity) and 602 whether they have confidence in that identity. SACM components 603 SHOULD have interfaces defined to transmit this data directly or to 604 refer to where the information can be retrieved. 606 OP-008 Provider Restriction: Request operations MUST include the 607 ability to restrict the data to be provided by a specific provider 608 or a provider with specific characteristics. Response operations 609 MUST include the ability to identify the provider that supplied the 610 response. For example, a SACM Consumer should be able to request 611 that all of the data come from a specific provider by identity (e.g. 612 Provider A) or from a Provider that is in a specific location (e.g. 613 in the Boston office). 615 2.6. Requirements for SACM Transport Protocols 617 The term transport protocol is frequently overloaded. The term SACM 618 transport protocol is intended to be distinguished from underlying 619 layer 3 and 4 protocols such as TCP/IP and TLS. However, it is 620 possible that a layer 3 or 4 protocol may be used as a SACM transport 621 protocol, either alone or as part of a SACM transport protocol (i.e. 623 using HTTP over TLS with XML as the content). The SACM transport 624 protocol is focused on moving data and performing necessary access 625 control operations; it is agnostic to the data model operations. 627 The requirements for SACM transport protocols include: 629 T-001 Multiple Transport Protocol Support: SACM transport protocols 630 MUST support different network transport protocols in a deployment 631 to support different transport layer requirements, different device 632 capabilities, and system configurations dealing with connectivity. 634 T-002 Data Integrity: SACM transport protocols MUST be able to 635 ensure data integrity for data in transit. 637 T-003 Data Confidentiality: SACM transport protocols MUST be able to 638 support data confidentiality. SACM transport protocols MUST ensure 639 data protection for data in transit (e.g. by encryption) to provide 640 confidentiality, integrity, and robustness against protocol-based 641 attacks. Note that while the transport MUST be able to support data 642 confidentiality, implementations MAY provide a configuration option 643 that enables and disables confidentiality in deployments. 644 Protection for data at rest is not in scope for transport protocols. 645 Data protection MAY be used for both privacy and non-privacy 646 scenarios. 648 T-004 Transport Protection: SACM transport protocols MUST be capable 649 of supporting mutual authentication and replay protection. 651 T-005 Transport Reliability: SACM transport protocols MUST provide 652 reliable delivery of data. This includes the ability to perform 653 fragmentation and reassembly, and to detect replays. The SACM 654 transport may take advantage of reliability features in the network 655 transport; however, the network transport may be unreliable (e.g. 656 UDP), in which case the SACM transport running over the unreliable 657 network transport is responsible for ensuring reliability (i.e. by 658 provisions such as confirmations and re-transmits). 660 T-006 Transport Layer Requirements: Each SACM transport protocol 661 MUST clearly specify the transport layer requirements it needs to 662 operate correctly. Examples of items that may need to be specified 663 include connectivity requirements, replay requirements, data link 664 encryption requirements, and/or channel binding requirements. These 665 requirements are needed in order for deployments to be done 666 correctly. For example, a proxy server between UDP and TCP can 667 provide a connection that correctly fulfills the connectivity and 668 replay requirements as well as data link requirements (through the 669 use of TLS and DTLS) but would be unable to provide a channel 670 binding requirement, as that implies there is no MITM to look at the 671 data. 673 3. Acknowledgements 675 The authors would like to thank Barbara Fraser, Jim Bieda, and Adam 676 Montville for reviewing and contributing to this draft. In addition, 677 we recognize valuable comments and suggestions made by Jim Schaad and 678 Chris Inacio. 680 4. IANA Considerations 682 This memo includes no request to IANA. 684 5. Security Considerations 686 This document defines the requirements for SACM. As such, it is 687 expected that several data models, protocols, and transports may be 688 defined or reused from already existing standards. This section will 689 highlight security considerations that may apply to SACM based on the 690 architecture and standards applied in SACM. In particular, 691 highlights to security considerations that may apply to the SACM 692 reference architecture and standard data models and transports will 693 be discussed. 695 To address security and privacy considerations, the data model, 696 protocols, and transports must consider authorization based on 697 consumer function and privileges, to only allow authorized consumers 698 and providers to access specific information being requested or 699 published. 701 To enable federation across multiple entities (such as across 702 organizational or geographic boundaries) authorization must also 703 extend to infrastructure elements themselves, such as central 704 controllers / brokers / data repositories. 706 In addition, authorization needs to extend to specific information or 707 resources available in the environment. In other words, 708 authorization is based on the subject (the information requestor), 709 the provider (the information responder), the object (the endpoint 710 the information is being requested on), and the attribute (what piece 711 of data is being requested). The method by which this authorization 712 is applied is unspecified. 714 SACM's charter focuses on the workflow orchestration and the sharing 715 of posture information for improving efficacy of security 716 applications such as compliance, configuration, assurance and other 717 threat and vulnerability reporting and remediation systems. While 718 the goal is to facilitate the flow of information securely, it is 719 important to note that participating endpoints may not be cooperative 720 or trustworthy. 722 5.1. Trust between Provider and Requestor 724 The information given from the provider to a requestor may come with 725 different levels of trustworthiness given the different potential 726 deployment scenarios and compromise either at the provider, the 727 requesting consumer, or devices that are involved in the transport 728 between the provider and requestor. This section will describe the 729 different considerations that may reduce the level of trustworthiness 730 of the information provided. 732 In the information transport flow, it is possible that some of the 733 devices may serve as proxies or brokers and as such, may be able to 734 observe the communications flowing between an information provider 735 and requestor. Without appropriate protections, it is possible for 736 these proxies and brokers to inject and affect man-in-the-middle 737 attacks. 739 It is common to, in general, distrust the network service provider, 740 unless the full hop by hop communications process flow is well 741 understood. As such, the posture information provider should protect 742 the posture information data it provides as well as the transport it 743 uses. Similarly, while there may be providers whose goal is to 744 openly share its information, there may also be providers whose 745 policy is to grant access to certain posture information based on its 746 business or regulatory policy. In those situations, a provider may 747 require full authentication and authorization of the requestor (or 748 set of requestors) and share only the authorized information to the 749 authenticated and authorized requestors. 751 A requestor beyond distrusting the network service provider, must 752 also account that the information received from the provider may have 753 been communicated through an undetermined network communications 754 system. That is, the posture information may have traversed through 755 many devices before reaching the requestor. SACM specifications 756 should provide the means for verifying data origin and data integrity 757 and at minimum, provide endpoint authentication and transport 758 integrity. 760 A requestor may require data freshness indications, both knowledge of 761 data origination as well as time of publication so that it can make 762 more informed decisions about the relevance of the data based on its 763 currency and/or age. 765 It is also important to note that endpoint assessment reports, 766 especially as they may be provided by the target endpoint may pose 767 untrustworthy information. The considerations for this are described 768 in Section 8 of [RFC5209]. 770 The trustworthiness of the posture information given by the provider 771 to one or many requestors is dependent on several considerations. 772 Some of these include the requestor requiring: 774 o Full disclosure of the network topology path to the provider(s). 776 o Direct (peer to peer) communication with the provider. 778 o Authentication and authorization of the provider. 780 o Either or both confidentiality and integrity at the transport 781 layer. 783 o Either or both confidentiality and integrity at the data layer. 785 5.2. Privacy Considerations 787 SACM information may contain sensitive information about the target 788 endpoint as well as revealing identity information of the producer or 789 consumer of such information. Similarly, as part of the SACM 790 discovery mechanism, the advertised capabilities (and roles, e.g. 791 SACM components enabled) by the endpoint may be construed as private 792 information. There may be applications as well as business and 793 regulatory practicess that require that aspects of such information 794 be hidden 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., "Secure Automation and Continuous Monitoring 823 (SACM) Terminology", draft-ietf-sacm-terminology-08 (work 824 in progress), October 2015. 826 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 827 Requirement Levels", BCP 14, RFC 2119, 828 DOI 10.17487/RFC2119, March 1997, 829 . 831 [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. 832 Tardo, "Network Endpoint Assessment (NEA): Overview and 833 Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008, 834 . 836 [RFC7632] Waltermire, D. and D. Harrington, "Endpoint Security 837 Posture Assessment: Enterprise Use Cases", RFC 7632, 838 DOI 10.17487/RFC7632, September 2015, 839 . 841 7.2. Informative References 843 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 844 Morris, J., Hansen, M., and R. Smith, "Privacy 845 Considerations for Internet Protocols", RFC 6973, 846 DOI 10.17487/RFC6973, July 2013, 847 . 849 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 858 Lisa Lorenzin 859 Pulse Secure 860 2700 Zanker Rd., Suite 200 861 San Jose, CA 95134 862 US 864 Email: llorenzin@pulsesecure.net