RFC 8412
Software Inventory Message and Attributes (SWIMA) for PA-TNC
Pages: 101
Proposed Standard
Proposed Standard
Part 1 of 6 – Pages 1 to 12
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-TNCAbstract
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.
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
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
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 ...............................................1011. 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.
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.
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].
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
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.
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
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.
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.
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)