Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8412

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

Pages: 101
Proposed Standard
Part 1 of 6 – Pages 1 to 12
None   None   Next

Top   ToC   RFC8412 - 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   RFC8412 - 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   RFC8412 - 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   RFC8412 - 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   RFC8412 - 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   RFC8412 - 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   RFC8412 - 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   RFC8412 - 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   RFC8412 - 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   RFC8412 - 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   RFC8412 - 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   RFC8412 - 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