| SACM Working Group | S. Banghart |
| Internet-Draft | D. Waltermire |
| Intended status: Informational | National Institute of Standards and Technology |
| Expires: September 27, 2019 | March 26, 2019 |
Definition of the ROLIE Software Descriptor Extension
draft-ietf-sacm-rolie-softwaredescriptor-05
This document uses the "information-type" extension point as defined in the Resource-Oriented Lightweight Information Exchange (ROLIE) [RFC8322] Section 7.1.2 to better support Software Record and Software Inventory use cases. This specification registers a new ROLIE information-type, "software-descriptor", that allows for the categorization of information relevant to software description activities and formats. In particular, the usage of the ISO 19770-2:2015 (SWID Tag) and the Concise SWID (COSWID) formats in ROLIE are standardized. Additionally, this document discusses requirements and usage of other ROLIE elements in order to best syndicate software description information.
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 https://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 September 27, 2019.
Copyright (c) 2019 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.
This document defines an extension to the Resource-Oriented Lightweight Information Exchange (ROLIE) [RFC8322] to support the publication of software descriptor information. Software descriptor information is information that characterizes static software components, packages, and installers; including identifying, versioning, software creation and publication, and file artifact information.
Software descriptor information provides data about what might be installed, but doesn't describe a specific software installation's configuration or execution. This static approach to software description is a smaller state space that covers the majority of current use cases for software inventory and record keeping.
Some possible use cases for software descriptor information ROLIE Feeds include:
This document supports these use cases by describing the content requirements for Feeds and Entries of software descriptor information that are to be published to or retrieved from a ROLIE repository.
The key words "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT," "SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
Several places in this document refer to the "information-type" of a Resource (Entry or Feed). This refers to the "value" attribute of an "atom:category" element whose scheme is "urn:ietf:params:rolie:category:information-type". For an Entry, this value can be inherited from it's containing Feed as per [RFC8322].
In order to effectively protect and secure an endpoint, it is vital to know what the software load of that endpoint is. This software load, the combination of software, patches and installers on a device, represents the majority of the endpoint's attack surface. Unfortunately, without a reliable and secure package manager, or otherwise a secured and managed operating system, tracking what software is installed on an endpoint is currently not feasible without undue effort. Even attempting to whitelist software is difficult without a way of identifying software and its editions, versions and hotfixes.
Software descriptor information, such as that standardized in the ISO 19770-2:2015 SWID Tag format, or expressed in proprietary enterprise databases, attempts to provide as much data about this software as possible.
Once this information is expressed, it needs to be stored and shared to internal and external parties. ROLIE provides a mechanism to handle this sharing in an automation-friendly way.
When an "atom:category" element has a "scheme" attribute equal to "urn:ietf:params:rolie:category:information-type", the "value" attribute defines the information type of the associated resource. A new information type value: "software-descriptor", is described in this section, and registered in Section 8.1.
The "software-descriptor" information type represents any static information that describes a piece of software. This document uses the definition of software provided by [RFC4949]. Note that as per this definition, this information type pertains to static software, that is, code on the disc. The "software-descriptor" information type is intended to provide a category for information that does one or more of the following:
Provided below is a non-exhaustive list of information that may be considered to be of a software-descriptor information type.
Note again that this list is not exhaustive, any information that in is the abstract realm of an incident should be classified under this information-type.
It is important to note that software descriptor information is static for a given piece of software. That is, the information expressed is the data that doesn't change from the publication of the software to its final install. Information about the current status (e.g. install location, memory usage, CPU usage, launch parameters, job progress, etc.), is out of scope of this information type.
This document registers new valid rolie:property names as follows:
This property provides an exposure point for the plain text name of the software being described. Naming of software is not a well standardized process, and software names can change between product versions or editions. As such, care should be taken that this value is set as consistently as possible by generating it directly from an attached software descriptor resource.
This property provides an exposure point for the version of the software being described. This value should be generated or taken from the software descriptor linked to by the entry. This helps avoid, but does not prevent, inconsistent versioning schemes being shared.
This property provides an exposure point for a plain text name of the creator of the software being described. This is in many cases an organization or company, but certainly could be a single person. Most software descriptor formats include this information, and where possible, this property should be set equal to that value.
This section defines usage guidance and additional requirements related to data formats above and beyond those specified in [RFC8322]. The following formats are expected to be commonly used to express software descriptor information. For this reason, this document specifies additional requirements to ensure interoperability.
ISO/IEC 19770-2:2015 defines a software record data format referred to as a "SWID Tag". It provides several tag types:
For a more complete overview as well as normative requirements, refer to ISO/IEC 19770-2:2015 [SWID].
For additional requirements and guidance around creation of SWID Tags, consult NIST Internal Report 8060 [NISTIR8060].
For an Entry to be considered as a "SWID Tag Entry", it MUST fulfill the following conditions:
A "SWID Tag Entry" MUST conform to the following requirements:
The Concise SWID (COSWID) format is an alternative representation of the SWID Tag format using a Concise Binary Object Representation (CBOR) encoding. This provides the format with a reduced size that is more suitable for constrained devices. It provides the same features and attributes as are specified in ISO 19770-2:2015, plus:
For more information and the complete specification, refer to the COSWID internet draft [I-D.ietf-sacm-coswid].
For an Entry to be considered as a "COSWID Tag Entry", it MUST fulfill the following conditions:
A "COSWID Tag Entry" MUST conform to the following requirements:
This section defines additional link relationships that implementations MUST support. These relationships are not registered in the Link Relation IANA table as their use case is too narrow. Each relationship is named and described.
These relations come in related pairs. The first of each pair is expected to be more common, as they can be determined at the time that the Entry is created. The second of each pair will often need to be added retroactively to an Entry.
| Name | Description |
|---|---|
| ancestor | Links to a software descriptor resource that defines an ancestor of the software being described by this Entry. This is usually a previous version of the software. |
| descendent | Links to a software descriptor resource that defines an descendent of the software being described by this Entry. This is usually a more recent version or edition of the software. |
| patches | Links to a software descriptor resource that defines the software being patched by this software |
| patchedby | Links to a software descriptor resource that defines the patch or update itself that can be or has been applied to this software. |
| requires | Links to a software descriptor resource that defines a piece of software required for this software to function properly, i.e., a dependency. |
| requiredBy | Links to a software descriptor resource that defines a piece of software that requires this software to function properly. |
| installs | Links to a software descriptor resource that defines the software that is installed by this software. |
| installedBy | Links to a software descriptor resource that defines the software package that installs this software. |
| patchesVulnerability | Links to a vulnerability that this software update fixes. Used for software descriptors that are describing software patches or updates. |
| hasVulnerability | Links to a vulnerability description object that details a vulnerability that this software has. |
IANA has added an entry to the "ROLIE Security Resource Information Type Sub-Registry" registry located at <https://www.iana.org/assignments/rolie/category/information-type> .
The entry is as follows:
IANA has added an entry to the "ROLIE URN Parameters" registry located in <https://www.iana.org/assignments/rolie/>.
The entry is as follows:
IANA has added an entry to the "ROLIE URN Parameters" registry located in <https://www.iana.org/assignments/rolie/>.
The entry is as follows:
IANA has added an entry to the "ROLIE URN Parameters" registry located in <https://www.iana.org/assignments/rolie/>.
The entry is as follows:
Use of this extension implies dealing with the security implications of both ROLIE and of software descriptors in general. As with any data, care should be taken to verify the trustworthiness and veracity of the descriptor information to the fullest extent possible.
Ideally, software descriptors should have been signed by the software manufacturer, or signed by whichever agent processed the source code. Software descriptor documents from these sources are more likely to be accurate than those generated by scraping installed software.
These "authoritative" sources of software descriptor content should consider additional security for their ROLIE repository beyond the typical recommendations, as the central importance of the repository is likely to make it a target.
Version information is often represented differently across manufacturers and even across product releases. If using software version information for low fault tolerance comparisons and searches, care should be taken that the correct version scheme is being utilized.
This document does not require any schema extensions.
Use of this extension in a ROLIE repository will not typically change that repository's operation. As such, the general examples provided by the ROLIE core document would serve as examples. Provided below is a sample software descriptor ROLIE entry:
<?xml version="1.0" encoding="UTF-8"?>
<entry xmlns="http://www.w3.org/2005/Atom"
xmlns:rolie="urn:ietf:params:xml:ns:rolie-1.0">
<id>dd786dba-88e6-440b-9158-b8fae67ef67c</id>
<title>Sample Software Descriptor</title>
<published>2015-08-04T18:13:51.0Z</published>
<updated>2015-08-05T18:13:51.0Z</updated>
<summary>A descriptor for a piece of software published by this
organization. </summary>
<link rel="self" href="http://www.example.org/rolie/SWD/123456"/>
<link rel="feed" href="http://www.example.org/rolie/SWD/"/>
<link rel="requires" href="http://www.example.org/rolie/SWD/78430"/>
<rolie:property name=urn:ietf:params:rolie:property:swd:swname
value="Example Software Name"/>
<category
scheme="urn:ietf:params:rolie:category:information-type"
term="software-descriptor"/>
<rolie:format
ns="http://standards.iso.org/iso/19770/-2/2015/schema.xsd"/>
<content type="application/swid+xml"
src="http://www.example.org/rolie/SWD/123456/data"/>
</entry>