Internet Engineering Task Force (IETF)                     N. Cam-Winget
Request for Comments: 8248                                 Cisco Systems
Category: Informational                                      L. Lorenzin
ISSN: 2070-1721                                             Pulse Secure
                                                          September 2017
Internet Engineering Task Force (IETF)                     N. Cam-Winget
Request for Comments: 8248                                 Cisco Systems
Category: Informational                                      L. Lorenzin
ISSN: 2070-1721                                             Pulse Secure
                                                          September 2017

Security Automation and Continuous Monitoring (SACM) Requirements




This document defines the scope and set of requirements for the Security Automation and Continuous Monitoring (SACM) architecture, data model, and transfer protocols. The requirements and scope are based on the agreed-upon use cases described in RFC 7632.

本文件定义了安全自动化和连续监控(SACM)体系结构、数据模型和传输协议的范围和要求集。需求和范围基于RFC 7632中描述的商定用例。

Status of This Memo


This document is not an Internet Standards Track specification; it is published for informational purposes.


This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.

本文件是互联网工程任务组(IETF)的产品。它代表了IETF社区的共识。它已经接受了公众审查,并已被互联网工程指导小组(IESG)批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准;见RFC 7841第2节。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at


Copyright Notice


Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.

版权所有(c)2017 IETF信托基金和确定为文件作者的人员。版权所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ( in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(自本文件出版之日起生效。请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本,并提供简化BSD许可证中所述的无担保。

Table of Contents


   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Requirements for SACM . . . . . . . . . . . . . . . . . .   4
     2.2.  Requirements for the Architecture . . . . . . . . . . . .   7
     2.3.  Requirements for the Information Model  . . . . . . . . .   9
     2.4.  Requirements for the Data Model . . . . . . . . . . . . .  10
     2.5.  Requirements for Data Model Operations  . . . . . . . . .  12
     2.6.  Requirements for SACM Transfer Protocols  . . . . . . . .  14
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
     4.1.  Trust between Provider and Requestor  . . . . . . . . . .  16
     4.2.  Privacy Considerations  . . . . . . . . . . . . . . . . .  17
   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  18
     5.1.  Normative References  . . . . . . . . . . . . . . . . . .  18
     5.2.  Informative References  . . . . . . . . . . . . . . . . .  18
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  18
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19
   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Requirements for SACM . . . . . . . . . . . . . . . . . .   4
     2.2.  Requirements for the Architecture . . . . . . . . . . . .   7
     2.3.  Requirements for the Information Model  . . . . . . . . .   9
     2.4.  Requirements for the Data Model . . . . . . . . . . . . .  10
     2.5.  Requirements for Data Model Operations  . . . . . . . . .  12
     2.6.  Requirements for SACM Transfer Protocols  . . . . . . . .  14
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
     4.1.  Trust between Provider and Requestor  . . . . . . . . . .  16
     4.2.  Privacy Considerations  . . . . . . . . . . . . . . . . .  17
   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  18
     5.1.  Normative References  . . . . . . . . . . . . . . . . . .  18
     5.2.  Informative References  . . . . . . . . . . . . . . . . .  18
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  18
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19
1. Introduction
1. 介绍

Today's environment of rapidly evolving security threats highlights the need to automate the sharing of security information (such as posture information) while protecting user information and the systems that store, process, and transmit this information. Security threats can be detected in a number of ways. The Security Automation and Continuous Monitoring (SACM) charter focuses on how to collect and share this information based on use cases that involve posture assessment of endpoints.


Scalable and sustainable collection, expression, and evaluation of endpoint information is foundational to SACM's objectives. To secure and defend a network, one must reliably determine what devices are on the network, how those devices are configured from a hardware perspective, what software products are installed on those devices, and how those products are configured. We need to be able to determine, share, and use this information in a secure, timely, consistent, and automated manner to perform endpoint posture assessments.


This document focuses on describing the requirements for facilitating the exchange of posture assessment information in the enterprise, in particular, for the use cases as exemplified in [RFC7632].


As proposals are evaluated for SACM standardization, the documents describing each proposal are expected to include a section that describes how the enumerated requirements are addressed.


This document uses terminology defined in [TERMS].


1.1. Requirements Language
1.1. 需求语言

Use of each capitalized word within a sentence or phrase carries the following meaning during the SACM WG's protocol selection process:


MUST - indicates an absolute requirement


MUST NOT - indicates something absolutely prohibited


SHOULD - indicates a strong recommendation of a desired result


SHOULD NOT - indicates a strong recommendation against a result


MAY - indicates a willingness to allow an optional outcome


When the words appear in lower case, their natural language meaning is used.


2. Requirements
2. 要求

This document defines requirements based on the SACM use cases described in [RFC7632]. This section describes the requirements used by SACM to assess and compare candidate data models, interfaces, and protocols. These requirements express characteristics or features that a candidate protocol, information model, or data model must be capable of offering to ensure security and interoperability.


Multiple data models, protocols, and transfers may be employed in a SACM environment. A SACM transfer protocol is one that runs on top of transport-layer protocols such as TCP/IP or internet-layer protocols such as HTTP, carries operations (requests/responses), and moves data.


SACM will define an architecture and information model focused on addressing the needs for determining, sharing, and using posture information securely via posture information providers and posture information consumers. With the information model defining assets and attributes to facilitate the guidance, collection, and assessment of posture, tasks that should be considered include:


1. Asset Classification: Map the target endpoint and/or the assets on the target endpoints to asset classes. This enables

1. 资产分类:将目标端点和/或目标端点上的资产映射到资产类。这使得

identification of the attributes needed to exchange information pertaining to the target endpoint.


2. Attribute Definition: Define the attributes desired to be collected from each target endpoint. For instance, organizations will want to know what software is installed and its critical security attributes such as patch level.

2. 属性定义:定义要从每个目标端点收集的属性。例如,组织将希望知道安装了什么软件及其关键安全属性,如补丁级别。

3. Policy Definition: This is where an organization can express its policy for acceptable or problematic values of an endpoint attribute. The expected values of an endpoint attribute are determined for later comparison against the actual endpoint attribute values during the evaluation process. Expected values may include both values that are good as well as values that represent problems, such as vulnerabilities. The organization can also specify the endpoint attributes that are to be present for a given target endpoint.

3. 策略定义:在这里,组织可以针对端点属性的可接受或有问题的值表达其策略。将确定端点属性的预期值,以便在评估过程中与实际端点属性值进行比较。预期值可能包括良好值和表示问题的值,如漏洞。组织还可以指定给定目标端点的端点属性。

4. Information Collection: Collect information (attribute values) from the target endpoint to populate the endpoint data.

4. 信息收集:从目标端点收集信息(属性值)以填充端点数据。

5. Endpoint Assessment: Evaluate the actual values of the endpoint attributes against those expressed in the policy. (An evaluation result may become additional endpoint data.)

5. 端点评估:根据策略中表示的端点属性值评估端点属性的实际值。(评估结果可能成为附加端点数据。)

6. Result Reporting: Report the results of the evaluation for use by other components. Examples of the use of a report would be additional evaluation, network enforcement, vulnerability detection, and license management.

6. 结果报告:报告评估结果,供其他组件使用。使用报告的示例包括附加评估、网络实施、漏洞检测和许可证管理。

2.1. Requirements for SACM
2.1. 对SACM的要求

Many deployment scenarios can be instantiated to address the above tasks and the use cases defined in [RFC7632]. To ensure interoperability, scalability, and flexibility in any of these deployments, the following requirements are defined for proposed SACM standards:


G-001 (Solution Extensibility): The information model, data models, protocols, and transfers defined by SACM MUST be designed to allow support for future extensions. SACM MUST allow for both standardized and proprietary extensions.


1. The information model and programmatic interfaces (see G-012 for one example) MUST support the ability to add new operations while maintaining backwards compatibility. SACM-defined transfer protocols MUST have extensibility to allow them to transfer operations that are defined in the future.

1. 信息模型和编程接口(例如,参见G-012)必须支持在保持向后兼容性的同时添加新操作的能力。SACM定义的传输协议必须具有可扩展性,以允许它们传输将来定义的操作。

2. The query language MUST allow for general inquiries as well as expression of specific attributes or relationships between attributes; the retrieval of specific information based on an event or on a continuous basis; and the ability to retrieve specific pieces of information, specific types or classes of information, or the entirety of available information.

2. 查询语言必须允许一般查询以及特定属性或属性之间关系的表达;基于事件或持续的基础上检索特定信息;以及检索特定信息片段、特定类型或类别的信息或全部可用信息的能力。

3. The information model MUST accommodate the interoperable addition of new data types and/or schemas.

3. 信息模型必须适应新数据类型和/或模式的互操作添加。

G-002 (Interoperability): The data models, protocols, and transports MUST be specified with enough details to ensure interoperability.


G-003 (Scalability): SACM needs to support a broad set of deployment scenarios. The data models, protocols, and transports have to be scalable unless they are specifically defined to apply to a special-purpose scenario, such as constrained devices. A SACM transfer protocol standard SHOULD include a section on scalability considerations that addresses the number of endpoints and amount of information to which it can reasonably be expected to scale. Scalability must be addressed to support:


* Large messages: It is possible that the size of posture assessment information can vary from a single assessment that is small in size to a very large message or a very large set of assessments (up to multiple gigabytes in size).

* 大消息:姿势评估信息的大小可能会有所不同,从一个较小的评估到一个非常大的消息或一组非常大的评估(最大可达数GB)。

* Large number of messages per second: A deployment may involve many rapid or simultaneous events that require processing, generating many messages per second.

* 每秒大量消息:部署可能涉及许多需要处理的快速或同时发生的事件,每秒生成许多消息。

* Large number of providers and consumers: A deployment may consist of a very large number of endpoints requesting and/or producing posture assessment information.

* 大量提供者和使用者:部署可能包括大量端点,请求和/或生成姿势评估信息。

* Large number of target endpoints: A deployment may be managing information of a very large number of target endpoints.

* 大量目标端点:部署可能正在管理大量目标端点的信息。

G-004 (Versatility): The data model, protocols, and transports must be suitably specified to enable implementations to fit into different deployment models and scenarios, including considerations for implementations of data models and transports operating in constrained environments. Separate solutions may be necessary to meet the needs of specific deployment models and scenarios.


G-005 (Information Extensibility): Non-standard (implementation-specific) attributes MUST be supported. A method SHOULD be defined for preventing collisions from occurring in the naming of all


attributes independent of their source. For interoperability and scope boundary, the information model MUST define the mandatory set of attributes.


G-006 (Data Protection): To protect the information being shared, SACM components MUST protect the integrity and confidentiality of data in transit (end to end) and data at rest (as information is stored in repositories). Mechanisms for this protection are unspecified but should include industry best practices. These mechanisms are required to be available (i.e., all data-handling components must support them) but are not required to be used in all cases.


G-007 (Data Partitioning): A method for partitioning data MUST be supported to accommodate considerations such as geographic, regulatory, operational requirements, overlay boundaries, and federation (where the data may be collected in multiple locations and either centralized or kept in the local region). Where replication of data is supported, it is required that methods exist to prevent update loops.


G-008 (Versioning and Backward Compatibility): Announcement and negotiation of versions, inclusive of existing capabilities (such as transfer protocols, data models, specific attributes within data models, standard attribute expression sets, etc.) MUST be supported. Negotiation for both versioning and capabilities is needed to accommodate future growth and ecosystems with mixed capabilities.


G-009 (Information Discovery): There MUST be mechanisms for components to discover what information is available across the ecosystem (i.e., a method for cataloging data available in the ecosystem and advertising it to consumers), where to go to get a specific piece of that information (i.e., which provider has the information), and what schemas are in use for organizing the information. For example, a method can be provided by which a node can locate the advertised information so that consumers are not required to have a priori knowledge to find available information.


G-010 (Target Endpoint Discovery): SACM MUST define the means by which target endpoints may be discovered. The use case in Section 2.1.2 of [RFC7632] describes the need to discover endpoints and their composition.


G-011 (Push and Pull Access): Three methods of data access MUST be supported: a Pull model, a solicited Push model, and an unsolicited Push model. All of the methods of data access MUST support the ability for the initiator to filter the set of posture assessment information to be delivered. Additionally, the provider of the


information MUST be able to filter the set of posture assessment information based on the permissions of the recipient. This requirement is driven by the use cases in Sections 2.1.3 and 2.1.4 of [RFC7632].


G-012 (SACM Component Interface): The interfaces by which SACM components communicate to share endpoint posture information MUST be well defined. That is, the interface defines the data model, SACM transfer protocols, and network transfer protocols to enable SACM components to communicate.


G-013 (Endpoint Location and Network Topology): The SACM architecture and interfaces MUST allow for the target endpoint (network) location and network topology to be modeled and understood. Where appropriate, the data model and the interfaces SHOULD allow for discovery of the target endpoint location, network topology, or both.


G-014 (Target Endpoint Identity): The SACM architecture and interfaces MUST support the ability of components to provide attributes that can be used to compose an identity for a target endpoint. These identities MAY be composed of attributes from one or more SACM components.


G-015 (Data Access Control): Methods of access control must be supported to accommodate considerations such as geographic, regulatory, operational, and federations. Entities accessing or publishing data MUST identify themselves and pass access policy.


2.2. Requirements for the Architecture
2.2. 体系结构的需求

Following are the requirements for the SACM architecture:


ARCH-001 (Component Functions): At the simplest abstraction, the SACM architecture MUST represent the core components and interfaces needed to perform the production and consumption of posture assessment information.


ARCH-002 (Scalability): The architectural components MUST account for a range of deployments, from very small sets of endpoints to very large deployments.


ARCH-003 (Flexibility): The architectural components MUST account for different deployment scenarios where the architectural components may be implemented, deployed, or used within a single application, service, or network, or may comprise a federated system.


ARCH-004 (Separation of Data and Management Functions): SACM MUST define both the configuration and management of the SACM data models and protocols used to transfer and share posture assessment information.


ARCH-005 (Topology Flexibility): Both centralized and decentralized (peer-to-peer) information exchange MUST be supported. Centralized data exchange enables use of a common data format to bridge together data exchange between diverse systems and can leverage a virtual data store that centralizes and offloads all data access, storage, and maintenance to a dedicated resource. Decentralized data exchange enables simplicity of sharing data between relatively uniform systems and between small numbers of systems, especially within a single enterprise domain. The fact that a centralized or decentralized deployment is used SHOULD be invisible to a consumer. However, there may be cases where the producer chooses to include that information due to consumer preference.


ARCH-006 (Capability Negotiation): Announcement and negotiation of functional capabilities (such as authentication protocols, authorization schemes, data models, transfer protocols, etc.) MUST be supported, enabling a SACM component to make inquiries about the capabilities of other components in the SACM ecosystem.


ARCH-007 (Role-Based Authorization): The SACM architecture MUST be capable of effecting role-based authorization. Distinction of endpoints capable of and authorized to provide or consume information is required to address appropriate access controls.


ARCH-008 (Context-Based Authorization): The SACM architecture MUST be capable of effecting context-based authorization. Different policies (e.g., business, regulatory, etc.) might specify what data may be exposed to, or shared by, consumers based on one or more attributes of the consumer. The policy might specify that consumers are required to share specific information either back to the system or to administrators.


ARCH-009 (Time Synchronization): Actions or decisions based on time-sensitive data (such as user logon/logoff, endpoint connection/ disconnection, endpoint behavior events, etc.) are all predicated on a synchronized understanding of time. The SACM architecture MUST provide a mechanism for all components to synchronize time. A mechanism for detecting and reporting time discrepancies SHOULD be provided by the architecture and reflected in the information model.


2.3. Requirements for the Information Model
2.3. 对信息模型的要求

The SACM information model represents the abstracted representation for posture assessment information to be communicated. SACM data models must adhere to and comply with the SACM information model. The requirements for the SACM information model include:


IM-001 (Extensible Attribute Vocabulary): The information model MUST define a minimum set of attributes for communicating posture information, to ensure interoperability between data models. (Individual data models may define attributes beyond the mandatory-to-implement minimum set.) The attributes should be defined with a clear mechanism for extensibility to enable data models to adhere to SACM's required attributes as well as allow for their own extensions. The attribute vocabulary should be defined with a clear mechanism for extensibility to enable future versions of the information model to be interoperably expanded with new attributes.


IM-002 (Posture Data Publication): The information model MUST allow for the data to be provided by a SACM component either solicited or unsolicited. No aspect of the information model should be dependent upon or assume a Push or Pull model of publication.


IM-003 (Data Model Negotiation): SACM's information model MUST allow support for different data models, data model versions, and different versions of the operations on the data models and transfer protocols. The SACM information model MUST include the ability to discover and negotiate the use of a particular data model or any data model.


IM-004 (Data Model Identification): The information model MUST provide a means to uniquely identify each data model. The identifier MUST contain both an identifier of the data model and a version indicator for the data model. The identifiers SHOULD be decomposable so that a customer can query for any version of a specific data model and compare returned values for older or newer than a desired version.


IM-005 (Data Lifetime Management): The information model MUST provide a means to allow data models to include data lifetime management. The information model must identify attributes that can allow data models to, at minimum, identify the data's origination time and expected time of next update or data longevity (how long the data should be assumed to still be valid).


IM-006 (Singularity and Modularity): The SACM information model MUST be singular (i.e., there is only one information model, not multiple alternative information models from which to choose) and MAY be


modular (a conjunction of several subcomponents) for ease of maintenance and extension. For example, endpoint identification could be an independent subcomponent of the information model, to simplify updating of endpoint identification attributes.


2.4. Requirements for the Data Model
2.4. 对数据模型的要求

The SACM information model represents an abstraction for "what" information can be communicated and "how" it is to be represented and shared. It is expected that as applications may produce posture assessment information, they may share it using a specific data model. Similarly, applications consuming or requesting posture assessment information may require that it be based on a specific data model. Thus, while there may exist different data models and schemas, they should adhere to the SACM information model and meet the requirements defined in this section.


The specific requirements for candidate data models include:


DM-001 (Element Association): A SACM information model consists of a set of SACM information model elements. A SACM data model MUST be derived from the SACM information model. A SACM data model consists of a set of SACM data model elements. In this derivation, a SACM data model element MAY map to one or more SACM information model elements. In addition, a SACM data model MAY include additional data model elements that are not associated with any SACM information model elements.


DM-002 (Data Model Structure): The data model can be structured either as one single module or separated into modules and submodules that allow for references between them. The data model structure MAY reflect structure in the information model but does not need to. For example, the data model might use one module to define endpoints, and that module might reference other modules that describe the various assets associated with the endpoint. Constraints and interfaces might further be defined to resolve or tolerate ambiguity in the references (e.g., the same IP address used in two separate networks).


DM-003 (Search Flexibility): The search interfaces and actions MUST include the ability to start a search anywhere within a data model structure and the ability to search based on patterns ("wildcard searches") as well as specific data elements.


DM-004 (Full vs. Partial Updates): The data model SHOULD include the ability to allow providers of data to provide the data as a whole or when updates occur. For example, a consumer can request a full update on initial engagement, then request to receive deltas


(updates containing only the changes since the last update) on an ongoing basis as new data is generated.


DM-005 (Loose Coupling): The data model SHOULD allow for a loose coupling between the provider and the consumer, such that the consumer can request information without being required to request it from a specific provider, and a provider can publish information without having a specific consumer targeted to receive it.


DM-006 (Data Cardinality): The data model MUST describe their constraints (e.g., cardinality). As posture information and the tasks for collection, aggregation, or evaluation could comprise one or more attributes, interfaces and actions MUST allow and account for such cardinality and for conditional, optional, or mandatory attributes.


DM-007 (Data Model Negotiation): The interfaces and actions in the data model MUST include capability negotiation to enable discovery of supported and available data types and schemas.


DM-008 (Data Origin): The data model MUST include the ability for consumers to identify the data origin (provider that collected the data).


DM-009 (Origination Time): The data model SHOULD allow the provider to include the information's origination time.


DM-010 (Data Generation): The data model MUST allow the provider to include attributes defining how the data was generated (e.g., self-reported, reported by aggregator, scan result, etc.).


DM-011 (Data Source): The data model MUST allow the provider to include attributes identifying the data source (target endpoint from which the data was collected), e.g., hostname, domain (DNS) name, or application name.


DM-012 (Data Updates): The data model SHOULD allow the provider to include attributes defining whether the information provided is a delta, partial, or full set of information.


DM-013 (Multiple Collectors): The data model MUST support the collection of attributes by a variety of collectors, including internal collectors, external collectors with an authenticated relationship with the endpoint, and external collectors based on network and other observers.


DM-014 (Attribute Extensibility): All of the use cases in Section 2 of [RFC7632] describe the need for an attribute dictionary. With


SACM's scope focused on posture assessment, the data model attribute collection and aggregation MUST have a well-understood set of attributes inclusive of their meaning or usage intent. The data model MUST include all attributes defined in the information model and MAY include additional attributes beyond those found in the information model. Additional attributes MUST be defined in accordance with the extensibility framework provided in the information model (see IM-001).


DM-015 (Solicited vs. Unsolicited Updates): The data model MUST enable a provider to publish data either solicited (in response to a request from a consumer) or unsolicited (as new data is generated, without a request required). For example, an external collector can publish data in response to a request by a consumer for information about an endpoint, or it can publish data as it observes new information about an endpoint, without any specific consumer request triggering the publication; a compliance-server provider may publish endpoint posture information in response to a request from a consumer (solicited), or it may publish posture information driven by a change in the posture of the endpoint (unsolicited).


DM-016 (Transfer Agnostic): The data model MUST be transfer agnostic, to allow for the data operations to leverage the most appropriate SACM transfer protocol.


2.5. Requirements for Data Model Operations
2.5. 数据模型操作的要求

Posture information data adhering to a data model must also provide interfaces that include operations for access and production of the data. Operations requirements are distinct from transfer requirements in that operations requirements are requirements on the application performing requests and responses, whereas transfer requirements are requirements on the transfer protocol carrying the requests and responses. The specific requirements for such operations include:


OP-001 (Time Synchronization): Request and response operations MUST be timestamped, and published information SHOULD capture time of publication. Actions or decisions based on time-sensitive data (such as user logon/logoff, endpoint connection/disconnection, endpoint behavior events, etc.) are all predicated on a synchronized understanding of time. A method for detecting and reporting time discrepancies SHOULD be provided.


OP-002 (Collection Abstraction): Collection is the act of a SACM component gathering data from a target endpoint. The request for a data item MUST include enough information to properly identify the item to collect, but the request shall not be a command to directly


execute nor be directly applied as arguments to a command. The purpose of this requirement is primarily to reduce the potential attack vectors but has the additional benefit of abstracting the request for collection from the collection method, thereby allowing more flexibility in how collection is implemented.


OP-003 (Collection Composition): A collection request MAY be composed of multiple collection requests (which yield collected values). The desire for multiple values MUST be expressed as part of the collection request, so that the aggregation can be resolved at the point of collection without having to interact with the requestor. This requirement should not be interpreted as preventing a collector from providing attributes that were not part of the original request.


OP-004 (Attribute-Based Query): A query operation is the act of requesting data from a provider. Query operations SHOULD be based on a set of attributes. Query operations MUST support both a query for specific attributes and a query for all attributes. The use case in Section 2.1.2 of [RFC7632] describes the need for the data model to support a query operation based on a set of attributes to facilitate collection of information such as posture assessment, inventory (of endpoints or endpoint components), and configuration checklist.


OP-005 (Information-Based Query with Filtering): The query operation MUST support filtering. The use case in Section 2.1.3 of [RFC7632] describes the need for the data model to support the means for the information to be collected through a query mechanism. Furthermore, the query operation requires filtering capabilities to allow for only a subset of information to be retrieved. The query operation MAY be a synchronous request or asynchronous request.


OP-006 (Operation Scalability): The operation resulting from a query operation MUST be able to handle the return and receipt of large amounts of data. The use case in Section 2.1.4 of [RFC7632] describe the need for the data model to support scalability. For example, the query operation may result in a very large set of attributes as well as a large set of targets.


OP-007 (Data Abstraction): The data model MUST allow a SACM component to communicate what data was used to construct the target endpoint's identity, so that other SACM components can determine whether they are constructing an equivalent target endpoint (and its identity) and whether they have confidence in that identity. SACM components SHOULD have interfaces defined to transmit this data directly or to refer to where the information can be retrieved.


OP-008 (Provider Restriction): Request operations MUST include the ability to restrict the data to be provided by a specific provider or a provider with specific characteristics. Response operations MUST include the ability to identify the provider that supplied the response. For example, a SACM consumer should be able to request that all of the data come from a specific provider by identity (e.g., Provider A) or from a provider that is in a specific location (e.g., in the Boston office).


2.6. Requirements for SACM Transfer Protocols
2.6. SACM传输协议的要求

The term "SACM transfer protocol" is intended to be distinguished from underlying transport- and internet-layer protocols such as TCP/ IP or operating at an application-layer protocol such as HTTP. The SACM transfer protocol is focused on moving data and performing necessary access control operations; it is agnostic to the data model operations.


The requirements for SACM transfer protocols include:


T-001 (Multiple Transfer Protocol Support): SACM transfer protocols will vary depending on the deployment model that relies on different transfer-layer requirements, different device capabilities, and system configurations dealing with connectivity. For example, where posture attributes may be collected directly from an endpoint using the Network Endpoint Assessment (NEA) model [RFC5209], different transports may be defined to collect them using Posture Transport Protocol for Extensible Authentication Protocol Tunnel Methods (PT-EAP) [RFC7171] or Posture Transport Protocol over TLS (PT-TLS) [RFC6876], depending on the deployment scenario.


T-002 (Data Integrity): SACM transfer protocols MUST be able to ensure data integrity for data in transit.


T-003 (Data Confidentiality): SACM transfer protocols MUST be able to support data confidentiality. SACM transfer protocols MUST ensure data protection for data in transit (e.g., by encryption) to provide confidentiality, integrity, and robustness against protocol-based attacks. Note that while the transfer MUST be able to support data confidentiality, implementations MAY provide a configuration option that enables and disables confidentiality in deployments. Protection for data at rest is not in scope for transfer protocols. Data protection MAY be used for both privacy and non-privacy scenarios.


T-004 (Transfer Protection): SACM transfer protocols MUST be capable of supporting mutual authentication and replay protection.


T-005 (Transfer Reliability): SACM transfer protocols MUST provide reliable delivery of data. This includes the ability to perform fragmentation and reassembly and to detect replays. The SACM transfer may take advantage of reliability features in the network transport; however, the network transport may be unreliable (e.g., UDP), in which case the SACM transfer running over the unreliable network transport is responsible for ensuring reliability (i.e., by provisions such as confirmations and retransmits).


T-006 (Transfer-Layer Requirements): Each SACM transfer protocol MUST clearly specify the transport-layer requirements it needs to operate correctly. Examples of items that may need to be specified include connectivity requirements, replay requirements, data link encryption requirements, and/or channel-binding requirements. These requirements are needed in order for deployments to be done correctly.


T-007 (Transfer Protocol Adoption): SACM SHOULD, where reasonably possible, leverage and use existing IETF transfer protocols versus defining new ones.


3. IANA Considerations
3. IANA考虑

This document does not require any IANA actions.


4. Security Considerations
4. 安全考虑

This document defines the requirements for SACM. As such, it is expected that several data models, protocols, and transfer protocols may be defined or reused from already-existing standards.


To address security and privacy considerations, the data model, protocols, and transports must consider authorization based on consumer function and privileges, to only allow authorized consumers and providers to access specific information being requested or published.


To enable federation across multiple entities (such as across organizational or geographic boundaries), authorization must also extend to infrastructure elements themselves, such as central controllers, brokers, and data repositories.


In addition, authorization needs to extend to specific information or resources available in the environment. In other words, authorization is based on the subject (the information requestor), the provider (the information responder), the object (the endpoint the information is being requested on), and the attribute (what piece


of data is being requested). The method by which this authorization is applied is unspecified.


SACM's charter focuses on the workflow orchestration and the sharing of posture information for improving the efficacy of security applications such as compliance, configuration, assurance, and other threat and vulnerability reporting and remediation systems. While the goal is to facilitate the flow of information securely, it is important to note that participating endpoints may not be cooperative or trustworthy.


4.1. Trust between Provider and Requestor
4.1. 提供者和请求者之间的信任

The information given from the provider to a requestor may come with different levels of trustworthiness given the different potential deployment scenarios and compromise at the provider, the requesting consumer, or devices that are involved in the transfer between the provider and requestor. This section will describe the different considerations that may reduce the level of trustworthiness of the information provided.


In the information transfer flow, it is possible that some of the devices may serve as proxies or brokers and, as such, may be able to observe the communications flowing between an information provider and requestor. Without appropriate protections, it is possible for these proxies and brokers to inject and affect man-in-the-middle attacks.


In general, it is common to distrust the network service provider, unless the full hop-by-hop communications process flow is well understood. As such, the posture information provider should protect the posture information data it provides as well as the transfer it uses. Similarly, while there may be providers whose goal is to openly share its information, there may also be providers whose policy is to grant access to certain posture information based on its business or regulatory policy. In those situations, a provider may require full authentication and authorization of the requestor (or set of requestors) and share only the authorized information to the authenticated and authorized requestors.


Beyond distrusting the network service provider, a requestor must also take into account that the information received from the provider may have been communicated through an undetermined network communications system. That is, the posture information may have traversed through many devices before reaching the requestor. SACM specifications should provide the means for verifying data origin and data integrity and, at minimum, provide endpoint authentication and transfer integrity.


A requestor may require data freshness indications, both knowledge of data origination as well as time of publication, so that it can make more informed decisions about the relevance of the data based on its currency and/or age.


It is also important to note that endpoint assessment reports, especially as they may be provided by the target endpoint, may pose untrustworthy information. The considerations for this are described in Section 8 of [RFC5209].


The trustworthiness of the posture information given by the provider to one or many requestors is dependent on several considerations. Some of these include the requestor requiring:


o Full disclosure of the network topology path to the provider(s).

o 向提供商完全公开网络拓扑路径。

o Direct (peer-to-peer) communication with the provider.

o 与提供商直接(对等)通信。

o Authentication and authorization of the provider.

o 提供程序的身份验证和授权。

o Either or both confidentiality and integrity at the transfer layer.

o 传输层的机密性和完整性。

o Either or both confidentiality and integrity at the data layer.

o 数据层的机密性和完整性。

4.2. Privacy Considerations
4.2. 隐私考虑

SACM information may contain sensitive information about the target endpoint as well as revealing identity information of the producer or consumer of such information. Similarly, as part of the SACM discovery mechanism, the capabilities and roles (e.g., SACM components enabled) advertised by the endpoint may be construed as private information.


In addition to identity and SACM capabilities information disclosure, the use of timestamps (or other attributes that can be used as identifiers) could be further used to determine a target endpoint or user's behavioral patterns. Such attributes may also be deemed sensitive and may require further protection or obfuscation to meet privacy concerns. That is, there may be applications as well as business and regulatory practices that require that aspects of such information be hidden from any parties that do not need to know it.


Data confidentiality can provide some level of privacy but may fall short where unnecessary data is still transmitted. In those cases, filtering requirements at the data model such as OP-005 must be applied to ensure that such data is not disclosed. [RFC6973]


provides guidelines that SACM protocols, information models, and data models should follow.


5. References
5. 工具书类
5.1. Normative References
5.1. 规范性引用文件

[RFC7632] Waltermire, D. and D. Harrington, "Endpoint Security Posture Assessment: Enterprise Use Cases", RFC 7632, DOI 10.17487/RFC7632, September 2015, <>.

[RFC7632]Waltermire,D.和D.Harrington,“端点安全态势评估:企业用例”,RFC 7632,DOI 10.17487/RFC7632,2015年9月<>.

5.2. Informative References
5.2. 资料性引用

[RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. Tardo, "Network Endpoint Assessment (NEA): Overview and Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008, <>.

[RFC5209]Sangster,P.,Khosravi,H.,Mani,M.,Narayan,K.,和J.Tardo,“网络端点评估(NEA):概述和要求”,RFC 5209,DOI 10.17487/RFC5209,2008年6月<>.

[RFC6876] Sangster, P., Cam-Winget, N., and J. Salowey, "A Posture Transport Protocol over TLS (PT-TLS)", RFC 6876, DOI 10.17487/RFC6876, February 2013, <>.

[RFC6876]Sangster,P.,Cam Winget,N.,和J.Salowey,“TLS上的姿态传输协议(PT-TLS)”,RFC 6876,DOI 10.17487/RFC6876,2013年2月<>.

[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <>.

[RFC6973]Cooper,A.,Tschofenig,H.,Aboba,B.,Peterson,J.,Morris,J.,Hansen,M.,和R.Smith,“互联网协议的隐私考虑”,RFC 6973,DOI 10.17487/RFC6973,2013年7月<>.

[RFC7171] Cam-Winget, N. and P. Sangster, "PT-EAP: Posture Transport (PT) Protocol for Extensible Authentication Protocol (EAP) Tunnel Methods", RFC 7171, DOI 10.17487/RFC7171, May 2014, <>.

[RFC7171]Cam Winget,N.和P.Sangster,“PT-EAP:可扩展认证协议(EAP)隧道方法的姿态传输(PT)协议”,RFC 7171,DOI 10.17487/RFC7171,2014年5月<>.

[TERMS] Birkholz, H., Lu, J., Strassner, J., and N. Cam-Winget, "Security Automation and Continuous Monitoring (SACM) Terminology", Work in Progress, draft-ietf-sacm-terminology-13, July 2017.

[术语]Birkholz,H.,Lu,J.,Strassner,J.,和N.Cam Winget,“安全自动化和连续监控(SACM)术语”,正在进行的工作,草案-ietf-SACM-Terminology-132017年7月。



The authors would like to thank Barbara Fraser, Jim Bieda, and Adam Montville for reviewing and contributing to this document. In addition, we recognize valuable comments and suggestions made by Jim Schaad and Chris Inacio.

作者要感谢Barbara Fraser、Jim Bieda和Adam Montville对本文件的审阅和贡献。此外,我们感谢Jim Schaad和Chris Inacio提出的宝贵意见和建议。

Authors' Addresses


Nancy Cam-Winget Cisco Systems 3550 Cisco Way San Jose, CA 95134 United States of America



Lisa Lorenzin Pulse Secure 2700 Zanker Rd., Suite 200 San Jose, CA 95134 United States of America

美国加利福尼亚州圣何塞市赞克路2700号Lisa Lorenzin Pulse Secure 200室,邮编95134