Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 8412

Proposed STD
Pages: 101
Top     in Index     Prev     Next
in Group Index     Prev in Group     No Next: Highest Number in Group     Group: SACM

Software Inventory Message and Attributes (SWIMA) for PA-TNC

Part 1 of 6, p. 1 to 12
None       Next Section

 


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                        C. Schmidt
Request for Comments: 8412                                     D. Haynes
Category: Standards Track                                      C. Coffin
ISSN: 2070-1721                                    The MITRE Corporation
                                                           D. Waltermire
                          National Institute of Standards and Technology
                                                     J. Fitzgerald-McKay
                                  United States National Security Agency
                                                               July 2018


      Software Inventory Message and Attributes (SWIMA) for PA-TNC

Abstract

   This document extends "PA-TNC: A Posture Attribute (PA) Protocol
   Compatible with Trusted Network Connect (TNC)" (RFC 5792) by
   providing specific attributes and message exchanges to allow
   endpoints to report their installed software inventory information to
   a NEA Server, as defined in "Network Endpoint Assessment (NEA):
   Overview and Requirements" (RFC 5209).

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   https://www.rfc-editor.org/info/rfc8412.

Top      ToC       Page 2 
Copyright Notice

   Copyright (c) 2018 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
   (https://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.

Table of Contents

   1. Introduction ....................................................4
      1.1. Network Endpoint Assessment (NEA) ..........................6
      1.2. Conventions Used in This Document ..........................7
      1.3. Definitions ................................................7
   2. Background ......................................................8
      2.1. Supported Use Cases ........................................8
           2.1.1. Use Software Inventory as an Access Control Factor ..8
           2.1.2. Central Stores of Up-to-Date Endpoint
                  Software Inventory Data .............................9
           2.1.3. PA-TNC Use Cases ....................................9
      2.2. Use Cases That Are Not Supported ...........................9
      2.3. SWIMA Requirements ........................................10
      2.4. Non-SWIMA Requirements ....................................11
      2.5. Assumptions ...............................................12
      2.6. Assumptions Not Made ......................................12
   3. System Requirements ............................................12
      3.1. Data Sources ..............................................13
      3.2. Data Models ...............................................14
      3.3. Basic Attribute Exchange ..................................16
      3.4. Core Software-Reporting Information .......................17
           3.4.1. Software Identifiers ...............................17
           3.4.2. Data Model Type ....................................19
           3.4.3. Record Identifiers .................................19
           3.4.4. Software Locators ..................................20
           3.4.5. Source Identifiers .................................21
           3.4.6. Using Software and Record Identifiers in
                  SWIMA Attributes ...................................22
      3.5. Targeted Requests .........................................22
      3.6. Monitoring Changes in an Endpoint's Software
           Inventory Evidence Collection .............................23

Top      ToC       Page 3 
      3.7. Reporting Change Events ...................................26
           3.7.1. Event Identifiers ..................................27
           3.7.2. Core Event-Tracking Information ....................28
           3.7.3. Updating Inventory Knowledge Based on Events .......29
           3.7.4. Using Event Records in SWIMA Attributes ............29
           3.7.5. Partial and Complete Lists of Event Records
                  in SWIMA Attributes ................................30
           3.7.6. Synchronizing Event Identifiers and Epochs .........32
      3.8. Subscriptions .............................................33
           3.8.1. Establishing Subscriptions .........................34
           3.8.2. Managing Subscriptions .............................35
           3.8.3. Terminating Subscriptions ..........................36
           3.8.4. Subscription Status ................................36
           3.8.5. Fulfilling Subscriptions ...........................37
                  3.8.5.1. Subscriptions That Report Inventories .....38
                  3.8.5.2. Subscriptions That Report Events ..........38
                  3.8.5.3. Targeted Subscriptions ....................40
                  3.8.5.4. No Subscription Consolidation .............40
                  3.8.5.5. Delayed Subscription Fulfillment ..........41
      3.9. Error Handling ............................................41
   4. Protocol .......................................................43
      4.1. Direct Response to a SWIMA Request ........................44
      4.2. Subscription-Based Response ...............................45
      4.3. Required Exchanges ........................................45
   5. Software Inventory Messages and Attributes .....................46
      5.1. PA Subtype (aka PA-TNC Component Type) ....................46
      5.2. SWIMA Attribute Overview ..................................46
      5.3. Message Diagram Syntax ....................................48
      5.4. Normalization of Text Encoding ............................49
      5.5. Request IDs ...............................................49
      5.6. SWIMA Request .............................................50
      5.7. Software Identifier Inventory .............................54
      5.8. Software Identifier Events ................................58
      5.9. Software Inventory ........................................64
      5.10. Software Events ..........................................67
      5.11. Subscription Status Request ..............................72
      5.12. Subscription Status Response .............................73
      5.13. Source Metadata Request ..................................75
      5.14. Source Metadata Response .................................76
      5.15. PA-TNC Error as Used by SWIMA ............................78
           5.15.1. SWIMA_ERROR, SWIMA_SUBSCRIPTION_DENIED_ERROR, and
                   SWIMA_SUBSCRIPTION_ID_REUSE_ERROR Information .....81
           5.15.2. SWIMA_RESPONSE_TOO_LARGE_ERROR Information ........83
           5.15.3. SWIMA_SUBSCRIPTION_FULFILLMENT_ERROR Information ..85

Top      ToC       Page 4 
   6. Supported Data Models ..........................................87
      6.1. ISO 2015 SWID Tags Using XML ..............................87
           6.1.1. Guidance on Normalizing Source Data to ISO 2015
                  SWID Tags Using XML ................................87
           6.1.2. Guidance on Creation of Software Identifiers from
                  ISO 2015 SWID Tags .................................88
      6.2. ISO 2009 SWID Tags Using XML ..............................88
           6.2.1. Guidance on Normalizing Source Data to ISO 2009
                  SWID Tags Using XML ................................88
           6.2.2. Guidance on Creation of Software Identifiers from
                  ISO 2009 SWID Tags .................................89
   7. Relationship to Other Specifications ...........................89
   8. Security Considerations ........................................90
      8.1. Evidentiary Value of Software Inventory Evidence Records ..90
      8.2. Sensitivity of Collected Records ..........................91
      8.3. Integrity of Endpoint Records .............................92
      8.4. SWIMA-PC Access Permissions ...............................92
      8.5. Sanitization of Record Fields .............................93
      8.6. PA-TNC Security Threats ...................................93
   9. Privacy Considerations .........................................93
   10. IANA Considerations ...........................................94
      10.1. Guidance for the Designated Experts ......................94
      10.2. PA Subtypes ..............................................95
      10.3. PA-TNC Attribute Types ...................................96
      10.4. PA-TNC Error Codes .......................................97
      10.5. Software Data Model Types ................................97
   11. References ....................................................98
      11.1. Normative References .....................................98
      11.2. Informative References ...................................99
   Authors' Addresses ...............................................101

1.  Introduction

   Knowing the list of software installed on endpoints is useful to
   understand and maintain the security state of a network.  For
   example, if an enterprise policy requires the presence of certain
   software and prohibits the presence of other software, reported
   software installation information can be used to indicate compliance
   and non-compliance with these requirements.  Endpoint software
   installation inventory lists (hereinafter "software inventories") can
   further be used to determine an endpoint's exposure to attack based
   on comparison of vulnerability or threat alerts against identified
   software's patch-level data.  These are some of the highly useful
   management use cases supported by software inventory data.

Top      ToC       Page 5 
   Software Inventory Message and Attributes (SWIMA) for PA-TNC (see
   "PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted
   Network Connect (TNC)" [RFC5792]) provides a standardized method for
   exchanging software inventory data that includes a unique Software
   Identifier associated with a specific version of a software product.
   SWIMA can also convey metadata about software products beyond this
   identifier.  SWIMA enables software identification, installation, and
   characterization information to be transported to a central server
   from any endpoint that supports this specification.  Such information
   can come from multiple sources, including tag files (such as ISO
   Software Identification (SWID) tags [SWID15]), reports from
   third-party inventory tools, output from package managers, and other
   sources.  SWIMA does not standardize how software is detected,
   instead relying on a set of "data sources" to provide information
   about installed software.  SWIMA provides a flexible transport
   capable of conveying this information, regardless of how it is
   expressed.

   This specification is designed to only report software that is
   installed on a target endpoint.  In particular, it does not monitor
   or report information about what software is running on the endpoint.
   Likewise, it is not intended to report individual files, libraries,
   installation packages, or similar artifacts.  While all of this
   information has its uses, this information requires different
   metadata and monitoring methods.  As a result, this specification
   focuses solely on software inventory information, leaving the
   reporting of other classes of endpoint information to other
   specifications.

   Note that while this specification focuses on "software inventory",
   the mechanisms it describes could also be used to convey information
   about firmware and operating systems associated with an endpoint.
   The focus on software throughout this document should not be read as
   excluding the use of SWIMA for these other purposes.

   This specification defines a new set of PA-TNC attributes; these
   attributes are used to communicate requests for software inventory
   information and software installation change events.  The exchange of
   these messages allows software inventory information to be sent to a
   Network Endpoint Assessment (NEA) Server, which can make this
   information available to other applications.

   Part of the motivation for the development of SWIMA was to support
   the IETF's Security Automation and Continuous Monitoring (SACM)
   architecture.  More details about SWIMA's role in SACM appear in
   Section 7.  However, SWIMA has no dependencies on any part of SACM
   and is usable wherever the NEA architecture is employed.

Top      ToC       Page 6 
1.1.  Network Endpoint Assessment (NEA)

   SWIMA defines extensions to the PA-TNC specification [RFC5792]; these
   extensions are part of the NEA architecture.  The NEA specifications
   define an open solution architecture that enables network operators
   to collect and utilize information about endpoint configuration and
   state.  This information can be used to enforce policies and monitor
   endpoint health, among many other activities.  Information about the
   software present on an endpoint is an important consideration for
   such activities.  The new PA-TNC attributes defined in this document
   are used to communicate software inventory evidence, collected from a
   range of possible sources, from the Posture Collector on the endpoint
   to the Posture Validator on a NEA Server using the PA-TNC interface,
   as shown in Figure 1 below.

       +-------------+                          +--------------+
       |  Posture    |   <--------PA-------->   |   Posture    |
       |  Collectors |                          |   Validators |
       |  (1 .. N)   |                          |   (1 .. N)   |
       +-------------+                          +--------------+
             |                                         |
             |                                         |
             |                                         |
       +-------------+                          +--------------+
       |   Posture   |                          |   Posture    |
       |   Broker    |   <--------PB-------->   |   Broker     |
       |   Client    |                          |   Server     |
       +-------------+                          +--------------+
             |                                         |
             |                                         |
       +-------------+                          +--------------+
       |   Posture   |                          |   Posture    |
       |   Transport |   <--------PT-------->   |   Transport  |
       |   Client    |                          |   Server     |
       |   (1 .. N)  |                          |   (1 .. N)   |
       +-------------+                          +--------------+
          NEA CLIENT                               NEA SERVER

                       Figure 1: NEA Reference Model

   To better understand this specification, the reader should review the
   NEA reference architecture as described in "Network Endpoint
   Assessment (NEA): Overview and Requirements" [RFC5209].  The reader
   should also review the PA-TNC interfaces as defined in RFC 5792
   [RFC5792].

Top      ToC       Page 7 
   This document is based on standards published by the Trusted
   Computing Group's Trusted Network Communications (TNC) workgroup (see
   <https://trustedcomputinggroup.org/>).  The TNC and NEA architectures
   are interoperable, and many components are equivalent.

1.2.  Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

1.3.  Definitions

   This section defines terms that have special meaning within this
   document.

   o  SWIMA-PC - A NEA Posture Collector (PC) that interprets SWIMA
      attributes sent by SWIMA-PVs and that conforms to this
      specification.  Note that such a Posture Collector might also
      support other PA-TNC exchanges beyond those defined herein.

   o  SWIMA-PV - A NEA Posture Validator (PV) that interprets SWIMA
      attributes sent by SWIMA-PCs and that conforms to this
      specification.  Note that such a Posture Validator might also
      support other PA-TNC exchanges beyond those defined herein.

   o  SWIMA Attribute - A PA-TNC attribute (as defined in RFC 5792
      [RFC5792]) whose structure and behavior is defined in this
      specification.

   o  Endpoint's Software Inventory Evidence Collection - The set of
      information regarding the set of software installed on an
      endpoint.  An endpoint's Software Inventory Evidence Collection
      might include information created by or derived from multiple
      sources, including but not limited to SWID tag files deposited on
      the filesystem during software installation, information generated
      by software discovery tools, and information dynamically generated
      by a software or package management system on an endpoint.

   o  Software Inventory Evidence Record - Part of the endpoint's
      Software Inventory Evidence Collection (which is composed of
      "records").  Each record corresponds to one installed instance of
      a particular software product as reported by some data source.  It
      is possible for a single installed instance to have multiple

Top      ToC       Page 8 
      Software Inventory Evidence Records in an endpoint's Software
      Inventory Evidence Collection -- this can happen if multiple
      sources all report the same software installation instance.

   o  Software Identifier - A string associated with a specific version
      of a specific software product.  These identifiers are derived
      from the records used to describe software products.  SWIMA does
      not limit the formats of these records, nor does it enforce that
      all data sources populate records using the same format.  As such,
      while each Software Identifier uniquely identifies a specific
      software product, the same software product might be associated
      with multiple Software Identifiers reflecting differences between
      different data sources and supported record formats.

2.  Background

2.1.  Supported Use Cases

   This section describes the use cases supported by this specification.
   The primary use of exchanging software inventory information over the
   PA-TNC interface is to enable a challenger (e.g., a NEA Server) to
   obtain inventory evidence about some system in a way that conforms to
   NEA procedures.  Collected software information can support a range
   of security activities, including determining whether an endpoint is
   permitted to connect to the enterprise, determining which endpoints
   contain software that requires patching, and similar activities.

2.1.1.  Use Software Inventory as an Access Control Factor

   Some enterprises might define security policies that require
   connected endpoints to have certain pieces of security software
   installed.  By contrast, some security policies might prevent access
   to resources by endpoints that have certain prohibited pieces of
   software installed, since such applications might pose a security
   risk.  To support such policies, the NEA Server needs to collect
   software inventory evidence from a target endpoint that is seeking to
   initiate or continue connectivity to the enterprise resource.

   Based on this specification, the SWIMA-PC can provide a complete or
   partial inventory to the SWIMA-PV as required to determine policy
   compliance.  The SWIMA-PV can then use this as evidence of compliance
   or non-compliance to make a policy-based access decision.

Top      ToC       Page 9 
2.1.2.  Central Stores of Up-to-Date Endpoint Software Inventory Data

   Many tools use information about an endpoint's software inventory to
   monitor and enforce the security of a network.  For example, a
   software-patching tool needs to determine if there is out-of-date
   software installed that needs to be updated.  A vulnerability
   management tool needs to identify endpoints with known vulnerable
   software installed (patched or otherwise) to gauge an endpoint's
   relative exposure to attack.  A license management tool needs to
   verify that all installed software within the enterprise is accounted
   for.  A central repository representing an up-to-date understanding
   of each endpoint's software inventory facilitates these activities.
   Multiple tools can share such a repository, ensuring that software
   inventory information is collected more frequently and efficiently,
   leading to a more complete and consistent understanding of installed
   software state as compared to each tool collecting the same inventory
   information from endpoints individually.

   This specification supports these activities through a number of
   mechanisms.  As noted above, a SWIMA-PC can provide a complete list
   of software present in an endpoint's Software Inventory Evidence
   Collection to the SWIMA-PV, which can then pass this information on
   to a central repository, such as a Configuration Management Database
   (CMDB) or similar application.  In addition, SWIMA-PCs are required
   to be able to monitor for changes to an endpoint's Software Inventory
   Evidence Collection in near real time and can be requested to
   immediately push reports of detected changes to the SWIMA-PV.  Thus,
   any central repository fed by a SWIMA-PV receiving inventory
   information can be updated quickly after a change occurs.  Keeping a
   central repository synchronized with current software inventory
   information in this way allows tools to make efficient decisions
   based on up-to-date, consistent information.

2.1.3.  PA-TNC Use Cases

   SWIMA is intended to operate over the PA-TNC interface and, as such,
   is intended to meet the use cases set out in the PA-TNC
   specification.

2.2.  Use Cases That Are Not Supported

   Some use cases not covered by this specification include:

   o  Addressing how the endpoint's Software Inventory Evidence
      Collection is populated.  In particular, NEA components are not
      expected to perform software discovery activities beyond compiling
      information in an endpoint's Software Inventory Evidence
      Collection.  This collection might come from multiple sources on

Top      ToC       Page 10 
      the endpoint (e.g., information generated dynamically by package
      management tools or discovery tools, as well as SWID tag files
      discovered on the filesystem).  While an enterprise might make use
      of software discovery capabilities to identify installed software,
      such capabilities are outside the scope of this specification.

   o  Converting inventory information expressed in a proprietary format
      into formats used in the attributes described in this
      specification.  Instead, this specification focuses exclusively on
      defining interfaces for the transportation of software
      information, expecting that reporting tools will converge around
      some set of standardized formats for this information.

   o  Mechanisms for a Posture Validator to request a specific list of
      software information based on arbitrary software properties.  For
      example, requesting only information about software from a
      particular vendor is not supported.  After the endpoint's Software
      Inventory Evidence Collection has been copied to some central
      location, such as the CMDB, processes there can perform queries
      based on any criteria present in the collected information, but
      this specification does not address using such queries to
      constrain the initial collection of this information from the
      endpoint.

   o  Use of properties of certain sources of software information that
      might facilitate local tests (i.e., on the endpoint) of endpoint
      state.  For example, the optional package_footprint field of an
      ISO SWID tag can contain a list of files and hash values
      associated with the software indicated by the tag.  Tools on the
      endpoint can use the values in this field to test for the presence
      of the indicated files.  Successful evaluation of such tests leads
      to greater assurance that the indicated software is present on the
      endpoint.  Currently, most SWID tag creators do not provide values
      for tag fields that support local testing.  For this reason, the
      added complexity of supporting endpoint testing using these fields
      is out of scope for this specification, but this topic may be
      considered in a future version.

2.3.  SWIMA Requirements

   Below are the requirements that SWIMA must meet in order to
   successfully play its role in the NEA architecture.

   Efficient:  The NEA architecture enables delay of network access
      until the endpoint is determined not to pose a security threat to
      the network, based on its asserted integrity information.  To
      minimize user frustration, SWIMA ought to minimize overhead delays
      and make PA-TNC communications as rapid and efficient as possible.

Top      ToC       Page 11 
   Scalable:  SWIMA needs to be usable in enterprises that contain tens
      of thousands of endpoints or more.  As such, it needs to allow
      security tools to make decisions based on up-to-date information
      about an endpoint's software inventory without creating an
      excessive burden on the enterprise's network.

   Support precise and complete historical reporting:  This
      specification outlines capabilities that support real-time
      understanding of the state of endpoints in a network in a way that
      can be used by other tools.  One means of facilitating such an
      outcome is for a CMDB to be able to contain information about all
      endpoints connected to the enterprise for all points in time
      between the endpoint's first connection and the present.  In such
      a scenario, it is necessary that any SWIMA-PC be able to report
      any changes to its Software Inventory Evidence Collection in near
      real time while connected and, upon reconnection to the
      enterprise, be able to update the NEA Server (and, through it, the
      CMDB) with regard to the state of its Software Inventory Evidence
      Collection throughout the entire interval when it was not
      connected.

2.4.  Non-SWIMA Requirements

   There are certain capabilities that users of SWIMA might require but
   that are beyond the scope of SWIMA itself and need to be addressed by
   other standards.

   Confidentiality:  SWIMA does not define a mechanism for
      confidentiality, nor is confidentiality automatically provided by
      using the PA-TNC interface.  In the NEA architecture,
      confidentiality is generally provided by the underlying transport
      protocols, such as the PT binding to TLS [RFC6876] or PT-EAP
      (Posture Transport for Tunneled Extensible Authentication Protocol
      (EAP) Methods) [RFC7171]; see Section 7 for more information on
      related standards.  The information conveyed by SWIMA is often
      sensitive in nature for both security (Section 8) and privacy
      (Section 9) reasons.  Those who implement SWIMA need to ensure
      that appropriate NEA transport mechanisms are employed to meet
      confidentiality requirements.

Top      ToC       Page 12 
2.5.  Assumptions

   The Posture Broker Client and Posture Broker Server are assumed to
   provide reliable delivery for PA-TNC messages and attributes sent
   between the SWIMA-PCs and the SWIMA-PVs.  "Reliable delivery" means
   that either a message is delivered or the sender is made aware of the
   delivery failure.  In the event that reliable delivery cannot be
   provided, some SWIMA features, primarily subscriptions, might not
   behave as expected.

2.6.  Assumptions Not Made

   This specification explicitly does not assume that software inventory
   information exchanges reflect the software installation state of the
   endpoint.  This specification does not attempt to detect when the
   endpoint is providing false information, either through malice or
   error, but instead focuses on correctly and reliably providing the
   reported Software Inventory Evidence Collection to the NEA Server.
   Tools that employ the SWIMA standard can include methods to help
   verify the accuracy of reports, but how those tools do so is beyond
   the scope of this specification.

   Similarly, this specification makes no assumption about the
   completeness of the Software Inventory Evidence Collection's coverage
   of the total set of software installed on the endpoint.  It is
   possible, and even likely, that some installed software is not
   represented by a record in an endpoint's Software Inventory Evidence
   Collection.  Instead, SWIMA ensures that what does get reported is
   reported consistently and that the software products that are
   reported can be reliably tracked.

   See Section 8 for more on this security consideration.



(page 12 continued on part 2)

Next Section