[Docs] [txt|pdf|xml] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-camwinget-sacm-requirements) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 RFC 8248

SACM                                                       N. Cam-Winget
Internet-Draft                                             Cisco Systems
Intended status: Informational                               L. Lorenzin
Expires: November 21, 2015                                  Pulse Secure
                                                            May 20, 2015


    Secure Automation and Continuous Monitoring (SACM) Requirements
                    draft-ietf-sacm-requirements-06

Abstract

   This document defines the scope and set of requirements for the
   Secure Automation and Continuous Monitoring (SACM) architecture, data
   model and protocols.  The requirements and scope are based on the
   agreed upon use cases.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on November 21, 2015.

Copyright Notice

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

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



Cam-Winget & Lorenzin   Expires November 21, 2015               [Page 1]


Internet-Draft              Abbreviated Title                   May 2015


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Requirements for SACM . . . . . . . . . . . . . . . . . .   3
     2.2.  Requirements for the Architecture . . . . . . . . . . . .   6
     2.3.  Requirements for the Information Model  . . . . . . . . .   7
     2.4.  Requirements for the Data Model . . . . . . . . . . . . .   8
     2.5.  Requirements for Data Model Operations  . . . . . . . . .  11
     2.6.  Requirements for Transport Protocols  . . . . . . . . . .  12
   3.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  13
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
     5.1.  Trust between Provider and Requestor  . . . . . . . . . .  14
   6.  Change Log  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     6.1.  -05 to -06  . . . . . . . . . . . . . . . . . . . . . . .  15
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  15
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

1.  Introduction

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

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

   This document focuses on describing the requirements for facilitating
   the exchange of posture assessment information in the enterprise, in
   particular, for the use cases as exemplified in
   [I-D.ietf-sacm-use-cases].  Also, this document uses terminology
   defined in [I-D.ietf-sacm-terminology].





Cam-Winget & Lorenzin   Expires November 21, 2015               [Page 2]


Internet-Draft              Abbreviated Title                   May 2015


2.  Requirements

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

   SACM defines an architecture and information model focused on
   addressing the needs for determining, sharing, and using posture
   information.  With the information model defining assets and
   attributes to facilitate the guidance, collection and assessment of
   posture, the following tasks should be considered:

   1.  Map the assets to an endpoint class.  This requires populating
       the attributes needed to exchange information pertaining to the
       assets composing an endpoint.

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

   3.  Evaluation task: Evaluate the actual values of the asset data
       against those expressed in the policy.

   4.  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.

   5.  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

   Many deployment scenarios can be instantiated to address the above
   tasks and use cases defined in [I-D.ietf-sacm-use-cases].  To ensure
   interoperability, scalability, and flexibility in any of these




Cam-Winget & Lorenzin   Expires November 21, 2015               [Page 3]


Internet-Draft              Abbreviated Title                   May 2015


   deployments, the following requirements are defined for proposed SACM
   standards:

   G-001  Solution Extensibility: The data models, protocols, and
    transports defined by SACM MUST be designed to allow support for
    future extensions.



    1.  The information model and interfaces MUST support the ability to
        add new operations while maintaining backwards compatibility.

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

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

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

   G-003  Scalability: The data models, protocols, and transports MUST
    be scalable.  SACM needs to support a broad set of deployment
    scenarios.  Scalability must be addressed to support:



    *  Large datagrams: It is possible that the size of posture
       assessment information can vary from a single assessment that is
       small in size to a very large datagram or a very large set of
       assessments.

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

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

   G-004  Agility: The data model, protocols, and transports MUST be
    suitably specified to enable implementations to fit into different
    deployment models and scenarios, including considerations for




Cam-Winget & Lorenzin   Expires November 21, 2015               [Page 4]


Internet-Draft              Abbreviated Title                   May 2015


    implementations of data models and transports operating in
    constrained environments.

   G-005  Information Extensibility: Non-standard (implementation-
    specific) data attributes MUST be supported.  A method SHOULD be
    defined for preventing collisions from occurring in the naming of
    all data attributes independent of their source.  For
    interoperability and scope boundary, the information model MUST
    define the mandatory set of data attributes.  The set of attributes
    defined by the information model MUST be well defined.

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

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

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

   G-010  Endpoint Discovery: SACM MUST define the means by which
    endpoints may be discovered.  Use Case 2.1.2 describes the need to
    discover endpoints and their composition.

   G-011  Push and Pull Access: Three methods of data access MUST be
    supported: the standard Pull model as well as solicited and
    unsolicited Push models.  All of the methods of data access MUST
    support the ability for the initiator to filter the set of posture



Cam-Winget & Lorenzin   Expires November 21, 2015               [Page 5]


Internet-Draft              Abbreviated Title                   May 2015


    assessment information to be delivered.  Additionally, the provider
    of the information MUST be able to filter the set of posture
    assessment information based on the permissions of the recipient.
    This requirement is driven by use cases 2.1.3, 2.1.4 and 2.1.5.

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

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

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

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

2.2.  Requirements for the Architecture

   At the simplest abstraction, the SACM architecture represents the
   core components and interfaces needed to perform the production and
   consumption of posture assessment information.  Requirements relating
   to the SACM's architecture include:

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

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

   ARCH-003  Separation of Data and Management functions: SACM MUST
    define both the configuration and management of the SACM data models




Cam-Winget & Lorenzin   Expires November 21, 2015               [Page 6]


Internet-Draft              Abbreviated Title                   May 2015


    and protocols used to transport and share posture assessment
    information.

   ARCH-004  Topology Flexibility: Both centralized and decentralized
    (peer-to-peer) information exchange MUST be supported.  Centralized
    data exchange enables use of a common data format to bridge together
    data exchange between diverse systems, and can leverage a virtual
    data store that centralizes and offloads all data access, storage,
    and maintenance to a dedicated resource.  Decentralized data
    exchange enables simplicity of sharing data between relatively
    uniform systems, and between small numbers of systems, especially
    within a single enterprise domain.  The fact that a centralized or
    decentralized deployment is used SHOULD be invisible to a Posture
    Information Consumer.

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

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

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

2.3.  Requirements for the Information Model

   The SACM information represents the abstracted representation for the
   Posture Assessment information to be communicated.  SACM data models
   must adhere and comply to the SACM Information Model.  The
   requirements for the SACM information model include:



Cam-Winget & Lorenzin   Expires November 21, 2015               [Page 7]


Internet-Draft              Abbreviated Title                   May 2015


   IM-001  Extensible Attribute Dictionary: the Information Model MUST
    define a minimum set of attributes for communicating Posture
    Information, to ensure interoperability between data models.
    (Individual data models may define attributes beyond the mandatory-
    to-implement minimum set.)  The attributes should be defined with a
    clear mechanism for extensibility to enable data models to adhere to
    SACM's required attributes as well as allow for their own
    extensions.  The attribute 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  Posture Data Publication: The Information Model SHOULD allow
    for the data to be provided by an endpoint either solicited or
    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
    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
    the use of a particular data model or any data model.

   IM-004  Data Model Identification: The Information model MUST provide
    a means to uniquely identify each Data Model 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

   The SACM information model represents an abstraction for "what"
   information can be communicated and "how" it is to be represented and
   shared.





Cam-Winget & Lorenzin   Expires November 21, 2015               [Page 8]


Internet-Draft              Abbreviated Title                   May 2015


   It is expected that as applications may produce posture assessment
   information, they may share it using a specific data model.
   Similarly, applications consuming or requesting posture assessment
   information, may require it be based on a specific data model.  Thus,
   while there may exist different data models and schemas, they should
   adhere to the SACM information model and meets the requirements
   defined in this section.

   The specific requirements for candidate data models include:

   DM-001  The data model MUST associate each data object with exactly
    one information model element (e.g. endpoint, IP address, asset).

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

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

   DM-004  Full versus partial updates: The data model SHOULD include
    the ability to allow providers of data to provide the data as a
    whole or when updates occur.  For example, a consumer can request a
    full update on initial engagement, then request to receive deltas
    (updates containing only the changes since the last update) on an
    ongoing basis as new data is generated.

   DM-005  Loose Coupling: The data model SHOULD allow for a loose
    coupling between the provider and the requestor.

   DM-006  Provider identification: The interfaces and actions in the
    data model MUST include the ability to identify data from a specific
    provider.  For example, a SACM consumer should be able to request



Cam-Winget & Lorenzin   Expires November 21, 2015               [Page 9]


Internet-Draft              Abbreviated Title                   May 2015


    all data to come from a specific provider (e.g.  Provider A) as
    there can be a larger set of providers.

   DM-007  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.

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

   DM-009  Data Source: The data model MUST include the ability for
    providers to identify the data origin.  For example, a provider
    endpoint could share self-reported data vs. data collected from a
    different SACM endpoint or by some externally-observed data.

   DM-010  Attribute Dictionary: Use Cases in the whole of Section 2
    describe the need for an attribute dictionary.  With SACM's scope
    focused on posture assessment, the data model attribute collection
    and aggregation MUST have a well-understood set of attributes
    inclusive of their meaning or usage intent.

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

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

   DM-013  Data Origin: The data model SHOULD allow the provider to
    include attributes defining the data source (e.g. hostname, domain
    (DNS) name or application name.)"

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

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

   DM-016  Solicited vs. Unsolicited Updates: The data model SHOULD
    enable a provider to publish data either solicited (in response to a



Cam-Winget & Lorenzin   Expires November 21, 2015              [Page 10]


Internet-Draft              Abbreviated Title                   May 2015


    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

   Posture information data adhering to a Data Model must also provide
   interfaces that include operations for access and production of the
   data.  The specific requirements for such operations include:

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

   OP-002  Collection Abstraction: The request for a data item MUST
    include enough information to properly identify the item to collect,
    but the request shall not be a command to directly execute nor
    directly be applied as arguments to a command.  The purpose of this
    requirement is primarily to reduce the potential attack vectors, but
    has the additional benefit of abstracting the request for collection
    from the collection method, thereby allowing more flexibility in how
    collection is implemented.

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

   OP-004  Attribute-based Query: A query operation SHOULD be based on a
    set of attributes.  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.

   OP-005  Information-based Query with Filtering: The query operation
    MUST support filtering.  Use Case 2.1.3 describes the need for the



Cam-Winget & Lorenzin   Expires November 21, 2015              [Page 11]


Internet-Draft              Abbreviated Title                   May 2015


    data model to support the means for the information to be collected
    through a query mechanism.  Furthermore, the query operation
    requires filtering capabilities to allow for only a subset of
    information to be retrieved.  The query operation MAY be a
    synchronous request or asynchronous request.

   OP-006  Data Model Scalability: The operation resulting from a query
    operation MUST be able to handle the return and receipt of large
    amounts of data.  Use Cases 2.1.4 and 2.1.5 describes the need for
    the data model to support scalability.  For example, the query
    operation may result in a very large set of attributes, as well as a
    large set of targets.

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

2.6.  Requirements for Transport Protocols

   The requirements for transport protocols include:

   T-001  Transport Variability: Different transports MUST be supported
    to address different deployment and time constraints.  Supporting
    transports MAY be at the data link layer, network, transport, or
    application layers.

   T-002  Data Integrity: Transport protocols MUST be able to ensure
    data integrity.

   T-003  Data Confidentiality: Transport protocols MUST be able to
    support data confidentiality.  Transport protocols SHOULD ensure
    data protection for data in transit by encryption to provide
    confidentiality, integrity, and robustness against protocol-based
    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.






Cam-Winget & Lorenzin   Expires November 21, 2015              [Page 12]


Internet-Draft              Abbreviated Title                   May 2015


   T-005  Transport Reliability: Transport protocols MUST provide
    reliable delivery of data.  This includes the ability to perform
    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

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

4.  IANA Considerations

   This memo includes no request to IANA.

5.  Security Considerations

   This document defines the requirements for SACM.  As such, it is
   expected that several data models, protocols and transports may be
   defined or reused from already existing standards.  This section will
   highlight security considerations that may apply to SACM based on the
   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,
   protocols and transport must consider authorization based on consumer
   function and privileges, to only allow authorized consumers and
   providers to access specific information being requested or
   published.

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

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




Cam-Winget & Lorenzin   Expires November 21, 2015              [Page 13]


Internet-Draft              Abbreviated Title                   May 2015


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

   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 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,
   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 received from the provider may have
   been communicated through an undetermined network communications
   system.  That is, the posture information may have traversed through
   many devices before reaching the requestor.  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.




Cam-Winget & Lorenzin   Expires November 21, 2015              [Page 14]


Internet-Draft              Abbreviated Title                   May 2015


   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.  Change Log

6.1.  -05 to -06

   Updated G-005 to clarify the MUST to allow non-standard extensions,
   SHOULD avoid collisions and ensure interoperability.

   Cleaned up and clarified IM-003, DM-001.

   Cleaned up some of the OP-XXX and ARCH-XXX per Jim Schaad's comments.

   Updated some of the text around Editor notes and removed all 'Editor
   Note' comments

7.  References

7.1.  Normative References

   [I-D.ietf-sacm-terminology]
              Waltermire, D., Montville, A., Harrington, D., Cam-Winget,
              N., Lu, J., Ford, B., and M. Kaeo, "Terminology for
              Security Assessment", draft-ietf-sacm-terminology-06 (work
              in progress), February 2015.



Cam-Winget & Lorenzin   Expires November 21, 2015              [Page 15]


Internet-Draft              Abbreviated Title                   May 2015


   [I-D.ietf-sacm-use-cases]
              Waltermire, D. and D. Harrington, "Endpoint Security
              Posture Assessment - Enterprise Use Cases", draft-ietf-
              sacm-use-cases-09 (work in progress), March 2015.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              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.

7.2.  Informative References

   [RFC3444]  Pras, A. and J. Schoenwaelder, "On the Difference between
              Information Models and Data Models", RFC 3444, January
              2003.

Authors' Addresses

   Nancy Cam-Winget
   Cisco Systems
   3550 Cisco Way
   San Jose, CA  95134
   US

   Email: ncamwing@cisco.com


   Lisa Lorenzin
   Pulse Secure
   2700 Zanker Rd., Suite 200
   San Jose, CA  95134
   US

   Email: llorenzin@pulsesecure.net















Cam-Winget & Lorenzin   Expires November 21, 2015              [Page 16]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/