draft-ietf-sacm-requirements-18.txt   rfc8248.txt 
SACM N. Cam-Winget Internet Engineering Task Force (IETF) N. Cam-Winget
Internet-Draft Cisco Systems Request for Comments: 8248 Cisco Systems
Intended status: Informational L. Lorenzin Category: Informational L. Lorenzin
Expires: February 2, 2018 Pulse Secure ISSN: 2070-1721 Pulse Secure
August 1, 2017 September 2017
Security Automation and Continuous Monitoring (SACM) Requirements Security Automation and Continuous Monitoring (SACM) Requirements
draft-ietf-sacm-requirements-18
Abstract Abstract
This document defines the scope and set of requirements for the This document defines the scope and set of requirements for the
Secure Automation and Continuous Monitoring (SACM) architecture, data Security Automation and Continuous Monitoring (SACM) architecture,
model and transfer protocols. The requirements and scope are based data model, and transfer protocols. The requirements and scope are
on the agreed upon use cases ([RFC7632]). based on the agreed-upon use cases described in RFC 7632.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." 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.
This Internet-Draft will expire on February 2, 2018. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8248.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements for SACM . . . . . . . . . . . . . . . . . . 4 2.1. Requirements for SACM . . . . . . . . . . . . . . . . . . 4
2.2. Requirements for the Architecture . . . . . . . . . . . . 7 2.2. Requirements for the Architecture . . . . . . . . . . . . 7
2.3. Requirements for the Information Model . . . . . . . . . 9 2.3. Requirements for the Information Model . . . . . . . . . 9
2.4. Requirements for the Data Model . . . . . . . . . . . . . 10 2.4. Requirements for the Data Model . . . . . . . . . . . . . 10
2.5. Requirements for Data Model Operations . . . . . . . . . 12 2.5. Requirements for Data Model Operations . . . . . . . . . 12
2.6. Requirements for SACM Transfer Protocols . . . . . . . . 14 2.6. Requirements for SACM Transfer Protocols . . . . . . . . 14
3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 4.1. Trust between Provider and Requestor . . . . . . . . . . 16
5.1. Trust between Provider and Requestor . . . . . . . . . . 16 4.2. Privacy Considerations . . . . . . . . . . . . . . . . . 17
5.2. Privacy Considerations . . . . . . . . . . . . . . . . . 17 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.1. Normative References . . . . . . . . . . . . . . . . . . 18
6.1. Normative References . . . . . . . . . . . . . . . . . . 18 5.2. Informative References . . . . . . . . . . . . . . . . . 18
6.2. Informative References . . . . . . . . . . . . . . . . . 18 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
Today's environment of rapidly-evolving security threats highlights Today's environment of rapidly evolving security threats highlights
the need to automate the sharing of security information (such as the need to automate the sharing of security information (such as
posture information) while protecting user information and the posture information) while protecting user information and the
systems that store, process, and transmit this information. Security systems that store, process, and transmit this information. Security
threats can be detected in a number of ways. The Secure Automation threats can be detected in a number of ways. The Security Automation
and Continuous Monitoring (SACM) charter focuses on how to collect and Continuous Monitoring (SACM) charter focuses on how to collect
and share this information based on use cases that involve posture and share this information based on use cases that involve posture
assessment of endpoints. assessment of endpoints.
Scalable and sustainable collection, expression, and evaluation of Scalable and sustainable collection, expression, and evaluation of
endpoint information is foundational to SACM's objectives. To secure endpoint information is foundational to SACM's objectives. To secure
and defend a network, one must reliably determine what devices are on and defend a network, one must reliably determine what devices are on
the network, how those devices are configured from a hardware the network, how those devices are configured from a hardware
perspective, what software products are installed on those devices, perspective, what software products are installed on those devices,
and how those products are configured. We need to be able to and how those products are configured. We need to be able to
determine, share, and use this information in a secure, timely, determine, share, and use this information in a secure, timely,
consistent, and automated manner to perform endpoint posture consistent, and automated manner to perform endpoint posture
assessments. assessments.
This document focuses on describing the requirements for facilitating This document focuses on describing the requirements for facilitating
the exchange of posture assessment information in the enterprise, in the exchange of posture assessment information in the enterprise, in
particular, for the use cases as exemplified in [RFC7632]. As particular, for the use cases as exemplified in [RFC7632].
proposals are evaluated for SACM standardization, their drafts are
expected to include a section that describe how they address each of
the enumerated requirements.
Also, this document uses terminology defined in As proposals are evaluated for SACM standardization, the documents
[I-D.ietf-sacm-terminology]. 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. Requirements Language
Use of each capitalized word within a sentence or phrase carries the Use of each capitalized word within a sentence or phrase carries the
following meaning during the SACM WG's protocol selection process: following meaning during the SACM WG's protocol selection process:
MUST - indicates an absolute requirement MUST - indicates an absolute requirement
MUST NOT - indicates something absolutely prohibited MUST NOT - indicates something absolutely prohibited
skipping to change at page 3, line 37 skipping to change at page 3, line 40
This document defines requirements based on the SACM use cases This document defines requirements based on the SACM use cases
described in [RFC7632]. This section describes the requirements used described in [RFC7632]. This section describes the requirements used
by SACM to assess and compare candidate data models, interfaces, and by SACM to assess and compare candidate data models, interfaces, and
protocols. These requirements express characteristics or features protocols. These requirements express characteristics or features
that a candidate protocol, information model, or data model must be that a candidate protocol, information model, or data model must be
capable of offering to ensure security and interoperability. capable of offering to ensure security and interoperability.
Multiple data models, protocols, and transfers may be employed in a Multiple data models, protocols, and transfers may be employed in a
SACM environment. A SACM transfer protocol is one that runs on top SACM environment. A SACM transfer protocol is one that runs on top
of transport layer protocols such as TCP/IP or internet layer of transport-layer protocols such as TCP/IP or internet-layer
protocols such as HTTP, carries operations (requests / responses), protocols such as HTTP, carries operations (requests/responses), and
and moves data. moves data.
SACM will define an architecture and information model focused on SACM will define an architecture and information model focused on
addressing the needs for determining, sharing, and using posture addressing the needs for determining, sharing, and using posture
information via Posture Information Providers and Posture Information information securely via posture information providers and posture
Consumers securely. With the information model defining assets and information consumers. With the information model defining assets
attributes to facilitate the guidance, collection, and assessment of and attributes to facilitate the guidance, collection, and assessment
posture, tasks that should be considered include: of posture, tasks that should be considered include:
1. Asset Classification: Map the target endpoint and/or the assets 1. Asset Classification: Map the target endpoint and/or the assets
on the target endpoints to asset classes. This enables on the target endpoints to asset classes. This enables
identification of the attributes needed to exchange information identification of the attributes needed to exchange information
pertaining to the target endpoint. pertaining to the target endpoint.
2. Attribute Definition: Define the attributes desired to be 2. Attribute Definition: Define the attributes desired to be
collected from each target endpoint. For instance, organizations collected from each target endpoint. For instance, organizations
will want to know what software is installed and its critical will want to know what software is installed and its critical
security attributes such as patch level. security attributes such as patch level.
3. Policy Definition: This is where an organization can express its 3. Policy Definition: This is where an organization can express its
policy for acceptable or problematic values of an endpoint policy for acceptable or problematic values of an endpoint
attribute. The expected values of an endpoint attribute are attribute. The expected values of an endpoint attribute are
determined for later comparison against the actual endpoint determined for later comparison against the actual endpoint
attribute values during the evaluation process. Expected values attribute values during the evaluation process. Expected values
may include both those values which are good as well as those may include both values that are good as well as values that
values which represent problems, such as vulnerabilities. The represent problems, such as vulnerabilities. The organization
organization can also specify the endpoint attributes that are to can also specify the endpoint attributes that are to be present
be present for a given target endpoint. for a given target endpoint.
4. Information Collection: Collect information (attribute values) 4. Information Collection: Collect information (attribute values)
from the target endpoint to populate the endpoint data. from the target endpoint to populate the endpoint data.
5. Endpoint Assessment: Evaluate the actual values of the endpoint 5. Endpoint Assessment: Evaluate the actual values of the endpoint
attributes against those expressed in the policy. (An evaluation attributes against those expressed in the policy. (An evaluation
result may become additional endpoint data). result may become additional endpoint data.)
6. Result Reporting: Report the results of the evaluation for use by 6. Result Reporting: Report the results of the evaluation for use by
other components. Examples of use of a report would be other components. Examples of the use of a report would be
additional evaluation, network enforcement, vulnerability additional evaluation, network enforcement, vulnerability
detection, and license management. detection, and license management.
2.1. Requirements for SACM 2.1. Requirements for SACM
Many deployment scenarios can be instantiated to address the above Many deployment scenarios can be instantiated to address the above
tasks and use cases defined in [RFC7632]. To ensure tasks and the use cases defined in [RFC7632]. To ensure
interoperability, scalability, and flexibility in any of these interoperability, scalability, and flexibility in any of these
deployments, the following requirements are defined for proposed SACM deployments, the following requirements are defined for proposed SACM
standards: standards:
G-001 Solution Extensibility: The information model, data models, G-001 (Solution Extensibility): The information model, data models,
protocols, and transfers defined by SACM MUST be designed to allow protocols, and transfers defined by SACM MUST be designed to allow
support for future (SACM) extensions. SACM MUST allow for both support for future extensions. SACM MUST allow for both
standardized and proprietary extensions. standardized and proprietary extensions.
1. The information model and programmatic interfaces (see G-012 for 1. The information model and programmatic interfaces (see G-012 for
one example) MUST support the ability to add new operations one example) MUST support the ability to add new operations
while maintaining backwards compatibility. SACM-defined while maintaining backwards compatibility. SACM-defined
transfer protocols MUST have extensibility to allow them to transfer protocols MUST have extensibility to allow them to
transfer operations that are defined in the future. transfer operations that are defined in the future.
2. The query language MUST allow for general inquiries, as well as 2. The query language MUST allow for general inquiries as well as
expression of specific attributes or relationships between expression of specific attributes or relationships between
attributes; the retrieval of specific information based on an attributes; the retrieval of specific information based on an
event, or on a continuous basis; and the ability to retrieve event or on a continuous basis; and the ability to retrieve
specific pieces of information, specific types or classes of specific pieces of information, specific types or classes of
information, or the entirety of available information. information, or the entirety of available information.
3. The information model MUST accommodate the interoperable 3. The information model MUST accommodate the interoperable
addition of new data types and/or schemas. addition of new data types and/or schemas.
G-002 Interoperability: The data models, protocols, and transpors G-002 (Interoperability): The data models, protocols, and transports
MUST be specified with enough details to ensure interoperability. MUST be specified with enough details to ensure interoperability.
G-003 Scalability: SACM needs to support a broad set of deployment G-003 (Scalability): SACM needs to support a broad set of deployment
scenarios. The data models, protocols, and transports has to be scenarios. The data models, protocols, and transports have to be
scalable unless they are specifically defined to apply to a special- scalable unless they are specifically defined to apply to a special-
purpose scenario, such as constrained devices. A SACM transfer purpose scenario, such as constrained devices. A SACM transfer
protocol standard SHOULD include a section on scalability protocol standard SHOULD include a section on scalability
considerations that addresses the number of endpoints and amount of considerations that addresses the number of endpoints and amount of
information to which it can reasonably be expected to scale. information to which it can reasonably be expected to scale.
Scalability must be addressed to support: Scalability must be addressed to support:
* Large message: It is possible that the size of posture assessment * Large messages: It is possible that the size of posture
information can vary from a single assessment that is small in assessment information can vary from a single assessment that is
size to a very large message or a very large set of assessments small in size to a very large message or a very large set of
(up to multiple gigabytes in size). assessments (up to multiple gigabytes in size).
* Large number of messages per second: A deployment may involve * Large number of messages per second: A deployment may involve
many rapid or simultaneous events that require processing, many rapid or simultaneous events that require processing,
generating many messages per second. generating many messages per second.
* Large number of providers and consumers: A deployment may consist * Large number of providers and consumers: A deployment may consist
of a very large number of endpoints requesting and/or producing of a very large number of endpoints requesting and/or producing
posture assessment information. posture assessment information.
* Large number of target endpoints: A deployment may be managing * Large number of target endpoints: A deployment may be managing
information of a very large number of target endpoints. information of a very large number of target endpoints.
G-004 Versatility: The data model, protocols, and transports must be G-004 (Versatility): The data model, protocols, and transports must
suitably specified to enable implementations to fit into different be suitably specified to enable implementations to fit into
deployment models and scenarios, including considerations for different deployment models and scenarios, including considerations
implementations of data models and transports operating in for implementations of data models and transports operating in
constrained environments. Separate solutions may be necessary to constrained environments. Separate solutions may be necessary to
meet the needs of specific deployment models and scenarios. meet the needs of specific deployment models and scenarios.
G-005 Information Extensibility: Non-standard (implementation- G-005 (Information Extensibility): Non-standard (implementation-
specific) attributes MUST be supported. A method SHOULD be defined specific) attributes MUST be supported. A method SHOULD be defined
for preventing collisions from occurring in the naming of all for preventing collisions from occurring in the naming of all
attributes independent of their source. For interoperability and attributes independent of their source. For interoperability and
scope boundary, the information model MUST define the mandatory set scope boundary, the information model MUST define the mandatory set
of attributes. of attributes.
G-006 Data Protection: To protect the information being shared, SACM G-006 (Data Protection): To protect the information being shared,
components MUST protect the integrity and confidentiality of data in SACM components MUST protect the integrity and confidentiality of
transit (end to end) and data at rest (as information is stored in data in transit (end to end) and data at rest (as information is
repositories). Mechanisms for this protection are unspecified but stored in repositories). Mechanisms for this protection are
should include industry best practices. These mechanisms are unspecified but should include industry best practices. These
required to be available (i.e. all data-handling components must mechanisms are required to be available (i.e., all data-handling
support them), but are not required to be used in all cases. 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 G-007 (Data Partitioning): A method for partitioning data MUST be
supported to accommodate considerations such as geographic, supported to accommodate considerations such as geographic,
regulatory, operational requirements, overlay boundaries, and regulatory, operational requirements, overlay boundaries, and
federation (where the data may be collected in multiple locations federation (where the data may be collected in multiple locations
and either centralized or kept in the local region). Where and either centralized or kept in the local region). Where
replication of data is supported, it is required that methods exist replication of data is supported, it is required that methods exist
to prevent update loops. to prevent update loops.
G-008 Versioning and Backward Compatibility: Announcement and G-008 (Versioning and Backward Compatibility): Announcement and
negotiation of versions, inclusive of existing capabilities (such as negotiation of versions, inclusive of existing capabilities (such as
transfer protocols, data models, specific attributes within data transfer protocols, data models, specific attributes within data
models, standard attribute expression sets, etc.) MUST be models, standard attribute expression sets, etc.) MUST be supported.
supported. Negotiation for both versioning and capabilities is Negotiation for both versioning and capabilities is needed to
needed to accommodate future growth and ecosystems with mixed accommodate future growth and ecosystems with mixed capabilities.
capabilities.
G-009 Information Discovery: There MUST be mechanisms for components G-009 (Information Discovery): There MUST be mechanisms for
to discover what information is available across the ecosystem (i.e. components to discover what information is available across the
a method for cataloging data available in the ecosystem and ecosystem (i.e., a method for cataloging data available in the
advertising it to consumers), where to go to get a specific piece of ecosystem and advertising it to consumers), where to go to get a
that information (i.e. which provider has the information), and what specific piece of that information (i.e., which provider has the
schemas are in use for organizing the information. For example, information), and what schemas are in use for organizing the
providing a method by which a node can locate the advertised information. For example, a method can be provided by which a node
information so that consumers are not required to have a priori can locate the advertised information so that consumers are not
knowledge to find available information. required to have a priori knowledge to find available information.
G-010 Target Endpoint Discovery: SACM MUST define the means by which G-010 (Target Endpoint Discovery): SACM MUST define the means by
target endpoints may be discovered. Use Case 2.1.2 describes the which target endpoints may be discovered. The use case in
need to discover endpoints and their composition. 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 G-011 (Push and Pull Access): Three methods of data access MUST be
supported: a Pull model, a solicited Push model, and an unsolicited supported: a Pull model, a solicited Push model, and an unsolicited
Push models. All of the methods of data access MUST support the Push model. All of the methods of data access MUST support the
ability for the initiator to filter the set of posture assessment ability for the initiator to filter the set of posture assessment
information to be delivered. Additionally, the provider of the information to be delivered. Additionally, the provider of the
information MUST be able to filter the set of posture assessment information MUST be able to filter the set of posture assessment
information based on the permissions of the recipient. This information based on the permissions of the recipient. This
requirement is driven by use cases 2.1.3, 2.1.4 and 2.1.5. 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 G-012 (SACM Component Interface): The interfaces by which SACM
components communicate to share endpoint posture information MUST be components communicate to share endpoint posture information MUST be
well defined. That is, the interface defines the data model, SACM well defined. That is, the interface defines the data model, SACM
transfer protocols, and network transfer protocols to enable SACM transfer protocols, and network transfer protocols to enable SACM
components to communicate. components to communicate.
G-013 Endpoint Location and Network Topology: The SACM architecture G-013 (Endpoint Location and Network Topology): The SACM
and interfaces MUST allow for the target endpoint (network) location architecture and interfaces MUST allow for the target endpoint
and network topology to be modeled and understood. Where (network) location and network topology to be modeled and
appropriate, the data model and the interfaces SHOULD allow for understood. Where appropriate, the data model and the interfaces
discovery of the target endpoint location or network topology or SHOULD allow for discovery of the target endpoint location, network
both. topology, or both.
G-014 Target Endpoint Identity: The SACM architecture and interfaces G-014 (Target Endpoint Identity): The SACM architecture and
MUST support the ability of components to provide attributes that interfaces MUST support the ability of components to provide
can be used to compose an identity for a target endpoint. These attributes that can be used to compose an identity for a target
identities MAY be composed of attributes from one or more SACM endpoint. These identities MAY be composed of attributes from one
components. or more SACM components.
G-015 Data Access Control: Methods of access control must be G-015 (Data Access Control): Methods of access control must be
supported to accommodate considerations such as geographic, supported to accommodate considerations such as geographic,
regulatory, operational and federations. Entities accessing or regulatory, operational, and federations. Entities accessing or
publishing data MUST identify themselves and pass access policy. publishing data MUST identify themselves and pass access policy.
2.2. Requirements for the Architecture 2.2. Requirements for the Architecture
Following are the requirements for the SACM architecture: Following are the requirements for the SACM architecture:
ARCH-001 Component functions: At the simplest abstraction, the SACM ARCH-001 (Component Functions): At the simplest abstraction, the
architecture MUST represent the core components and interfaces SACM architecture MUST represent the core components and interfaces
needed to perform the production and consumption of posture needed to perform the production and consumption of posture
assessment information. assessment information.
ARCH-002 Scalability: The architectural components MUST account for ARCH-002 (Scalability): The architectural components MUST account
a range of deployments, from very small sets of endpoints to very for a range of deployments, from very small sets of endpoints to
large deployments. very large deployments.
ARCH-003 Flexibility: The architectural components MUST account for ARCH-003 (Flexibility): The architectural components MUST account
different deployment scenarios where the architectural components for different deployment scenarios where the architectural
may be implemented, deployed, or used within a single application, components may be implemented, deployed, or used within a single
service, or network, or may comprise a federated system. application, service, or network, or may comprise a federated
system.
ARCH-004 Separation of Data and Management Functions: SACM MUST ARCH-004 (Separation of Data and Management Functions): SACM MUST
define both the configuration and management of the SACM data models define both the configuration and management of the SACM data models
and protocols used to transfer and share posture assessment and protocols used to transfer and share posture assessment
information. information.
ARCH-005 Topology Flexibility: Both centralized and decentralized ARCH-005 (Topology Flexibility): Both centralized and decentralized
(peer-to-peer) information exchange MUST be supported. Centralized (peer-to-peer) information exchange MUST be supported. Centralized
data exchange enables use of a common data format to bridge together data exchange enables use of a common data format to bridge together
data exchange between diverse systems, and can leverage a virtual data exchange between diverse systems and can leverage a virtual
data store that centralizes and offloads all data access, storage, data store that centralizes and offloads all data access, storage,
and maintenance to a dedicated resource. Decentralized data and maintenance to a dedicated resource. Decentralized data
exchange enables simplicity of sharing data between relatively exchange enables simplicity of sharing data between relatively
uniform systems, and between small numbers of systems, especially uniform systems and between small numbers of systems, especially
within a single enterprise domain. The fact that a centralized or within a single enterprise domain. The fact that a centralized or
decentralized deployment is used SHOULD be invisible to a consumer. decentralized deployment is used SHOULD be invisible to a consumer.
However, there may be cases where the producer chooses to include However, there may be cases where the producer chooses to include
that information due to consumer preference that information due to consumer preference.
ARCH-006 Capability Negotiation: Announcement and negotiation of ARCH-006 (Capability Negotiation): Announcement and negotiation of
functional capabilities (such as authentication protocols, functional capabilities (such as authentication protocols,
authorization schemes, data models, transfer protocols, etc.) MUST authorization schemes, data models, transfer protocols, etc.) MUST
be supported, enabling a SACM component to make inquiries about the be supported, enabling a SACM component to make inquiries about the
capabilities of other components in the SACM ecosystem. capabilities of other components in the SACM ecosystem.
ARCH-007 Role-based Authorization: The SACM architecture MUST be ARCH-007 (Role-Based Authorization): The SACM architecture MUST be
capable of effecting role-based authorization. Distinction of capable of effecting role-based authorization. Distinction of
endpoints capable of and authorized to provide or consume endpoints capable of and authorized to provide or consume
information is required to address appropriate access controls. information is required to address appropriate access controls.
ARCH-008 Context-based Authorization: The SACM architecture MUST be ARCH-008 (Context-Based Authorization): The SACM architecture MUST
capable of effecting context-based authorization. Different be capable of effecting context-based authorization. Different
policies (e.g. business, regulatory, etc.) might specify what data policies (e.g., business, regulatory, etc.) might specify what data
may be exposed to, or shared by, consumers based on one or more may be exposed to, or shared by, consumers based on one or more
attributes of the consumer. The policy might specify that consumers attributes of the consumer. The policy might specify that consumers
are required to share specific information either back to the system are required to share specific information either back to the system
or to administrators. or to administrators.
ARCH-009 Time Synchronization: Actions or decisions based on time- ARCH-009 (Time Synchronization): Actions or decisions based on time-
sensitive data (such as user logon/logoff, endpoint connection/ sensitive data (such as user logon/logoff, endpoint connection/
disconnection, endpoint behavior events, etc.) are all predicated on disconnection, endpoint behavior events, etc.) are all predicated on
a synchronized understanding of time. The SACM architecture MUST a synchronized understanding of time. The SACM architecture MUST
provide a mechanism for all components to synchronize time. A provide a mechanism for all components to synchronize time. A
mechanism for detecting and reporting time discrepancies SHOULD be mechanism for detecting and reporting time discrepancies SHOULD be
provided by the architecture and reflected in the information model. provided by the architecture and reflected in the information model.
2.3. Requirements for the Information Model 2.3. Requirements for the Information Model
The SACM information model represents the abstracted representation The SACM information model represents the abstracted representation
for Posture Assessment information to be communicated. SACM data for posture assessment information to be communicated. SACM data
models must adhere to and comply with the SACM information model. models must adhere to and comply with the SACM information model.
The requirements for the SACM information model include: The requirements for the SACM information model include:
IM-001 Extensible Attribute Vocabulary: The information model MUST IM-001 (Extensible Attribute Vocabulary): The information model MUST
define a minimum set of attributes for communicating Posture define a minimum set of attributes for communicating posture
Information, to ensure interoperability between data models. information, to ensure interoperability between data models.
(Individual data models may define attributes beyond the mandatory- (Individual data models may define attributes beyond the mandatory-
to-implement minimum set.) The attributes should be defined with a to-implement minimum set.) The attributes should be defined with a
clear mechanism for extensibility to enable data models to adhere to clear mechanism for extensibility to enable data models to adhere to
SACM's required attributes as well as allow for their own SACM's required attributes as well as allow for their own
extensions. The attribute vocabulary should be defined with a clear extensions. The attribute vocabulary should be defined with a clear
mechanism for extensibility to enable future versions of the mechanism for extensibility to enable future versions of the
information model to be interoperably expanded with new attributes. information model to be interoperably expanded with new attributes.
IM-002 Posture Data Publication: The information model MUST allow IM-002 (Posture Data Publication): The information model MUST allow
for the data to be provided by a SACM component either solicited or for the data to be provided by a SACM component either solicited or
unsolicited. No aspect of the information model should be dependent unsolicited. No aspect of the information model should be dependent
upon or assume a push or pull model of publication. upon or assume a Push or Pull model of publication.
IM-003 Data Model Negotiation: SACM's information model MUST allow IM-003 (Data Model Negotiation): SACM's information model MUST allow
support for different data models, data model versions, and support for different data models, data model versions, and
different versions of the operations on the data models and transfer different versions of the operations on the data models and transfer
protocols. The SACM information model MUST include the ability to protocols. The SACM information model MUST include the ability to
discover and negotiate the use of a particular data model or any discover and negotiate the use of a particular data model or any
data model. data model.
IM-004 Data Model Identification: The information model MUST provide IM-004 (Data Model Identification): The information model MUST
a means to uniquely identify each data model. The identifier MUST provide a means to uniquely identify each data model. The
contain both an identifier of the data model and a version indicator identifier MUST contain both an identifier of the data model and a
for the data model. The identifiers SHOULD be decomposable so that version indicator for the data model. The identifiers SHOULD be
a customer can query for any version of a specific data model and decomposable so that a customer can query for any version of a
compare returned values for older or newer than a desired version. 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 IM-005 (Data Lifetime Management): The information model MUST
a means to allow data models to include data lifetime management. provide a means to allow data models to include data lifetime
The information model must identify attributes that can allow data management. The information model must identify attributes that can
models to, at minimum, identify the data's origination time and allow data models to, at minimum, identify the data's origination
expected time of next update or data longevity (how long should the time and expected time of next update or data longevity (how long
data be assumed to still be valid). the data should be assumed to still be valid).
IM-006 Singularity and Modularity: The SACM information model MUST IM-006 (Singularity and Modularity): The SACM information model MUST
be singular (i.e. there is only one information model, not multiple be singular (i.e., there is only one information model, not multiple
alternative information models from which to choose) and MAY be alternative information models from which to choose) and MAY be
modular (a conjunction of several sub-components) for ease of modular (a conjunction of several subcomponents) for ease of
maintenance and extension. For example, endpoint identification maintenance and extension. For example, endpoint identification
could be an independent sub-component of the information model, to could be an independent subcomponent of the information model, to
simplify updating of endpoint identification attributes. simplify updating of endpoint identification attributes.
2.4. Requirements for the Data Model 2.4. Requirements for the Data Model
The SACM information model represents an abstraction for "what" The SACM information model represents an abstraction for "what"
information can be communicated and "how" it is to be represented and information can be communicated and "how" it is to be represented and
shared. It is expected that as applications may produce posture shared. It is expected that as applications may produce posture
assessment information, they may share it using a specific data assessment information, they may share it using a specific data
model. Similarly, applications consuming or requesting posture model. Similarly, applications consuming or requesting posture
assessment information, may require it be based on a specific data assessment information may require that it be based on a specific
model. Thus, while there may exist different data models and data model. Thus, while there may exist different data models and
schemas, they should adhere to the SACM information model and meet schemas, they should adhere to the SACM information model and meet
the requirements defined in this section. the requirements defined in this section.
The specific requirements for candidate data models include: The specific requirements for candidate data models include:
DM-001 Element Association: A SACM Information Model consists of a DM-001 (Element Association): A SACM information model consists of a
set of SACM Information Model elements. A SACM Data Model MUST be set of SACM information model elements. A SACM data model MUST be
derived from the SACM Information Model. A SACM Data Model consists derived from the SACM information model. A SACM data model consists
of a set of SACM Data Model elements. In this derivation, a SACM 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 data model element MAY map to one or more SACM information model
elements. In addition, a SACM Data Model MAY include additional elements. In addition, a SACM data model MAY include additional
Data Model elements that are not associated with any SACM data model elements that are not associated with any SACM
Information Model elements. information model elements.
DM-002 Data Model Structure: The data model can be structured either DM-002 (Data Model Structure): The data model can be structured
as one single module or separated into modules and sub-modules that either as one single module or separated into modules and submodules
allow for references between them. The data model structure MAY that allow for references between them. The data model structure
reflect structure in the information model, but does not need to. MAY reflect structure in the information model but does not need to.
For example, the data model might use one module to define For example, the data model might use one module to define
endpoints, and that module might reference other modules that endpoints, and that module might reference other modules that
describe the various assets associated with the endpoint. describe the various assets associated with the endpoint.
Constraints and interfaces might further be defined to resolve or Constraints and interfaces might further be defined to resolve or
tolerate ambiguity in the references (e.g. same IP address used in tolerate ambiguity in the references (e.g., the same IP address used
two separate networks). in two separate networks).
DM-003 Search Flexibility: The search interfaces and actions MUST DM-003 (Search Flexibility): The search interfaces and actions MUST
include the ability to start a search anywhere within a data model include the ability to start a search anywhere within a data model
structure, and the ability to search based on patterns ("wildcard structure and the ability to search based on patterns ("wildcard
searches") as well as specific data elements. searches") as well as specific data elements.
DM-004 Full vs. Partial Updates: The data model SHOULD include the 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, ability to allow providers of data to provide the data as a whole or
or when updates occur. For example, a consumer can request a full when updates occur. For example, a consumer can request a full
update on initial engagement, then request to receive deltas update on initial engagement, then request to receive deltas
(updates containing only the changes since the last update) on an (updates containing only the changes since the last update) on an
ongoing basis as new data is generated. ongoing basis as new data is generated.
DM-005 Loose Coupling: The data model SHOULD allow for a loose DM-005 (Loose Coupling): The data model SHOULD allow for a loose
coupling between the provider and the consumer, such that the coupling between the provider and the consumer, such that the
consumer can request information without being required to request consumer can request information without being required to request
it from a specific provider, and a provider can publish information it from a specific provider, and a provider can publish information
without having a specific consumer targeted to receive it. without having a specific consumer targeted to receive it.
DM-006 Data Cardinality: The data model MUST describe their DM-006 (Data Cardinality): The data model MUST describe their
constraints (e.g. cardinality). As posture information and the constraints (e.g., cardinality). As posture information and the
tasks for collection, aggregation, or evaluation, could comprise one tasks for collection, aggregation, or evaluation could comprise one
or more attributes, interfaces and actions MUST allow and account or more attributes, interfaces and actions MUST allow and account
for such cardinality as well as whether the attributes are for such cardinality and for conditional, optional, or mandatory
conditional, optional, or mandatory. attributes.
DM-007 Data Model Negotiation: The interfaces and actions in the DM-007 (Data Model Negotiation): The interfaces and actions in the
data model MUST include capability negotiation to enable discovery data model MUST include capability negotiation to enable discovery
of supported and available data types and schemas. of supported and available data types and schemas.
DM-008 Data Origin: The data model MUST include the ability for DM-008 (Data Origin): The data model MUST include the ability for
consumers to identify the data origin (provider that collected the consumers to identify the data origin (provider that collected the
data). data).
DM-009 Origination Time: The data model SHOULD allow the provider to DM-009 (Origination Time): The data model SHOULD allow the provider
include the information's origination time. to include the information's origination time.
DM-010 Data Generation: The data model MUST allow the provider to DM-010 (Data Generation): The data model MUST allow the provider to
include attributes defining how the data was generated (e.g. self- include attributes defining how the data was generated (e.g., self-
reported, reported by aggregator, scan result, etc.). reported, reported by aggregator, scan result, etc.).
DM-011 Data Source: The data model MUST allow the provider to DM-011 (Data Source): The data model MUST allow the provider to
include attributes identifying the data source (target endpoint from include attributes identifying the data source (target endpoint from
which the data was collected) - e.g. hostname, domain (DNS) name or which the data was collected), e.g., hostname, domain (DNS) name, or
application name. application name.
DM-012 Data Updates: The data model SHOULD allow the provider to DM-012 (Data Updates): The data model SHOULD allow the provider to
include attributes defining whether the information provided is a include attributes defining whether the information provided is a
delta, partial, or full set of information. delta, partial, or full set of information.
DM-013 Multiple Collectors: The data model MUST support the DM-013 (Multiple Collectors): The data model MUST support the
collection of attributes by a variety of collectors, including collection of attributes by a variety of collectors, including
internal collectors, external collectors with an authenticated internal collectors, external collectors with an authenticated
relationship with the endpoint, and external collectors based on relationship with the endpoint, and external collectors based on
network and other observers. network and other observers.
DM-014 Attribute Extensibility: Use Cases in the whole of Section 2 DM-014 (Attribute Extensibility): All of the use cases in Section 2
describe the need for an attribute dictionary. With SACM's scope of [RFC7632] describe the need for an attribute dictionary. With
focused on posture assessment, the data model attribute collection SACM's scope focused on posture assessment, the data model attribute
and aggregation MUST have a well-understood set of attributes collection and aggregation MUST have a well-understood set of
inclusive of their meaning or usage intent. The data model MUST attributes inclusive of their meaning or usage intent. The data
include all attributes defined in the information model and MAY model MUST include all attributes defined in the information model
include additional attributes beyond those found in the information and MAY include additional attributes beyond those found in the
model. Additional attributes MUST be defined in accordance with the information model. Additional attributes MUST be defined in
extensibility framework provided in the information model (see IM- accordance with the extensibility framework provided in the
001). information model (see IM-001).
DM-015 Solicited vs. Unsolicited Updates: The data model MUST enable DM-015 (Solicited vs. Unsolicited Updates): The data model MUST
a provider to publish data either solicited (in response to a enable a provider to publish data either solicited (in response to a
request from a consumer) or unsolicited (as new data is generated, request from a consumer) or unsolicited (as new data is generated,
without a request required). For example, an external collector can without a request required). For example, an external collector can
publish data in response to a request by a consumer for information publish data in response to a request by a consumer for information
about an endpoint, or can publish data as it observes new about an endpoint, or it can publish data as it observes new
information about an endpoint, without any specific consumer request information about an endpoint, without any specific consumer request
triggering the publication; a compliance-server provider may publish triggering the publication; a compliance-server provider may publish
endpoint posture information in response to a request from a endpoint posture information in response to a request from a
consumer (solicited), or it may publish posture information driven consumer (solicited), or it may publish posture information driven
by a change in the posture of the endpoint (unsolicited). by a change in the posture of the endpoint (unsolicited).
DM-016 tTransfer Agnostic: The data model MUST be transfer agnostic, DM-016 (Transfer Agnostic): The data model MUST be transfer
to allow for the data operations to leverage the most appropriate agnostic, to allow for the data operations to leverage the most
SACM transfer protocol. appropriate SACM transfer protocol.
2.5. Requirements for Data Model Operations 2.5. Requirements for Data Model Operations
Posture information data adhering to a data model must also provide Posture information data adhering to a data model must also provide
interfaces that include operations for access and production of the interfaces that include operations for access and production of the
data. Operations requirements are distinct from transfer data. Operations requirements are distinct from transfer
requirements in that operations requirements are requirements on the requirements in that operations requirements are requirements on the
application performing requests and responses, whereas transfer application performing requests and responses, whereas transfer
requirements are requirements on the transfer protocol carrying the requirements are requirements on the transfer protocol carrying the
requests / responses. The specific requirements for such operations requests and responses. The specific requirements for such
include: operations include:
OP-001 Time Synchronization: Request and response operations MUST be OP-001 (Time Synchronization): Request and response operations MUST
timestamped, and published information SHOULD capture time of be timestamped, and published information SHOULD capture time of
publication. Actions or decisions based on time-sensitive data publication. Actions or decisions based on time-sensitive data
(such as user logon/logoff, endpoint connection/disconnection, (such as user logon/logoff, endpoint connection/disconnection,
endpoint behavior events, etc.) are all predicated on a synchronized endpoint behavior events, etc.) are all predicated on a synchronized
understanding of time. A method for detecting and reporting time understanding of time. A method for detecting and reporting time
discrepancies SHOULD be provided. discrepancies SHOULD be provided.
OP-002 Collection Abstraction: Collection is the act of a SACM OP-002 (Collection Abstraction): Collection is the act of a SACM
component gathering data from a target endpoint. The request for a component gathering data from a target endpoint. The request for a
data item MUST include enough information to properly identify the data item MUST include enough information to properly identify the
item to collect, but the request shall not be a command to directly item to collect, but the request shall not be a command to directly
execute nor directly be applied as arguments to a command. The execute nor be directly applied as arguments to a command. The
purpose of this requirement is primarily to reduce the potential purpose of this requirement is primarily to reduce the potential
attack vectors, but has the additional benefit of abstracting the attack vectors but has the additional benefit of abstracting the
request for collection from the collection method, thereby allowing request for collection from the collection method, thereby allowing
more flexibility in how collection is implemented. more flexibility in how collection is implemented.
OP-003 Collection Composition: A collection request MAY be composed OP-003 (Collection Composition): A collection request MAY be
of multiple collection requests (which yield collected values). The composed of multiple collection requests (which yield collected
desire for multiple values MUST be expressed as part of the values). The desire for multiple values MUST be expressed as part
collection request, so that the aggregation can be resolved at the of the collection request, so that the aggregation can be resolved
point of collection without having to interact with the requestor. at the point of collection without having to interact with the
This requirement should not be interpreted as preventing a collector requestor. This requirement should not be interpreted as preventing
from providing attributes which were not part of the original a collector from providing attributes that were not part of the
request. original request.
OP-004 Attribute-based Query: A query operation is the act of OP-004 (Attribute-Based Query): A query operation is the act of
requesting data from a provider. Query operations SHOULD be based requesting data from a provider. Query operations SHOULD be based
on a set of attributes. Query operations MUST support both a query on a set of attributes. Query operations MUST support both a query
for specific attributes and a query for all attributes. Use Case for specific attributes and a query for all attributes. The use
2.1.2 describes the need for the data model to support a query case in Section 2.1.2 of [RFC7632] describes the need for the data
operation based on a set of attributes to facilitate collection of model to support a query operation based on a set of attributes to
information such as posture assessment, inventory (of endpoints or facilitate collection of information such as posture assessment,
endpoint components), and configuration checklist. inventory (of endpoints or endpoint components), and configuration
checklist.
OP-005 Information-based Query with Filtering: The query operation OP-005 (Information-Based Query with Filtering): The query operation
MUST support filtering. Use Case 2.1.3 describes the need for the MUST support filtering. The use case in Section 2.1.3 of [RFC7632]
data model to support the means for the information to be collected describes the need for the data model to support the means for the
through a query mechanism. Furthermore, the query operation information to be collected through a query mechanism. Furthermore,
requires filtering capabilities to allow for only a subset of the query operation requires filtering capabilities to allow for
information to be retrieved. The query operation MAY be a only a subset of information to be retrieved. The query operation
synchronous request or asynchronous request. MAY be a synchronous request or asynchronous request.
OP-006 Operation Scalability: The operation resulting from a query OP-006 (Operation Scalability): The operation resulting from a query
operation MUST be able to handle the return and receipt of large operation MUST be able to handle the return and receipt of large
amounts of data. Use Cases 2.1.4 and 2.1.5 describe the need for amounts of data. The use case in Section 2.1.4 of [RFC7632]
the data model to support scalability. For example, the query describe the need for the data model to support scalability. For
operation may result in a very large set of attributes, as well as a example, the query operation may result in a very large set of
large set of targets. attributes as well as a large set of targets.
OP-007 Data Abstraction: The data model MUST allow a SACM component OP-007 (Data Abstraction): The data model MUST allow a SACM
to communicate what data was used to construct the target endpoint's component to communicate what data was used to construct the target
identity, so other SACM components can determine whether they are endpoint's identity, so that other SACM components can determine
constructing an equivalent target endpoint (and its identity) and whether they are constructing an equivalent target endpoint (and its
whether they have confidence in that identity. SACM components identity) and whether they have confidence in that identity. SACM
SHOULD have interfaces defined to transmit this data directly or to components SHOULD have interfaces defined to transmit this data
refer to where the information can be retrieved. directly or to refer to where the information can be retrieved.
OP-008 Provider Restriction: Request operations MUST include the OP-008 (Provider Restriction): Request operations MUST include the
ability to restrict the data to be provided by a specific provider ability to restrict the data to be provided by a specific provider
or a provider with specific characteristics. Response operations or a provider with specific characteristics. Response operations
MUST include the ability to identify the provider that supplied the MUST include the ability to identify the provider that supplied the
response. For example, a SACM Consumer should be able to request 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. that all of the data come from a specific provider by identity
Provider A) or from a Provider that is in a specific location (e.g. (e.g., Provider A) or from a provider that is in a specific location
in the Boston office). (e.g., in the Boston office).
2.6. Requirements for SACM Transfer Protocols 2.6. Requirements for SACM Transfer Protocols
The term SACM transfer protocol is intended to be distinguished from The term "SACM transfer protocol" is intended to be distinguished
underlying transport and internet layer protocols such as TCP/IP or from underlying transport- and internet-layer protocols such as TCP/
operating at an equivalent level as the HTTP. The SACM transfer IP or operating at an application-layer protocol such as HTTP. The
protocol is focused on moving data and performing necessary access SACM transfer protocol is focused on moving data and performing
control operations; it is agnostic to the data model operations. necessary access control operations; it is agnostic to the data model
operations.
The requirements for SACM transfer protocols include: The requirements for SACM transfer protocols include:
T-001 Multiple transfer Protocol Support: SACM transfer protocols T-001 (Multiple Transfer Protocol Support): SACM transfer protocols
will vary depending on the deployment model that relies on different will vary depending on the deployment model that relies on different
transfer layer requirements, different device capabilities, and transfer-layer requirements, different device capabilities, and
system configurations dealing with connectivity. For example, where system configurations dealing with connectivity. For example, where
posture attributes may be collected directly from an endpoint using posture attributes may be collected directly from an endpoint using
NEA's model [RFC5209], different transports may be defined to the Network Endpoint Assessment (NEA) model [RFC5209], different
collect them using PT-EAP [RFC7171] or PT-TLS [RFC6876] depending on transports may be defined to collect them using Posture Transport
the deployment scenario. 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 T-002 (Data Integrity): SACM transfer protocols MUST be able to
data integrity for data in transit. ensure data integrity for data in transit.
T-003 Data Confidentiality: SACM transfer protocols MUST be able to T-003 (Data Confidentiality): SACM transfer protocols MUST be able
support data confidentiality. SACM transfer protocols MUST ensure to support data confidentiality. SACM transfer protocols MUST
data protection for data in transit (e.g. by encryption) to provide ensure data protection for data in transit (e.g., by encryption) to
confidentiality, integrity, and robustness against protocol-based provide confidentiality, integrity, and robustness against protocol-
attacks. Note that while the transfer MUST be able to support data based attacks. Note that while the transfer MUST be able to support
confidentiality, implementations MAY provide a configuration option data confidentiality, implementations MAY provide a configuration
that enables and disables confidentiality in deployments. option that enables and disables confidentiality in deployments.
Protection for data at rest is not in scope for transfer protocols. Protection for data at rest is not in scope for transfer protocols.
Data protection MAY be used for both privacy and non-privacy Data protection MAY be used for both privacy and non-privacy
scenarios. scenarios.
T-004 Transfer Protection: SACM transfer protocols MUST be capable T-004 (Transfer Protection): SACM transfer protocols MUST be capable
of supporting mutual authentication and replay protection. of supporting mutual authentication and replay protection.
T-005 Transfer Reliability: SACM transfer protocols MUST provide T-005 (Transfer Reliability): SACM transfer protocols MUST provide
reliable delivery of data. This includes the ability to perform reliable delivery of data. This includes the ability to perform
fragmentation and reassembly, and to detect replays. The SACM fragmentation and reassembly and to detect replays. The SACM
transfer may take advantage of reliability features in the network transfer may take advantage of reliability features in the network
transport; however, the network transport may be unreliable (e.g. transport; however, the network transport may be unreliable (e.g.,
UDP), in which case the SACM transfer running over the unreliable UDP), in which case the SACM transfer running over the unreliable
network transport is responsible for ensuring reliability (i.e. by network transport is responsible for ensuring reliability (i.e., by
provisions such as confirmations and re-transmits). provisions such as confirmations and retransmits).
T-006 Transfer Layer Requirements: Each SACM transfer protocol MUST T-006 (Transfer-Layer Requirements): Each SACM transfer protocol
clearly specify the transport layer requirements it needs to operate MUST clearly specify the transport-layer requirements it needs to
correctly. Examples of items that may need to be specified include operate correctly. Examples of items that may need to be specified
connectivity requirements, replay requirements, data link encryption include connectivity requirements, replay requirements, data link
requirements, and/or channel binding requirements. These encryption requirements, and/or channel-binding requirements. These
requirements are needed in order for deployments to be done requirements are needed in order for deployments to be done
correctly. correctly.
T-007 Transfer Protocol adoption: SACM SHOULD where reasonably T-007 (Transfer Protocol Adoption): SACM SHOULD, where reasonably
possible, leverage and use existing IETF transfer protocols versus possible, leverage and use existing IETF transfer protocols versus
defining new ones. defining new ones.
3. Acknowledgments 3. IANA Considerations
The authors would like to thank Barbara Fraser, Jim Bieda, and Adam
Montville for reviewing and contributing to this draft. In addition,
we recognize valuable comments and suggestions made by Jim Schaad and
Chris Inacio.
4. IANA Considerations
This memo includes no request to IANA. This document does not require any IANA actions.
5. Security Considerations 4. Security Considerations
This document defines the requirements for SACM. As such, it is This document defines the requirements for SACM. As such, it is
expected that several data models, protocols, and transfer protocols expected that several data models, protocols, and transfer protocols
may be defined or reused from already existing standards. may be defined or reused from already-existing standards.
To address security and privacy considerations, the data model, To address security and privacy considerations, the data model,
protocols, and transports must consider authorization based on protocols, and transports must consider authorization based on
consumer function and privileges, to only allow authorized consumers consumer function and privileges, to only allow authorized consumers
and providers to access specific information being requested or and providers to access specific information being requested or
published. published.
To enable federation across multiple entities (such as across To enable federation across multiple entities (such as across
organizational or geographic boundaries) authorization must also organizational or geographic boundaries), authorization must also
extend to infrastructure elements themselves, such as central extend to infrastructure elements themselves, such as central
controllers / brokers / data repositories. controllers, brokers, and data repositories.
In addition, authorization needs to extend to specific information or In addition, authorization needs to extend to specific information or
resources available in the environment. In other words, resources available in the environment. In other words,
authorization is based on the subject (the information requestor), authorization is based on the subject (the information requestor),
the provider (the information responder), the object (the endpoint the provider (the information responder), the object (the endpoint
the information is being requested on), and the attribute (what piece the information is being requested on), and the attribute (what piece
of data is being requested). The method by which this authorization of data is being requested). The method by which this authorization
is applied is unspecified. is applied is unspecified.
SACM's charter focuses on the workflow orchestration and the sharing SACM's charter focuses on the workflow orchestration and the sharing
of posture information for improving efficacy of security of posture information for improving the efficacy of security
applications such as compliance, configuration, assurance and other applications such as compliance, configuration, assurance, and other
threat and vulnerability reporting and remediation systems. While threat and vulnerability reporting and remediation systems. While
the goal is to facilitate the flow of information securely, it is the goal is to facilitate the flow of information securely, it is
important to note that participating endpoints may not be cooperative important to note that participating endpoints may not be cooperative
or trustworthy. or trustworthy.
5.1. Trust between Provider and Requestor 4.1. Trust between Provider and Requestor
The information given from the provider to a requestor may come with The information given from the provider to a requestor may come with
different levels of trustworthiness given the different potential different levels of trustworthiness given the different potential
deployment scenarios and compromise either at the provider, the deployment scenarios and compromise at the provider, the requesting
requesting consumer, or devices that are involved in the transfer consumer, or devices that are involved in the transfer between the
between the provider and requestor. This section will describe the provider and requestor. This section will describe the different
different considerations that may reduce the level of trustworthiness considerations that may reduce the level of trustworthiness of the
of the information provided. information provided.
In the information transfer flow, it is possible that some of the 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 devices may serve as proxies or brokers and, as such, may be able to
observe the communications flowing between an information provider observe the communications flowing between an information provider
and requestor. Without appropriate protections, it is possible for and requestor. Without appropriate protections, it is possible for
these proxies and brokers to inject and affect man-in-the-middle these proxies and brokers to inject and affect man-in-the-middle
attacks. attacks.
It is common to, in general, distrust the network service provider, In general, it is common to distrust the network service provider,
unless the full hop by hop communications process flow is well unless the full hop-by-hop communications process flow is well
understood. As such, the posture information provider should protect understood. As such, the posture information provider should protect
the posture information data it provides as well as the transfer it the posture information data it provides as well as the transfer it
uses. Similarly, while there may be providers whose goal is to uses. Similarly, while there may be providers whose goal is to
openly share its information, there may also be providers whose openly share its information, there may also be providers whose
policy is to grant access to certain posture information based on its policy is to grant access to certain posture information based on its
business or regulatory policy. In those situations, a provider may business or regulatory policy. In those situations, a provider may
require full authentication and authorization of the requestor (or require full authentication and authorization of the requestor (or
set of requestors) and share only the authorized information to the set of requestors) and share only the authorized information to the
authenticated and authorized requestors. authenticated and authorized requestors.
A requestor beyond distrusting the network service provider, must Beyond distrusting the network service provider, a requestor must
also account that the information received from the provider may have also take into account that the information received from the
been communicated through an undetermined network communications provider may have been communicated through an undetermined network
system. That is, the posture information may have traversed through communications system. That is, the posture information may have
many devices before reaching the requestor. SACM specifications traversed through many devices before reaching the requestor. SACM
should provide the means for verifying data origin and data integrity specifications should provide the means for verifying data origin and
and at minimum, provide endpoint authentication and transfer data integrity and, at minimum, provide endpoint authentication and
integrity. transfer integrity.
A requestor may require data freshness indications, both knowledge of A requestor may require data freshness indications, both knowledge of
data origination as well as time of publication so that it can make 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 more informed decisions about the relevance of the data based on its
currency and/or age. currency and/or age.
It is also important to note that endpoint assessment reports, It is also important to note that endpoint assessment reports,
especially as they may be provided by the target endpoint may pose especially as they may be provided by the target endpoint, may pose
untrustworthy information. The considerations for this are described untrustworthy information. The considerations for this are described
in Section 8 of [RFC5209]. in Section 8 of [RFC5209].
The trustworthiness of the posture information given by the provider The trustworthiness of the posture information given by the provider
to one or many requestors is dependent on several considerations. to one or many requestors is dependent on several considerations.
Some of these include the requestor requiring: Some of these include the requestor requiring:
o Full disclosure of the network topology path to the provider(s). o Full disclosure of the network topology path to the provider(s).
o Direct (peer to peer) communication with the provider. o Direct (peer-to-peer) communication with the provider.
o Authentication and authorization of the provider. o Authentication and authorization of the provider.
o Either or both confidentiality and integrity at the transfer o Either or both confidentiality and integrity at the transfer
layer. layer.
o Either or both confidentiality and integrity at the data layer. o Either or both confidentiality and integrity at the data layer.
5.2. Privacy Considerations 4.2. Privacy Considerations
SACM information may contain sensitive information about the target SACM information may contain sensitive information about the target
endpoint as well as revealing identity information of the producer or endpoint as well as revealing identity information of the producer or
consumer of such information. Similarly, as part of the SACM consumer of such information. Similarly, as part of the SACM
discovery mechanism, the advertised capabilities (and roles, e.g. discovery mechanism, the capabilities and roles (e.g., SACM
SACM components enabled) by the endpoint may be construed as private components enabled) advertised by the endpoint may be construed as
information. private information.
In addition to identity and SACM capabilities information disclosure, In addition to identity and SACM capabilities information disclosure,
the use of time stamps (or other attributes that can be used as the use of timestamps (or other attributes that can be used as
identifiers) could be further used to determine a target endpoint or identifiers) could be further used to determine a target endpoint or
user's behavioral patterns. Such attributes may also be deemed user's behavioral patterns. Such attributes may also be deemed
sensitive and may required further protection or obfuscation to meet sensitive and may require further protection or obfuscation to meet
privacy concerns. That is, there may be applications as well as privacy concerns. That is, there may be applications as well as
business and regulatory practices that require that aspects of such business and regulatory practices that require that aspects of such
information be hidden from any parties that do not need to know it. information be hidden from any parties that do not need to know it.
Data confidentiality can provide some level of privacy but may fall Data confidentiality can provide some level of privacy but may fall
short where unnecessary data is still transmitted. In those cases, short where unnecessary data is still transmitted. In those cases,
filtering requirements at the data model such as OP-005 must be filtering requirements at the data model such as OP-005 must be
applied to ensure that such data is not disclosed. [RFC6973] applied to ensure that such data is not disclosed. [RFC6973]
provides guidelines for which SACM protocols and information and data provides guidelines that SACM protocols, information models, and data
models should follow. models should follow.
6. References 5. References
6.1. Normative References 5.1. Normative References
[RFC7632] Waltermire, D. and D. Harrington, "Endpoint Security [RFC7632] Waltermire, D. and D. Harrington, "Endpoint Security
Posture Assessment: Enterprise Use Cases", RFC 7632, Posture Assessment: Enterprise Use Cases", RFC 7632,
DOI 10.17487/RFC7632, September 2015, DOI 10.17487/RFC7632, September 2015,
<http://www.rfc-editor.org/info/rfc7632>. <https://www.rfc-editor.org/info/rfc7632>.
6.2. Informative References
[I-D.ietf-sacm-terminology] 5.2. Informative References
Birkholz, H., Lu, J., Strassner, J., and N. Cam-Winget,
"Security Automation and Continuous Monitoring (SACM)
Terminology", draft-ietf-sacm-terminology-13 (work in
progress), July 2017.
[RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J.
Tardo, "Network Endpoint Assessment (NEA): Overview and Tardo, "Network Endpoint Assessment (NEA): Overview and
Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008, Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008,
<http://www.rfc-editor.org/info/rfc5209>. <https://www.rfc-editor.org/info/rfc5209>.
[RFC6876] Sangster, P., Cam-Winget, N., and J. Salowey, "A Posture [RFC6876] Sangster, P., Cam-Winget, N., and J. Salowey, "A Posture
Transport Protocol over TLS (PT-TLS)", RFC 6876, Transport Protocol over TLS (PT-TLS)", RFC 6876,
DOI 10.17487/RFC6876, February 2013, DOI 10.17487/RFC6876, February 2013,
<http://www.rfc-editor.org/info/rfc6876>. <https://www.rfc-editor.org/info/rfc6876>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973, Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013, DOI 10.17487/RFC6973, July 2013,
<http://www.rfc-editor.org/info/rfc6973>. <https://www.rfc-editor.org/info/rfc6973>.
[RFC7171] Cam-Winget, N. and P. Sangster, "PT-EAP: Posture Transport [RFC7171] Cam-Winget, N. and P. Sangster, "PT-EAP: Posture Transport
(PT) Protocol for Extensible Authentication Protocol (EAP) (PT) Protocol for Extensible Authentication Protocol (EAP)
Tunnel Methods", RFC 7171, DOI 10.17487/RFC7171, May 2014, Tunnel Methods", RFC 7171, DOI 10.17487/RFC7171, May 2014,
<http://www.rfc-editor.org/info/rfc7171>. <https://www.rfc-editor.org/info/rfc7171>.
[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.
Acknowledgments
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.
Authors' Addresses Authors' Addresses
Nancy Cam-Winget Nancy Cam-Winget
Cisco Systems Cisco Systems
3550 Cisco Way 3550 Cisco Way
San Jose, CA 95134 San Jose, CA 95134
US United States of America
Email: ncamwing@cisco.com Email: ncamwing@cisco.com
Lisa Lorenzin Lisa Lorenzin
Pulse Secure Pulse Secure
2700 Zanker Rd., Suite 200 2700 Zanker Rd., Suite 200
San Jose, CA 95134 San Jose, CA 95134
US United States of America
Email: llorenzin@pulsesecure.net Email: llorenzin-ietf@1000plus.com
 End of changes. 143 change blocks. 
340 lines changed or deleted 345 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/