draft-ietf-sacm-requirements-06.txt   draft-ietf-sacm-requirements-07.txt 
SACM N. Cam-Winget SACM N. Cam-Winget
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Informational L. Lorenzin Intended status: Informational L. Lorenzin
Expires: November 21, 2015 Pulse Secure Expires: January 8, 2016 Pulse Secure
May 20, 2015 July 7, 2015
Secure Automation and Continuous Monitoring (SACM) Requirements Secure Automation and Continuous Monitoring (SACM) Requirements
draft-ietf-sacm-requirements-06 draft-ietf-sacm-requirements-07
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 Secure Automation and Continuous Monitoring (SACM) architecture, data
model and protocols. The requirements and scope are based on the model and transport protocols. The requirements and scope are based
agreed upon use cases. on the agreed upon use cases.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 21, 2015. This Internet-Draft will expire on January 8, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 (http://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
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements for SACM . . . . . . . . . . . . . . . . . . 3 2.1. Requirements for SACM . . . . . . . . . . . . . . . . . . 4
2.2. Requirements for the Architecture . . . . . . . . . . . . 6 2.2. Requirements for the Architecture . . . . . . . . . . . . 7
2.3. Requirements for the Information Model . . . . . . . . . 7 2.3. Requirements for the Information Model . . . . . . . . . 8
2.4. Requirements for the Data Model . . . . . . . . . . . . . 8 2.4. Requirements for the Data Model . . . . . . . . . . . . . 9
2.5. Requirements for Data Model Operations . . . . . . . . . 11 2.5. Requirements for Data Model Operations . . . . . . . . . 12
2.6. Requirements for Transport Protocols . . . . . . . . . . 12 2.6. Requirements for Transport Protocols . . . . . . . . . . 13
3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
5.1. Trust between Provider and Requestor . . . . . . . . . . 14 5.1. Trust between Provider and Requestor . . . . . . . . . . 15
6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 15 6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.1. -05 to -06 . . . . . . . . . . . . . . . . . . . . . . . 15 6.1. -05 to -06 . . . . . . . . . . . . . . . . . . . . . . . 17
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.1. Normative References . . . . . . . . . . . . . . . . . . 15 7.1. Normative References . . . . . . . . . . . . . . . . . . 17
7.2. Informative References . . . . . . . . . . . . . . . . . 16 7.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
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 such information while protecting the need to automate the sharing of such information while protecting
user information as well as the systems that store, process, and user information as well as the systems that store, process, and
transmit this information. Security threats can be detected in a transmit this information. Security threats can be detected in a
number of ways. SACM's charter focuses on how to collect and share number of ways. SACM's charter focuses on how to collect and share
this information based on use cases that involve posture assessment this information based on use cases that involve posture assessment
of endpoints. of endpoints.
skipping to change at page 3, line 15 skipping to change at page 3, line 15
2. Requirements 2. Requirements
This document defines requirements based on the SACM use cases This document defines requirements based on the SACM use cases
defined in [I-D.ietf-sacm-use-cases]. This section describes the defined in [I-D.ietf-sacm-use-cases]. This section describes the
requirements used by SACM to assess and compare candidate data requirements used by SACM to assess and compare candidate data
models, interfaces, and protocols, to suit the SACM architecture. models, interfaces, and protocols, to suit the SACM architecture.
These requirements express characteristics or features that a These requirements express characteristics or features that a
candidate protocol or data model must be capable of offering to candidate protocol or data model must be capable of offering to
ensure security and interoperability. ensure security and interoperability.
Multiple data models, protocols, and transports may be employed in a
SACM environment. A SACM transport protocol is one that runs on top
of L3 protocols such as TCP/IP or L4 protocols such as HTTP, carries
operations (requests / responses), and moves data.
SACM defines an architecture and information model focused on SACM defines 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. With the information model defining assets and information via Posture Information Providers and Posture Information
attributes to facilitate the guidance, collection and assessment of Consumers mediated by a Controller. With the information model
posture, the following tasks should be considered: defining assets and attributes to facilitate the guidance,
collection, and assessment of posture, the following tasks should be
considered:
1. Map the assets to an endpoint class. This requires populating 1. Asset Definition: Define the attributes desired to be collected
the attributes needed to exchange information pertaining to the from an asset. This is what we want to know about an asset. For
assets composing an endpoint. instance, organizations will want to know what software is
installed and its many critical security attributes such as patch
level.
2. Policy Definition: This is where an organization can express its 2. Asset Classification: Map the asset to an endpoint class. This
requires populating the attributes needed to exchange information
pertaining to the assets composing an endpoint.
3. Policy Definition: This is where an organization can express its
policy for acceptable or problematic values of an asset policy for acceptable or problematic values of an asset
attribute. The expected values of an asset attribute are attribute. The expected values of an asset attribute are
determined for later comparison against the actual asset determined for later comparison against the actual asset
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 those values which are good as well as those
values which represent problems, such as vulnerabilities. The values which represent problems, such as vulnerabilities. The
organization can also specify the asset attributes that are to be organization can also specify the asset attributes that are to be
present for a given asset. present for a given asset.
3. Evaluation task: Evaluate the actual values of the asset data 4. Information Collection: Collect information (attribute values)
against those expressed in the policy. from the endpoint to populate the asset data.
4. Report results: Report the results of the evaluation for use by 5. Endpoint Assessment: Evaluate the actual values of the asset data
against those expressed in the policy. (An evaluation result may
become additional asset data).
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 use of a report would be
additional evaluation, network enforcement, vulnerability additional evaluation, network enforcement, vulnerability
detection and license management. detection, and license management.
5. Access Control Policy: Classes of entities and access control 7. Access Control Policy: Classes of entities and access control
policies are assigned to generic attributes as well as attributes policies are assigned to generic attributes as well as attributes
for specific endpoints. for specific endpoints.
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 [I-D.ietf-sacm-use-cases]. To ensure tasks and use cases defined in [I-D.ietf-sacm-use-cases]. 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 data models, protocols, and G-001 Solution Extensibility: The information model, data models,
transports defined by SACM MUST be designed to allow support for protocols, and transports defined by SACM MUST be designed to allow
future extensions. support for future extensions, including both standard and
proprietary transport protocols and data models.
1. The information model and interfaces MUST support the ability to 1. The information model and interfaces MUST support the ability to
add new operations while maintaining backwards compatibility. add new operations while maintaining backwards compatibility.
SACM-defined transport protocols MUST have extensibility to
allow them to transport 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 to follow; the retrieval of specific information attributes to follow; the retrieval of specific information
based on an event, or on a continuous basis and the ability to based on an event, or on a continuous basis; and the ability to
retrieve specific pieces of information, specific types or retrieve specific pieces of information, specific types or
classes of information, or the entirety of available classes of information, or the entirety of available
information. information.
3. The information model MUST accommodate the addition of new data 3. The information model MUST accommodate the interoperable
types and/or schemas. addition of new data types and/or schemas.
G-002 Interoperability: The data models, protocols, and transports 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: The data models, protocols, and transports MUST G-003 Scalability: SACM needs to support a broad set of deployment
be scalable. SACM needs to support a broad set of deployment scenarios. The data models, protocols, and transports MUST be
scenarios. Scalability must be addressed to support: scalable unless they are specifically defined to apply to a special-
purpose scenario, such as constrained devices. A SACM transport
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 datagrams: It is possible that the size of posture * Large datagrams: It is possible that the size of posture
assessment information can vary from a single assessment that is assessment information can vary from a single assessment that is
small in size to a very large datagram or a very large set of small in size to a very large datagram or a very large set of
assessments. assessments (up to multiple gigabytes in size).
* 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 Agility: The data model, protocols, and transports MUST be G-004 Agility: The data model, protocols, and transports MUST be
suitably specified to enable implementations to fit into different suitably specified to enable implementations to fit into different
deployment models and scenarios, including considerations for deployment models and scenarios, including considerations for
implementations of data models and transports operating in implementations of data models and transports operating in
constrained environments. constrained environments.
G-005 Information Extensibility: Non-standard (implementation- G-005 Information Extensibility: Non-standard (implementation-
specific) data attributes MUST be supported. A method SHOULD be specific) attributes MUST be supported. A method SHOULD be defined
defined for preventing collisions from occurring in the naming of for preventing collisions from occurring in the naming of all
all data attributes independent of their source. For attributes independent of their source. For interoperability and
interoperability and scope boundary, the information model MUST scope boundary, the information model MUST define the mandatory set
define the mandatory set of data attributes. The set of attributes of attributes. The set of attributes defined by the information
defined by the information model MUST be well defined. model MUST be well defined.
G-006 Data Integrity: A method for ensuring data integrity MUST be G-006 Data Integrity: A method for ensuring data integrity MUST be
provided. This method is required to be available (i.e. all data- provided. This method is required to be available (i.e. all data-
handling components must support it), but is not required to be used handling components must support it), but is not required to be used
in all cases. 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 and federation (where the data may be collected in multiple locations
either centralized or kept in the local region. Where replication and either centralized or kept in the local region). Where
of data is supported, it is required that methods exist to prevent replication of data is supported, it is required that methods exist
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
transport protocols, data models, specific attributes within data transport protocols, data models, specific attributes within data
models, standard attribute expression sets, etc.) MUST be models, standard attribute expression sets, etc.) MUST be
supported. Negotiation for both versioning and capability is needed supported. Negotiation for both versioning and capability is needed
to accommodate future growth and ecosystems with mixed capabilities. to accommodate future growth and ecosystems with mixed capabilities.
G-009 Discovery: There MUST be a mechanism for components to G-009 Information Discovery: There MUST be mechanisms for components
discover what information is available across the ecosystem (i.e. a to discover what information is available across the ecosystem (i.e.
method for cataloging data available in the ecosystem and a method for cataloging data available in the ecosystem and
advertising it to consumers), and where to go to get a specific advertising it to consumers), where to go to get a specific piece of
piece of that information. For example, providing a method by which that information (i.e. which provider has the information), and what
a node can locate the advertised information so that consumers are schemas are in use for organizing the information. For example,
not required to have a priori knowledge to find available providing a method by which a node can locate the advertised
information. information so that consumers are not required to have a priori
knowledge to find available information.
G-010 Endpoint Discovery: SACM MUST define the means by which G-010 Target Endpoint Discovery: SACM MUST define the means by which
endpoints may be discovered. Use Case 2.1.2 describes the need to target endpoints may be discovered. Use Case 2.1.2 describes the
discover endpoints and their composition. 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: the standard Pull model as well as solicited and supported: the standard Pull model as well as solicited and
unsolicited Push models. All of the methods of data access MUST unsolicited Push models. All of the methods of data access MUST
support the ability for the initiator to filter the set of posture support the ability for the initiator to filter the set of posture
assessment information to be delivered. Additionally, the provider assessment information to be delivered. Additionally, the provider
of the information MUST be able to filter the set of posture of the information MUST be able to filter the set of posture
assessment information based on the permissions of the recipient. assessment 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. This requirement is driven by use cases 2.1.3, 2.1.4 and 2.1.5.
G-012 Device Interface: the interfaces by which SACM components G-012 Device Interface: The interfaces by which SACM components
communicate to share endpoint posture information MUST be well communicate to share endpoint posture information MUST be well
defined. That is, the interface defines the data model protocols defined. That is, the interface defines the data model, SACM
and network transport protocols to enable SACM components to transport protocols, and network transport protocols to enable SACM
communicate. components to communicate. [Revised per our 6/29 conversation -
does this work? -LL]
G-013 Device location and network topology: the SACM architecture G-013 Endpoint Location and Network Topology: The SACM architecture
and interfaces MUST allow for the target endpoint (network) location and interfaces MUST allow for the target endpoint (network) location
and network topology to be modeled and understood. Where and network topology to be modeled and understood. Where
appropriate, the data model and the interfaces SHOULD allow for appropriate, the data model and the interfaces SHOULD allow for
discovery of the target endpoint location or network topology or discovery of the target endpoint location or network topology or
both. both.
G-014 Target Endpoint Identity: the SACM architecture and interfaces G-014 Target Endpoint Identity: The SACM architecture and interfaces
MUST support the ability of components to provide attributes that MUST support the ability of components to provide attributes that
can be used to compose an identity for a target endpoint. These can be used to compose an identity for a target endpoint. These
identities MAY be composed of attributes from one or more SACM identities MAY be composed of attributes from one or more SACM
components. 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
At the simplest abstraction, the SACM architecture represents the At the simplest abstraction, the SACM architecture represents the
core components and interfaces needed to perform the production and core components and interfaces needed to perform the production and
consumption of posture assessment information. Requirements relating consumption of posture assessment information. Requirements relating
to the SACM's architecture include: to SACM's architecture include:
ARCH-001 Scalability: The architectural components MUST account for ARCH-001 Scalability: The architectural components MUST account for
a range of deployments, from very small sets of endpoints to very a range of deployments, from very small sets of endpoints to very
large deployments. large deployments.
ARCH-002 Flexibility: The architectural components MUST account for ARCH-002 Flexibility: The architectural components MUST account for
different deployment scenarios where the architectural components different deployment scenarios where the architectural components
may be implemented, deployed, or used within a single application, may be implemented, deployed, or used within a single application,
service, or network, or may comprise a federated system. service, or network, or may comprise a federated system.
ARCH-003 Separation of Data and Management functions: SACM MUST ARCH-003 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 transport and share posture assessment and protocols used to transport and share posture assessment
information. information.
ARCH-004 Topology Flexibility: Both centralized and decentralized ARCH-004 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 Posture decentralized deployment is used SHOULD be invisible to a consumer.
Information Consumer.
ARCH-005 Modularity: Announcement and negotiation of functional ARCH-005 Modularity: Announcement and negotiation of functional
capabilities (such as authentication protocols, authorization capabilities (such as authentication protocols, authorization
schemes, data models, transport protocols, etc.) must be supported, schemes, data models, transport protocols, etc.) must be supported,
enabling a SACM component to make inquiries about the capabilities enabling a SACM component to make inquiries about the capabilities
of other components in the SACM ecosystem. of other components in the SACM ecosystem.
ARCH-006 Role-based Authorization: The SACM architecture MUST be ARCH-006 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 and authorized to provide or consume information endpoints capable of and authorized to provide or consume
is required to address appropriate access controls. information is required to address appropriate access controls.
ARCH-007 Context-based Authorization: The SACM architecture MUST be ARCH-007 Context-based Authorization: The SACM architecture MUST be
capable of effecting context based authorization. Different capable of effecting context-based authorization. Different
policies (e.g. business, regulatory, etc.) may specify what data may policies (e.g. business, regulatory, etc.) may specify what data may
be exposed to, or shared by consumers based on one or more be exposed to, or shared by, consumers based on one or more
attributes of the consumer. The policy may specify that consumers attributes of the consumer. The policy may specify that consumers
are required to share specific information either back to the the are required to share specific information either back to the system
system or to administrators. or to administrators.
IM-006 Time Synchronization: Actions or decisions based on time- IM-006 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 behaviour events, etc.) are all predicated disconnection, endpoint behavior events, etc.) are all predicated on
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 represents the abstracted representation for the The SACM information model represents the abstracted representation
Posture Assessment information to be communicated. SACM data models for Posture Assessment information to be communicated. SACM data
must adhere and comply to the SACM Information Model. The models must adhere to and comply with the SACM information model.
requirements for the SACM information model include: The requirements for the SACM information model include:
IM-001 Extensible Attribute Dictionary: the Information Model MUST IM-001 Extensible Attribute Dictionary: 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 dictionary should be defined with a clear extensions. The attribute dictionary 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 expanded with new attributes. information model to be interoperably expanded with new attributes.
IM-002 Posture Data Publication: The Information Model SHOULD allow IM-002 Posture Data Publication: The information model MUST allow
for the data to be provided by an endpoint either solicited or for the data to be provided by a SACM component either solicited or
unsolicited. That is, data models MUST support at least one or both unsolicited. No aspect of the information model should be dependent
means to publish data: solicited or unsolicited. For example, a upon or assume a push (unsolicited) or pull (solicited) model of
compliance-server provider may publish endpoint posture information publication.
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).
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 different support for different data models, data model versions, and
versions of the operations (and network layer transport). The SACM different versions of the operations (and network layer transport).
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 The SACM information model MUST include the ability to discover and
a means to uniquely identify each Data Model uniquely. The negotiate the use of a particular data model or any data model.
identifier MUST contain both an identifier of the model and a
version indicator for the model. The identifiers SHOULD be IM-004 Data Model Identification: The information model MUST provide
a means to uniquely identify each data model uniquely. 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 decomposable so that a customer can query for any version of a
specific model and compare returned values for older or newer than a specific data model and compare returned values for older or newer
desired version. than a desired version.
IM-005 Data Lifetime Management: The information model MUST provide IM-005 Data Lifetime Management: The information model MUST provide
a means to allow data models to include data lifetime management. a means to allow data models to include data lifetime management.
The information model must identify attributes that can allow data The information model must identify attributes that can allow data
models to at minimum, identify the data's origination time and models to, at minimum, identify the data's origination time and
expected time of next update or data longevity (how long should the expected time of next update or data longevity (how long should the
data be assumed to still be valid). data 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 sub-components) for ease of
maintenance and extension. For example, endpoint identification
could be an independent sub-component of the information model, to
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. shared. It is expected that as applications may produce posture
assessment information, they may share it using a specific data
It is expected that as applications may produce posture assessment model. Similarly, applications consuming or requesting posture
information, they may share it using a specific data model. assessment information, may require it be based on a specific data
Similarly, applications consuming or requesting posture assessment model. Thus, while there may exist different data models and
information, may require it be based on a specific data model. Thus, schemas, they should adhere to the SACM information model and meet
while there may exist different data models and schemas, they should the requirements defined in this section.
adhere to the SACM information model and meets the requirements
defined in this section.
The specific requirements for candidate data models include: The specific requirements for candidate data models include:
DM-001 The data model MUST associate each data object with exactly DM-001 Unique Association: The data model MUST associate each data
one information model element (e.g. endpoint, IP address, asset). object with exactly one information model element (e.g. endpoint, IP
address, asset).
DM-002 Data Model Structure: The data model can be structured either DM-002 Data Model Structure: The data model can be structured either
as one single module or separated into modules and sub-modules that as one single module or separated into modules and sub-modules that
allow for references between them. The data model structure MAY allow for references between them. The data model structure MAY
reflect structure in the information model, but does not need to. reflect structure in the information model, but does not need to.
For example, the data model may use one module to define endpoints, For example, the data model may use one module to define endpoints,
and that module will reference other modules that describe the and that module will reference other modules that describe the
various assets associated with the endpoint. Constraints and various assets associated with the endpoint. Constraints and
interfaces may further be defined to resolve or tolerate ambiguity interfaces may further be defined to resolve or tolerate ambiguity
in the references (e.g. same IP address used in two separate in the references (e.g. same IP address used in two separate
networks). The data model MAY be structured into modules and networks).
submodules to allow for data references within a module. For
example, an endpoint may be defined as a module that references one
or more submodules that further describe the one or more assets.
Constraints and interfaces may further be defined to resolve or
tolerate ambiguity in the references (e.g. same IP address used 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 versus partial updates: The data model SHOULD include DM-004 Full Vs. Partial Updates: The data model SHOULD include the
the ability to allow providers of data to provide the data as a ability to allow providers of data to provide the data as a whole,
whole or when updates occur. For example, a consumer can request a or when updates occur. For example, a consumer can request a full
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 requestor. 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 Provider identification: The interfaces and actions in the DM-006 Provider Identification: The interfaces and actions in the
data model MUST include the ability to identify data from a specific data model MUST include the ability to identify data from a specific
provider. For example, a SACM consumer should be able to request provider. For example, a SACM consumer should be able to request
all data to come from a specific provider (e.g. Provider A) as all data to come from a specific provider (e.g. Provider A) as
there can be a larger set of providers. there can be a larger set of providers.
DM-007 Data cardinality: The data model MUST describe their DM-007 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 as well as whether the attributes are
conditional, optional, or mandatory. conditional, optional, or mandatory.
DM-008 Data model negotiation: The interfaces and actions in the DM-008 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-009 Data Source: The data model MUST include the ability for DM-009 Data Origin: The data model MUST include the ability for
providers to identify the data origin. For example, a provider consumers to identify the data origin (provider that collected the
endpoint could share self-reported data vs. data collected from a data).
different SACM endpoint or by some externally-observed data.
DM-010 Attribute Dictionary: Use Cases in the whole of Section 2
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.
DM-011 Origination Time: The data model SHOULD allow the provider to DM-010 Origination Time: The data model SHOULD allow the provider to
include the information's origination time. include the information's origination time.
DM-012 Data Generation: The data model SHOULD allow the provider to DM-011 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-013 Data Origin: The data model SHOULD allow the provider to DM-012 Data Source: The data model MUST allow the provider to
include attributes defining the data source (e.g. hostname, domain include attributes defining the data source (target endpoint from
(DNS) name or application name.)" which the data was collected) - e.g. hostname, domain (DNS) name or
application name.
DM-014 Data Updates: The data model SHOULD allow the provider to DM-013 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-015 Multiple Collectors: The data model MUST support the DM-014 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-016 Solicited vs. Unsolicited Updates: The data model SHOULD DM-015 Attribute Extensibility: Use Cases in the whole of Section 2
enable a provider to publish data either solicited (in response to a describe the need for an attribute dictionary. With SACM's scope
request from a from a consumer) or unsolicited (as new data is focused on posture assessment, the data model attribute collection
generated, without a request required). For example, an external and aggregation MUST have a well-understood set of attributes
collector can publish data in response to a request by a consumer inclusive of their meaning or usage intent. The data model MUST
for information about an endpoint, or can publish data as it include all attributes defined in the information model and MAY
observes new information about an endpoint, without any specific include additional attributes beyond those found in the information
consumer request triggering the publication. model. Additional attributes MUST be defined in accordance with the
extensibility framework provided in the information model.
DM-016 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 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-017 Transport Agnostic: The data model MUST be transport
agnostic, to allow for the data operations to leverage the most
appropriate SACM transport 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. The specific requirements for such operations include: data. Operations requirements are distinct from transport
requirements in that operations requirements are requirements on the
application performing requests and responses, whereas transport
requirements are requirements on the transport protocol carrying the
requests / responses. The specific requirements for such operations
include:
OP-001 Time Synchronization: Request and response operations SHOULD OP-001 Time Synchronization: Request and response operations MUST be
be timestamped, and published information SHOULD capture time of 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: The request for a data item MUST OP-002 Collection Abstraction: Collection is the act of a SACM
include enough information to properly identify the item to collect, component gathering data from a target endpoint. The request for a
but the request shall not be a command to directly execute nor data item MUST include enough information to properly identify the
directly be applied as arguments to a command. The purpose of this item to collect, but the request shall not be a command to directly
requirement is primarily to reduce the potential attack vectors, but execute nor directly be applied as arguments to a command. The
has the additional benefit of abstracting the request for collection purpose of this requirement is primarily to reduce the potential
from the collection method, thereby allowing more flexibility in how attack vectors, but has the additional benefit of abstracting the
collection is implemented. 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 OP-003 Collection Composition: A collection request MAY be composed
of multiple collection requests (which yield collected values). The of multiple collection requests (which yield collected values). The
desire for multiple values MUST be expressed as part of the desire for multiple values MUST be expressed as part of the
collection request, so that the aggregation can be resolved at the collection request, so that the aggregation can be resolved at the
point of collection without having to interact with the requester. point of collection without having to interact with the requestor.
This requirement SHOULD NOT be interpreted as preventing a collector This requirement SHOULD NOT be interpreted as preventing a collector
from providing attributes which were not part of the original from providing attributes which were not part of the original
request. request.
OP-004 Attribute-based Query: A query operation SHOULD be based on a OP-004 Attribute-based Query: A query operation is the act of
set of attributes. Use Case 2.1.2 describes the need for the data requesting data from a provider. Query operations SHOULD be based
model to support a query operation based on a set of attributes to on a set of attributes. Query operations MUST support both a query
facilitate collection of information such as posture assessment, for specific attributes and a query for all attributes. Use Case
inventory (of endpoints or endpoint components), and configuration 2.1.2 describes the need for the data model to support a query
checklist. 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 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. Use Case 2.1.3 describes the need for the
data model to support the means for the information to be collected data model to support the means for the information to be collected
through a query mechanism. Furthermore, the query operation through a query mechanism. Furthermore, the query operation
requires filtering capabilities to allow for only a subset of requires filtering capabilities to allow for only a subset of
information to be retrieved. The query operation MAY be a information to be retrieved. The query operation MAY be a
synchronous request or asynchronous request. synchronous request or asynchronous request.
OP-006 Data Model Scalability: The operation resulting from a query OP-006 Data Model 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 describes the need for amounts of data. Use Cases 2.1.4 and 2.1.5 describes the need for
the data model to support scalability. For example, the query the data model to support scalability. For example, the query
operation may result in a very large set of attributes, as well as a operation may result in a very large set of attributes, as well as a
large set of targets. 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 component
to communicate what data was used to construct the target endpoint's to communicate what data was used to construct the target endpoint's
identity, so other SACM components can determine whether they are identity, so other SACM components can determine whether they are
constructing an equivalent target enpoint (and their identity) and constructing an equivalent target endpoint (and their identity) and
whether they have confidence in that identity. SACM components whether they have confidence in that identity. SACM components
SHOULD have interfaces defined to transmit this data directly or to SHOULD have interfaces defined to transmit this data directly or to
refer to where the information can be retrieved. refer to where the information can be retrieved.
2.6. Requirements for Transport Protocols 2.6. Requirements for Transport Protocols
The requirements for transport protocols include: The requirements for SACM transport protocols include:
T-001 Transport Variability: Different transports MUST be supported T-001 Multiple Transport Protocol Support: Different transport
to address different deployment and time constraints. Supporting protocols MUST be supported in a deployment to support different
transports MAY be at the data link layer, network, transport, or transport layer requirements, different device capabilities, and
application layers. system configurations dealing with connectivity.
T-002 Data Integrity: Transport protocols MUST be able to ensure T-002 Data Integrity: transport protocols MUST be able to ensure
data integrity. data integrity for data in transit.
T-003 Data Confidentiality: Transport protocols MUST be able to T-003 Data Confidentiality: transport protocols MUST be able to
support data confidentiality. Transport protocols SHOULD ensure support data confidentiality. SACM transport protocols SHOULD
data protection for data in transit by encryption to provide ensure data protection for data in transit by encryption to provide
confidentiality, integrity, and robustness against protocol-based confidentiality, integrity, and robustness against protocol-based
attacks. Note that while the transport MUST be able to support data attacks. Note that while the transport MUST be able to support data
confidentiality, implementations MAY choose to make confidentiality confidentiality, implementations MAY choose to make confidentiality
optional. Protection for data at rest is not in scope for SACM. optional. Protection for data at rest is not in scope for transport
Data protection MAY be used for both privacy and non-privacy protocols. Data protection MAY be used for both privacy and non-
scenarios. privacy scenarios.
T-004 Transport Protection: Transport protocols MUST be capable of T-004 Transport Protection: transport protocols MUST be capable of
supporting mutual authentication and replay protection. supporting mutual authentication and replay protection.
T-005 Transport Reliability: Transport protocols MUST provide T-005 Transport Reliability: transport 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. fragmentation and reassembly, and to detect replays.
T-006 Transport Agnostic: the data model SHOULD be transport T-006 Transport Layer Requirements: Each transport protocol MUST
agnostic, to allow for the data operations to leverage the most clearly specify the transport layer requirements it needs to operate
appropriate transport Internet layer (e.g. Link Layer, TCP, UDP, correctly. Examples of items that may need to be specified include
etc.). 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. For example, a proxy server between UDP and TCP can
provide a connection that correctly fulfills the connectivity and
replay requirements as well as data link requirements (through the
use of TLS and DTLS) but would be unable to provide a channel
binding requirement, as that implies there is no MITM to look at the
data.
3. Acknowledgements 3. Acknowledgements
The authors would like to thank Barbara Fraser, Jim Bieda, and Adam The authors would like to thank Barbara Fraser, Jim Bieda, and Adam
Montville for reviewing and contributing to this draft. In addition, Montville for reviewing and contributing to this draft. In addition,
we recognize valuable comments and suggestions made by Jim Schaad and we recognize valuable comments and suggestions made by Jim Schaad and
Chris Inacio. Chris Inacio.
4. IANA Considerations 4. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
5. Security Considerations 5. 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 transports may be expected that several data models, protocols, and transports may be
defined or reused from already existing standards. This section will defined or reused from already existing standards. This section will
highlight security considerations that may apply to SACM based on the highlight security considerations that may apply to SACM based on the
architecture and standards applied in SACM. In particular, architecture and standards applied in SACM. In particular,
highlights to security considerations that may apply to the SACM highlights to security considerations that may apply to the SACM
reference architecture and standard data models and transports will reference architecture and standard data models and transports will
be discussed be discussed.
To address security and privacy considerations, the data model, To address security and privacy considerations, the data model,
protocols and transport must consider authorization based on consumer protocols, and transports must consider authorization based on
function and privileges, to only allow authorized consumers and consumer function and privileges, to only allow authorized consumers
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 / 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 requester), 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 focus on the sharing of posture information for To protect the information being shared, SACM components MUST protect
the integrity and confidentiality of data in transit (while
information is being transferred between providers and consumers, and
through proxies and/or repositories) and data at rest (for
information stored on repositories and on providers / consumers).
Mechanisms for this protection are unspecified but should include
industry best practices such as encrypted storage, encrypted
transports, data checksums, etc.
SACM's charter focuses on the sharing of posture information for
improving efficacy of security applications such as compliance, improving efficacy of security applications such as compliance,
configuration, assurance and other threat and vulnerability reporting configuration, assurance and other threat and vulnerability reporting
and remediation systems. While the goal is to facilitate the flow of and remediation systems. While the goal is to facilitate the flow of
information securely, it is important to note that participating information securely, it is important to note that participating
endpoints may not be cooperative or trustworthy. endpoints may not be cooperative or trustworthy.
5.1. Trust between Provider and Requestor 5.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 either at the provider, the
requestor or devices that are involved in the transport between the requesting consumer, or devices that are involved in the transport
provider and requestor. This section will describe the different between the provider and requestor. This section will describe the
considerations that may reduce the level of trustworthiness of the different considerations that may reduce the level of trustworthiness
information provided. of the information provided.
In the information transport flow, it is possible that some of the In the information transport 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 requester. 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, It is common to, in general, 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 transport it the posture information data it provides as well as the transport 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 A requestor beyond distrusting the network service provider, must
also account that the information received from the provider may have also account that the information received from the provider may have
been communicated through an undetermined network communications been communicated through an undetermined network communications
system. That is, the posture information may have traversed through system. That is, the posture information may have traversed through
many devices before reaching the requestor. Providing non- many devices before reaching the requestor. SACM specifications
repudiation in SACM is out of scope. However, SACM specifications should provide the means for verifying data origin and data integrity
should provide the means for allowing non-repudiation possible and at and at minimum, provide endpoint authentication and transport
minimum, provide endpoint authentication and transport integrity. 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 is described untrustworthy information. The considerations for this is described
in Section 8 of [RFC5209]. in Section 8 of [RFC5209].
skipping to change at page 16, line 8 skipping to change at page 17, line 29
[I-D.ietf-sacm-terminology] [I-D.ietf-sacm-terminology]
Waltermire, D., Montville, A., Harrington, D., Cam-Winget, Waltermire, D., Montville, A., Harrington, D., Cam-Winget,
N., Lu, J., Ford, B., and M. Kaeo, "Terminology for N., Lu, J., Ford, B., and M. Kaeo, "Terminology for
Security Assessment", draft-ietf-sacm-terminology-06 (work Security Assessment", draft-ietf-sacm-terminology-06 (work
in progress), February 2015. in progress), February 2015.
[I-D.ietf-sacm-use-cases] [I-D.ietf-sacm-use-cases]
Waltermire, D. and D. Harrington, "Endpoint Security Waltermire, D. and D. Harrington, "Endpoint Security
Posture Assessment - Enterprise Use Cases", draft-ietf- Posture Assessment - Enterprise Use Cases", draft-ietf-
sacm-use-cases-09 (work in progress), March 2015. sacm-use-cases-10 (work in progress), July 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[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, June 2008. Requirements", RFC 5209, June 2008.
7.2. Informative References 7.2. Informative References
 End of changes. 88 change blocks. 
223 lines changed or deleted 289 lines changed or added

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