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