draft-ietf-sacm-requirements-04.txt   draft-ietf-sacm-requirements-05.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: September 9, 2015 Pulse Secure Expires: November 10, 2015 Pulse Secure
March 8, 2015 May 9, 2015
Secure Automation and Continuous Monitoring (SACM) Requirements Secure Automation and Continuous Monitoring (SACM) Requirements
draft-ietf-sacm-requirements-04 draft-ietf-sacm-requirements-05
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 protocols. The requirements and scope are based on the
agreed upon use cases. agreed upon use cases.
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 September 9, 2015. This Internet-Draft will expire on November 10, 2015.
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 . . . . . . . . . . . . 6
2.3. Requirements for the Information Model . . . . . . . . . 7 2.3. Requirements for the Information Model . . . . . . . . . 7
2.4. Requirements for the Data Model . . . . . . . . . . . . . 7 2.4. Requirements for the Data Model . . . . . . . . . . . . . 8
2.5. Requirements for Data Model Operations . . . . . . . . . 9 2.5. Requirements for Data Model Operations . . . . . . . . . 11
2.6. Requirements for Transport Protocols . . . . . . . . . . 10 2.6. Requirements for Transport Protocols . . . . . . . . . . 12
3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
5.1. Trust between Provider and Requestor . . . . . . . . . . 12 5.1. Trust between Provider and Requestor . . . . . . . . . . 14
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.1. Normative References . . . . . . . . . . . . . . . . . . 13 6.1. Normative References . . . . . . . . . . . . . . . . . . 15
6.2. Informative References . . . . . . . . . . . . . . . . . 14 6.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
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 2, line 45 skipping to change at page 2, line 45
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 particular, for the exchange of posture assessment information in the enterprise, in
the use cases as exemplified in [I-D.ietf-sacm-use-cases]. Also, particular, for the use cases as exemplified in
this document uses terminology defined in [I-D.ietf-sacm-use-cases]. Also, this document uses terminology
[I-D.ietf-sacm-terminology]. defined in [I-D.ietf-sacm-terminology].
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.
In order to address the needs for determining, sharing, and using In order to address the needs for determining, sharing, and using
posture information, the following tasks should be considered: posture information, the following tasks should be considered:
1. Define the assets. This is what we want to know about an asset. 1. Define the assets. This is what we want to know about an asset.
For instance, organizations will want to know what software is For instance, organizations will want to know what software is
installed and its many critical security attributes such as patch installed and its many critical security attributes such as patch
level. level. [EDITOR Note: Should this really be a task as I think it
may need to be pre-defined as part of the SACM information model?
This refers to comment on Mar 23 made by Jim Schaad]
2. Resolve what assets actually compose an endpoint. This requires 2. Map the assets to an endpoint class. This requires populating
populating the data elements and attributes needed to exchange the attributes needed to exchange information pertaining to the
information pertaining to the assets composing an endpoint. assets composing an endpoint. [EDITOR Note: Do we need to add
another task or subtask for the creation of such a mapping as
commented by Jim Schaad?]
3. Determine the expected values for the data elements and 3. Policy Definition: This is where an organization can express its
attributes that need to be evaluated against the actual collected policy for acceptable or problematic values of an asset
instances of asset data. This is how an organization can express attribute. The expected values of an asset attribute are
its policy for an acceptable data element or attribute value. A determined for later comparison against the actual asset
system administrator can also identify specific data elements and attribute values during the evaluation process. Expected values
attributes that represent problems, such as vulnerabilities, that may include both those values which are good as well as those
need to be detected on an endpoint. values which represent problems, such as vulnerabilities. The
organization can also specify the asset attributes that are to be
present for a given asset.
4. Evaluate the collected instances of the asset data against those 4. Evaluation task: Evaluate the actual values of the asset data
expressed in the policy. against those expressed in the policy.
5. Report the results of the evaluation. 5. Report results: Report the results of the evaluation for use by
other components. Examples of use of a report would be
additional evaluation, network enforcement, vulnerability
detection and license management.
6. Access Control Policy: Classes of entities and access control
policies are assigned to generic attributes as well as attributes
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 data models, protocols, and
transports defined by SACM MUST be extensible to allow support for transports defined by SACM MUST be designed to allow support for
non-standard and future extensions. future extensions.
1. The transport protocol MUST support the ability to add new 1. The information model and interfaces MUST support the ability to
operations while maintaining backwards compatibility. add new operations while maintaining backwards compatibility.
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 paths to follow; the retrieval of expression of specific paths to follow; the retrieval of
specific information based on an event, as well as on a specific information based on an event, or on a continuous basis
continuous basis and the ability to retrieve specific pieces of and the ability to retrieve specific pieces of information,
information, specific types or classes of information, and/or specific types or classes of information, or the entirety of
the entirety of available information. available information. [EDITOR Note: this should be part of the
operations on data model section, but we haven't defined
routability for source paths so not sure this is even in scope
for SACM]
3. The information model MUST accommodate the addition of new data 3. The information model MUST accommodate the addition of new data
types and/or schemas in a backwards compatible fashion. 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.
[EDITOR Note: Can we remove this requirement?] [EDITOR Note: Can we remove this requirement?]
G-003 Scalability: The data models, protocols, and transports MUST G-003 Scalability: The data models, protocols, and transports MUST
be scalable. SACM must support a broad set of deployment scenarios. be scalable. SACM needs to support a broad set of deployment
Scalability must be addressed to support: scenarios. 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 (record or datagram) size to a very large datagram or a small in size to a very large datagram or a very large set of
very large set of assessments. assessments.
* 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 requiring or producing (or of a very large number of endpoints requesting and/or producing
both) 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 the suitably specified to enable implementations to fit into different
different deployment models and scenarios, including considerations deployment models and scenarios, including considerations for
for lightweight implementations of data models and transports. implementations of data models and transports operating in
constrained environments.
G-005 Information Extensibility: A method for expressing both G-005 Information Extensibility: A method for expressing both
standard and non-standard (implementation-specific) data attributes standard and non-standard (implementation-specific) data attributes
while avoiding collisions SHOULD be defined. For interoperability while avoiding collisions SHOULD be defined. For interoperability
and scope boundary, an explicit set of data attributes MUST be and scope boundary, an explicit set of data attributes MUST be
defined as mandatory to implement. defined in the information model as mandatory to implement.
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. [EDITOR Note: is the intent to provide data transport
integrity only?]
G-007 Data Isolation: 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, overlay boundaries, and federation, where an regulatory, operational requirements, overlay boundaries and
organization may want to differentiate between information that can federation where the data may be collected in multiple locations and
be shared outside its own domain and information that cannot. As either centralized or kept in the local region. Where replication
with the requirement for data integrity, this method is required to of data is supported, it is required that methods exist to prevent
be available (i.e. all data-handling components must support it), update loops.
but is not required to be used in all cases.
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 Discovery: There MUST be a mechanism for components to
discover what information is available across the ecosystem (i.e. a discover what information is available across the ecosystem (i.e. a
method for cataloging data available in the ecosystem and 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), and where to go to get a specific
piece of that information. For example, providing a method by which piece of that information. For example, providing a method by which
a node can locate the advertised information so that consumers are a node can locate the advertised information so that consumers are
not required to have a priori knowledge to find available not required to have a priori knowledge to find available
information. information.
G-010 Endpoint Discovery: SACM MUST define the means by which G-010 Endpoint Discovery: SACM MUST define the means by which
endpoints may be discovered. Use Case 2.1.2 describes the need to endpoints may be discovered. Use Case 2.1.2 describes the need to
discover endpoints and their composition. discover endpoints and their composition. [EDITOR Note: should we
make this a sub-requirement to G-009 as suggested by Jim Schaad?]
G-011 Unsolicited publication, updates, or change modifications with G-011 Push and Pull Access: Three methods of data access MUST be
filtering MUST be defined: Use Cases 2.1.3, 2.1.4 and 2.1.5 describe supported: the standard Pull model as well as solicited and
the need for the data model to support the means for the information unsolicited Push models. All of the methods of data access MUST
to be published unsolicited. Similarly, the data model must support support the ability for the initiator to filter the set of posture
the means for a requestor to obtain updates or change modifications assessment information to be delivered. Additionally, the provider
without constant querying (or polling). Like the query operation, of the information MUST be able to filter the set of posture
these update notifications must be able to be set up with a filter assessment information based on the permissions of the recipient.
to allow for only a subset of posture assessment information to be This requirement is driven by use cases 2.1.3, 2.1.4 and 2.1.5.
obtained.
G-012 Device Interface: the interfaces by which endpoint communicate G-012 Device Interface: the interfaces by which SACM components
to share endpoint posture information MUST be well defined. communicate to share endpoint posture information MUST be well
defined. [EDITOR Note: to address Chris' comment, we can clarify by
changing the term interface to communication transport both at the
network and data layer]
G-013 Device location and network topology: the SACM architecture G-013 Device location and network topology: the SACM architecture
and interfaces MUST allow for the endpoint (network) location and and interfaces MUST allow for the target endpoint (network) location
network topology to be modeled and understood. Where appropriate, and network topology to be modeled and understood. Where
the data model and the interfaces SHOULD allow for discovery of appropriate, the data model and the interfaces SHOULD allow for
endpoint location or network topology or both. discovery of the target endpoint location or network topology or
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
supported to accommodate considerations such as geographic,
regulatory, operational and federations. Entities accessing or
publishing data MUST identify themselves and pass access policy.
2.2. Requirements for the Architecture 2.2. 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 the 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.
skipping to change at page 6, line 42 skipping to change at page 7, line 23
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. within a single enterprise domain. The fact that a centralized or
decentralized deployment is used SHOULD be invisible to a Posture
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 and authorized to provide or consume information
is required to address appropriate access controls. 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 or shared by particular consumers, as well as how be exposed to, or shared by consumers based on one or more
consumers may be required to share the information. The context attributes of the consumer. The policy may specify that consumers
defines the composite set of guidelines provided by policy for are required to share specific information either back to the the
affecting what posture data is allowed to be communicated from system or to administrators.
providers to consumers.
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 represents the abstracted representation for the
Posture Assessment information to be communicated. SACM data models Posture Assessment information to be communicated. SACM data models
must adhere and comply to the SACM Information Model. The must adhere and comply to the SACM Information Model. The
requirements for the SACM information model include: 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 the minimum set of attributes for communicating Posture define a minimum set of attributes for communicating Posture
Information. The attributes should be defined within an extensible Information, to ensure interoperability between data models.
attribute dictionary to enable data models to adhere to SACM's (Individual data models may define attributes beyond the mandatory-
required attributes as well as allow for their own extensions. to-implement minimum set.) The attributes should be defined with a
clear mechanism for extensibility to enable data models to adhere to
SACM's required attributes as well as allow for their own
extensions. The attribute dictionary should be defined with a clear
mechanism for extensibility to enable future versions of the
information model to be expanded with new attributes.
IM-002 Ephemerality: The Information Model SHOULD account for the IM-002 Posture Data Publication: The Information Model SHOULD allow
Posture information's ephemerality as the data may be provided by a for the data to be provided by an endpoint either solicited or
requestor either solicited or unsolicited. unsolicited. That is, data models MUST support at least one or both
means to publish data: solicited or unsolicited. For example, 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).
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 and data model versions. The SACM support for different data models, data model versions and different
versions of the operations (and network layer transport). The SACM
Information Model MUST include the ability to discover and negotiate Information Model MUST include the ability to discover and negotiate
the use of a particular or any data model. the use of a particular or any data model.
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 model and a
version indicator for the model. The identifiers SHOULD be
decomposable so that a customer can query for any version of a
specific model and compare returned values for older or newer than a
desired version.
IM-005 Data lifetime management: The information model MUST provide
a means to allow data models to include data lifetime management.
The information model must identify attributes that can allow data
models to at minimum, identify the data's origination time and
expected time of next update or data longevity (how long should the
data be assumed to still be valid).
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 It is expected that as applications may produce posture assessment
information, they may share it using a specific data model. information, they may share it using a specific data model.
Similarly, applications consuming or requesting posture assessment Similarly, applications consuming or requesting posture assessment
information, may require it be based on a specific data model. Thus, information, may require it be based on a specific data model. Thus,
skipping to change at page 8, line 18 skipping to change at page 9, line 26
that MUST be uniquely referenced (e.g. endpoint, IP address, asset). that MUST be uniquely referenced (e.g. endpoint, IP address, asset).
DM-002 The data model MAY be structured into modules and submodules DM-002 The data model MAY be structured into modules and submodules
to allow for data references within a module. For example, an to allow for data references within a module. For example, an
endpoint may be defined as a module that references one or more endpoint may be defined as a module that references one or more
submodules that further describe the one or more assets. submodules that further describe the one or more assets.
Constraints and interfaces may further be defined to resolve or Constraints and interfaces may 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. same IP address used in
two separate networks). two separate networks).
DM-003 The interfaces and actions in the data model MUST include DM-003 Search Flexibility: The search interfaces and actions MUST
support for rootless searches and wildcard searches. include the ability to start a search anywhere within a data model
structure, and the ability to search based on patterns ("wildcard
DM-004 The search interfaces and actions MUST include the ability to searches") as well as specific data elements. .
start a search anywhere within a data model structure.
DM-005 The data model SHOULD include management of the data,
including data lifetime management (longevity or expiration of data)
and persistence considerations.
DM-006 Ephemerality: The data model SHOULD include the ability to DM-004 Full versus partial updates: The data model SHOULD include
allow providers of data to provide the data as a whole or when the ability to allow providers of data to provide the data as a
updates occur. The data may be provided by a requestor either whole or when updates occur. For example, a consumer can request a
solicited or unsolicited. full update on initial engagement, then request to receive deltas
(updates containing only the changes since the last update) on an
ongoing basis as new data is generated.
DM-007 The data model SHOULD allow for a loose coupling between the DM-005 The data model SHOULD allow for a loose coupling between the
provider and the requestor. provider and the requestor.
DM-008 The interfaces and actions in the data model MUST include the DM-006 Provider identification: The interfaces and actions in the
ability to identify data from a specific provider. data model MUST include the ability to identify data from a specific
provider. For example, a SACM consumer should be able to request
all data to come from a specific provider (e.g. Provider A) as
there can be a larger set of providers.
DM-009 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-010 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-011 Provenance: The data model MUST include the ability for DM-009 Data source: The data model MUST include the ability for
providers to identify the data origin and provide a method for providers to identify the data origin. For example, a provider
provenance information to be captured and communicated. endpoint could share self-reported data vs. data collected from a
different SACM endpoint or by some externally-observed data.
DM-012 Attribute Dictionary: Use Cases in the whole of Section 2 DM-010 Attribute Dictionary: Use Cases in the whole of Section 2
describe the need for an attribute dictionary. With SACM's scope describe the need for an attribute dictionary. With SACM's scope
focused on posture assessment, the data model attribute collection focused on posture assessment, the data model attribute collection
and aggregation MUST have a well-understood set of attributes and aggregation MUST have a well-understood set of attributes
inclusive of their meaning or usage intent. inclusive of their meaning or usage intent. [EDITOR Note: Per Jim
Schaad`s comment, this is really subsumed by IM-001. Should we
DM-013 Transport Agnostic: the data model SHOULD be transport remove it or incorporate into IM-001?]
agnostic, to allow for the data operations to leverage the most
appropriate transport Internet layer (e.g. Link Layer, TCP, UDP,
etc.). [Editor's Note: Per Dan Romanascu's comment, should this
requirement be removed? Or perhaps moved to the Data Model
Operations, whereby the operations should be defined in a transport
agnostic encapsulation?]
DM-014 The data model SHOULD allow the provider to include the DM-011 The data model SHOULD allow the provider to include the
information's origination time. information's origination time.
DM-015 The data model SHOULD allow the provider to include DM-012 The data model SHOULD allow the provider to include
attributes defining how the data was generated (e.g. self-reported, attributes defining how the data was generated (e.g. self-reported,
reported by aggregator, scan result, etc.). reported by aggregator, scan result, etc.).
DM-016 The data model SHOULD allow the provider to include DM-013 The data model SHOULD allow the provider to include
attributes defining the location of the data source. attributes defining the data source (e.g. hostname, domain (DNS)
name or application name.)"
DM-017 The data model SHOULD allow the provider to include DM-014 The data model SHOULD allow the provider to include
attributes defining whether the information provided is a delta, attributes defining whether the information provided is a delta,
partial, or full set of information. partial, or full set of information.
DM-018 The data model MUST support the collection of attributes by a DM-015 The data model MUST support the collection of attributes by a
variety of collectors, including internal collectors, external variety of collectors, including internal collectors, external
collectors with an authenticated relationship with the endpoint, and collectors with an authenticated relationship with the endpoint, and
external collectors based on network and other observations. external collectors based on network and other observers.
DM-016 Solicited vs. Unsolicited Updates: The data model SHOULD
enable a provider to publish data either solicited (in response to a
request from a 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.
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. The specific requirements for such operations include:
OP-001 Synchronization: Request and response operations SHOULD be OP-001 Time Synchronization: Request and response operations SHOULD
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 separation: The request for a data item MUST OP-002 Collection separation: The request for a data item MUST
include enough information to properly identify the item to collect, include enough information to properly identify the item to collect,
but the request shall not be a command to directly execute nor but the request shall not be a command to directly execute nor
directly be applied as arguments to a command. The purpose of this directly be applied as arguments to a command. The purpose of this
skipping to change at page 10, line 50 skipping to change at page 12, line 15
OP-007 The data model MUST allow a SACM component to communicate OP-007 The data model MUST allow a SACM component to communicate
what data was used to construct the target endpoint's identity, so what data was used to construct the target endpoint's identity, so
other SACM components can determine whether they are constructing an other SACM components can determine whether they are constructing an
equivalent target enpoint (and their identity) and whether they have equivalent target enpoint (and their identity) and whether they have
confidence in that identity. SACM components SHOULD have interfaces confidence in that identity. SACM components SHOULD have interfaces
defined to transmit this data directly or to refer to where the defined to transmit this data directly or to refer to where the
information can be retrieved. information can be retrieved.
2.6. Requirements for Transport Protocols 2.6. Requirements for Transport Protocols
EDITOR Note: this section is meant to relate to Network tranport
layer protocols. For the data, I pesumed the transport would fall as
an operation on the data model. But we need group consensus and
terminology to clarify this.
The requirements for transport protocols include: The requirements for transport protocols include:
T-001 Transport variability: Different transports MUST be supported T-001 Transport variability: Different transports MUST be supported
to address different deployment and time constraints. Supporting to address different deployment and time constraints. Supporting
transports MAY be at the data link layer, network, transport, or transports MAY be at the data link layer, network, transport, or
application layers. application layers.
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.
skipping to change at page 11, line 30 skipping to change at page 12, line 47
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 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
agnostic, to allow for the data operations to leverage the most
appropriate transport Internet layer (e.g. Link Layer, TCP, UDP,
etc.).
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. 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 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
skipping to change at page 12, line 18 skipping to change at page 13, line 44
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 should be based on both subject (the information authorization should be based on both subject (the information
requestor) and object (the information requested). The method by requestor) and object (the information requested). The method by
which this authorization is applied is unspecified. which this authorization is applied is unspecified.
With SACM's charter focus on the sharing of posture information for SACM's charter focus 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 requestor or devices that are involved in the transport between the
provider and requestor. This section will describe the different provider and requestor. This section will describe the different
considerations that may reduce the level of trustworthiness of the considerations that may reduce the level of trustworthiness of the
information provided. 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 and requester. Without appropriate protections, it is possible for
these proxies and brokers to inject and affect man-in-the-middle
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. As such, providing non- many devices before reaching the requestor. Providing non-
repudiation in SACM is out of scope. However, SACM specifications repudiation in SACM is out of scope. However, SACM specifications
should provide the means for allowing non-repudiation possible and at should provide the means for allowing non-repudiation possible and at
minimum, provide endpoint authentication and transport integrity. minimum, provide endpoint authentication and transport 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,
skipping to change at page 13, line 52 skipping to change at page 15, line 33
[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-08 (work in progress), February 2015. sacm-use-cases-09 (work in progress), March 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.
6.2. Informative References 6.2. Informative References
 End of changes. 57 change blocks. 
136 lines changed or deleted 208 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/