draft-ietf-sacm-requirements-02.txt   draft-ietf-sacm-requirements-03.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: April 27, 2015 Pulse Secure Expires: July 6, 2015 Pulse Secure
October 24, 2014 January 2, 2015
Secure Automation and Continuous Monitoring (SACM) Requirements Secure Automation and Continuous Monitoring (SACM) Requirements
draft-ietf-sacm-requirements-02 draft-ietf-sacm-requirements-03
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 working group. The Secure Automation and Continuous Monitoring working group. The
requirements and scope are based on the agreed upon use cases. requirements and scope are based 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
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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 April 27, 2015. This Internet-Draft will expire on July 6, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1. Requirements for SACM . . . . . . . . . . . . . . . . . . 3 2.1. Requirements for SACM . . . . . . . . . . . . . . . . . . 3
2.2. Requirements based on Use Cases . . . . . . . . . . . . . 5 2.2. Requirements for the Architecture . . . . . . . . . . . . 5
2.3. Requirements for the Architecture . . . . . . . . . . . . 7 2.3. Requirements for the Data Model . . . . . . . . . . . . . 6
2.4. Requirements for the Information Model . . . . . . . . . 7 2.4. Requirements for Transport Protocols . . . . . . . . . . 9
2.5. Requirements for Transport Protocols . . . . . . . . . . 10 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Trust between Provider and Requestor . . . . . . . . . . 10
6.1. Normative References . . . . . . . . . . . . . . . . . . 11 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.2. Informative References . . . . . . . . . . . . . . . . . 11 6.1. Normative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 6.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
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 51 skipping to change at page 2, line 51
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 particular, for
the use cases as exemplified in [I-D.ietf-sacm-use-cases].Also, this the use cases as exemplified in [I-D.ietf-sacm-use-cases].Also, this
document uses terminology defined in [I-D.ietf-sacm-terminology]. document uses 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 information requirements used by SACM to assess and compare candidate data
models and protocols to suit the architecture. These requirements models, their interfaces and protocols to suit the SACM architecture.
express characteristics or features that a candidate protocol or data
model must be capable of offering to ensure security and These requirements express characteristics or features that a
interoperability. candidate protocol or data model must be capable of offering to
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.
2. Resolve what assets actually compose an endpoint. This requires 2. Resolve what assets actually compose an endpoint. This requires
skipping to change at page 3, line 38 skipping to change at page 3, line 39
4. Evaluate the collected instances of the asset data against those 4. Evaluate the collected instances of the asset data against those
expressed in the policy. expressed in the policy.
5. Report the results of the evaluation. 5. Report the results of the evaluation.
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 all use deployments, the following requirements are defined for proposed SACM
cases: standards:
G-001 Extensibility: The data models, protocols and transports G-001 Solution Extensibility: The data models, protocols and
defined by SACM must be extensible to allow support for non-standard transports defined by SACM MUST be extensible to allow support for
and future extensions. non-standard and future extensions.
1. The transport protocol must support easily adding new operations 1. The transport protocol MUST support the ability to add new
while maintaining backwards compatibility. operations while maintaining backwards compatibility.
2. The query language must allow general inquiries as well as 2. The query language must allow general inquiries as well as
expression of specific paths to follow; retrieval of specific expression of specific paths to follow; retrieval of specific
information based on an event, as well as on a continuous basis; information based on an event, as well as on a continuous basis;
and the ability to retrieve specific pieces of information, and the ability to retrieve specific pieces of information,
specific classes of information, and/or the entirety of specific types or classes of information, and/or the entirety of
available information. available information.
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 in a backwards compatible fashion.
G-002 Interoperability: The data models, protocols and transports G-002 Interoperability: The data models, protocols and transports
must be specified with enough details and state machine to ensure must be specified with enough details to ensure interoperability.
interoperability.
G-003 Scalability: The data models, protocols and transports must be G-003 Scalability: The data models, protocols and transports must be
scalable. SACM must support a broad set of deployment scenarios. scalable. SACM must support a broad set of deployment scenarios.
As such, it is possible that the size of posture assessment As such, it is possible that the size of posture assessment
information can vary from a single assessment that is small in information can vary from a single assessment that is small in
(record or datagram) size to a very large datagram or a very large (record or datagram) size to a very large datagram or a very large
set of assessments. This must be defined by the SACM set of assessments. This must be defined by the SACM
specifications. specifications.
G-004 Agility: The agility requirement is to ensure that the data G-004 Agility: The agility requirement is to ensure that the data
model, protocols, transports are suitably to implemented to fit into model, protocols, and transports are suitably specified to enable
the different deployment models and scenarios. Considerations for implementions to fit into the different deployment models and
the lightweight implementations of data models and transports is scenarios. Considerations for lightweight implementations of data
required. Use cases, especially in the vulnerability assessment and models and transports is required.
threat defense applications, require time criticality in both
obtaining the information as well as consuming (e.g. parsing) the
data.
G-005 / T-001 Transport variability: Moved to the Section 2.5.
G-006 / GN-005 Extensibility: A method for expressing both standard
and non-standard (implemention-specific) data attributes while
avoiding collisions should be defined. For interoperability and
scope boundary, an explicit set of data attributes as mandatory to
implement.
G-007 / GN-006/ T-002 Data Integrity: A method for ensuring data
integrity must be provided. This method is required to be available
(i.e. all data-handling components must support it), but is not
required to be used in all cases.
G-008 / T-003 Data Protection: Moved to the Section 2.5. G-005 Information Extensibility: A method for expressing both
standard and non-standard (implemention-specific) data attributes
while avoiding collisions SHOULD be defined. For interoperability
and scope boundary, an explicit set of data attributes MUST be
defined mandatory to implement.
G-009 / ARCH-004 Topology Flexibility: Moved to the Section 2.3. G-006 Data Integrity: A method for ensuring data integrity MUST be
provided. This method is required to be available (i.e. all data-
handling components must support it), but is not required to be used
in all cases.
G-010 / GN-007 Data Isolation: A method for partitioning data must G-007 Data Isolation: A method for partitioning data MUST be
be supported, to accommodate considerations such as geographic, supported, to accommodate considerations such as geographic,
regulatory, overlay boundaries and federation, where an organization regulatory, overlay boundaries and federation, where an organization
may want to differentiate between information that can be shared may want to differentiate between information that can be shared
outside its own domain and information that cannot. As with the outside its own domain and information that cannot. As with the
requirement for data integrity, this method is required to be requirement for data integrity, this method is required to be
available (i.e. all data-handling components must support it), but available (i.e. all data-handling components must support it), but
is not required to be used in all cases. is not required to be used in all cases.
G-011 / ARCH-005 Modularity: has been moved to the Section 2.3. G-008 Versioning and Backward Compatibility: Announcement and
negotiation of versions, inclusive of exisiting capabilities (such
G-012 / GN-008 Versioning and Backward Compatibility: Announcement as transport protocols, data models, specific attributes within data
and negotiation of versions, inclusive of exisiting capabilities models, standard attribute expression sets, etc.) MUST be
(such as transport protocols, data models, specific attributes supported. Negotiation for both versioning and capability is needed
within data models, standard attribute expression sets, etc.) must to accommodate future growth and ecosystems with mixed capabilities.
be supported. Negotiation for both versioning and capability is
needed to accommodate future growth and ecosystems with mixed
capabilities.
G-013 / GN-009 Discovery: There must be a mechanism for components G-009 Discovery: There must be a mechanism for components to
to discover what information is available across the ecosystem (i.e. discover what information is available across the ecosystem (i.e. a
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-014 / IM-013 Synchronization: has been moved to the Section 2.4. G-010 Endpoint Discovery: SACM MUST define the means by which
endpoints may be discovered. Use Case 2.1.2 describes the need to
G-015 / IM-014 Collection separation: has been moved to the
Section 2.4.
G-016 / IM-015 Collection composition has been moved to the
Section 2.4.
2.2. Requirements based on Use Cases
This section describes the requirements that may apply to information
models, data models, protocols or transports as identified by the use
cases in [I-D.ietf-sacm-use-cases] and referenced by the section
numbers from that draft.
REQ-001 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 attribute collection and
aggregation must have a well understood set of attributes inclusive
of their meaning or usage intent.
REQ-002 Information Model: Use Case 2.1.1 describes the need for an
Information Model to drive content definition. As SACM endeavors to
reuse already existing standards which may have their own data
models defined by instantiating an information model, the data
models can be mapped to SACM's information model. See [RFC3444] for
a description and distinctions between an information and data
model.
REQ-003 Data Model to Protocol mapping: Use Case 2.1.1 describes the
need to instantiate a data model that can map to the SACM protocols
for posture content operations such as publication, query, change
detection and asynchronous notifications.
REQ-004 Endpoint Discovery: Use Case 2.1.2 describes the need to
discover endpoints and their composition. discover endpoints and their composition.
REQ-005 Attribute based query: Use Case 2.1.2 describes the need for G-011 Unsolicited publication, updates or change modifications with
the data model to support a query operation based on a set of filtering: Use Cases 2.1.3, 2.1.4 and 2.1.5 describe the need for
attributes to facilitate collection of information such as posture the data model to support the means for the information to be
assessment, inventory (of endpoints or endpoint components) and published unsolicited. Similarly, the data model must support the
configuration checklist. . means for a requestor to obtain updates or change modifications
without constant querying (or polling). Like the query operation,
REQ-006 Information based query with filtering: Use Case 2.1.3 these update notifications can be set up with a filter to allow for
describes the need for the data model to support the means for the only a subset of posture assessment information to be obtained.
information to be collected through a query mechanism. Furthermore,
the query operation requires filtering capabilities to allow for
only a subset of information to be retrieved. The query operation
may be a synchronous request or asynchronous request.
REQ-007 Asynchronous publication, updates or change modifications
with filtering: Use Cases 2.1.3, 2.1.4 and 2.1.5 describe the need
for the data model to support the means for the information to be
published asynchronously. Similarly, the data model must support
the means for a requestor to obtain updates or change modifications
asynchronously. Like the query operation, these update
notifications can be set up with a filter to allow for only a subset
of posture assessment information to be obtained.
REQ-008 Data model scalability: Use Cases 2.1.4 and 2.1.5 describes
the need for the data model to support scalability. For example,
the query operation may result in a very large set of attributes as
well as a large set of targets.
REQ-009 Separation of Collection Request and Collection Action: The
data model should distinguish the request for a data attribute for
collection versus a request to process, execute or apply the data
attributes for evaluation or analysis. N.B. This requirement is
based on most of the Use Cases in Section of
[I-D.ietf-sacm-use-cases] and defines a requirement about the
Information Model, thus this is the same as IM-014.
2.3. 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
the SACM's architecture include: 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 set of endpoints are used to a range of deployments, from very small set of endpoints are used to
very large deployments. very large deployments.
skipping to change at page 7, line 45 skipping to change at page 6, line 21
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.
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.
2.4. Requirements for the Information Model ARCH-006 Role based Authorization: The SACM architecture MUST be
capable of affecting role based authorization. Distinction of
endpoints capable and authorized to provide or consume information
is required to address appropriate access controls.
ARCH-007 Context based Authorization: The SACM architecture MUST be
capable of affecting a context based authorization. Different
policies (e.g. business, regulatory, etc) may specify what data may
be exposed or shared by particular consumers as well as how
consumers may be required to share the information. The context
defines the composite set of guidelines provided by policy for
affecting what posture data is allowed to be communicated from
providers to consumers.
2.3. 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 based on a specific data model. Thus, information, may require it be based on a specific data model. Thus,
while there may exist different data models and schemas, they should while there may exist different data models and schemas, they should
adhere to a SACM information model that meets a set of requirements adhere to a SACM information model that meets the requirements
defined in this section. defined in this section.
The specific requirements include: The specific requirements for candidate data models include:
IM-001 The information model MUST define the data attributes as IM-001 The data model MUST define the data attributes as objects
objects that MUST be uniquely referenced (e.g. endpoint, IP address, that MUST be uniquely referenced (e.g. endpoint, IP address, asset).
asset).
IM-002 The information model may structure data models into modules IM-002 The data model may be structured into modules and submodules
and submodules to allow for data references within a module. For to allow for data references within a module. For example, an
example, an endpoint may be defined as a module that references one endpoint may be defined as a module that references one or more
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).
IM-003 The interfaces and actions in the information model MUST IM-003 The interfaces and actions in the data model MUST include
include support for rootless searches and wildcard searches support for rootless searches and wildcard searches
IM-004 The search interfaces and actions MUST include the ability to IM-004 The search interfaces and actions MUST include the ability to
start a search anywhere within a data model structure. start a search anywhere within a data model structure.
IM-005 The information model SHOULD include management of the data, IM-005 The data model SHOULD include management of the data,
including data lifetime management (longevity or expiration of including data lifetime management (longevity or expiration of
data). data).
IM-006 The information model SHOULD include data ephemerality IM-006 Ephemerality: The information model SHOULD include the
(update vs. notify). ability to allow providers of data to provide the data as a whole or
when updates occur. The data may be provided by a requestor either
IM-007 The information model SHOULD allow for a loose coupling solicited or unsolicited.
between producer and consumer.
IM-008 The interfaces and actions in the information model MUST
include the ability to identify data from a specific producer.
IM-009 The structures in the information model MUST account for
metadata cardinality. As Posture information and the tasks for
collection, aggregation or evaluation could comprise one or more
attributes, interfaces and actions must allow and account for such
cardinality as well as whether the attributes are conditional,
optional or mandatory.
IM-010 The interfaces and actions in the information model MUST
include capability negotiation to enable discovery of supported and
available data types and schemas.
IM-011 Provenance of data -
* Publisher identity, classification, trustworthiness,
authoritativeness
* Freshness of data IM-007 The data model SHOULD allow for a loose coupling between the
provider and the requestor.
* Method by which data was generated (i.e. self-reported, reported IM-008 The interfaces and actions in the data model MUST include the
by aggregator, result of scan, etc.) ability to identify data from a specific provider.
* Location of data IM-009 Data cardinality: The data model MUST describe their
constraints (e.g. cardinality). As Posture information and the
tasks for collection, aggregation or evaluation could comprise one
or more attributes, interfaces and actions must allow and account
for such cardinality as well as whether the attributes are
conditional, optional or mandatory.
* Delta results vs. total results IM-010 Data model negotiation: The interfaces and actions in the
information model MUST include capability negotiation to enable
discovery of supported and available data types and schemas.
IM-012 Freshness: Published data must be associated with the time of IM-011 The data model SHOULD include the ability for providers to
origination - separately from the time of publication required in identify the data origin.
IM-013. This allows consumers can make decisions about the
relevance of the data based on its currency and/or age.
IM-013 Synchronization: Request and response operations must be IM-012 Synchronization: Request and response operations SHOULD be
timestamped, and published information must 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 must be provided. discrepancies SHOULD be provided.
IM-014 Collection separation: The request for a data item must IM-013 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 applied as arguments to a command. The purpose of this directly be applied as arguments to a command. The purpose of this
requirement is primarily to reduce the potential attack vectors, but requirement is primarily to reduce the potential attack vectors, but
has the additional benefit of abstracting the request for collection has the additional benefit of abstracting the request for collection
from the collection method thereby allowing more flexibility in how from the collection method thereby allowing more flexibility in how
collection is implemented. collection is implemented.
IM-015 Collection composition A collection request can be composed IM-014 Collection composition: A collection request can be composed
of multiple collection requests (which yield collected values). of multiple collection requests (which yield collected values).
This must be able to be expressed as part of the collection request This must be able to be expressed as part of the collection request
so that the aggregation can be resolved at the point of collection so that the aggregation can be resolved at the point of collection
without having to interact with the requester. without having to interact with the requester.
2.5. Requirements for Transport Protocols IM-015 Attribute based query: Use Case 2.1.2 describes the need for
the data model to support a query operation based on a set of
attributes to facilitate collection of information such as posture
assessment, inventory (of endpoints or endpoint components) and
configuration checklist.
IM-016 Information based query with filtering: Use Case 2.1.3
describes the need for the data model to support the means for the
information to be collected through a query mechanism. Furthermore,
the query operation requires filtering capabilities to allow for
only a subset of information to be retrieved. The query operation
MAY be a synchronous request or asynchronous request.
IM-017 Data model scalability: Use Cases 2.1.4 and 2.1.5 describes
the need for the data model to support scalability. For example,
the query operation may result in a very large set of attributes as
well as a large set of targets.
IM-018 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.
IM-019 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.).
IM-020 The data model SHOULD allow the provider to include the
information's origination time.
IM-021 The data model SHOULD allow the provider to include attributs
defining how the data was generated (e.g. self-reported, reported by
aggregator, scan result, etc.).
IM-022 The data model SHOULD allow the provider to include
attributes defining the location of the data source.
IM-023 The data model SHOULD allow the provider to include
attributes defining whether the information provided is a delta,
partial or full set of information.
2.4. Requirements for Transport Protocols
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 Layer 2, Layer 3 and higher application transports MAY be at the data link layer, network transport layer or
layers. the application layers.
T-002 Data Integrity: A method for ensuring data integrity must be T-002 Data Integrity: Transport protocols MUST be able to support
provided if required at the transport layer. data integrity.
T-003 Data Protection: Transport protocols must ensure data T-003 Data Confidentiality: Transport protocols MUST be able to
protection for data in transit by encryption and robustness against support data confidentiality. Transport protocols SHOULD ensure
protocol-based attacks. Protection for data at rest is not in scope data protection for data in transit by encryption to provide
for SACM. Data protection may be used for both privacy and non- confidentiality, integrity and robustness against protocol-based
privacy scenarios. attacks. Note that while the transport MUST be able to support data
confidentiality, implementations MAY choose to make confidentiality
optional. Protection for data at rest is not in scope for SACM.
Data protection MAY be used for both privacy and non-privacy
scenarios.
T-004 Transport protection: Transport protocols MUST be capable of
supporting mutual authentication and replay protection.
T-005 Transport reliability: Transport protocols MUST provide
reliable delivery of data. This includes the ability to perform
fragmentation and reassembly, and detect replays.
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.
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. architecture and standards applied in SACM. In particular,
highlights to security considerations that may apply to the SACM
reference architecture and standard data models and transports will
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 transport must consider authorization based on consumer
function and privileges, to only allow authorized consumers and function and privileges, to only allow authorized consumers and
providers to access specific information being requested or 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 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
improving efficacy of security applications such as compliance,
configuration, assurance and other threat and vulnerability reporting
and remediation systems. While the goal is to facilitate the flow of
information securely, it is important to note that participating
endpoints may not be cooperative or trustworthy.
5.1. Trust between Provider and Requestor
The information given from the provider to a requestor may come with
different levels of trustworthiness given the different potential
deployment scenarios and compromise either at the provider, the
requestor or devices that are involved in the transport between the
provider and requestor. This section will describe the different
considerations that may reduce the level of trustworthiness of the
information provided.
In the information transport flow, it is possible that some of the
devices may serve as proxies or brokers and as such, may be able to
observe the communications flowing between an information provider
and requester. Without appropriate protections
It is common to, in general, distrust the network service provider,
unless the full hop by hop communications process flow is well
understood. As such, the posture information provider should protect
the posture information data it provides as well as the transport it
uses. Similarly, while there may be providers whose goal is to
openly share its information, there may also be providers whose
policy is to grant access to certain posture information based on its
business or regulatory policy. In those situations, a provider may
require full authentication and authorization of the requestor (or
set of requestors) and share only the authorized information to the
authenticated and authorized requestors.
A requestor beyond distrusting the network service provider, must
also account that the information recieved from the provider may have
been communicated through an undetermined network communications
system. That is, the posture information may have traversed through
many devices before reaching the requestor. As such, providing non-
repudiation in SACM is out of scope. However, SACM specifications
should provide the means for allowing non-repudiation possible and at
minimum, provide endpoint authentication and transport integrity.
A requestor may require data freshness indications, both knowledge of
data origination as well as time of publication so that it can make
more informed decisions about the relevance of the data based on its
currency and/or age.
It is also important to note that endpoint assessment reports,
especially as they may be provided by the target endpoint may pose
untrustworthy information. The considerations for this is described
in Section 8 of [RFC5209].
The trustworthiness of the posture information given by the provider
to one or many requestors is dependent on several considerations.
Some of these include the requestor requiring:
o Full disclosure of the network topology path to the provider(s).
o Direct (peer to peer) communication with the provider.
o Authentication and authorization of the provider.
o Either or both confidentiality and integrity at the transport
layer.
o Either or both confidentiality and integrity at the data layer.
6. References 6. References
6.1. Normative References 6.1. Normative References
[I-D.ietf-sacm-terminology] [I-D.ietf-sacm-terminology]
Waltermire, D., Montville, A., Harrington, D., and N. Cam- Waltermire, D., Montville, A., Harrington, D., and N. Cam-
Winget, "Terminology for Security Assessment", draft-ietf- Winget, "Terminology for Security Assessment", draft-ietf-
sacm-terminology-05 (work in progress), August 2014. sacm-terminology-05 (work in progress), August 2014.
[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-07 (work in progress), April 2014. sacm-use-cases-07 (work in progress), April 2014.
[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.
Tardo, "Network Endpoint Assessment (NEA): Overview and
Requirements", RFC 5209, June 2008.
6.2. Informative References 6.2. Informative References
[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between
Information Models and Data Models", RFC 3444, January Information Models and Data Models", RFC 3444, January
2003. 2003.
[RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J.
Tardo, "Network Endpoint Assessment (NEA): Overview and
Requirements", RFC 5209, June 2008.
Authors' Addresses Authors' Addresses
Nancy Cam-Winget Nancy Cam-Winget
Cisco Systems Cisco Systems
3550 Cisco Way 3550 Cisco Way
San Jose, CA 95134 San Jose, CA 95134
US US
Email: ncamwing@cisco.com Email: ncamwing@cisco.com
Lisa Lorenzin Lisa Lorenzin
Pulse Secure Pulse Secure
2700 Zanker Rd., Suite 200 2700 Zanker Rd., Suite 200
San Jose, CA 95134 San Jose, CA 95134
US US
Email: llorenzin@pulsesecure.net Email: llorenzin@pulsesecure.net
 End of changes. 50 change blocks. 
205 lines changed or deleted 257 lines changed or added

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