RFC 8412
Software Inventory Message and Attributes (SWIMA) for PA-TNC
Pages: 101
Proposed Standard
Proposed Standard
Part 6 of 6 – Pages 87 to 101
6. Supported Data Models
SWIMA supports an extensible list of data models for representing and transmitting software inventory information. This list of data models appears in the "Software Data Model Types" registry (see Section 10.5). This document provides guidance for an initial set of data models. Other documents might provide guidance on the use of new data models by SWIMA and will be referenced by extensions to the "Software Data Model Types" registry.6.1. ISO 2015 SWID Tags Using XML
The International Organization for Standardization and the International Electrotechnical Commission (ISO/IEC) published the specification governing SWID tag construction and use (ISO/IEC 19770-2:2009) in 2009 [SWID09], with a revised version of the specification (ISO/IEC 19770-2:2015) published in 2015 [SWID15]. Since that time, a growing number of vendors have integrated SWID tags into their software products. SWID tags significantly simplify the task of identifying pieces of software: instead of relying on discovery processes that look for clues as to software presence, such as the presence of particular files or registry keys, vendors can use a readily available list of SWID tags that provides simple and immediate evidence as to the presence of the given piece of software. SWIMA has no reliance on the presence or management of SWID tags on an endpoint as described in the ISO 2015 SWID tag specification. However, as presented in the ISO 2015 SWID tag specification, the data model for describing software provides a robust and comprehensive way of describing software and is adopted here as a means of representing and transmitting software information. It should be emphasized that the use of the ISO SWID tag data model makes no assumption as to whether (1) the source of the recorded information was, in fact, an ISO SWID tag harvested from the endpoint or (2) the information was created using some other source and normalized to the SWID format.6.1.1. Guidance on Normalizing Source Data to ISO 2015 SWID Tags Using XML
Any record associated with this Software Data Model Type MUST conform to [SWID15]. If generating a new ISO 2015 SWID tag, the software generating the tag MUST use a Tag Creator RegID that is associated with the generating software, unless this is impossible, in which case it MUST use the "http://invalid.unavailable" Tag Creator RegID value. (This conforms to conventions for an unknown tag creator in the ISO 2015
SWID tag specification.) Do not use a RegID associated with any other party. In particular, it is incorrect to use a Tag Creator RegID associated with the software being described by the tag, the enterprise that is using the software, or any other entity except that of the party that built the tool that is generating the SWID tag. This reflects the requirement that the Tag Creator RegID identify the party that created the tag. Moreover, any generated tags SHOULD conform to guidance for tag creators as provided in NISTIR 8060 [NIST8060], which provides additional recommendations to increase interoperable use of SWID tags.6.1.2. Guidance on Creation of Software Identifiers from ISO 2015 SWID Tags
A Software Identifier generated from an ISO 2015 SWID tag is expressed as a concatenation of the value of the Tag Creator RegID field and the Unique ID field. Specifically, (1) it MUST be of the form TAG_CREATOR_REGID "_" "_" UNIQUE_ID and (2) it consists of the Tag Creator RegID and the Unique ID from the tag connected with a double underscore (_), without any other connecting character or whitespace.6.2. ISO 2009 SWID Tags Using XML
As noted above, ISO's SWID tag specification provides a useful data model for representation of software information. As of the writing of this specification, while the ISO 2015 specification is considered more comprehensive and addresses some issues with the ISO 2009 specification, 2009-format SWID tags remain far more common in deployments. For this reason, ISO 2009 SWID tags are included in the "Software Data Model Types" registry.6.2.1. Guidance on Normalizing Source Data to ISO 2009 SWID Tags Using XML
Any record associated with this Software Data Model Type MUST conform to [SWID09]. Any such tag SHOULD use a UTF-8 encoding [RFC3629] but MUST NOT alter the existing encoding if doing so would invalidate digital signatures included in the tag. If generating a new ISO 2009 SWID tag, the software generating the tag MUST use a Tag Creator RegID that is associated with the generating software, unless this is impossible, in which case it MUST use "unknown", which indicates that the tag creator is unknown. (This conforms to conventions for an unknown tag creator in the ISO 2009 SWID tag specification.) Do not use a RegID associated with any other party. In particular, it is incorrect to use a Tag Creator RegID associated with the software being described by the tag, the
enterprise that is using the software, or any other entity except that of the party that built the tool that is generating the SWID tag. This reflects the requirement that the Tag Creator RegID identify the party that created the tag.6.2.2. Guidance on Creation of Software Identifiers from ISO 2009 SWID Tags
A Software Identifier generated from an ISO 2009 SWID tag is expressed as a concatenation of the value of the Tag Creator RegID field and the Unique ID field. Specifically, (1) it MUST be of the form TAG_CREATOR_REGID "_" "_" UNIQUE_ID and (2) it consists of the Tag Creator RegID and the Unique ID from the tag connected with a double underscore (_), without any other connecting character or whitespace.7. Relationship to Other Specifications
This specification is expected to participate in a standard NEA architecture. As such, it is expected to be used in conjunction with the other protocols used in a NEA exchange. In particular, SWIMA attributes are conveyed over PB-TNC [RFC5793], which is in turn conveyed over some variant of PT (either PT-TLS [RFC6876] or PT-EAP [RFC7171]). These protocols have an especially important role, as they are responsible for ensuring that attributes defined under this specification are delivered reliably, securely, and to the appropriate party. It is important to note that the Product Information, Numeric Version, and String Version attributes defined in the PA-TNC specification [RFC5792] are also meant to convey information about installed applications and the versions thereof. As such, there is some conceptual overlap between those attributes and the intent of this specification. However, PA-TNC was designed to respond to very specific queries about specific classes of products, while SWIMA is able to convey a broader query, resulting in a more comprehensive set of information regarding an endpoint's installed software. As such, this specification provides important capabilities not present in the PA-TNC specification. The NEA architecture is intended to support a broad range of activities and, as such, might be employed by other specifications. For example, requirement T-001 in the SACM Requirements document [RFC8248] notes that NEA can support data collection from endpoints within the broader SACM architecture. (Other parts of the NEA architecture, which SWIMA uses, meet the other SACM data transport requirements.) In the SACM architecture, a SWIMA-PV corresponds to a "SACM Collector" and a SWIMA-PC corresponds to a "SACM Internal
Collector". In the SACM architecture, SWIMA can support activities relating to software inventory collection. Specifically, SWIMA supports the SACM "Endpoint Posture Attribute Value Collection" use case (Section 2.1.3 in [RFC7632]) by describing a collection mechanism that enables event-driven, scheduled, and ad hoc data collection of software inventory information. SWIMA's flexibility with regard to the format of inventory data records means that it is compatible with virtually any data format that implements SACM's "Define, Publish, Query, and Retrieve Security Automation Data" use case (Section 2.1.1 in [RFC7632]). This is just one example of how SWIMA can support broader security solution standards. Note that while SWIMA can support these SACM use cases, SWIMA has no dependencies on the SACM architecture or any other context in which NEA might reasonably be applied.8. Security Considerations
This section discusses some of the security threats facing SWIMA-PCs and SWIMA-PVs. This section primarily notes potential issues for implementers to consider, although it does contain a handful of normative requirements to address certain security issues. The issues identified below focus on capabilities specific to this document. Implementers are advised to consult other relevant NEA specifications, particularly [RFC5209] (the NEA architecture) and [RFC5792] (PA-TNC), for security issues that are applicable to such components in general.8.1. Evidentiary Value of Software Inventory Evidence Records
The degree to which an endpoint's Software Inventory Evidence Collection accurately reflects the endpoint's actual software load and any changes made to this software load is dependent on the accuracy of the tools used to populate and manage the Software Inventory Evidence Records in this collection. While the SWIMA-PC is required to detect changes to an endpoint's Software Inventory Evidence Collection in near real time, some tools might not be designed to update records in the Software Inventory Evidence Collection in real time. This can result in a collection that is out of sync with actual system state. Moreover, tools might inaccurately characterize software or fail to properly record its removal. Finally, it is likely that there will be software on the endpoint that is not tracked by any source and thus is not reflected in the Software Inventory Evidence Collection. Tools that implement SWIMA ought to be aware of these potential issues and minimize them, but completely eliminating such issues is likely impossible. Users of collected Software Inventory Evidence Records need to understand that the information provided by SWIMA cannot be treated as completely accurate. Nonetheless, having endpoints report this information can
still provide useful insights into the state of the endpoint's software load and can alert administrators and policy tools of situations that require remediation.8.2. Sensitivity of Collected Records
Collected software records can be sensitive in nature. This can include both security sensitivities and privacy sensitivities. Privacy sensitivities are discussed more in Section 9. With regard to security, inventory records represent a wealth of information about the endpoint in question, and for an adversary who does not already have access to the endpoint a collection of the endpoint's inventory records might provide many details that are useful for mounting an attack. A list of the inventory records associated with an endpoint reveals a list of software installed on the endpoint. This list can be very detailed, noting specific versions and even patch levels; an adversary can use this information to identify vulnerable software and design efficacious attacks. The following information might also be gleaned from a collection of software inventory records: o An inventory record might include information about where the product was installed on a given endpoint. This can reveal details about the file organization of that endpoint that an attacker can utilize. o An inventory record might include information about how the software was provided to the endpoint, who in an organization signs off on the package release, and who packaged the product for installation. This information might be used as a starting point for the development of supply chain attacks. o Events affecting inventory records are reported with timestamps indicating when each given event occurred. This can give the attacker an indication of how quickly an organization distributes patches and updates, helping the attacker determine how long an attack window might remain open. Any consolidated software inventory is a potential risk, because such an inventory can provide an adversary an insight into the enterprise's configuration and management process. It is recommended that a centralized software inventory record collection be protected against unauthorized access. Mechanisms to accomplish this can include encrypting the data at rest, ensuring that access to the data is limited only to authorized individuals and processes, and other basic security precautions.
8.3. Integrity of Endpoint Records
SWIMA-PCs maintain records of detected changes to the endpoint's Software Inventory Evidence Collection. These records are used to respond to a SWIMA-PV's request for change events. The SWIMA-PV might use a list of reported events to update its understanding of the endpoint's Software Inventory Evidence Collection without needing to receive a full inventory report from the SWIMA-PC. For this reason, preserving the integrity of the SWIMA-PC's record of events is extremely important. If an attacker modifies the SWIMA-PC's record of changes to the endpoint's Software Inventory Evidence Collection, this might cause the SWIMA-PV's understanding of the endpoint's Software Inventory Evidence Collection to differ from its actual state. The results of such an attack might include leading the SWIMA-PV to believe that (1) absent software was present or, conversely, that present software was absent or (2) patches have been installed even if this is not the case. Such an attack could also cause the SWIMA-PV to be unaware of other changes to Software Inventory Evidence Records. As such, the SWIMA-PC MUST take steps to protect the integrity of its event records. In addition, records of established SWIMA-PV subscriptions also require protection against manipulation or corruption. If an attacker is able to modify or delete records of a SWIMA-PV's established subscription, the SWIMA-PC might fail to correctly fulfill this subscription. The SWIMA-PV would not be aware that its subscription was not being correctly fulfilled unless it received additional information that indicated a discrepancy. For example, the SWIMA-PV might collect a full inventory and realize from this information that certain events had not been correctly reported in accordance with an established subscription. For this reason, the SWIMA-PC MUST protect the integrity of subscription records.8.4. SWIMA-PC Access Permissions
A SWIMA-PC requires sufficient permissions to collect Software Inventory Evidence Records from all of its supported sources, as well as sufficient permissions to interact with the endpoint's Posture Broker Client. With regard to the former, this might require permissions to read the contents of directories throughout the filesystem. Depending on the operating environment and other activities undertaken by a SWIMA-PC (or software that incorporates a SWIMA-PC as one of its capabilities), additional permissions might be required by the SWIMA-PC software. The SWIMA-PC SHOULD NOT be granted permissions beyond what it needs to fulfill its duties.
8.5. Sanitization of Record Fields
Not all sources of software inventory evidence are necessarily tightly controlled. For example, consider a source that gathers .swid files from the endpoint's filesystem. Any party could create a new .swid file that could be collected and turned into a Software Inventory Evidence Record. As a result, it is important that the contents of source information not be automatically trusted. In particular, tools that read source information and the Software Inventory Evidence Records derived therefrom, including SWIMA-PCs, need to be careful to sanitize input to prevent buffer overflow attacks, encoding attacks, and other weaknesses that might be exploited by an adversary who can control the contents of a record.8.6. PA-TNC Security Threats
In addition to the aforementioned considerations, the SWIMA protocol is subject to the same security threats as other PA-TNC transactions; see Section 5.2 of PA-TNC [RFC5792]. These include, but are not limited to, attribute theft, message fabrication, attribute modification, attribute replay, attribute insertion, and denial of service. Implementers are advised to consult the PA-TNC specification to better understand these security issues.9. Privacy Considerations
As noted in Section 8.2, if an adversary can gain an understanding of the software installed on an endpoint, they can utilize this to launch attacks and maintain footholds on this endpoint. For this reason, the NEA Server needs to ensure that adequate safeguards are in place to prevent exposure of collected inventory records. For similar reasons, it is advisable that an endpoint only send records to a NEA Server that is authorized to receive this information and that can be trusted to safeguard this information after collection. In addition, software inventory information can lead to insights about the endpoint's primary user if that user is able to install software. (Note that users might be "able" to install their own software even if they are not "allowed" to do so.) This is especially true on endpoints that support "apps", as individual apps can be closely tied to specific groups or activities. This could conceivably allow inferences about things such as a user's hobbies; the banks and other financial institutions that they use; and information about the user's race, sex, or sexual orientation.
Organizations that collect software inventory information from endpoints ought to make sure the endpoints' users are aware of this collection. In addition, organizations should be aware that a software inventory associated with an individual, such as the inventory of the individual's primary endpoint, could expose sensitive personal information. For this reason, privacy safeguards are necessary for collected inventory information. Such safeguards would require not only protection of the inventory's confidentiality but also appropriate access controls so that only those trained in relevant privacy requirements are able to view the data.10. IANA Considerations
This section extends multiple existing IANA registries. Specifically, it extends the "PA-TNC Attribute Types" and "PA-TNC Error Codes" registries defined in the PA-TNC specification [RFC5792] and the "PA Subtypes" registry defined in the PB-TNC specification [RFC5793] and extended in PA-TNC. This specification only adds values to these registries and does not alter how these registries work or are maintained. Consult the appropriate specifications for details on the operations and maintenance of these registries. This section also defines a new IANA registry for "Software Data Model Types". The structure and requirements for this registry are provided, as well as guidelines for reviewers adjudicating the addition of new entries to this registry.10.1. Guidance for the Designated Experts
For the "Software Data Model Types" registry defined by this specification, new values are added to the registry using the "Specification Required" process defined in RFC 8126 [RFC8126]. This section provides guidance to designated experts so that they may make decisions using a philosophy appropriate for this registry. Designated experts should focus on the following requirements. All values in this IANA registry MUST be documented in a specification that is permanently and publicly available. Values MUST also be useful, not harmful to the Internet, and defined in a manner that is clear and likely to ensure interoperability. Designated experts should encourage vendors to avoid defining similar but incompatible values and instead agree on a single value allocated via IETF standards. However, it is beneficial to document existing practice.
There are several ways to ensure that a specification is permanently and publicly available. It may be published as an RFC. Alternatively, it may be published in another manner that makes it freely available to anyone. However, in this latter case, the vendor MUST supply a copy to IANA and authorize IANA to archive this copy and make it freely available to all, if at some point the document becomes no longer freely available to all through other channels. Sections 10.2, 10.3, and 10.4 define a new PA Subtype, new PA-TNC Attribute Types, and new PA-TNC Error Codes, respectively. Section 10.5 provides guidance to IANA in creating and managing the new "Software Data Model Types" registry defined by this specification.10.2. PA Subtypes
The following is an extension to the list of PA Subtypes provided in Section 7.2 of [RFC5792] and defined in the "PA Subtypes" registry in Section 6.3 of [RFC5793]. See <https://www.iana.org/assignments/ pb-tnc-parameters/>. +-----+---------+------------------+------------------------+ | PEN | Integer | Name | Defining Specification | +-----+---------+------------------+------------------------+ | 0 | 9 | SWIMA Attributes | RFC 8412 | +-----+---------+------------------+------------------------+
10.3. PA-TNC Attribute Types
Section 5.2 of this specification defines several new PA-TNC attributes. The following values have been added to the "PA-TNC Attribute Types" registry defined in the PA-TNC specification. Note that Table 1 in Section 5.2 lists these attributes in both hexadecimal and decimal format. The decimal values given in that table are identical to those provided here. Note also that Table 1 includes an entry for the PA-TNC Error attribute, but the IANA information associated with the PA-TNC Error attribute is already defined in the PA-TNC specification and is not reproduced here. +-----+---------+----------------------------+----------------------+ | PEN | Integer | Name | Defining | | | | | Specification | +-----+---------+----------------------------+----------------------+ | 0 | 13 | SWIMA Request | RFC 8412 | | | | | | | 0 | 14 | Software Identifier | RFC 8412 | | | | Inventory | | | | | | | | 0 | 15 | Software Identifier Events | RFC 8412 | | | | | | | 0 | 16 | Software Inventory | RFC 8412 | | | | | | | 0 | 17 | Software Events | RFC 8412 | | | | | | | 0 | 18 | Subscription Status | RFC 8412 | | | | Request | | | | | | | | 0 | 19 | Subscription Status | RFC 8412 | | | | Response | | | | | | | | 0 | 20 | Source Metadata Request | RFC 8412 | | | | | | | 0 | 21 | Source Metadata Response | RFC 8412 | +-----+---------+----------------------------+----------------------+
10.4. PA-TNC Error Codes
Section 5.15 of this specification defines several new PA-TNC Error Codes. The following values have been added to the "PA-TNC Error Codes" registry defined in the PA-TNC specification. Note that Table 9 in Section 5.15 lists these codes in both hexadecimal and decimal format. The decimal values given in that table are identical to those provided here. +-----+---------+--------------------------------------+---------------+ | PEN | Integer | Name | Defining | | | | | Specification | +-----+---------+--------------------------------------+---------------+ | 0 | 4 | SWIMA_ERROR | RFC 8412 | | | | | | | 0 | 5 | SWIMA_SUBSCRIPTION_DENIED_ERROR | RFC 8412 | | | | | | | 0 | 6 | SWIMA_RESPONSE_TOO_LARGE_ERROR | RFC 8412 | | | | | | | 0 | 7 | SWIMA_SUBSCRIPTION_FULFILLMENT_ERROR | RFC 8412 | | | | | | | 0 | 8 | SWIMA_SUBSCRIPTION_ID_REUSE_ERROR | RFC 8412 | +-----+---------+--------------------------------------+---------------+10.5. Software Data Model Types
For the "Software Data Model Types" registry (<https://www.iana.org/assignments/pa-tnc-parameters/ #software-data-model-types>, each entry should include a human-readable name, an SMI PEN, a decimal integer value between 0 and 2^8-1 (inclusive), and a reference to the specification where the use of this data model is defined. This referenced specification needs to provide both a description of the format used by the data model and the procedures by which Software Identifiers are derived from a record expressed using this data model. Note that a specification that just defines the data model structure and its use is generally not sufficient, as it would likely lack the procedures for constructing a Software Identifier. This is why the table below uses the SWIMA standard for ISO SWID tags as the reference for the use of ISO SWID tags and does not reference the ISO SWID tag specification.
The following entries for this registry are defined in this document. They are the initial entries in the "Software Data Model Types" registry. Additional entries to this registry are added following the "Specification Required" policy defined in [RFC8126], following the guidelines in Section 10.1. +-----+---------+-----------------------------+---------------------+ | PEN | Integer | Name | Defining | | | | | Specification | +-----+---------+-----------------------------+---------------------+ | 0 | 0 | ISO 2015 SWID tags using | RFC 8412 | | | | XML | | | | | | | | 0 | 1 | ISO 2009 SWID tags using | RFC 8412 | | | | XML | | | | | | | | 0 | 192-255 | Reserved for local | N/A | | | | enterprise use | | +-----+---------+-----------------------------+---------------------+11. References
11.1. Normative References
[NIST8060] Waltermire, D., Cheikes, B., Feldman, L., and G. Witte, "Guidelines for the Creation of Interoperable Software Identification (SWID) Tags", DOI 10.6028/NIST.IR.8060, April 2016, <https://nvlpubs.nist.gov/nistpubs/ir/2016/ NIST.IR.8060.pdf>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <https://www.rfc-editor.org/info/rfc3339>. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/info/rfc3629>. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, <https://www.rfc-editor.org/info/rfc5198>. [RFC5792] Sangster, P. and K. Narayan, "PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC)", RFC 5792, DOI 10.17487/RFC5792, March 2010, <https://www.rfc-editor.org/info/rfc5792>. [RFC8089] Kerwin, M., "The "file" URI Scheme", RFC 8089, DOI 10.17487/RFC8089, February 2017, <https://www.rfc-editor.org/info/rfc8089>. [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. [SWID09] The International Organization for Standardization/ International Electrotechnical Commission, "Information technology - Software asset management - Part 2: Software identification tag", ISO/IEC 19770-2:2009, November 2009, <https://www.iso.org/standard/53670.html>. [SWID15] The International Organization for Standardization/ International Electrotechnical Commission, "Information technology - Software asset management - Part 2: Software identification tag", ISO/IEC 19770-2:2015, October 2015, <https://www.iso.org/standard/65666.html>.11.2. Informative References
[RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. Tardo, "Network Endpoint Assessment (NEA): Overview and Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008, <https://www.rfc-editor.org/info/rfc5209>. [RFC5793] Sahita, R., Hanna, S., Hurst, R., and K. Narayan, "PB-TNC: A Posture Broker (PB) Protocol Compatible with Trusted Network Connect (TNC)", RFC 5793, DOI 10.17487/RFC5793, March 2010, <https://www.rfc-editor.org/info/rfc5793>.
[RFC6876] Sangster, P., Cam-Winget, N., and J. Salowey, "A Posture Transport Protocol over TLS (PT-TLS)", RFC 6876, DOI 10.17487/RFC6876, February 2013, <https://www.rfc-editor.org/info/rfc6876>. [RFC7171] Cam-Winget, N. and P. Sangster, "PT-EAP: Posture Transport (PT) Protocol for Extensible Authentication Protocol (EAP) Tunnel Methods", RFC 7171, DOI 10.17487/RFC7171, May 2014, <https://www.rfc-editor.org/info/rfc7171>. [RFC7632] Waltermire, D. and D. Harrington, "Endpoint Security Posture Assessment: Enterprise Use Cases", RFC 7632, DOI 10.17487/RFC7632, September 2015, <https://www.rfc-editor.org/info/rfc7632>. [RFC8248] Cam-Winget, N. and L. Lorenzin, "Security Automation and Continuous Monitoring (SACM) Requirements", RFC 8248, DOI 10.17487/RFC8248, September 2017, <https://www.rfc-editor.org/info/rfc8248>.
Authors' Addresses
Charles Schmidt The MITRE Corporation 202 Burlington Road Bedford, MA 01730 United States of America Email: cmschmidt@mitre.org Daniel Haynes The MITRE Corporation 202 Burlington Road Bedford, MA 01730 United States of America Email: dhaynes@mitre.org Chris Coffin The MITRE Corporation 202 Burlington Road Bedford, MA 01730 United States of America Email: ccoffin@mitre.org David Waltermire National Institute of Standards and Technology 100 Bureau Drive Gaithersburg, Maryland United States of America Email: david.waltermire@nist.gov Jessica Fitzgerald-McKay United States National Security Agency 9800 Savage Road Ft. Meade, Maryland United States of America Email: jmfitz2@radium.ncsc.mil