idnits 2.17.1 draft-ietf-sacm-nea-swima-patnc-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 5 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 5, 2018) is 2242 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 4216 -- Looks like a reference, but probably isn't: '2' on line 4218 == Missing Reference: 'RFC-to-be' is mentioned on line 4116, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'NIST8060' -- Possible downref: Non-RFC (?) normative reference: ref. 'SWID09' -- Possible downref: Non-RFC (?) normative reference: ref. 'SWID15' Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SACM C. Schmidt 3 Internet-Draft D. Haynes 4 Intended status: Standards Track C. Coffin 5 Expires: September 6, 2018 The MITRE Corporation 6 D. Waltermire 7 National Institute of Standards and Technology 8 J. Fitzgerald-McKay 9 United States National Security Agency 10 March 5, 2018 12 Software Inventory Message and Attributes (SWIMA) for PA-TNC 13 draft-ietf-sacm-nea-swima-patnc-04 15 Abstract 17 This document extends "PA-TNC: A Posture Attribute (PA) Protocol 18 Compatible with Trusted Network Connect (TNC)" (RFC 5792) by 19 providing specific attributes and message exchanges to allow 20 endpoints to report their installed software inventory information to 21 a NEA server, as defined in "Network Endpoint Assessment (NEA): 22 Overview and Requirements" (RFC 5209). 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 6, 2018. 41 Copyright Notice 43 Copyright (c) 2018 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.1. Network Endpoint Assessment (NEA) . . . . . . . . . . . . 5 60 1.2. Conventions Used in This Document . . . . . . . . . . . . 6 61 1.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7 62 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 2.1. Supported Use Cases . . . . . . . . . . . . . . . . . . . 8 64 2.1.1. Use Software Inventory as an Access Control Factor . 8 65 2.1.2. Central Stores of Up-to-Date Endpoint Software 66 Inventory Data . . . . . . . . . . . . . . . . . . . 8 67 2.1.3. PA-TNC Use Cases . . . . . . . . . . . . . . . . . . 9 68 2.2. Non-supported Use Cases . . . . . . . . . . . . . . . . . 9 69 2.3. SWIMA Requirements . . . . . . . . . . . . . . . . . . . 10 70 2.4. Non-SWIMA Requirements . . . . . . . . . . . . . . . . . 11 71 2.5. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 11 72 2.6. Non-Assumptions . . . . . . . . . . . . . . . . . . . . . 11 73 3. System Requirements . . . . . . . . . . . . . . . . . . . . . 12 74 3.1. Data Sources . . . . . . . . . . . . . . . . . . . . . . 12 75 3.2. Data Models . . . . . . . . . . . . . . . . . . . . . . . 13 76 3.3. Basic Attribute Exchange . . . . . . . . . . . . . . . . 15 77 3.4. Core Software Reporting Information . . . . . . . . . . . 16 78 3.4.1. Software Identifiers . . . . . . . . . . . . . . . . 16 79 3.4.2. Data Model Type . . . . . . . . . . . . . . . . . . . 17 80 3.4.3. Record Identifiers . . . . . . . . . . . . . . . . . 18 81 3.4.4. Software Locators . . . . . . . . . . . . . . . . . . 18 82 3.4.5. Source Identifiers . . . . . . . . . . . . . . . . . 19 83 3.4.6. Using Software and Record Identifiers in SWIMA 84 Attributes . . . . . . . . . . . . . . . . . . . . . 21 85 3.5. Targeted Requests . . . . . . . . . . . . . . . . . . . . 21 86 3.6. Monitoring Changes in an Endpoint's Software Inventory 87 Evidence Collection . . . . . . . . . . . . . . . . . . . 22 88 3.7. Reporting Change Events . . . . . . . . . . . . . . . . . 25 89 3.7.1. Event Identifiers . . . . . . . . . . . . . . . . . . 25 90 3.7.2. Core Event Tracking Information . . . . . . . . . . . 27 91 3.7.3. Updating Inventory Knowledge Based on Events . . . . 27 92 3.7.4. Using Event Records in SWIMA Attributes . . . . . . . 28 93 3.7.5. Partial and Complete Lists of Event Records in SWIMA 94 Attributes . . . . . . . . . . . . . . . . . . . . . 28 95 3.7.6. Synchronizing Event Identifiers and Epochs . . . . . 30 96 3.8. Subscriptions . . . . . . . . . . . . . . . . . . . . . . 32 97 3.8.1. Establishing Subscriptions . . . . . . . . . . . . . 32 98 3.8.2. Managing Subscriptions . . . . . . . . . . . . . . . 33 99 3.8.3. Terminating Subscriptions . . . . . . . . . . . . . . 33 100 3.8.4. Subscription Status . . . . . . . . . . . . . . . . . 34 101 3.8.5. Fulfilling Subscriptions . . . . . . . . . . . . . . 34 102 3.8.5.1. Subscriptions Reporting Inventories . . . . . . . 36 103 3.8.5.2. Subscriptions Reporting Events . . . . . . . . . 36 104 3.8.5.3. Targeted Subscriptions . . . . . . . . . . . . . 37 105 3.8.5.4. No Subscription Consolidation . . . . . . . . . . 38 106 3.8.5.5. Delayed Subscription Fulfillment . . . . . . . . 38 107 3.9. Error Handling . . . . . . . . . . . . . . . . . . . . . 39 108 4. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 41 109 4.1. Direct Response to a SWIMA Request . . . . . . . . . . . 41 110 4.2. Subscription-Based Response . . . . . . . . . . . . . . . 41 111 4.3. Required Exchanges . . . . . . . . . . . . . . . . . . . 42 112 5. Software Inventory Messages and Attributes . . . . . . . . . 42 113 5.1. PA Subtype (AKA PA-TNC Component Type) . . . . . . . . . 42 114 5.2. SWIMA Attribute Overview . . . . . . . . . . . . . . . . 43 115 5.3. Message Diagram Syntax . . . . . . . . . . . . . . . . . 45 116 5.4. SWIMA Attribute Enumeration . . . . . . . . . . . . . . . 45 117 5.5. Normalization of Text Encoding . . . . . . . . . . . . . 45 118 5.6. Request IDs . . . . . . . . . . . . . . . . . . . . . . . 45 119 5.7. SWIMA Request . . . . . . . . . . . . . . . . . . . . . . 46 120 5.8. Software Identifier Inventory . . . . . . . . . . . . . . 50 121 5.9. Software Identifier Events . . . . . . . . . . . . . . . 54 122 5.10. Software Inventory . . . . . . . . . . . . . . . . . . . 59 123 5.11. Software Events . . . . . . . . . . . . . . . . . . . . . 62 124 5.12. Subscription Status Request . . . . . . . . . . . . . . . 67 125 5.13. Subscription Status Response . . . . . . . . . . . . . . 68 126 5.14. Source Metadata Request . . . . . . . . . . . . . . . . . 70 127 5.15. Source Metadata Response . . . . . . . . . . . . . . . . 71 128 5.16. PA-TNC Error as Used by SWIMA . . . . . . . . . . . . . . 73 129 5.16.1. SWIMA_ERROR, 130 SWIMA_SUBSCRIPTION_DENIED_ERROR and 131 SWIMA_SUBSCRIPTION_ID_REUSE_ERROR Information . . . 76 132 5.16.2. SWIMA_RESPONSE_TOO_LARGE_ERROR Information . . . . . 77 133 5.16.3. SWIMA_SUBSCRIPTION_FULFILLMENT_ERROR Information . . 79 134 6. Supported Data Models . . . . . . . . . . . . . . . . . . . . 81 135 6.1. ISO 2015 SWID Tags using XML . . . . . . . . . . . . . . 81 136 6.1.1. Guidance on Normalizing Source Data to ISO 2015 SWID 137 Tags using XML . . . . . . . . . . . . . . . . . . . 81 138 6.1.2. Guidance on Creation of Software Identifiers from ISO 139 2015 SWID Tags . . . . . . . . . . . . . . . . . . . 82 140 6.2. ISO 2009 SWID Tags using XML . . . . . . . . . . . . . . 82 141 6.2.1. Guidance on Normalizing Source Data to ISO 2009 SWID 142 Tags using XML . . . . . . . . . . . . . . . . . . . 82 143 6.2.2. Guidance on Creation of Software Identifiers from ISO 144 2009 SWID Tags . . . . . . . . . . . . . . . . . . . 83 146 7. Relationship to Other Specifications . . . . . . . . . . . . 83 147 8. Security Considerations . . . . . . . . . . . . . . . . . . . 84 148 8.1. Evidentiary Value of Software Inventory Evidence Records 84 149 8.2. Sensitivity of Collected Records . . . . . . . . . . . . 85 150 8.3. Integrity of Endpoint Records . . . . . . . . . . . . . . 86 151 8.4. SWIMA-PC Access Permissions . . . . . . . . . . . . . . . 86 152 8.5. Sanitization of Record Fields . . . . . . . . . . . . . . 87 153 8.6. PA-TNC Security Threats . . . . . . . . . . . . . . . . . 87 154 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 87 155 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 88 156 10.1. PA Subtypes . . . . . . . . . . . . . . . . . . . . . . 88 157 10.2. Registry for PA-TNC Attribute Types . . . . . . . . . . 88 158 10.3. Registry for PA-TNC Error Codes . . . . . . . . . . . . 89 159 10.4. Registry for Software Data Models . . . . . . . . . . . 90 160 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 91 161 11.1. Normative References . . . . . . . . . . . . . . . . . . 91 162 11.2. Informative References . . . . . . . . . . . . . . . . . 92 163 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 93 164 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 93 166 1. Introduction 168 Knowing the list of the software installed on endpoints is useful to 169 understand and maintain the security state of a network. For 170 example, if an enterprise policy requires the presence of certain 171 software and prohibits the presence of other software, reported 172 software installation information can be used to indicate compliance 173 and non-compliance with these requirements. Endpoint software 174 installation inventory lists (hereinafter "software inventories") can 175 further be used to determine an endpoint's exposure to attack based 176 on comparison to vulnerability or threat alerts against identified 177 software's patch level data. These are some of the highly useful 178 management use cases supported by software inventory data. 180 Software Inventory Message and Attributes (SWIMA) for PA-TNC provides 181 a standardized method for exchanging software inventory data that 182 includes a unique software identifier associated with a specific 183 version of a software product. SWIMA can also convey metadata about 184 software products beyond this identifier. SWIMA enables software 185 identification, installation, and characterization information to be 186 be transported to a central server from any endpoint that supports 187 this specification. Such information can come from multiple sources, 188 including tag files (such as ISO SWID tags [SWID15]), reports from 189 third party inventory tools, output from package managers, and other 190 sources. SWIMA does not standardize how software is detected, 191 instead relying on a set of "data sources" to provide information 192 about installed software. Instead, SWIMA provides a flexible 193 transport capable of conveying this information regardless of how it 194 is expressed. 196 This specification is designed to only report software that is 197 installed on a target endpoint. In particular, it does not monitor 198 or report information about what software is running on the endpoint. 199 Likewise, it is not intended to report individual files, libraries, 200 installation packages, or similar artifacts. While all of this 201 information has its uses, this information requires different 202 metadata and monitoring methods. As a result, this specification 203 focuses solely on software inventory information, leaving reporting 204 of other classes of endpoint information to other specifications. 206 Note that while this specification focuses on "software inventory", 207 the mechanisms it describes could also be used to convey information 208 about firmware and operating systems associated with an endpoint. 209 The focus on software throughout this document should not be read as 210 excluding the use of SWIMA for these other purposes. 212 This specification defines a new set of PA-TNC attributes, which are 213 used to communicate requests for software inventory information and 214 software installation change events. The exchange of these messages 215 allows software inventory information to be sent to a NEA Server, 216 which can make this information available to other applications. 218 Part of the motivation for the development of SWIMA was to support 219 the IETF's Security Automation and Continuous Monitoring (SACM) 220 architecture. More details about SWIMA's role in SACM appear in 221 Section 7. However, SWIMA has no dependencies on any part of SACM 222 and is usable wherever the NEA architecture is employed. 224 1.1. Network Endpoint Assessment (NEA) 226 SWIMA defines extensions to the PA-TNC specification, which is part 227 of the Network Endpoint Assessment (NEA) architecture. The NEA 228 specifications define an open solution architecture that enables 229 network operators to collect and utilize information about endpoint 230 configuration and state. This information can be used to enforce 231 policies, monitor endpoint health, and for many other activities. 232 Information about the software present on an endpoint is an important 233 consideration for such activities. The new PA-TNC attributes defined 234 in this document are used to communicate software inventory evidence, 235 collected from a range of possible sources, from the posture 236 collector on the endpoint to the posture validator on a NEA Server 237 using the PA-TNC interface, as shown in Figure 1 below. 239 +-------------+ +--------------+ 240 | Posture | <--------PA--------> | Posture | 241 | Collectors | | Validators | 242 | (1 .. N) | | (1 .. N) | 243 +-------------+ +--------------+ 244 | | 245 | | 246 | | 247 +-------------+ +--------------+ 248 | Posture | | Posture | 249 | Broker | <--------PB--------> | Broker | 250 | Client | | Server | 251 +-------------+ +--------------+ 252 | | 253 | | 254 +-------------+ +--------------+ 255 | Posture | | Posture | 256 | Transport | <--------PT--------> | Transport | 257 | Client | | Server | 258 | (1 .. N) | | (1 .. N) | 259 +-------------+ +--------------+ 260 NEA CLIENT NEA SERVER 262 Figure 1: NEA Reference Model 264 To better understand this specification, the reader should review the 265 NEA reference architecture as described in the Network Endpoint 266 Assessment (NEA): Overview and Requirements [RFC5209]. The reader 267 should also review the PA-TNC interfaces as defined in RFC 5792 268 [RFC5792]. 270 This document is based on standards published by the Trusted 271 Computing Group's Trusted Network Communications (TNC) workgroup. 272 The TNC and NEA architectures are interoperable and many components 273 are equivalent. 275 1.2. Conventions Used in This Document 277 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 278 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 279 "OPTIONAL" in this document are to be interpreted as described in BCP 280 14 [RFC2119] [RFC8174] when, and only when, they appear in all 281 capitals, as shown here. 283 1.3. Definitions 285 This section defines terms with special meaning within this document. 287 SWIMA-PC - A NEA Posture Collector (PC) that interprets SWIMA 288 Attributes sent by SWIMA-PVs and which conforms to this 289 specification. Note that such a posture collector might also support 290 other PA-TNC exchanges beyond those defined herein. 292 SWIMA-PV - A NEA Posture Validator (PV) that interprets SWIMA 293 Attributes sent by SWIMA-PCs and which conforms to this 294 specification. Note that such a posture verifier might also support 295 other PA-TNC exchanges beyond those defined herein. 297 SWIMA Attribute - This is a PA-TNC attribute (as defined in RFC 5792 298 [RFC5792] extension as defined in this specification. 300 Endpoint's Software Inventory Evidence Collection - The set of 301 information regarding the set of software installed on an endpoint. 302 An endpoint's software inventory evidence collection might include 303 information created by or derived from multiple sources, including 304 but not limited to SWID tag files deposited on the file system during 305 software installation, information generated by software discovery 306 tools, and information dynamically generated by a software or package 307 management system on an endpoint. 309 Software Inventory Evidence Record - The endpoint's Software 310 Inventory Evidence Collection is composed of "records". Each record 311 corresponds to one installed instance of a particular software 312 product as reported by some data source. It is possible for a single 313 installed instance to have multiple software inventory evidence 314 records in an endpoint's Software Inventory Evidence Collection - 315 this can happen if multiple sources all report the same software 316 installation instance. 318 Software Identifier - A string associated with a specific version of 319 a specific software product. These identifiers are derived from the 320 records used to describe software products. SWIMA does not limit the 321 formats of these records, nor does it enforce that the same format be 322 populated the same way by all data sources. As such, while each 323 software identifier uniquely identifies a specific software product, 324 the same software product might be associated with multiple software 325 identifiers reflecting differences between different data sources and 326 supported record formats. 328 2. Background 330 2.1. Supported Use Cases 332 This section describes the use cases supported by this specification. 333 The primary use of exchanging software inventory information over the 334 PA-TNC interface is to enable a challenger (e.g., NEA Server) to 335 obtain inventory evidence about some system in a way that conforms to 336 NEA procedures and expressed using a standard format. Collected 337 software information can support a range of security activities 338 including determining whether an endpoint is permitted to connect to 339 the enterprise, determining which endpoints contain software that 340 requires patching, and similar activities. 342 2.1.1. Use Software Inventory as an Access Control Factor 344 Some enterprises might define security policies that require 345 connected endpoints to have certain pieces of security software 346 installed. By contrast, some security policies might prevent access 347 to resources by endpoints that have certain prohibited pieces of 348 software installed, since such applications might pose a security 349 risk. To support such policies, the NEA Server needs to collect 350 software inventory evidence from a target endpoint that is seeking to 351 initiate or continue connectivity to the enterprise resource. 353 Based on this specification, the SWIMA-PC can provide a complete or 354 partial inventory to the SWIMA-PV as required to determine policy 355 compliance. The SWIMA-PV can then use this as evidence of compliance 356 or non-compliance to make a policy-based access decision. 358 2.1.2. Central Stores of Up-to-Date Endpoint Software Inventory Data 360 Many tools use information about an endpoint's software inventory to 361 monitor and enforce the security of a network. For example, a 362 software patching tool needs to determine if there is out-of-date 363 software installed that needs to be updated. A vulnerability 364 management tool needs to identify endpoints with known vulnerable 365 software installed (patched or otherwise) to gauge an endpoint's 366 relative exposure to attack. A license management tool needs to 367 verify that all installed software within the enterprise is accounted 368 for. A central repository representing an up-to-date understanding 369 of each endpoint's software inventory facilitates these activities. 370 Multiple tools can share such a repository ensuring that software 371 inventory information is collected more frequently and efficiently, 372 leading to a more complete and consistent understanding of installed 373 software state as compared to each tool collecting the same inventory 374 information from endpoints individually. 376 This specification supports these activities through a number of 377 mechanisms. As noted above, a SWIMA-PC can provide a complete list 378 of software present in an endpoint's Software Inventory Evidence 379 Collection to the SWIMA-PV, which can then pass this information on 380 to a central repository, such as a Configuration Management Database 381 (CMDB) or similar application. In addition, SWIMA-PCs are required 382 to be able to monitor for changes to an endpoint's Software Inventory 383 Evidence Collection in near real-time and immediately push reports of 384 detected changes to the SWIMA-PV. Thus, any central repository fed 385 by a SWIMA-PV receiving inventory information can be updated quickly 386 after a change occurs. Keeping a central repository synchronized 387 with current software inventory information in this way allows tools 388 to make efficient decisions based on up-to-date, consistent 389 information. 391 2.1.3. PA-TNC Use Cases 393 SWIMA is intended to operate over the PA-TNC interface and, as such, 394 are intended to meet the use cases set out in the PA-TNC 395 specification. 397 2.2. Non-supported Use Cases 399 Some use cases not covered by this specification include: 401 o Addressing how the endpoint's Software Inventory Evidence 402 Collection is populated. In particular, NEA components are not 403 expected to perform software discovery activities beyond compiling 404 information in an endpoint's Software Inventory Evidence 405 Collection. This collection might come from multiple sources on 406 the endpoint (e.g., information generated dynamically by package 407 management tools or discovery tools, as well as SWID tag files 408 discovered on the file system). While an enterprise might make 409 use of software discovery capabilities to identify installed 410 software, such capabilities are outside the scope of this 411 specification. 413 o Converting inventory information expressed in a proprietary format 414 into formats used in the attributes described in this 415 specification. Instead, this specification focuses exclusively on 416 defining interfaces for the transportation of software information 417 expecting that reporting tools will converge around some set of 418 standardized formats for this information. 420 o Mechanisms for a posture validator to request a specific list of 421 software information based on arbitrary software properties. For 422 example, requesting only information about software from a 423 particular vendor is not supported. After the endpoint's Software 424 Inventory Evidence Collection has been copied to some central 425 location, such as the CMDB, processes there can perform queries 426 based on any criteria present in the collected information, but 427 this specification does not address using such queries to 428 constrain the initial collection of this information from the 429 endpoint. 431 o Use of properties of certain sources of software information that 432 might facilitate local tests (i.e., on the endpoint) of endpoint 433 state. For example, the optional package_footprint field of an 434 ISO SWID tag can contain a list of files and hash values 435 associated with the software indicated by the tag. Tools on the 436 endpoint can use the values in this field to test for the presence 437 of the indicated files. Successful evaluation of such tests leads 438 to greater assurance that the indicated software is present on the 439 endpoint. Currently, most SWID tag creators do not provide values 440 for tag fields that support local testing. For this reason, the 441 added complexity of supporting endpoint testing using these fields 442 is out of scope for this specification, but may be considered in a 443 future version. 445 2.3. SWIMA Requirements 447 Below are the requirements that the SWIMA specification is required 448 to meet in order to successfully play its role in the NEA 449 architecture. 451 Efficient: The NEA architecture enables delay of network access 452 until the endpoint is determined not to pose a security threat to 453 the network based on its asserted integrity information. To 454 minimize user frustration, SWIMA ought to minimize overhead delays 455 and make PA-TNC communications as rapid and efficient as possible. 457 Scalable: SWIMA needs to be usable in enterprises that contain tens 458 of thousands of endpoints or more. As such, it needs to allow a 459 security tools to make decisions based on up-to-date information 460 about an endpoint's software inventory without creating an 461 excessive burden on the enterprise's network. 463 Support precise and complete historical reporting: This 464 specification outlines capabilities that support real-time 465 understanding of the state of endpoint in a network in a way that 466 can be used by other tools. One means of facilitating such an 467 outcome is for a CMDB to be able to contain information about all 468 endpoints connected to the enterprise for all points in time 469 between the endpoint's first connection and the present. In such 470 a scenario, it is necessary that any PC be able to report any 471 changes to its software inventory evidence collection in near 472 real-time while connected and, upon reconnection to the 473 enterprise, be able to update the NEA Server (and through it the 474 CMDB) with regard to the state of its software inventory evidence 475 collection throughout the entire interval when it was not 476 connected. 478 2.4. Non-SWIMA Requirements 480 There are certain capabilities that users of the SWIMA specification 481 might require but which are beyond the scope of SWIMA itself and need 482 to be addressed by other standards. This list is not exhaustive. 484 End to End Confidentiality: The SWIMA specification does not define 485 a mechanism for confidentiality, nor is confidentiality 486 automatically provided by using the PA-TNC interface. In the NEA 487 architecture, confidentiality is generally provided by the 488 underlying transport protocols, such as the PT Binding to TLS 489 [RFC6876] or PT-EAP Posture Transport for Tunneled EAP Methods 490 [RFC7171] - see Section 7 for more information on related 491 standards. The information conveyed by SWIMA is often sensitive 492 in nature for both security (Section 8) and privacy (Section 9) 493 reasons. Those who implement SWIMA need to ensure that 494 appropriate NEA transport mechanisms are employed to meet 495 confidentiality requirements. 497 2.5. Assumptions 499 The Posture Broker Client and Posture Broker Server are assumed to 500 provide reliable delivery for PA-TNC messages and attributes sent 501 between the SWIMA-PCs and the SWIMA-PVs. Reliable delivery means 502 that either a message is delivered or the sender is made aware of the 503 delivery failure. In the event that reliable delivery cannot be 504 provided, the Posture Collector or Posture Validator is expected to 505 terminate the connection. 507 2.6. Non-Assumptions 509 This specification explicitly does not assume that software inventory 510 information exchanges reflect the software installation state of the 511 endpoint. This specification does not attempt to detect when the 512 endpoint is providing false information, either through malice or 513 error, but instead focuses on correctly and reliably providing the 514 reported Software Inventory Evidence Collection to the NEA Server. 515 Tools that employ the SWIMA standard can include methods to help 516 verify the accuracy of reports, but how those tools do so is beyond 517 the scope of this specification. 519 Similarly, this specification makes no assumption about the 520 completeness of the Software Inventory Evidence Collection's coverage 521 of the total set of software installed on the endpoint. It is 522 possible, and even likely, that some installed software is not 523 represented by a record in an endpoints Software Inventory Evidence 524 Collection. Instead, SWIMA ensures that what does get reported is 525 reported consistently and that the software products that are 526 reported can be reliably tracked. 528 See Section 8 for more on this security consideration. 530 3. System Requirements 532 The SWIMA specification facilitates the exchange of software 533 inventory and event information. Specifically, each application 534 supporting SWIMA includes a component known as the SWIMA-PC that 535 receives messages sent with the SWIMA Attributes component type. The 536 SWIMA-PC is also responsible for sending appropriate SWIMA Attributes 537 back to the SWIMA-PV in response. This section outlines what 538 software inventories and events are and the requirements on SWIMA-PCs 539 and SWIMA-PVs in order to support the stated use cases of this 540 specification. 542 3.1. Data Sources 544 The records in an endpoint's software inventory evidence collection 545 come from one or more "sources". A source represents one collection 546 of software inventory information about the endpoint. Examples of 547 sources include, but are not limited to, ISO SWID tags deposited on 548 the filesystem and collected therefrom, information derived from 549 package managers (e.g., RPM or YUM), and the output of software 550 inventory scanning tools. 552 There is no expectation that any one source of inventory information 553 will have either perfect or complete software inventory information. 554 For this reason, this specification supports the simultaneous use of 555 multiple sources of software inventory information. Each source 556 might have its own "sphere of expertise" and report the software 557 within that sphere. For example, a package manager would have 558 excellent understanding of the software that it managed, but would 559 not necessarily have any information about software installed via 560 other means. 562 A SWIMA-PC is not required to utilize every possible source of 563 software information on its endpoint. Some SWIMA-PCs might be 564 explicitly tied only to one or a handful of software inventory 565 sources, or it could be designed to dynamically accommodate new 566 sources. For all software inventory evidence sources that a 567 particular SWIMA-PC supports, it MUST completely support all 568 requirements of this specification with regard to those sources. A 569 potential source that cannot support some set of required 570 functionality (e.g., it is unable to monitor the software it reports 571 for change events, as discussed in Section 3.6) MUST NOT be used as a 572 source of endpoint software inventory information, even if it could 573 provide some information. In other words, a source either supports 574 full functionality as described in this specification, or it cannot 575 be used at all. 577 When sending information about installed software the SWIMA-PC MUST 578 include the complete set of relevant data from all supported sources 579 of software inventory evidence. In other words, sources need to be 580 used consistently. This is because, if a particular source is 581 included in an initial inventory, but excluded from a later 582 inventory, the SWIMA-PV receiving this information might reasonably 583 conclude that the software reported by that source was no longer 584 installed on the endpoint. As such, it is important that all 585 supported sources be used every time the SWIMA-PC provides 586 information to a SWIMA-PV. 588 Note that, if a SWIMA-PC collects data from multiple sources, it is 589 possible that some software products might be "double counted". This 590 can happen if both sources of inventory evidence provide a record for 591 a single installation of a software product. When a SWIMA-PC reports 592 information or records events from multiple inventory evidence 593 sources, it MUST use the information those sources provide, rather 594 than attempting to perform some form of reduction. In other words, 595 if multiple sources report records corresponding to a single 596 installation of a software product, all such records from each source 597 are required to be part of the SWIMA-PC's processing even if this 598 might lead to multiple reporting, and the SWIMA-PC is not to ignore 599 some records to avoid such multiple reporting. 601 All inventory records reported by a SWIMA-PC include a Source 602 Identifier linking them to a particular source. Source Identifiers 603 are discussed more in Section 3.4.5. 605 3.2. Data Models 607 SWIMA conveys records about software presence from a SWIMA-PC to a 608 SWIMA-PV. SWIMA does not manage the actual generation or collection 609 of such records on the endpoint. As a result, information available 610 to SWIMA-PCs might come in a variety of formats, and a SWIMA-PC could 611 have little control over the format of the data made available to it. 612 Because of this, SWIMA places no constraints on the format of these 613 generated records and supports an open set of record formats by which 614 installed software instances can be described. The following terms 615 are used in this document: 617 Data model - The format used to structure data within a given record. 618 SWIMA does not constrain the data models it conveys. 620 Record - A populated instance of some data model that describes a 621 software product. 623 Do not confuse the "data model" described here with the structure of 624 the SWIMA messages and attributes used to convey information between 625 SWIMA-PVs and PCs. The SWIMA specification dictates the structure of 626 its messages and attributes. Some attributes, however, have specific 627 fields used to convey inventory records, and those fields support an 628 extensible list of data models for their values. In other words, 629 SWIMA data models provide an extension point within SWIMA attributes 630 that allows the structure of inventory records to evolve. 632 The data model used to structure software inventory information has 633 very little impact on the behavior of the components defined in this 634 specification. The SWIMA-PV has no dependency on the data model of 635 records conveyed in SWIMA messages. For this reason, it MUST NOT 636 reject a message or respond with a PA-TNC Error due to the data model 637 used to structure records in attributes it receives. Similarly, it 638 MUST NOT reject a message or respond with a PA-TNC Error if a record 639 fails to comply with a stated format, unless that failure prevents 640 correct parsing of the attribute itself. In short, the record bodies 641 are effectively treated as "black boxes" by the SWIMA-PV. (Note that 642 the SWIMA-PV might serve as the front-end of other functionality that 643 does have a dependency on the data model used to structure software 644 information, but any such dependency is beyond the scope of this 645 specification and needs to be addressed outside the behaviors 646 specified in this document. This specification is only concerned 647 with collection and delivery of software inventory information; 648 components that consume and use this information are a separate 649 concern.) 651 The SWIMA-PC does have one functional dependency on the data models 652 used in the software records it delivers, but only insofar as it is 653 required to deterministically create a Software Identifier (described 654 in Section 3.4.1) based on each record it delivers. The SWIMA-PC 655 MUST be able to generate a Software Identifier for each record it 656 delivers, and if the SWIMA-PC cannot do so the record cannot be 657 delivered by the SWIMA-PC. All SWIMA-PCs MUST at least be able to 658 generate Software Identifiers for the data model types specified in 659 Section 6 of this document. A SWIMA-PC MAY include the ability to 660 generate Software Identifiers for other data model types, and thus be 661 able to support them as well. 663 3.3. Basic Attribute Exchange 665 In the most basic exchange supported by this specification, a SWIMA- 666 PV sends a request to the SWIMA-PC requesting some type of 667 information about the endpoint's software inventory. This simple 668 exchange is shown in Figure 2. 670 +-------------+ +--------------+ 671 | SWIMA-PC | | SWIMA-PV | Time 672 +-------------+ +--------------+ | 673 | | | 674 |<------------SWIMA Request---------------| | 675 | | | 676 |-------------SWIMA Response------------->| | 677 | | V 679 Figure 2: Basic SWIMA Attribute Exchange 681 Upon receiving such a SWIMA Request from the SWIMA-PV, the SWIMA-PC 682 is expected to collect all the relevant software inventory 683 information from the endpoint's software evidence collection and 684 place it within its response attribute. 686 SWIMA-PVs MUST discard without error any SWIMA Response attributes 687 that they receive for which they do not know the SWIMA Request 688 parameters that led to this SWIMA Response. This is due to the fact 689 that the SWIMA Request includes parameters that control the nature of 690 the response (as will be described in the following sections) and 691 without knowing those parameters the SWIMA Response cannot be 692 reliably interpreted. Most often receiving an unsolicited SWIMA 693 Response attribute happens when a NEA Server has multiple SWIMA-PVs; 694 one SWIMA-PV sends a SWIMA Request but, unless exclusive delivery is 695 set by the sender and honored by the recipient, both SWIMA-PVs 696 receive copies of the resulting SWIMA Response. In this case, the 697 SWIMA-PV that didn't send the SWIMA Request would lack the context 698 necessary to correctly interpret the SWIMA Response it received and 699 would simply discard it. Note, however, that proprietary measures 700 might allow a SWIMA-PV to discover the SWIMA Request parameters for a 701 SWIMA Response even if that SWIMA-PV did not send the given SWIMA 702 Request. As such, there is no blanket requirement for a SWIMA-PV to 703 discard all SWIMA Responses to SWIMA Request the SWIMA-PV did not 704 generate itself, only that SWIMA-PVs are required to discard SWIMA 705 Responses for which they cannot get the necessary context to 706 interpret. 708 In the case that it is possible to do so, the SWIMA-PC SHOULD send 709 its SWIMA Response attribute to the SWIMA-PV that requested it using 710 exclusive delivery as described in section 4.5 of RFC 5793 (PB-TNC) 711 [RFC5793]. Exclusive delivery requests that only the sender of the 712 SWIMA Request receives the resulting SWIMA Response. Note, however, 713 that PB-TNC does not require the recipient to honor the exclusive 714 delivery flag in messages that it receives, so setting the flag 715 cannot be guaranteed to prevent a SWIMA-PV from receiving unsolicited 716 SWIMA Responses. 718 All numeric values sent in SWIMA messages are sent in network (big 719 endian) byte order. 721 3.4. Core Software Reporting Information 723 Different parameters in the SWIMA Request can influence what 724 information is returned in the SWIMA Response. However, while each 725 SWIMA Response provides different additional information about this 726 installed software, they all share a common set of fields that 727 support reliable software identification on an endpoint. These 728 fields include: Software Identifiers, the Data Model Type, Record 729 Identifiers, Software Locators, and Source Identifiers. These fields 730 are present for each reported piece of software in each type of SWIMA 731 Response. The following sections examine these information types in 732 more detail. 734 3.4.1. Software Identifiers 736 A Software Identifier uniquely identifies a specific version of a 737 specific software product. The SWIMA specification does not dictate 738 the structure of a Software Identifier (beyond stating that it is a 739 string) or define how it is created. Instead, each data model 740 described in the Software Data Model IANA table (Section 10.4) 741 includes its own rules for how a Software Identifier is created based 742 on a record in the Endpoint's Software Inventory Evidence Collection 743 expressed in that data model. Other data models will have their own 744 procedures for the creation of associated Software Identifiers. 745 Within the SWIMA specification, the Software Identifier is simply an 746 opaque string and there is never any need to unpack any information 747 that might be part of that identifier. 749 A Software Identifier is a fraction of the size of the inventory 750 record from which it is derived. For some combinations of data 751 models and sources, the full record might never be necessary as the 752 identifier can be directly correlated to the contents of the full 753 record. This is possible with authoritative SWID tags, since these 754 tags always have the same contents and thus a Software Identifier 755 derived from these tags can be used as a lookup to a local copy of 756 the full tag. For other combinations of source and data model, a 757 server might not be able to determine the specific software product 758 and version associated with the identifier without requesting 759 delivery of the full record. However, even in those cases, 760 downstream consumers of this information might never need the full 761 record as long as the Software Identifiers they receive can be 762 tracked reliably. A SWIMA-PV can use Software Identifiers to track 763 the presence of specific software products on an endpoint over time 764 in a bandwidth-efficient manner. 766 There are two important limitations of Software Identifiers to keep 767 in mind: 769 1. The identifiers do not necessarily change when the associated 770 record changes. In some situations, a record in the endpoint's 771 Software Inventory Evidence Collection will change due to new 772 information becoming available or in order to correct prior 773 errors in that information. Such changes might or might not 774 result in changes to the Software Identifier, depending on the 775 nature of the changes and the rules governing how Software 776 Identifiers are derived from records of the appropriate data 777 model. 779 2. It is possible that a single software product is installed on a 780 single endpoint multiple times. If both of these installation 781 instances are reported by the same source using the same data 782 format, then this can result in identical Software Identifiers 783 for each installation instances. In other words, Software 784 Identifiers might not uniquely identify installation instances; 785 they just are intended to uniquely identify software products 786 (which might have more than one installation instance). Instead, 787 to reliably distinguish between multiple instances of a single 788 software product, one needs to make use of Record Identifiers, 789 described in Section 3.4.3. 791 3.4.2. Data Model Type 793 The Data Model Type consists of two fields: the Data Model Type PEN 794 and the Data Model Type. The combination of these fields is used to 795 identify the type of data model of the associated software inventory 796 record. The data model is significant not only because it informs 797 the recipient of the data model of the associated record, but because 798 the process for generation of the Software Identifier for the record 799 depends on the record's data model. Clearly identifying the type of 800 data model from which the Software Identifier was derived thus 801 provides useful context for that value. 803 The PEN (or Private Enterprise Number) identifies the organization 804 that assigns meaning to the Data Model Type field value. PENs are 805 managed by IANA in the Private Enterprise Numbers registry. PENs 806 allow vendors to designate their own set of data models for software 807 inventory description. IANA reserves the PEN of 0x000000. Data 808 Model Types associated with this PEN are defined in the Software Data 809 Model IANA table, created in Section 10.4 of this specification. 810 Note that this IANA table reserves all values greater than or equal 811 to 0xC0 (192) for enterprise use. This means that local enterprises 812 can use custom data formats and indicate them with the IANA PEN and a 813 Data Model Type value between 0xC0 and 0XFF, inclusive. Those 814 enterprises are responsible for configuring their SWIMA-PCs to 815 correctly report those custom data models. 817 3.4.3. Record Identifiers 819 A Record Identifier is a 4-byte unsigned integer generated by the 820 SWIMA-PC that is uniquely associated with a specific record within 821 the Endpoint's Software Inventory Evidence Collection. The SWIMA-PC 822 MUST assign a unique identifier to each record when it is added to 823 the Endpoint's Software Inventory Evidence Collection. The Record 824 Identifier SHOULD remain unchanged if that record is modified. 825 (However, it is recognized that, in some circumstances, record 826 modification might be hard to distinguish from record deletion 827 followed by creation of a new record. For this reason, retaining a 828 constant Record Identifier across record modification is recommended 829 but not required.) The SWIMA-PC might wish to assign Record 830 Identifiers sequentially, but any scheme is acceptable provided that 831 no two records receive the same identifier. 833 Servers can use Record Identifiers to distinguish between multiple 834 instances of a single software product installed on an endpoint. 835 Since each installation instance of a software product is associated 836 with a separate record, servers can use the record identifier to 837 distinguish between instances. For example, if an event is reported 838 (as described in Section 3.7), the record identifier will allow the 839 server to discern which instance of a software product is involved. 841 3.4.4. Software Locators 843 In addition to the need to identify software products, many use cases 844 of inventory information need to know where software is located on 845 the endpoint. This information might be needed to direct remediation 846 actions or similar processes. For this reason, every reported 847 software product also includes a Software Locator to identify where 848 the software is installed on the endpoint. 850 If the location is not provided directly by the record source the 851 SWIMA-PC is responsible for attempting to determine the location of 852 the software product. The "location" of a product SHOULD be the 853 directory in which the software products' executables are kept. The 854 source and/or SWIMA-PC MUST be consistent in reporting the location 855 of a software product (i.e., assuming a software product has not 856 moved, the SWIMA-PC cannot use one location in one report and a 857 different location for the same software product in another). 859 The location is expressed as a URI string. The string MUST conform 860 to URI syntax requirements. [RFC3986] The URI schema describes the 861 context of the described location. For example, in most cases the 862 location of the installed software product will be expressed in terms 863 of its path in the filesystem. For such locations, the location URI 864 scheme MUST be "file" and the URI MUST conform to the "file" URI 865 scheme standard [RFC8089] including percent-encoding of whitespace 866 and other special characters. It is possible that other schemes 867 could be used to represent other location contexts. Apart from 868 specifying the use of the "file" scheme, this specification does not 869 identify other schemes or define their use. When representing 870 software products in other location contexts, tools MUST be 871 consistent in their use of schemes, but the exact schemes are not 872 normatively defined here. SWIMA implementations are not limited to 873 the IANA list of URI schemes [1] and can define new schemes to 874 support other types of application locations. 876 It is possible, that a SWIMA-PC is unable to determine the location 877 of a reported software product. In this case, the SWIMA-PC MUST 878 provide a zero-length Software Locator. 880 3.4.5. Source Identifiers 882 All SWIMA-PCs MUST track the source of each piece of software 883 information they report. Each time a SWIMA-PC gets information to 884 send to a given SWIMA-PV from a new source (from the perspective of 885 that SWIMA-PV), the SWIMA-PC MUST assign that source a Source 886 Identification Number, which is an 8-bit unsigned integer. Each item 887 reported includes the Source Identification Number that provided that 888 information. All information that is provided by that source, MUST 889 be delivered with this same Source Identification Number. This MUST 890 be done for each source used. If the SWIMA-PC ever is unclear as to 891 whether a given source is new or not, it MUST assume that this is a 892 new source and assign it a new Source Identification Number. Source 893 Identification Numbers do not need to be assigned sequentially. 894 SWIMA does not support the presence of more than 256 sources as the 895 chance that a single endpoint will have more than 256 methods of 896 collecting inventory information is vanishingly small. All possible 897 values between 0 and 255 are valid; there are no reserved Source 898 Identification Numbers 900 Source Identification Numbers can help with (although will not 901 completely eliminate) the challenges posed by multiple reporting of a 902 single software instance: since a single source would only report an 903 instance or event once, if multiple reports of a similar instance 904 come from multiple sources, this might be an instance of multiple 905 reporting (although it still might not be so). On the other hand, if 906 multiple instances are reported by a single source, this almost 907 certainly means that there are actually multiple instances that are 908 being legitimately reported. 910 The SWIMA-PC is responsible for tracking associations between Source 911 Identifiers and the given data source. This association MUST remain 912 consistent with regard to a given SWIMA-PV while there is an active 913 PB-TNC session with that SWIMA-PV. The SWIMA-PC MAY have a different 914 Source Identifier association for different SWIMA-PVs. Likewise, the 915 SWIMA-PC MAY change the Source Identifier association for a given 916 SWIMA-PV if the PB-TNC session terminates. However, implementers of 917 SWIMA-PCs will probably find it easier to manage associations by 918 maintaining the same association for all SWIMA-PVs and across 919 multiple sessions. 921 Of special note, events records reported from the SWIMA-PC's event 922 log (discussed in Section 3.7) also need to be sent with their 923 associated data source. The Source Identifier reported with events 924 MUST be the current (i.e., at the time the event is sent) Source 925 Identifier associated with the data source that produced the event, 926 regardless of how long ago that event occurred. Event logs are 927 likely to persist far longer than a single PB-TNC session. SWIMA-PCs 928 MUST ensure that each event can be linked to the appropriate data 929 source, even if the Source Identifiers used when the event was 930 created have since been reassigned. In other words, when sending an 931 event, it needs to be sent with the Source Identifier currently 932 linked to the data source that produced it, regardless of whether a 933 different Source Identifier would have been associated with the event 934 when the event was first created. 936 Note that the Source Identification Number is primarily used to 937 support recognition, rather than identification, of sources. That is 938 to say, a Software Identification Number can tell a recipient that 939 two events were reported by the same source, but will not necessarily 940 help that recipient determine which source was used. Moreover, 941 different SWIMA-PCs will not necessarily use the same Source 942 Identification Numbers for the same sources. SWIMA-PCs MUST track 943 the assignment of Source Identification Numbers to ensure consistent 944 application thereof. SWIMA-PCs MUST also track which Source 945 Identification Numbers have been used with each SWIMA-PV with which 946 they communicate. 948 3.4.6. Using Software and Record Identifiers in SWIMA Attributes 950 A SWIMA Attribute reporting an endpoint's Software Inventory Evidence 951 Collection always contains the Software Identifiers associated with 952 the identified software products. A SWIMA Attribute might or might 953 not also contain copies of software inventory evidence records. The 954 attribute exchange is identical to the diagram shown in Figure 2 955 regardless of whether software inventory evidence records are 956 included. The SWIMA Request attribute indicates whether the response 957 is required to include software inventory evidence records. 958 Excluding software inventory evidence records can reduce the 959 attribute size of the response by multiple orders of magnitude when 960 compared to sending the same inventory with full records. 962 3.5. Targeted Requests 964 Sometimes a SWIMA-PV does not require information about every piece 965 of software on an endpoint but only needs to receive updates about 966 certain software instances. For example, enterprise endpoints might 967 be required to have certain software products installed and to keep 968 these updated. Instead of requesting a complete inventory just to 969 see if these products are present, the SWIMA-PV can make a "targeted 970 request" for the software in question. 972 Targeted requests follow the same attribute exchange described in 973 Figure 2. The SWIMA-PV targets its request by providing one or more 974 Software Identifiers in its SWIMA Request attribute. The SWIMA-PC 975 MUST then limit its response to contain only records that match the 976 indicated Software Identifier(s). This allows the network exchange 977 to exclude information that is not relevant to a given policy 978 question, thus reducing unnecessary bandwidth consumption. The 979 SWIMA-PC's response might or might not include software inventory 980 evidence records, depending on the parameters of the SWIMA Request. 982 Note that targeted requests identify the software relevant to the 983 request only through Software Identifiers. This specification does 984 not support arbitrary, parameterized querying of records. For 985 example, one cannot request all records from a certain software 986 publisher, or all records created by a particular record source. 987 Targeted requests only allow a requestor to request specific software 988 (as identified by their Software Identifiers) and receive a response 989 that is limited to the named software. 991 There is no assumption that a SWIMA-PC will recognize "synonymous 992 records" - that is, records from different sources for the same 993 software. Recall that different sources and data models may use 994 different Software Identifier strings for the same software product. 995 The SWIMA-PC returns only records that match the Software Identifiers 996 in the SWIMA Request, even if there might be other records in the 997 endpoint's Software Inventory Evidence Collection for the same 998 software product. This is necessary because SWIMA-PCs might not have 999 the ability to determine that two Software Identifiers refer to the 1000 same product. 1002 Targeted requests do not include Record Identifiers or Software 1003 Locators. The response to a targeted request MUST include all 1004 records associated with the named Software Identifiers, including the 1005 case where there are multiple records associated with a single 1006 Software Identifier. 1008 SWIMA-PCs MUST accept targeted requests and process them correctly as 1009 described above. SWIMA-PVs MUST be capable of making targeted 1010 requests and processing the responses thereto. 1012 3.6. Monitoring Changes in an Endpoint's Software Inventory Evidence 1013 Collection 1015 The software collection on an endpoint is not static. As software is 1016 installed, uninstalled, patched, or updated, the Software Inventory 1017 Evidence Collection is expected to change to reflect the new software 1018 state on the endpoint. Different record sources might update the 1019 evidence collection at different rates. For example, a package 1020 manager might update its records in the Software Inventory Evidence 1021 Collection immediately whenever it is used to add or remove a 1022 software product. By contrast, sources that perform periodic 1023 examination of the endpoint would likely only update their records in 1024 the Software Inventory Evidence Collection after each examination. 1026 All SWIMA-PCs MUST be able to be able to detect changes to the 1027 Software Inventory Evidence Collection. Specifically, SWIMA-PCs MUST 1028 be able to detect: 1030 o The creation of records 1032 o The deletion of records 1034 o The alteration of records 1036 An "alteration" is anything that modifies the contents of a record 1037 (or would modify it, if the record is dynamically generated on 1038 demand) in any way, regardless of whether the change is functionally 1039 meaningful. 1041 SWIMA-PCs MUST detect such changes to the endpoint's Software 1042 Inventory Evidence Collection in close to real-time (i.e., within 1043 seconds) when the Posture Collector is operating. In addition, in 1044 the case where there is a period during which the SWIMA-PC is not 1045 operating, the SWIMA-PC MUST be able to determine the net change to 1046 the endpoint's Software Inventory Evidence Collection over the period 1047 it was not operational. Specifically, the "net change" represents 1048 the difference between the state of the endpoint's Software Inventory 1049 Evidence Collection when the SWIMA-PC was last operational and 1050 monitoring its state, and the state of the endpoint's software 1051 inventory evidence collection when the SWIMA-PC resumed operation. 1052 Note that a net change might not reflect the total number of change 1053 events over this interval. For example, if a record was altered 1054 three times during a period when the SWIMA-PC was unable to monitor 1055 for changes, the net change of this interval might only note that 1056 there was an alteration to the record, but not how many individual 1057 alteration events occurred. It is sufficient for a SWIMA-PC's 1058 determination of a net change to note that there was a difference 1059 between the earlier and current state rather than enumerating all the 1060 individual events that allowed the current state to be reached. 1062 The SWIMA-PC MUST assign a time to each detected change in the 1063 endpoint's Software Inventory Evidence Collection. These timestamps 1064 correspond to the SWIMA-PC's best understanding as to when the 1065 detected change occurred. For changes to the endpoint's Software 1066 Inventory Evidence Collection that occur while the SWIMA-PC is 1067 operating, the SWIMA-PC ought to be able to assign a time to the 1068 event that is accurate to within a few seconds. For changes to the 1069 endpoint's Software Inventory Evidence Collection that occur while 1070 the SWIMA-PC is not operational, upon becoming operational the SWIMA- 1071 PC needs to make a best guess as to the time of the relevant events 1072 (possibly by looking at timestamps on files), but these values might 1073 be off. In the case of dynamically generated records, the time of 1074 change is the time at which the data from which the records are 1075 generate changes, not the time at which a changed record is 1076 generated. For example, if records are dynamically generated based 1077 on data in an RPM database, the time of change would be when the RPM 1078 database changed. 1080 With regard to deletions of records, the SWIMA-PC needs to detect the 1081 deletion and MUST retain a copy of the full deleted record along with 1082 the associated Record Identifier and Software Locator so that the 1083 record and associated information can be provided to the SWIMA-PV 1084 upon request. This copy of the record MUST be retained for a 1085 reasonable amount of time. Vendors and administrators determine what 1086 "reasonable" means, but a copy of the record SHOULD be retained for 1087 as long as the event recording the deletion of the record remains in 1088 the SWIMA-PC's event log (as described in Section 3.7). This is 1089 recommended because, as long as the event is in the SWIMA-PC's change 1090 logs, the SWIMA-PC might send an event attribute (described in 1091 Section 3.7) that references this record, and a copy of the record is 1092 needed if the SWIMA-PV wants a full copy of the relevant records. In 1093 the case that a SWIMA-PC is called upon to report a deletion event 1094 that is still in the event log but where the record itself is no 1095 longer available, the SWIMA-PC will still return an entry 1096 corresponding to the deletion event, but the field of that entry that 1097 would normally contain the full copy of the record SHOULD be 1098 0-length. 1100 With regard to alterations to a record, SWIMA-PCs MUST detect any 1101 alterations to the contents of a record. Alterations need to be 1102 detected even if they have no functional impact on the record. A 1103 good guideline is that any alteration to a record that might change 1104 the value of a hash taken on the record's contents needs to be 1105 detected by the SWIMA-PC. A SWIMA-PC might be unable to distinguish 1106 modifications to the content of a record from modifications to the 1107 metadata the file system associates with the record. For example, a 1108 SWIMA-PC might use the "last modification" timestamp as an indication 1109 of alteration to a given record, but a record's last modification 1110 time can change for reasons other than modifications to the record 1111 contents. A SWIMA-PC is still considered compliant with this 1112 specification if it also reports metadata change events that do not 1113 change the record itself as alterations to the record. In other 1114 words, while SWIMA-PC authors are encouraged to exclude modifications 1115 that do not affect the bytes within the record, discriminating 1116 between modifications to file contents and changes to file metadata 1117 can be difficult and time consuming on some systems. As such, as 1118 long as the alterations detected by a SWIMA-PC always cover all 1119 modifications to the contents of record, the SWIMA-PC is considered 1120 compliant even if it also registers alterations that do not modify 1121 the contents of a record as well. When recording an alteration to a 1122 record, the SWIMA-PC is only required to note that an alteration 1123 occurred. The SWIMA-PC is not required to note or record how the 1124 record altered, nor is it possible to include such details in SWIMA 1125 Attributes reporting the change to a SWIMA-PV. There is no need to 1126 retain a copy of the original record prior to the alteration. 1128 When a record changes it SHOULD retain the same Record Identifier. 1129 The Software Locator might or might not change, depending on whether 1130 the software changed locations during the changes that led to the 1131 record change. A record change MUST retain the same Software 1132 Identifier. This means that any action that changes a software 1133 product (e.g., application of a patch that results in a change to the 1134 product's version) MUST NOT be reflected by a record change but 1135 instead MUST result in the deletion of the old record and the 1136 creation of a new record. This reflects the requirement that a 1137 record in the endpoint's Software Inventory Evidence Collection 1138 correspond directly with an instance of a specific software product. 1140 3.7. Reporting Change Events 1142 As noted in Section 3.6, SWIMA-PCs are required to detect changes to 1143 the endpoints Software Inventory Evidence Collection (creation, 1144 deletion, and alteration) in near real-time while the SWIMA-PC is 1145 operational, and MUST be able to account for any net change to the 1146 endpoint's Software Inventory Evidence Collection that occurs when 1147 the SWIMA-PC is not operational. However, to be of use to the 1148 enterprise, the NEA Server needs to be able to receive these events 1149 and be able to understand how new changes relate to earlier changes. 1150 In SWIMA, this is facilitated by reporting change events. All SWIMA- 1151 PCs MUST be capable of receiving requests for change events and 1152 sending change event attributes. All SWIMA-PVs MUST be capable of 1153 requesting and receiving change event attributes. 1155 3.7.1. Event Identifiers 1157 To be useful, change events need to be correctly ordered. Ordering 1158 of events is facilitated by two pieces of information: an Event 1159 Identifier (EID) value and an EID Epoch value. 1161 An EID is a 4-byte unsigned integer that the SWIMA-PC assigns 1162 sequentially to each observed event (whether detected in real-time or 1163 deduced by looking for net changes over a period of SWIMA-PC 1164 inactivity). All EIDs exist within the context of some "EID Epoch", 1165 which is also represented as a 4-byte unsigned integer. EID Epochs 1166 are used to ensure synchronization between the SWIMA-PC and any 1167 SWIMA-PVs with which it communicates. EID Epoch values MUST be 1168 generated in such a way as to minimize the chance that an EID Epoch 1169 will be reused, even in the case where the SWIMA-PC reverts to an 1170 earlier state. For this reason, sequential EID Epochs are 1171 discouraged, since loss of state could result in value reuse. There 1172 are multiple reasons that a SWIMA-PC might need to deliberately reset 1173 its EID counter, including exhaustion of available EID values, the 1174 need to purge entries from the event log to recover memory, or 1175 corruption of the event log. In all case where a SWIMA-PC needs to 1176 reset its EID counter, a new EID Epoch MUST be selected. 1178 Within an Epoch, EIDs MUST be assigned sequentially, so that if a 1179 particular event is assigned an EID of N, the next observed event is 1180 given an EID of N+1. In some cases, events might occur 1181 simultaneously, or the SWIMA-PC might not otherwise be able to 1182 determine an ordering for events. In these cases, the SWIMA-PC 1183 creates an arbitrary ordering of the events and assigns EIDs 1184 according to this ordering. Two change events MUST NOT ever be 1185 assigned the same EID within the same EID Epoch. No meaningful 1186 comparison can be made between EID values of different Epochs. 1188 The EID value of 0 is reserved and MUST NOT be associated with any 1189 event. Specifically, an EID of 0 in a SWIMA Request attribute 1190 indicates that a SWIMA-PV wants an inventory response rather than an 1191 event response, while an EID of 0 in a SWIMA Response is used to 1192 indicate the initial state of the endpoint's Software Inventory 1193 Evidence Collection prior to the observation of any events. Thus the 1194 very first recorded event in a SWIMA-PC's records within an EID Epoch 1195 MUST be assigned a value of 1. Note that EID and EID Epoch values 1196 are assigned by the SWIMA-PC without regard to whether events are 1197 being reported to one or more SWIMA-PVs. The SWIMA-PC records events 1198 and assigns EIDs during its operation. All SWIMA-PVs that request 1199 event information from the SWIMA-PC will have those requests served 1200 from the same event records and thus will see the same EIDs and EID 1201 Epochs for the same events. 1203 If a SWIMA-PC uses multiple sources, a SWIMA-PC's assignment of EIDs 1204 MUST reflect the presence and order of all events on the endpoint (at 1205 least for supported sources) regardless of the source. This means 1206 that if source A experiences an event, and then source B experiences 1207 two events, and then source A experiences another two events, the 1208 SWIMA-PC is required to capture five events with consecutive EID 1209 values reflecting the order in which the events occur. 1211 The SWIMA-PC MUST ensure there is no coverage gap (i.e., change 1212 events that are not recorded in the SWIMA-PC's records) in its change 1213 event records. This is necessary because a coverage gap might give a 1214 SWIMA-PV a false impression of the endpoint's state. For example, if 1215 a SWIMA-PV saw an event indicating that a particular record had been 1216 added to the endpoint's software inventory evidence collection, and 1217 saw no subsequent events indicating that record had been deleted, it 1218 might reasonably assume that this record was still present and thus 1219 that the indicated software was still installed (assuming the Epoch 1220 has not changed). If there is a coverage gap in the SWIMA-PC's event 1221 records, however, this assumption could be false. For this reason, 1222 the SWIMA-PC's event records MUST NOT contain gaps. In the case 1223 where there are periods where it is possible that changes occurred 1224 without the SWIMA-PC detecting or recording them, the SWIMA-PC MUST 1225 either compute a net change and update its event records 1226 appropriately, or pick a new EID Epoch to indicate a discontinuity 1227 with previous event records. 1229 Within a given Epoch, once a particular event has been assigned an 1230 EID, this association MUST NOT be changed. That is, within an Epoch, 1231 once an EID is assigned to an event, that EID cannot be reassigned to 1232 a different event, and the event cannot be assigned a different EID. 1234 When the SWIMA-PC's Epoch changes, all of these associations between 1235 EIDs and events are cancelled, and EID values once again become free 1236 for assignment. 1238 3.7.2. Core Event Tracking Information 1240 Whether reporting events or full inventories it is important to know 1241 how the reported information fits into the overall timeline of change 1242 events. This is why all SWIMA Response attributes include fields to 1243 place that response within the sequence of detected events. 1244 Specifically, all SWIMA Responses include a Last EID and EID Epoch 1245 field. The EID Epoch field identifies the EID Epoch in which the 1246 SWIMA Response was sent. If the SWIMA Response is reporting events, 1247 all reported events occurred within the named EID Epoch. The Last 1248 EID (which is also always from the named EID Epoch) indicates the EID 1249 of the last recorded change event at the time that the SWIMA Response 1250 was sent. These two fields allow any response to be placed in the 1251 context of the complete set of detected change events within a given 1252 EID Epoch. 1254 3.7.3. Updating Inventory Knowledge Based on Events 1256 Modern endpoints can have hundreds of software products installed, 1257 most of which are unlikely to change from one day to the next. As 1258 such, instead of exchanging a complete list of an endpoint's 1259 inventory on a regular basis, one might wish to only identify changes 1260 since some earlier known state of this inventory. This is readily 1261 facilitated by the use of EIDs to place change events in a context 1262 relative to earlier state. 1264 As noted above, every SWIMA Response sent by a SWIMA-PC to a SWIMA-PV 1265 (as described in Section 3.3 through Section 3.5) includes the EID 1266 Epoch and EID of the last event recorded prior to that response being 1267 compiled. This allows the SWIMA-PV to place all subsequently 1268 received event records in context relative to this SWIMA Response 1269 attribute (since the EIDs represent a total ordering of all changes 1270 to the endpoint's software inventory evidence collection). 1271 Specifically, a SWIMA-PV (or, more likely, a database that collects 1272 and records its findings) can record an endpoint's full inventory and 1273 also the EID and Epoch of the most recent event reflected at the time 1274 of that inventory. From that point on, if change events are 1275 observed, the attribute describing these events indicates the nature 1276 of the change, the affected records, and the order in which these 1277 events occurred (as indicated by the sequential EIDs). Using this 1278 information, any remote record of the endpoint's Software Inventory 1279 Evidence Collection can be updated appropriately. 1281 3.7.4. Using Event Records in SWIMA Attributes 1283 A SWIMA-PV MUST be able to request a list of event records instead of 1284 an inventory. The attribute flow in such an exchange looks the same 1285 as the basic flow shown in Figure 2. The only difference is that, in 1286 the SWIMA Request attribute, the SWIMA-PV provides an EID other than 1287 0. (A value of 0 in these fields represents a request for an 1288 inventory.) When the SWIMA-PC receives such a request, instead of 1289 identifying records from the endpoint's Software Inventory Evidence 1290 Collection, it consults its list of detected changes. The SWIMA-PC 1291 MUST add an event record to the SWIMA Response attribute for each 1292 recorded change event with an EID greater than or equal to the EID in 1293 the SWIMA Request attribute (although targeting of requests, as 1294 described in the next paragraph, might limit this list). A list of 1295 event records MUST only contain events with EIDs that all come from 1296 the current Epoch. 1298 SWIMA-PVs can target requests for event records by including one or 1299 more Software Identifiers, as described in Section 3.5, in the SWIMA 1300 Request that requests an event record list. A targeted request for 1301 event records is used to indicate that only events affecting software 1302 that matches one of the provided Software Identifiers are to be 1303 returned. Specifically, in response to a targeted request for event 1304 records, the SWIMA-PC MUST exclude any event records that are less 1305 than the indicated EID (within the current EID Epoch) and exclude any 1306 event records where the affected software does not match one of the 1307 provided Software Identifiers. This might mean that the resulting 1308 list of event records sent in the response attribute does not provide 1309 a continuous sequence of EIDs. Both SWIMA-PCs and SWIMA-PVs MUST 1310 support targeted request for event records. 1312 3.7.5. Partial and Complete Lists of Event Records in SWIMA Attributes 1314 Over time, a SWIMA-PC might record a large number of change events. 1315 If a SWIMA-PV requests all change events covering a large period of 1316 time, the resulting SWIMA Response attribute might be extremely 1317 large, especially if the SWIMA-PV requests inclusion of software 1318 inventory evidence records in the response. In the case that the 1319 resulting attribute is too large to send (either because it exceeds 1320 the 4GB attribute size limit imposed by the PA-TNC specification, or 1321 because it exceeds some smaller size limit imposed on the SWIMA-PC) 1322 the SWIMA-PC MAY send a partial list of event records back to the 1323 SWIMA-PV. 1325 Generation of a partial list of events in a SWIMA Response attribute 1326 requires the SWIMA-PC to identify a "consulted range" of EIDs. A 1327 consulted range is the set of event records that are examined for 1328 inclusion in the SWIMA Response attribute and that are included in 1329 that attribute if applicable. Recall that, if a SWIMA Request is 1330 targeted, only event records that involve the indicated software 1331 would be applicable. (See Section 3.5 for more on Targeted Request.) 1332 If a request is not targeted, all event records in the considered 1333 range are applicable and included in the SWIMA Response attribute. 1335 The lower bound of the consulted range MUST be the EID provided in 1336 the SWIMA Request. (Recall that a SWIMA Request indicates a request 1337 for event records by providing a non-0 EID value in the SWIMA 1338 Request. See Section 3.7.4.) The upper bound of the consulted range 1339 is the EID of the latest event record (as ordered by EID values) that 1340 is included in the SWIMA Response attribute if it is applicable to 1341 the request. The EID of this last event record is called the "Last 1342 Consulted EID". The SWIMA-PC chooses this Last Consulted EID based 1343 on the size of the event record list it is willing to provide to the 1344 SWIMA-PV. 1346 A partial result list MUST include all applicable event records 1347 within the consulted range. This means that for any applicable event 1348 record (i.e., any event record in an un-targeted request, or any 1349 event record associated with software matching a requested Software 1350 Identifier in a targeted request) whose EID is greater than or equal 1351 to the EID provided in the SWIMA Request and whose EID is less than 1352 or equal to the Last Consulted EID, that event record MUST be 1353 included in the SWIMA Response conveying this partial list of event 1354 records. This ensures that every partial list of event records is 1355 always complete within its indicated range. Remember that, for 1356 targeted requests, "complete" doesn't mean that all EIDs between the 1357 range endpoints are present, but only that every matching EID between 1358 the range endpoints is included. 1360 All SWIMA Response attributes that convey event records include a 1361 Last Consulted EID field. This is in addition to the EID Epoch and 1362 Last EID fields that are present in all SWIMA Responses. Note that, 1363 if responding to a targeted SWIMA Request, the SWIMA Response 1364 attribute might not contain the event record whose EID matches the 1365 Last Consulted EID value. For example, the last consulted EID record 1366 might have been deemed inapplicable because it did not match the 1367 specified list of Software Identifiers in the SWIMA Request. 1369 If a SWIMA-PV receives a SWIMA Response attribute where the Last EID 1370 and Last Consulted EID fields are identical, the SWIMA-PV knows that 1371 it has received a result list that is complete, given the parameters 1372 of the request, up to the present time. 1374 On the other hand, if the Last EID is greater than the Last Consulted 1375 EID, the SWIMA-PV has received a partial result list. (The Last 1376 Consulted EID MUST NOT exceed the Last EID.) In this case, if the 1377 SWIMA-PV wishes to try to collect the rest of the partially delivered 1378 result list it then sends a new SWIMA Request whose EID is one 1379 greater than the Last Consulted EID in the preceding response. Doing 1380 this causes the SWIMA-PC to generate another SWIMA Response attribute 1381 containing event records where the earliest reported event record is 1382 the one immediately after the event record with the Last Consulted 1383 EID (since EIDs are assigned sequentially). By repeating this 1384 process until it receives a SWIMA Response where the Last EID and 1385 Last Consulted EID are equal, the SWIMA-PV is able to collect all 1386 event records over a given range, even if the complete set of event 1387 records would be too large to deliver via a single attribute. 1389 Implementers need to be aware that a SWIMA Request might specify an 1390 EID that is greater than the EID of the last event recorded by a 1391 SWIMA-PC. In accordance with the behaviors described in 1392 Section 3.7.4, a SWIMA-PC MUST respond to such a request with a SWIMA 1393 Response attribute that contains zero event records. This is because 1394 the SWIMA-PC has recorded no event records with EIDs greater than or 1395 equal to the EID in the SWIMA Request. In such a case, the Last 1396 Consulted EID field MUST be set to the same value as the Last EID 1397 field in this SWIMA Response attribute. This case is called out 1398 because the consulted range on a SWIMA-PC in such a situation is a 1399 negative range, where the "first" EID in the range (provided in the 1400 SWIMA Request) is greater than the "last" EID in the range (this 1401 being the EID of the last recorded event on the SWIMA-PC). 1402 Implementers need to ensure that SWIMA-PCs do not experience problems 1403 in such a circumstance. 1405 Note that this specification only supports the returning of partial 1406 results when returning event records. There is no way to return a 1407 partial inventory list under this specification. 1409 3.7.6. Synchronizing Event Identifiers and Epochs 1411 Since EIDs are sequential within an Epoch, if a SWIMA-PV's list of 1412 event records contains gaps in the EID values within a single Epoch, 1413 the SWIMA-PV knows that there are events that have not been accounted 1414 for. The SWIMA-PV can either request a new event list to collect the 1415 missing events or request a full inventory to re-sync its 1416 understanding of the state of the endpoint's Software Inventory 1417 Evidence Collection. In either case, after the SWIMA-PV's record of 1418 the endpoint's Software Inventory Evidence Collection has been 1419 updated, the SWIMA-PV can record the new latest EID value and track 1420 events normally from that point on. 1422 If the SWIMA-PV receives any attribute from a SWIMA-PC where the EID 1423 Epoch differs from the EID Epoch that was used previously, then 1424 SWIMA-PV or any entity using this information to track the endpoint's 1425 Software Inventory Evidence Collection knows that there is a 1426 discontinuity in their understanding of the endpoint's state. To 1427 move past this discontinuity and reestablish a current understanding 1428 of the state of the endpoint's Software Inventory Evidence 1429 Collection, the SWIMA-PV needs to receive a full inventory from the 1430 endpoint. The SWIMA-PV cannot be brought in sync with the endpoint's 1431 state through the collection of any set of event records in this 1432 situation. This is because it is not possible to account for all 1433 events on the SWIMA-PC since the previous Epoch was used, because 1434 there is no way to query for EIDs from a previous Epoch. Once the 1435 SWIMA-PV has received a full inventory for the new Epoch, the SWIMA- 1436 PV records the latest EID reported in this new Epoch and can track 1437 further events normally. 1439 A SWIMA-PC MUST NOT report events with EIDs from any Epoch other than 1440 the current EID Epoch. The SWIMA-PC MAY choose to purge all event 1441 records from a previous Epoch from memory after an Epoch change. 1442 Alternately, the SWIMA-PC MAY choose to retain some event records 1443 from a previous EID Epoch and assign them new EIDs in the current 1444 Epoch. However, in the case where a SWIMA-PC chooses the latter 1445 option it MUST ensure that the order of events according to their 1446 EIDs is unchanged and that there is no coverage gap between the first 1447 retained event recorded during the previous Epoch (now reassigned 1448 with an EID in the current Epoch) and the first event recorded during 1449 the current Epoch. In particular, the SWIMA-PC MUST ensure that all 1450 change events that occurred after the last recorded event from the 1451 previous Epoch are known and recorded. (This might not be possible 1452 if the Epoch change is due to state corruption on the SWIMA-PC.) A 1453 SWIMA-PC might choose to reassign EIDs to records from a preceding 1454 Epoch to create a "sliding window" of events, where each Epoch change 1455 represents a shift in the window of available events. 1457 In the case where a SWIMA-PC suffers a crash and loses track of its 1458 current EID Epoch or current EID, then it MUST generate a new EID 1459 Epoch value and begin assigning EIDs within that Epoch. In this 1460 case, the SWIMA-PC MUST purge all event records from before the crash 1461 as it cannot ensure that there is not a gap between the last of those 1462 records and the next detected event. The process for generating a 1463 new EID Epoch MUST minimize the possibility that the newly generated 1464 EID Epoch is the same as a previously used EID Epoch. 1466 The SWIMA-PV will normally never receive an attribute indicating that 1467 the latest EID is less than the latest EID reported in a previous 1468 attribute within the same EID Epoch. If this occurs, the SWIMA-PC 1469 has suffered an error of some kind, possibly indicative of at least 1470 partial corruption of its event log. In this case, the SWIMA-PV MUST 1471 treat the situation as if there was a change in Epoch and treat any 1472 local copy of the endpoint's Software Inventory Evidence Collection 1473 as out-of-sync until a full inventory can be reported by the SWIMA- 1474 PC. In this case, the SWIMA-PV SHOULD log the occurrence so the 1475 SWIMA-PC can be examined to ensure it is now operating properly. 1477 3.8. Subscriptions 1479 Thus far, all attribute exchanges discussed assume that a SWIMA-PV 1480 sent an SWIMA Request attribute and the SWIMA-PC is providing a 1481 direct response to that request. The SWIMA specification also 1482 supports the ability for a SWIMA-PC to send a SWIMA Response to the 1483 SWIMA-PV in response to observed changes in the endpoint's software 1484 inventory evidence collection, instead of in direct response to a 1485 SWIMA Request. An agreement by a SWIMA-PC to send content when 1486 certain changes are detected to the endpoint's Software Inventory 1487 Evidence Collection is referred to in this specification as a 1488 "subscription", and the SWIMA-PV that receives this content is said 1489 to be "subscribed to" the given SWIMA-PC. All SWIMA-PCs and SWIMA- 1490 PVs MUST support the use of subscriptions. 1492 3.8.1. Establishing Subscriptions 1494 A SWIMA-PV establishes a subscription on a particular SWIMA-PC by 1495 sending a SWIMA Request attribute with the Subscription flag set. 1496 The SWIMA Request attribute is otherwise identical to the SWIMA 1497 Requests discussed in previous sections. Specifically, such a SWIMA 1498 Request might or might not request inclusion of software inventory 1499 evidence records, might or might not be targeted, and might request 1500 change event records or endpoint inventory. Assuming no error is 1501 encountered, a SWIMA-PC MUST send a SWIMA Response attribute in 1502 direct response to this SWIMA Request attribute, just as if the 1503 Subscription flag was not set. As such, the attribute exchange that 1504 establishes a new subscription in a SWIMA-PC has the same flow seen 1505 in the previous attribute exchanges, as depicted in Figure 2. If the 1506 SWIMA-PV does not receive a PA-TNC Error attribute (as described in 1507 Section 3.9 and Section 5.16) in response to their subscription 1508 request, the subscription has been successfully established on the 1509 SWIMA-PC. The SWIMA Request attribute that establishes a new 1510 subscription is referred to as the "establishing request" for that 1511 subscription. 1513 When a subscription is established it is assigned a Subscription ID 1514 value. The Subscription ID is equal to the value of the Request ID 1515 of the establishing request. (For more about Request IDs, see 1516 Section 5.6.) 1518 A SWIMA-PC MUST have the ability to record and support at least 8 1519 simultaneous subscriptions and SHOULD have the ability to support 1520 more than this. These subscriptions might all come from a single 1521 SWIMA-PV, might all be from different SWIMA-PVs, or might be a mix. 1522 In the case that a SWIMA-PC receives a subscription request but is 1523 unable to support an additional subscription, it MUST respond to the 1524 request with a PA-TNC Error attribute of type 1525 SWIMA_SUBSCRIPTION_DENIED_ERROR. 1527 A SWIMA-PV MUST have the ability to record and support at least 256 1528 simultaneous subscriptions and SHOULD have the ability to support 1529 more than this. Any number of these subscriptions might be to the 1530 same SWIMA-PC and any number of these subscriptions might be to 1531 different SWIMA-PCs. 1533 3.8.2. Managing Subscriptions 1535 The SWIMA-PC MUST record each accepted subscription along with the 1536 identity of the party to whom attributes are to be pushed in 1537 compliance with the subscription. This identity includes both the 1538 NEA Server's connection ID and the Posture Validator Identifier from 1539 the PB-PA message that delivered the request. 1541 Likewise, SWIMA-PVs MUST record each accepted subscription for which 1542 they are the subscribing party along with the associated Subscription 1543 ID and the identity of the SWIMA-PC that will be fulfilling the 1544 subscription. The SWIMA-PV needs to retain this information in order 1545 to correctly interpret pushed SWIMA Response attributes sent in 1546 fulfillment of the subscription. The identity of the SWIMA-PC is 1547 given in the Posture Collector Identifier of the PB-PA message header 1548 in all messages from that SWIMA-PC. 1550 3.8.3. Terminating Subscriptions 1552 Subscriptions MAY be terminated at any time by the subscribing SWIMA- 1553 PV by setting the Clear Subscriptions flag in a SWIMA Request. (See 1554 Section 5.7 for more on using this flag.) In the case that a SWIMA 1555 Request with the Clear Subscriptions flag set is received the SWIMA- 1556 PC MUST only clear subscriptions that match both the NEA server 1557 connection ID and the SWIMA-PV ID for this SWIMA Request, and MUST 1558 clear all such subscriptions. 1560 This specification does not give the SWIMA-PV the ability to 1561 terminate subscriptions individually - all subscriptions to the 1562 SWIMA-PV are cleared when the Clear Subscriptions flag is set. 1564 This specification does not give the SWIMA-PC the ability to 1565 unilaterally terminate a subscription. However, if the SWIMA-PC 1566 experiences a fatal error fulfilling a subscription, resulting in 1567 sending a PA-TNC Error attribute of type 1568 SWIMA_SUBSCRIPTION_FULFILLMENT_ERROR, then the subscription whose 1569 fulfillment led to the error MUST be treated as terminated by both 1570 the SWIMA-PC and the SWIMA-PV. Only the subscription experiencing 1571 the error is cancelled and other subscriptions are unaffected. See 1572 Section 3.9 for more on this error condition. 1574 Finally, a subscription is terminated if the connection between the 1575 SWIMA-PC and SWIMA-PV is deleted. This occurs when the connection ID 1576 used in the messages between the SWIMA-PC and the SWIMA-PV becomes 1577 unbound. Loss of this connection ID would prevent the SWIMA-PC from 1578 sending messages in fulfillment of this subscription. As such, loss 1579 of the connection ID necessarily forces subscription termination 1580 between the affected parties. 1582 3.8.4. Subscription Status 1584 A SWIMA-PV can request that a SWIMA-PC report the list of active 1585 subscriptions for which the SWIMA-PV is the subscriber. A SWIMA-PV 1586 can use this to recover lost information about active subscriptions. 1587 A SWIMA-PV can also use this capability to verify that a SWIMA-PC has 1588 not forgotten any of its subscriptions. The latter is especially 1589 useful where a SWIMA-PC does not send any attributes in fulfillment 1590 of a given subscription for a long period of time. The SWIMA-PV can 1591 check the list of active subscriptions on the SWIMA-PC and verify 1592 whether the inactivity is due to a lack of reportable events or due 1593 to the SWIMA-PC forgetting its obligations to fulfill a given 1594 subscription. 1596 A SWIMA-PV requests a list of its subscriptions on a given SWIMA-PC 1597 by sending that SWIMA-PC a Subscription Status Request. The SWIMA-PC 1598 MUST then respond with a Subscription Status Response (or a PA-TNC 1599 Error if an error condition is experienced). The Subscription Status 1600 Response MUST contain one subscription record for each of the active 1601 subscriptions for which the SWIMA-PV is the subscribing party. 1603 3.8.5. Fulfilling Subscriptions 1605 As noted in Section 3.6 SWIMA-PCs are required to automatically 1606 detect changes to an endpoint's Software Inventory Evidence 1607 Collection in near real-time. For every active subscription, the 1608 SWIMA-PC MUST send an attribute to the subscribed SWIMA-PV whenever a 1609 change is detected to relevant records within the endpoint's Software 1610 Inventory Evidence Collection. Such an attribute is said to be sent 1611 "in fulfillment of" the given subscription and any such attribute 1612 MUST include that subscription's Subscription ID. If the 1613 establishing request for that subscription was a targeted request, 1614 then only records that match the Software Identifiers provided in 1615 that establishing request are considered relevant. Otherwise, (i.e., 1616 for non-targeted requests) any record is considered relevant for this 1617 purpose. Figure 3 shows a sample attribute exchange where a 1618 subscription is established and then later attributes are sent from 1619 the SWIMA-PC in fulfillment of the established subscription. 1621 +-------------+ +--------------+ 1622 | SWIMA-PC | | SWIMA-PV | Time 1623 +-------------+ +--------------+ | 1624 | | | 1625 |<----------SWIMA Request-----------| | 1626 | | | 1627 |-----------SWIMA Response--------->| | 1628 | | | 1629 . . . 1630 . . . 1631 . . . 1632 | | | 1633 |----------SWIMA Response---------->| | 1634 | | | 1635 . . . 1636 . . . 1637 . . . 1638 | | | 1639 |----------SWIMA Response---------->| | 1640 | | V 1642 Figure 3: Subscription Establishment and Fulfillment 1644 The contents of an attribute sent in fulfillment of a subscription 1645 depend on the parameters provided in the establishing request for 1646 that subscription. Specifically, the contents of an attribute sent 1647 in fulfillment of a subscription have the same format as would a 1648 direct response to the establishing request. For example, if the 1649 establishing request stipulated a response that contained an event 1650 record list that included software inventory evidence records, all 1651 attributes sent in fulfillment of this subscription will also consist 1652 of event record lists with software inventory evidence records. As 1653 such, all SWIMA Responses displayed in the exchange depicted in 1654 Figure 3 have the same format. A SWIMA Response generated in 1655 fulfillment of an active subscription MUST be a valid SWIMA Response 1656 attribute according to all the rules outlined in the preceding 1657 sections. In other words, an attribute constructed in fulfillment of 1658 a subscription will look the same as an attribute sent in direct 1659 response to an explicit request from a SWIMA-PV that had the same 1660 request parameters and which arrived immediately after the given 1661 change event. There are a few special rules that expand on this 1662 guideline: 1664 3.8.5.1. Subscriptions Reporting Inventories 1666 In the case that a SWIMA-PV subscribes to a SWIMA-PC requesting an 1667 inventory attribute whenever changes are detected (i.e., the EID in 1668 the establishing request is 0), then the SWIMA-PC MUST send the 1669 requested inventory whenever a relevant change is detected. (A 1670 "relevant change" is any change for untargeted requests, or a change 1671 to an indicated record in a targeted request.) Upon detection of a 1672 relevant change for an active subscription, the SWIMA-PC sends the 1673 appropriate inventory information as if it had just received the 1674 establishing request. Attributes sent in fulfillment of this 1675 subscription will probably have a large amount of redundancy, as the 1676 same records are likely to be present in each of these SWIMA 1677 Attributes. The role of an inventory subscription is not to report 1678 records just for the items that changed - that is the role of a 1679 subscription that reports events (see Section 3.8.5.2). A SWIMA-PC 1680 MUST NOT exclude a record from an attribute sent in fulfillment of an 1681 inventory subscription simply because that record was not involved in 1682 the triggering event (although a record might be excluded for other 1683 reasons, such as if the subscription is targeted - see 1684 Section 3.8.5.3). 1686 3.8.5.2. Subscriptions Reporting Events 1688 The way in which a SWIMA-PV indicates it wishes to establish a 1689 subscription requesting event records is by providing a non-zero EID 1690 in the SWIMA Request establishing the subscription (see 1691 Section 3.7.1). However, when the SWIMA-PC constructs an attribute 1692 in fulfillment of the subscription (other than the direct response to 1693 the establishing request), it MUST only include event records for the 1694 detected change(s) that precipitated this response attribute. In 1695 other words, it MUST NOT send a complete list of all changes starting 1696 with the establishing request's EID, up through the latest change, 1697 every time a new event is detected. In effect, the EID in the 1698 establishing request is treated as being updated every time an 1699 attribute is sent in fulfillment of this subscription, such that a 1700 single event is not reported twice in fulfillment of a single 1701 subscription. As such, every SWIMA-PC MUST track the EID of the last 1702 event that triggered an attribute for the given subscription. When 1703 the next event (or set of events) is detected, the SWIMA-PC MUST only 1704 report events with EIDs after the last reported event. In the case 1705 that the EID Epoch of the SWIMA-PC changes, the SWIMA-PC MUST reset 1706 this EID tracker to 0 (if the event log is completely purged) or to 1707 the new EID of the last reported retained event (if the event log is 1708 partially purged to create a "sliding window"). Doing this ensures 1709 that the SWIMA-PC continues to only send events that have not been 1710 previously reported. 1712 Note that while a subscription is active, the subscribing SWIMA-PV 1713 MAY make other requests for event records that overlap with events 1714 that are reported in fulfillment of a subscription. Such requests 1715 are unaffected by the presence of the subscription, nor is the 1716 subscription affected by such requests. In other words, a given 1717 request will get the same results back whether or not there was a 1718 subscription. Likewise, an attribute sent in fulfillment of a 1719 subscription will contain the same information whether or not other 1720 requests had been received from the SWIMA-PV. 1722 A SWIMA-PV needs to pay attention to the EID Epoch in these 1723 attributes, as changes in the Epoch might create discontinuities in 1724 the SWIMA-PV's understanding of the endpoint's Software Inventory 1725 Evidence Collection state, as discussed in Section 3.7.6. In 1726 particular, once the EID Epoch changes, a SWIMA-PV is unable to have 1727 confidence that it has a correct understanding of the state of an 1728 endpoint's Software Inventory Evidence Collection until after the 1729 SWIMA-PV collects a complete inventory. 1731 SWIMA-PCs MAY send partial lists of event records in fulfillment of a 1732 subscription. (See Section 3.7.5 for more on partial list of event 1733 records.) In the case that a SWIMA-PC sends a partial list of event 1734 records in fulfillment of a subscription, it MUST immediately send 1735 the next consecutive partial list, and continue doing so until it has 1736 sent the equivalent of the complete list of event records. In other 1737 words, if the SWIMA-PC sends a partial list it does not wait for 1738 another change event to send another SWIMA Response, but continues 1739 sending SWIMA Responses until it has sent all event records that 1740 would have been included in a complete fulfillment of the 1741 subscription. Note that the direct response to the establishing 1742 request is not considered to be sent in fulfillment of a 1743 subscription. However, in this case the SWIMA-PC MUST treat the 1744 presence of unreported events as a triggering event for pushing 1745 additional messages in fulfillment of the newly established 1746 subscription. As such, the net effect is that, if the direct 1747 response to the establishing request (i.e., the Subscription 1748 Fulfillment flag is unset) is partial, the SWIMA-PC will immediately 1749 follow this with additional attributes (with the Subscription 1750 Fulfillment flag set) until the complete set of events has been sent 1751 to the SWIMA-PV. 1753 3.8.5.3. Targeted Subscriptions 1755 Subscriptions MAY be targeted to only apply to records that match a 1756 given set of Software Identifiers. In the case where changes are 1757 detected that affect multiple records, some matching the establishing 1758 request's Software Identifiers and some not, the attribute sent in 1759 fulfillment of the subscription MUST only include inventory or events 1760 (as appropriate) for records that match the establishing request's 1761 Software Identifiers. The SWIMA-PC MUST NOT include non-matching 1762 records in the attribute, even if those non-matching records 1763 experienced change events that were co-temporal with change events on 1764 the matching records. 1766 In addition, a SWIMA-PC MUST send an attribute in fulfillment of a 1767 targeted subscription only when changes to the endpoint's Software 1768 Inventory Evidence Collection impact one or more records matching the 1769 subscription's establishing request's Software Identifiers. A SWIMA- 1770 PC MUST NOT send any attribute in fulfillment of a targeted 1771 subscription based on detected change to the endpoint's Software 1772 Inventory Evidence Collection that did not involve any of the records 1773 targeted by that subscription. 1775 3.8.5.4. No Subscription Consolidation 1777 A SWIMA-PV MAY establish multiple subscriptions to a given SWIMA-PC. 1778 If this is the case, it is possible that a single change event on the 1779 endpoint might require fulfillment by multiple subscriptions, and 1780 that the information included in attributes that fulfill each of 1781 these subscriptions might overlap. The SWIMA-PC MUST send separate 1782 attributes for each established subscription that requires a response 1783 due to the given event. Each of these attributes MUST contain all 1784 information required to fulfill that individual subscription, even if 1785 that information is also sent in other attributes sent in fulfillment 1786 of other subscriptions at the same time. In other words, SWIMA-PCs 1787 MUST NOT attempt to combine information when fulfilling multiple 1788 subscriptions simultaneously, even if this results in some redundancy 1789 in the attributes sent to the SWIMA-PV. 1791 3.8.5.5. Delayed Subscription Fulfillment 1793 A SWIMA-PC MAY delay the fulfillment of a subscription following a 1794 change event in the interest of waiting to see if additional change 1795 events are forthcoming and, if so, conveying the relevant records 1796 back to the SWIMA-PV in a single SWIMA Response attribute. This can 1797 help reduce network bandwidth consumption between the SWIMA-PC and 1798 the SWIMA-PV. For example, consider a situation where 10 changes 1799 occur a tenth of a second apart. If the SWIMA-PC does not delay in 1800 assembling and sending SWIMA Response attributes, the SWIMA-PV will 1801 receive 10 separate SWIMA Response attributes over a period of 1 1802 second. However, if the SWIMA-PC waits half a second after the 1803 initial event before assembling a SWIMA Response, the SWIMA-PV only 1804 receives two SWIMA Response attributes over the same period of time. 1806 Note that the ability to consolidate events for a single subscription 1807 over a given period of time does not contradict the rules in 1808 Section 3.8.5.4 prohibiting consolidation across multiple 1809 subscriptions. When delaying fulfillment of subscriptions, SWIMA-PCs 1810 are still required to fulfill each individual subscription 1811 separately. Moreover, in the case that change events within the 1812 delay window cancel each other out (e.g., a record is deleted and 1813 then re-added), the SWIMA-PC MUST still report each change event 1814 rather than just reporting the net effect of changes over the delay 1815 period. In other words, delayed fulfillment can decrease the number 1816 of attributes send by the SWIMA-PC, but it does not reduce the total 1817 number of change events reported. 1819 SWIMA-PCs are not required to support delayed fulfillment of 1820 subscriptions. However, in the case that the SWIMA-PC does support 1821 delayed subscription fulfillment, it MUST be possible to configure 1822 the SWIMA-PC to disable delayed fulfillment. In other words, parties 1823 deploying SWIMA-PCs need to be allowed to disable delayed 1824 subscription fulfillment in their SWIMA-PCs. The manner in which 1825 such configuration occurs is left to the discretion of implementers, 1826 although implementers MUST protect the configuration procedure from 1827 unauthorized tampering. In other words, there needs to be some 1828 assurance that unauthorized individuals are not able to introduce 1829 long delays in subscription fulfillment. 1831 3.9. Error Handling 1833 In the case where the SWIMA-PC detects an error in a SWIMA Request 1834 attribute that it receives it MUST respond with a PA-TNC Error 1835 attribute with an error code appropriate to the nature of the error. 1836 (See Section 4.2.8 of PA-TNC [RFC5792] for more details about PA-TNC 1837 Error attributes and error codes as well as Section 5.16 in this 1838 specification for error codes specific to SWIMA Attributes.) In the 1839 case that an error is detected in a SWIMA Request the SWIMA-PC MUST 1840 NOT take any action requested by this SWIMA Request, even if partial 1841 completion of the request is possible. In other words, a SWIMA 1842 Request that contains an error is completely ignored by the SWIMA-PC 1843 (beyond sending a PA-TNC Error attribute, and possibly logging the 1844 error locally) rather than being partially executed. 1846 In the case where the SWIMA-PC receives a valid SWIMA Request 1847 attribute but experiences an error during the process of responding 1848 to that attribute's instructions where that error prevents the SWIMA- 1849 PC from properly or completely fulfilling that request, the SWIMA-PC 1850 MUST send a PA-TNC Error attribute with an error code appropriate to 1851 the nature of the error. In the case where a PA-TNC Error attribute 1852 is sent, the SWIMA-PC MUST NOT take any of the actions requested by 1853 the SWIMA Request attribute which led to the detected error. This is 1854 the case even if some actions could have been completed successfully, 1855 and might even require the SWIMA-PC to reverse some successful 1856 actions already taken before the error condition was detected. In 1857 other words, either all aspects of a SWIMA Request complete fully and 1858 successfully (in which case the SWIMA-PC sends a SWIMA Response 1859 attribute), or no aspects of the SWIMA Request occur (in which case 1860 the SWIMA-PC sends a PA-TNC Error attribute). In the case that a 1861 SWIMA-PC sends a PA-TNC Error attribute in response to a SWIMA 1862 Request then the SWIMA-PC MUST NOT also send any SWIMA Response 1863 attribute in response to the same SWIMA Request. For this reason, 1864 the sending of a SWIMA Response attribute MUST be the last action 1865 taken by a SWIMA-PC in response to a SWIMA Request to avoid the 1866 possibility of a processing error occurring after that SWIMA Response 1867 attribute is sent. 1869 In the case that the SWIMA-PC detects an error that prevents it from 1870 properly or completely fulfilling its obligations under an active 1871 subscription, the SWIMA-PC MUST send a PA-TNC Error attribute of type 1872 SWIMA_SUBSCRIPTION_FULFILLMENT_ERROR to the SWIMA-PV that established 1873 this subscription. This type of PA-TNC Error attribute identifies 1874 the specific subscription that cannot be adequately honored due to 1875 the error condition as well as an error "sub-type". The error sub- 1876 type is used to indicate the type of error condition the SWIMA-PC 1877 experienced that prevented it from honoring the given subscription. 1878 In the case that the error condition cannot be identified or does not 1879 align with any of the defined error codes, the SWIMA_ERROR error code 1880 SHOULD be used in the sub-type. In the case that a 1881 SWIMA_SUBSCRIPTION_FULFILLMENT_ERROR is sent, the associated 1882 subscription MUST be treated as cancelled by both the SWIMA-PC and 1883 SWIMA-PV. 1885 The SWIMA-PV MUST NOT send any PA-TNC Error attributes to SWIMA-PCs. 1886 In the case that a SWIMA-PV detects an error condition, it SHOULD log 1887 this error but does not inform any SWIMA-PC's of this event. Errors 1888 might include, but are not limited to, detection of malformed SWIMA 1889 Response attributes sent from a given SWIMA-PC, as well as detection 1890 of error conditions when the SWIMA-PV processes SWIMA Responses. 1892 Both SWIMA-PCs and SWIMA-PVs SHOULD log errors so that administrators 1893 can trace the causes of errors. Log entries SHOULD include the type 1894 of the error, the time it was detected, and additional descriptive 1895 information to aid in understanding the nature and cause of the 1896 error. Logs are an important debugging tool and implementers are 1897 strongly advised to include comprehensive logging capabilities in 1898 their products. 1900 4. Protocol 1902 The software inventory protocol supports two different types of 1903 message exchanges which are described the following subsections, 1904 along with implementation requirements for supporting these 1905 exchanges. 1907 4.1. Direct Response to a SWIMA Request 1909 The first type of exchange is used to provide the SWIMA-PV with a 1910 software inventory or event collection from the queried endpoint. 1912 +-------------+ +--------------+ 1913 | SWIMA-PC | | SWIMA-PV | Time 1914 +-------------+ +--------------+ | 1915 | | | 1916 |<-----------SWIMA Request------------| | 1917 | | | 1918 | SWIMA Response* | | 1919 |-----------------or----------------->| | 1920 | PA-TNC Error | | 1921 | | V 1923 *SWIMA Response is one of the following: Software Identifier 1924 Inventory, Software Identifier Events, Software Inventory, 1925 or Software Events. 1927 Figure 4: SWIMA Attribute Exchange (Direct Response to SWIMA Request) 1929 In this exchange, the SWIMA-PV indicates to the SWIMA-PC, via a SWIMA 1930 Request, the nature of the information it wishes to receive 1931 (inventory vs. events, full or targeted) and how it wishes the 1932 returned inventory to be expressed (with or without software 1933 inventory evidence records). The SWIMA-PC responds with the 1934 requested information using the appropriate attribute type. A single 1935 SWIMA Request MUST only lead to a single SWIMA Response or PA-TNC 1936 Error that is in direct response to that request. 1938 4.2. Subscription-Based Response 1940 The second type of exchange allows change event-based reporting based 1941 on a subscription. If there is an active subscription on the 1942 endpoint, the SWIMA-PC sends a SWIMA Response to the SWIMA-PV 1943 following a change event on the endpoint in fulfillment of that 1944 subscription. Such an exchange is shown in Figure 5. 1946 +-------------+ +--------------+ 1947 | SWIMA-PC | | SWIMA-PV | Time 1948 +-------------+ +--------------+ | 1949 | | | 1950 | | | 1951 |------SWIMA Response(s)*------>| | 1952 | | | 1954 *SWIMA Response is one of the following: Software Identifier 1955 Inventory, Software Identifier Events, Software Inventory, 1956 or Software Events. 1958 Figure 5: SWIMA Attribute Exchange (In Fulfillment of an Active 1959 Subscription) 1961 Note that, unlike direct responses to a SWIMA Request, a single 1962 change event can precipitate multiple SWIMA Responses for a single 1963 subscription, but only if all but the last of those SWIMA Responses 1964 convey partial lists of event records. When providing multiple SWIMA 1965 Responses in this way, the initial responses contain partial lists of 1966 event records and the last of those SWIMA Responses conveys the 1967 remainder of the relevant event records, completing the delivery of 1968 all relevant events in response to the change event. A single Change 1969 Event MUST NOT otherwise be followed by multiple SWIMA Response or 1970 PA-TNC Error attributes in any combination. 1972 4.3. Required Exchanges 1974 All SWIMA-PVs and SWIMA-PCs MUST support both types of exchanges. In 1975 particular, SWIMA-PCs MUST be capable of pushing a SWIMA Response to 1976 a SWIMA-PV immediately upon detection of a change to the endpoint's 1977 Software Inventory Evidence Collection in fulfillment of established 1978 SWIMA-PV subscriptions, as described in Section 3.8. 1980 5. Software Inventory Messages and Attributes 1982 This section describes the format and semantics of the SWIMA 1983 protocol. This protocol uses the PA-TNC message header format 1984 [RFC5792]. 1986 5.1. PA Subtype (AKA PA-TNC Component Type) 1988 The NEA PB-TNC interface provides a general message-batching protocol 1989 capable of carrying one or more PA-TNC messages between the Posture 1990 Broker Client and Posture Broker Server. When PB-TNC is carrying a 1991 PA-TNC message, the PB-TNC message headers contain a 32 bit 1992 identifier called the PA Subtype. The PA Subtype field indicates the 1993 type of component associated with all of the PA-TNC attributes 1994 carried by the PB-TNC message. The core set of PA Subtypes is 1995 defined in the PA-TNC specification. This specification defines a 1996 new "SWIMA Attributes" PA Subtype, which is registered in 1997 Section 10.1 of this document, which is used as a namespace for the 1998 collection of SWIMA Attributes defined in this document. 2000 For more information on PB-TNC and PA-TNC messages and message 2001 headers, see the PB-TNC [RFC5793] and PA-TNC [RFC5792] 2002 specifications, respectively. 2004 5.2. SWIMA Attribute Overview 2006 Each PA-TNC attribute described in this specification is intended to 2007 be sent between the SWIMA-PC and SWIMA-PV, so will be carried in a 2008 PB-TNC message indicating a PA Subtype of "SWIMA Attributes". PB-TNC 2009 messages MUST always include the SWIMA Attributes Subtype defined in 2010 Section 5.1 when carrying SWIMA Attributes over PA-TNC. The 2011 attributes defined in this specification appear below along with a 2012 short summary of their purposes. 2014 PA-TNC attribute types are identified in the PA-TNC Attribute Header 2015 via the Attribute Type Vendor ID and Attribute Type fields. Table 1 2016 identifies the appropriate values for these fields for each attribute 2017 type used within the SWIMA protocol. All attributes have a PEN value 2018 of 0x000000. For the Integer value field, both the hexadecimal and 2019 decimal values are provided. Each attribute is described in greater 2020 detail in subsequent sections identified in the attribute 2021 description. 2023 +--------------+------------+---------------------------------------+ 2024 | Attribute | Integer | Description | 2025 | Name | | | 2026 +--------------+------------+---------------------------------------+ 2027 | SWIMA | 0x0000000D | Request sent from a SWIMA-PV to a | 2028 | Request | (13) | SWIMA-PC for the SWIMA-PC to provide | 2029 | | | a software inventory or event list. | 2030 | | | It might also establish a | 2031 | | | subscription. (Section 5.7) | 2032 | | | | 2033 | Software | 0x0000000E | An inventory sent without software | 2034 | Identifier | (14) | inventory evidence records sent from | 2035 | Inventory | | a SWIMA-PC. (Section 5.8) | 2036 | | | | 2037 | Software | 0x0000000F | A collection of events impacting the | 2038 | Identifier | (15) | endpoint's Software Inventory | 2039 | Events | | Evidence Collection, where events do | 2040 | | | not include software inventory | 2041 | | | evidence records. (Section 5.9) | 2042 | | | | 2043 | Software | 0x00000010 | An inventory including software | 2044 | Inventory | (16) | inventory evidence records sent from | 2045 | | | a SWIMA-PC. (Section 5.10) | 2046 | | | | 2047 | Software | 0x00000011 | A collection of events impacting the | 2048 | Events | (17) | endpoint's Software Inventory | 2049 | | | Evidence Collection, where events | 2050 | | | include software inventory evidence | 2051 | | | records. (Section 5.11) | 2052 | | | | 2053 | Subscription | 0x00000012 | A request for a list of a SWIMA-PV's | 2054 | Status | (18) | active subscription on a SWIMA-PC. | 2055 | Request | | (Section 5.12) | 2056 | | | | 2057 | Subscription | 0x00000013 | A list of a SWIMA-PV's active | 2058 | Status | (19) | subscriptions on a SWIMA-PC. (Section | 2059 | Response | | 5.13) | 2060 | | | | 2061 | Source | 0x00000014 | A request for information about a | 2062 | Metadata | (20) | SWIMA-PC's data sources. (Section | 2063 | Request | | 5.14) | 2064 | | | | 2065 | Subscription | 0x00000015 | Descriptive metadata about a SWIMA- | 2066 | Metadata | (21) | PC's data sources. (Section 5.15) | 2067 | Response | | | 2068 | | | | 2069 | PA-TNC Error | 0x00000008 | An error attribute as defined in the | 2070 | | (8) | PA-TNC specification [RFC5792]. | 2071 +--------------+------------+---------------------------------------+ 2073 Table 1: SWIMA Attribute Enumeration 2075 Because one of the Software Identifier Inventory, Software Identifier 2076 Events, Software Inventory, or Software Events attributes are 2077 expected to be sent to a SWIMA-PV in direct response to a SWIMA 2078 Request attribute or in fulfillment of an active subscription, those 2079 four attribute types are referred to collectively in this document as 2080 "SWIMA Response attributes". 2082 All SWIMA-PVs MUST be capable of sending SWIMA Request attributes and 2083 be capable of receiving and processing all SWIMA Response attributes 2084 as well as PA-TNC Error attributes. All SWIMA-PCs MUST be capable of 2085 receiving and processing SWIMA Request attributes and be capable of 2086 sending all types of SWIMA Response attributes as well as PA-TNC 2087 Error attributes. In other words, both SWIMA-PVs and SWIMA-PCs are 2088 required to support their role in exchanges using any of the 2089 attribute types defined in this section. SWIMA-PVs MUST ignore any 2090 SWIMA Request attributes that they receive. SWIMA-PCs MUST ignore 2091 any SWIMA Response attributes or PA-TNC Error attributes that they 2092 receive. 2094 5.3. Message Diagram Syntax 2096 This specification defines the syntax of new PA-TNC messages and 2097 attributes using diagrams. Each diagram depicts the format and size 2098 of each field in bits. Implementations MUST send the bits in each 2099 diagram as they are shown from left to right for each 32-bit quantity 2100 traversing the diagram from top to bottom. Fields representing 2101 numeric values MUST be sent in network (big endian) byte order. 2103 Descriptions of bit fields (e.g., flags) values refer to the position 2104 of the bit within the field. These bit positions are numbered from 2105 the most significant bit through the least significant bit. As such, 2106 an octet with only bit 0 set would have a value of 0x80 (1000 0000), 2107 an octet with only bit 1 set would have a value of 0x40 (0100 0000), 2108 and an octet with only bit 7 set would have a value of 0x01 (0000 2109 0001). 2111 5.4. SWIMA Attribute Enumeration 2113 5.5. Normalization of Text Encoding 2115 In order to ensure consistency of transmitted attributes some fields 2116 require normalization of their format. When this is necessary, this 2117 is indicated in the field's description. In such cases, the field 2118 contents MUST be normalized to Network Unicode format as defined in 2119 RFC 5198 [RFC5198]. Network Unicode format defines a refinement of 2120 UTF-8 [RFC3629] that ensures a normalized expression of characters. 2121 SWIMA-PCs and SWIMA-PVs MUST NOT perform conversion and normalization 2122 on any field values except those specifically identified as requiring 2123 normalization in the following sections. Note, however, that some 2124 data models require additional normalization before source 2125 information is added to an Endpoint's Inventory Evidence Collection 2126 as a record. The references from the Software Data Model IANA table 2127 (see Section 10.4) will note where this is necessary. 2129 5.6. Request IDs 2131 All SWIMA Request attributes MUST include a Request ID value. The 2132 Request ID field provides a value that identifies a given request 2133 relative to other requests between a SWIMA-PV and the receiving 2134 SWIMA-PC. Specifically, the SWIMA-PV assigns each SWIMA Request 2135 attribute a Request ID value that is intended to be unique within the 2136 lifetime of a given network connection ID as assigned by the SWIMA- 2137 PV's Posture Broker Server. 2139 In the case that a SWIMA Request requests the establishment of a 2140 subscription and the receiving SWIMA-PC agrees to that subscription, 2141 the Request ID of that SWIMA Request (i.e., the establishing request 2142 of the subscription) becomes that subscription's Subscription ID. 2143 All attributes sent in fulfillment of this subscription include a 2144 flag indicating that the attribute fulfills a subscription and the 2145 subscription's Subscription ID. A SWIMA-PV MUST NOT reuse a Request 2146 ID value in communicating to a given SWIMA-PC while that Request ID 2147 is also serving as a Subscription ID for an active subscription with 2148 that SWIMA-PC. In the case where a SWIMA-PC receives a SWIMA Request 2149 from a given SWIMA-PV where that Request ID is also the Subscription 2150 ID of an active subscription with that SWIMA-PV, the SWIMA-PC MUST 2151 respond with a PA-TNC Error attribute with an error code of 2152 SWIMA_SUBSCRIPTION_ID_REUSE_ERROR. Note that this error does not 2153 cancel the indicated subscription. 2155 Subscription Status Requests and Subscription Status Responses do not 2156 include Request IDs. 2158 In the case where all possible Request ID values have been exhausted 2159 within the lifetime of a single network connection ID, the sender MAY 2160 reuse previously used Request IDs within the same network connection 2161 if the ID is not being used as a Subscription ID. In such a case of 2162 Request ID reuse, Request IDs SHOULD be reused in the order of their 2163 original use. In other words, a SWIMA-PC SHOULD NOT use a given 2164 Request ID value more than once within a persistent connection 2165 between a given Posture Broker Client-Posture Broker Server pair. In 2166 the case where reuse is necessary due to exhaustion of possible ID 2167 values, the SWIMA-PC SHOULD structure the reuse to maximize the time 2168 between original and subsequent use. The Request ID value is 2169 included in a SWIMA Response attribute directly responding to this 2170 SWIMA Request to indicate which SWIMA Request was received and caused 2171 the response. Request IDs can be randomly generated or sequential, 2172 as long as values are not repeated per the rules in this paragraph. 2173 SWIMA-PCs are not required to check for duplicate Request IDs. 2175 5.7. SWIMA Request 2177 A SWIMA-PV sends this attribute to a SWIMA-PC to request that the 2178 SWIMA-PC send software inventory information to the SWIMA-PV. A 2179 SWIMA-PC MUST NOT send this attribute. 2181 1 2 3 2182 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2184 | Flags | Software Identifier Count | 2185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2186 | Request ID | 2187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2188 | Earliest EID | 2189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2190 | | 2191 | SUB-BLOCK (Repeated "Software Identifier Count" times) | 2192 | | 2193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2195 Figure 6: SWIMA Request Attribute 2197 1 2 3 2198 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2200 | Software Identifier Length | Software Identifier (var len) | 2201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2203 Figure 7: SWIMA Request Attribute SUB-BLOCK 2205 +---------------+---------------------------------------------------+ 2206 | Field | Description | 2207 +---------------+---------------------------------------------------+ 2208 | Flags: Bit 0 | If set (1), the SWIMA-PC MUST delete all | 2209 | - Clear | subscriptions established by the requesting | 2210 | Subscriptions | SWIMA-PV (barring any errors). | 2211 | | | 2212 | Flags: Bit 1 | If set (1), in addition to responding to the | 2213 | - Subscribe | request as described, the SWIMA-PC MUST establish | 2214 | | a subscription with parameters matching those in | 2215 | | the request attribute (barring any errors). | 2216 | | | 2217 | Flags: Bit 2 | If unset (0), the SWIMA-PC's response MUST | 2218 | - Result Type | include software inventory evidence records and | 2219 | | thus the response MUST be a Software Inventory, a | 2220 | | Software Events, or a PA-TNC Error attribute. If | 2221 | | set (1), the response MUST NOT include software | 2222 | | inventory evidence records and thus the response | 2223 | | MUST be a Software Identifier Inventory, a | 2224 | | Software Identifier Events, or a PA-TNC Error | 2225 | | attribute. | 2226 | | | 2227 | Flags: Bit | Reserved for future use. This field MUST be set | 2228 | 3-7 - | to zero on transmission and ignored upon | 2229 | Reserved | reception. | 2230 | | | 2231 | Software | A 3-byte unsigned integer indicating the number | 2232 | Identifier | of Software Identifiers that follow. If this | 2233 | Count | value is non-zero, this is a targeted request, as | 2234 | | described in Section 3.5. The Software | 2235 | | Identifier Length and Software Identifier fields | 2236 | | are repeated, in order, the number of times | 2237 | | indicated in this field. In the case where | 2238 | | Software Identifiers are present, the SWIMA-PC | 2239 | | MUST only report software that corresponds to the | 2240 | | identifiers the SWIMA-PV provided in this | 2241 | | attribute (or with a PA-TNC Error attribute). | 2242 | | This field value MAY be 0, in which case there | 2243 | | are no instances of the Software Identifier | 2244 | | Length and Software Identifier fields. In this | 2245 | | case, the SWIMA-PV is indicating an interest in | 2246 | | all software inventory evidence records on the | 2247 | | endpoint (i.e., this is not a targeted request). | 2248 | | | 2249 | Request ID | A value that uniquely identifies this SWIMA | 2250 | | Request from a particular SWIMA-PV. | 2251 | | | 2252 | Earliest EID | In the case where the SWIMA-PV is requesting | 2253 | | software events, this field contains the EID | 2254 | | value of the earliest event the SWIMA-PV wishes | 2255 | | to have reported. (Note - the report will be | 2256 | | inclusive of the event with this EID value.) In | 2257 | | the case where the SWIMA-PV is requesting an | 2258 | | inventory, then this field MUST be 0. | 2259 | | (0x00000000) In the case where this field is non- | 2260 | | zero, the SWIMA-PV is requesting events and the | 2261 | | SWIMA-PC MUST respond using a Software Events, | 2262 | | Software Identifier Events, or a PA-TNC Error | 2263 | | attribute. In the case where this field is zero, | 2264 | | the SWIMA-PV is requesting an inventory and the | 2265 | | SWIMA-PC MUST respond using a Software Inventory, | 2266 | | a Software Identifier Inventory, or a PA-TNC | 2267 | | Error attribute. | 2268 | | | 2269 | Software | A 2-byte unsigned integer indicating the length | 2270 | Identifier | in bytes of the Software Identifier field. | 2271 | Length | | 2272 | | | 2273 | Software | A string containing the Software Identifier value | 2274 | Identifier | from a software inventory evidence record. This | 2275 | | field value MUST be normalized to Network Unicode | 2276 | | format, as described in Section 5.5. This string | 2277 | | MUST NOT be NULL terminated. | 2278 +---------------+---------------------------------------------------+ 2280 Table 2: SWIMA Request Attribute Fields 2282 The SWIMA-PV sends the SWIMA Request attribute to a SWIMA-PC to 2283 request the indicated information. Note that between the Result Type 2284 flag and the Earliest EID field, the SWIMA-PC is constrained to a 2285 single possible SWIMA Response attribute type (or a PA-TNC Error 2286 attribute) in its response to the request. 2288 The Subscribe and Clear Subscription flags are used to manage 2289 subscriptions for the requesting SWIMA-PV on the receiving SWIMA-PC. 2290 Specifically, an attribute with the Subscribe flag set seeks to 2291 establish a new subscription by the requesting SWIMA-PV to the given 2292 SWIMA-PC, while an attribute with the Clear Subscription flag seeks 2293 to delete all existing subscriptions by the requesting SWIMA-PV on 2294 the given SWIMA-PC. Note that, in the latter case, only the 2295 subscriptions associated with the Connection ID and the Posture 2296 Validator ID of the requester are deleted as described in 2297 Section 3.8.3. A newly established subscription has the parameters 2298 outlined in the Request attribute. Specifically, the Result Type 2299 flag indicates the type of result to send in fulfillment of the 2300 subscription, the value of the Earliest EID field indicates whether 2301 the fulfillment attributes list inventories or events, and the fields 2302 describing Software Identifiers (if present) indicate if and how a 2303 subscription is targeted. In the case that the SWIMA-PC is unable or 2304 unwilling to comply with the SWIMA-PV's request to establish or clear 2305 subscriptions, the SWIMA-PC MUST respond with a PA-TNC Error 2306 attribute with the SWIMA_SUBSCRIPTION_DENIED_ERROR error code. If 2307 the SWIMA-PV requests that subscriptions be cleared but has no 2308 existing subscriptions, this is not an error. 2310 An attribute requesting the establishment of a subscription is 2311 effectively doing double-duty, as it is a request for an immediate 2312 response from the SWIMA-PC in addition to setting up the 2313 subscription. Assuming the SWIMA-PC is willing to comply with the 2314 subscription it MUST send an appropriate response attribute to a 2315 request with the Subscribe flag set containing all requested 2316 information. The same is true of the Clear Subscription flag - 2317 assuming there is no error the SWIMA-PC MUST generate a response 2318 attribute without regard to the presence of this flag in addition to 2319 clearing its subscription list. 2321 Both the Subscribe and Clear Subscription flags MAY be set in a 2322 single SWIMA Request attribute. In the case where this request is 2323 successful, the end result MUST be equivalent to the SWIMA-PC 2324 clearing its subscription list for the given SWIMA-PV first and then 2325 creating a new subscription in accordance with the request 2326 parameters. In other words, do not first create the new subscription 2327 and then clear all the subscriptions including the one that was just 2328 created. In the case that the requested actions are successfully 2329 completed, the SWIMA-PC MUST respond with a SWIMA Response attribute. 2330 The specific type of SWIMA Response attribute depends on the Result 2331 Type and Earliest EID fields, as described above. In the case where 2332 there is a failure that prevents some part this request from 2333 completing, the SWIMA-PC MUST NOT add a new subscription, MUST NOT 2334 clear the old subscriptions, and the SWIMA-PC MUST respond with a PA- 2335 TNC Error attribute. In other words, the SWIMA-PC MUST NOT partially 2336 succeed at implementing such a request; either all actions succeed, 2337 or none succeed. 2339 The Earliest EID field is used to indicate if the SWIMA-PV is 2340 requesting an inventory or event list from the SWIMA-PC. A value of 2341 0 (0x00000000) represents a request for inventory information. 2342 Otherwise, the SWIMA-PV is requesting event information. For 2343 Earliest EID values other than 0, the SWIMA-PC's response MUST 2344 respond with event records, as described in Section 3.7. Note that 2345 the request does not identify a particular EID Epoch, since responses 2346 can only include events in the SWIMA-PC's current EID Epoch. 2348 The Software Identifier Count indicates the number of Software 2349 Identifiers in the attribute. This number might be any value between 2350 0 and 16,777,216, inclusive. A single Software Identifier is 2351 represented by the following fields: Software Identifier Length and 2352 Software Identifier. These fields are repeated a number of times 2353 equal to the Software Identifier Count, which may be 0. The Software 2354 Identifier Length field indicates the number of bytes allocated to 2355 the Software Identifier field. The Software Identifier field 2356 contains a Software Identifier as describe in Section 3.4.1. The 2357 presence of one or more Software Identifiers is used by the SWIMA-PV 2358 to indicate a targeted request, which seeks only inventories of or 2359 events affecting software corresponding to the given identifiers. 2360 The SWIMA-PC MUST only report software that matched the Software 2361 Identifiers provided in the SWIMA-PVs SWIMA Request attribute. 2363 5.8. Software Identifier Inventory 2365 A SWIMA-PC sends this attribute to a SWIMA-PV to convey the inventory 2366 of the endpoint's Software Inventory Evidence Collection without the 2367 inclusion of software inventory evidence records. This list might 2368 represent a complete inventory or a targeted list of records, 2369 depending on the parameters in the SWIMA-PV's request. A SWIMA-PV 2370 MUST NOT send this attribute. The SWIMA-PC either sends this 2371 attribute in fulfillment of an existing subscription where the 2372 establishing request has a Result Type of 1 and the Earliest EID is 2373 zero, or in direct response to a SWIMA Request attribute where the 2374 Result Type is 1 and the Earliest EID is zero. 2376 1 2 3 2377 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2379 | Flags | Software Identifier Count | 2380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2381 | Request ID Copy / Subscription ID | 2382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2383 | EID Epoch | 2384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2385 | Last EID | 2386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2387 | | 2388 | SUB-BLOCK (Repeated "Software Identifier Count" times) | 2389 | | 2390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2392 Figure 8: Software Identifier Inventory Attribute 2394 1 2 3 2395 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2397 | Record Identifier | 2398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2399 | Data Model Type PEN |Data Model Type| 2400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2401 | Source Id Num | Software Identifier Length |Software Id (v)| 2402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2403 | Software Locator Length |Software Locator (variable len)| 2404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2406 Figure 9: Software Identifier Inventory Attribute SUB-BLOCK 2408 +----------------+--------------------------------------------------+ 2409 | Field | Description | 2410 +----------------+--------------------------------------------------+ 2411 | Flags: Bit 0 - | In the case that this attribute is sent in | 2412 | Subscription | fulfillment of a subscription this bit MUST be | 2413 | Fulfillment | set (1). In the case that this attribute is a | 2414 | | direct response to a SWIMA Request, this bit | 2415 | | MUST be unset (0). | 2416 | | | 2417 | Flags: Bit 1-7 | Reserved for future use. This field MUST be set | 2418 | - Reserved | to zero on transmission and ignored upon | 2419 | | reception. | 2420 | | | 2421 | Software | The number of Software Identifiers that follow. | 2422 | Identifier | This field is an unsigned integer. The Record | 2423 | Count | Identifier, Data Model Type PEN, Data Model | 2424 | | Type, Source Identification Number, Software | 2425 | | Identifier Length, Software Identifier, Software | 2426 | | Locator Length, and Software Locator fields are | 2427 | | repeated, in order, the number of times | 2428 | | indicated in this field. This field value MAY be | 2429 | | 0, in which case there are no instances of these | 2430 | | fields. | 2431 | | | 2432 | Request ID | In the case where this attribute is in direct | 2433 | Copy / | response to a SWIMA Request attribute from a | 2434 | Subscription | SWIMA-PV, this field MUST contain an exact copy | 2435 | ID | of the Request ID field from that SWIMA Request. | 2436 | | In the case where this attribute is sent in | 2437 | | fulfillment of an active subscription, this | 2438 | | field MUST contain the Subscription ID of the | 2439 | | subscription being fulfilled by this attribute. | 2440 | | | 2441 | EID Epoch | The EID Epoch of the Last EID value. This field | 2442 | | is an unsigned 4-byte unsigned integer. | 2443 | | | 2444 | Last EID | The EID of the last event recorded by the SWIMA- | 2445 | | PC, or 0 if the SWIMA-PC has no recorded events. | 2446 | | This field is an unsigned 4-byte unsigned | 2447 | | integer. | 2448 | | | 2449 | Record | A 4-byte unsigned integer containing the Record | 2450 | Identifier | Identifier value from a software inventory | 2451 | | evidence record. | 2452 | | | 2453 | Data Model | A 3-byte unsigned integer containing the Private | 2454 | Type PEN | Enterprise Number (PEN) of the organization that | 2455 | | assigned the meaning of the Data Model Type | 2456 | | value. | 2457 | | | 2458 | Data Model | A 1-byte unsigned integer containing an | 2459 | Type | identifier number that identifies the data model | 2460 | | of the reported record. | 2461 | | | 2462 | Source | The Source Identification Number associated with | 2463 | Identification | the source from which this software installation | 2464 | Number | inventory instance was reported. | 2465 | | | 2466 | Software | A 2-byte unsigned integer indicating the length | 2467 | Identifier | in bytes of the SW ID field. | 2468 | Length | | 2469 | | | 2470 | Software | A string containing the Software Identifier | 2471 | Identifier | value from a software inventory evidence record. | 2472 | | This field value MUST be normalized to Network | 2473 | | Unicode format as described in Section 5.5. This | 2474 | | string MUST NOT be NULL terminated. | 2475 | | | 2476 | Software | A 2-byte unsigned integer indicating the length | 2477 | Locator Length | in bytes of the Software Locator field. | 2478 | | | 2479 | Software | A string containing the Software Locator value. | 2480 | Locator | This field value MUST first be normalized to | 2481 | | Network Unicode format, as described in Section | 2482 | | 5.5, and then encoded as a URI [RFC3986]. This | 2483 | | string MUST NOT be NULL terminated. | 2484 +----------------+--------------------------------------------------+ 2486 Table 3: Software Identifier Inventory Attribute Fields 2488 In the case that this attribute is sent in fulfillment of a 2489 subscription, the Subscription Fulfillment bit MUST be set (1). In 2490 the case that this attribute is sent in direct response to a SWIMA 2491 Request, the Subscription Fulfillment bit MUST be unset (0). Note 2492 that the SWIMA Response attribute sent in direct response to a SWIMA 2493 Request that establishes a subscription (i.e., a subscription's 2494 establishing request) MUST be treated as a direct response to that 2495 SWIMA Request (and thus the Subscription Fulfillment bit is unset). 2496 SWIMA Response attributes are only treated as being in fulfillment of 2497 a subscription (i.e., Subscription Fulfillment bit set) if they are 2498 sent following a change event, as shown in Figure 3. 2500 The Software Identifier Count field indicates the number of Software 2501 Identifiers present in this inventory. Each Software Identifier is 2502 represented by the following set of fields: Record Identifier, Data 2503 Model Type, Software Identifier Length, Software Identifier, Software 2504 Locator Length, and Software Locator. These fields will appear once 2505 for each reported record. 2507 When responding directly to a SWIMA Request attribute, the Request ID 2508 Copy / Subscription ID field MUST contain an exact copy of the 2509 Request ID field from that SWIMA Request. When this attribute is 2510 sent in fulfillment of an existing subscription on this Posture 2511 Collector, then this field MUST contain the Subscription ID of the 2512 fulfilled subscription. 2514 The EID Epoch field indicates the EID Epoch of the Last EID value. 2515 The Last EID field MUST contain the EID of the last recorded change 2516 event (see Section 3.7 for more about EIDs and recorded events) at 2517 the time this inventory was collected. In the case where there are 2518 no recorded change events at the time that this inventory was 2519 collected, the Last EID field MUST contain 0. These fields can be 2520 interpreted to indicate that the provided inventory reflects the 2521 state of the endpoint after all changes up to and including this last 2522 event have been accounted for. 2524 The Data Model Type PEN and Data Model Type fields are used to 2525 identify the data model associated with the given software record. 2526 These fields are discussed more in Section 3.4.2. 2528 The Source Identification Number field is used to identify the source 2529 that provided the given record, as described in Section 3.1. 2531 5.9. Software Identifier Events 2533 A SWIMA-PC sends this attribute to a SWIMA-PV to convey events where 2534 the affected records are reported without software inventory evidence 2535 records. A SWIMA-PV MUST NOT send this attribute. The SWIMA-PC 2536 either sends this attribute in fulfillment of an existing 2537 subscription where the establishing request has a Result Type is 1 2538 and the Earliest EID is non-zero, or in direct response to a SWIMA 2539 Request attribute where the Result Type is 1 and the Earliest EID is 2540 non-zero. 2542 1 2 3 2543 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2545 | Flags | Event Count | 2546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2547 | Request ID Copy / Subscription ID | 2548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2549 | EID Epoch | 2550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2551 | Last EID | 2552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2553 | Last Consulted EID | 2554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2555 | | 2556 | SUB-BLOCK (Repeated "Event Count" times) | 2557 | | 2558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2560 Figure 10: Software Identifier Events Attribute 2561 1 2 3 2562 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2564 | EID | 2565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2566 | | 2567 +- -+ 2568 | | 2569 +- -+ 2570 | Timestamp | 2571 +- -+ 2572 | | 2573 +- -+ 2574 | | 2575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2576 | Record Identifier | 2577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2578 | Data Model Type PEN |Data Model Type| 2579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2580 | Source Id Num | Action | Software Identifier Length | 2581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2582 | Software Identifier (variable length) | 2583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2584 | Software Locator Length |Software Locator (variable len)| 2585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2587 Figure 11: Software Identifier Events Attribute SUB-BLOCK 2589 +----------------+--------------------------------------------------+ 2590 | Field | Description | 2591 +----------------+--------------------------------------------------+ 2592 | Flags: Bit 0 - | In the case that this attribute is sent in | 2593 | Subscription | fulfillment of a subscription this bit MUST be | 2594 | Fulfillment | set (1). In the case that this attribute is a | 2595 | | direct response to a SWIMA Request, this bit | 2596 | | MUST be unset (0). | 2597 | | | 2598 | Flags: Bit 1-7 | Reserved for future use. This field MUST be set | 2599 | - Reserved | to zero on transmission and ignored upon | 2600 | | reception. | 2601 | | | 2602 | Event Count | The number of events that are reported in this | 2603 | | attribute. This field is a 3-byte unsigned | 2604 | | integer. The EID, Timestamp, Record Identifier, | 2605 | | Data Model Type PEN, Data Model Type, Source | 2606 | | Identification Number, Action, Software | 2607 | | Identifier Length, Software Identifier, Software | 2608 | | Locator Length, and Software Locator fields are | 2609 | | repeated, in order, the number of times | 2610 | | indicated in this field. This field value MAY be | 2611 | | 0, in which case there are no instances of these | 2612 | | fields. | 2613 | | | 2614 | Request ID | In the case where this attribute is in direct | 2615 | Copy / | response to a SWIMA Request attribute from a | 2616 | Subscription | SWIMA-PV, this field MUST contain an exact copy | 2617 | ID | of the Request ID field from that SWIMA Request. | 2618 | | In the case where this attribute is sent in | 2619 | | fulfillment of an active subscription, this | 2620 | | field MUST contain the Subscription ID of the | 2621 | | subscription being fulfilled by this attribute. | 2622 | | | 2623 | EID Epoch | The EID Epoch of the Last EID value. This field | 2624 | | is an unsigned 4-byte unsigned integer. | 2625 | | | 2626 | Last EID | The EID of the last event recorded by the SWIMA- | 2627 | | PC, or 0 if the SWIMA-PC has no recorded events. | 2628 | | This field contains the EID of the SWIMA-PC's | 2629 | | last recorded change event (which might or might | 2630 | | not be included as an event record in this | 2631 | | attribute). | 2632 | | | 2633 | Last Consulted | The EID of the last event record that was | 2634 | EID | consulted when generating the event record list | 2635 | | included in this attribute. This is different | 2636 | | from the Last EID field value if and only if | 2637 | | this attribute is conveying a partial list of | 2638 | | event records. See Section 3.7.5 for more on | 2639 | | partial list of event records. | 2640 | | | 2641 | EID | The EID of the event in this event record. | 2642 | | | 2643 | Timestamp | The timestamp associated with the event in this | 2644 | | event record. This timestamp is the SWIMA-PC's | 2645 | | best understanding of when the given event | 2646 | | occurred. Note that this timestamp might be an | 2647 | | estimate. The Timestamp date and time MUST be | 2648 | | represented as an RFC 3339 [RFC3339] compliant | 2649 | | ASCII string in Coordinated Universal Time (UTC) | 2650 | | time with the additional restrictions that the | 2651 | | 'T' delimiter and the 'Z' suffix MUST be | 2652 | | capitalized and fractional seconds (time- | 2653 | | secfrac) MUST NOT be included. This field | 2654 | | conforms to the date-time ABNF production from | 2655 | | section 5.6 of RFC 3339 with the above | 2656 | | restrictions. Leap seconds are permitted and | 2657 | | SWIMA-PVs MUST support them. The Timestamp | 2658 | | string MUST NOT be NULL terminated or padded in | 2659 | | any way. The length of this field is always 20 | 2660 | | octets. | 2661 | | | 2662 | Record | A 4-byte unsigned integer containing the Record | 2663 | Identifier | Identifier value from a software inventory | 2664 | | evidence record. | 2665 | | | 2666 | Data Model | A 3-byte unsigned integer containing the Private | 2667 | Type PEN | Enterprise Number (PEN) of the organization that | 2668 | | assigned the meaning of the Data Model Type | 2669 | | value. | 2670 | | | 2671 | Data Model | A 1-byte unsigned integer containing an | 2672 | Type | identifier number that identifies the data model | 2673 | | of the reported record. | 2674 | | | 2675 | Source | The Source Identification Number associated with | 2676 | Identification | the source from which this software installation | 2677 | Number | inventory instance was reported. | 2678 | | | 2679 | Action | The type of event that is recorded in this event | 2680 | | record. Possible values are: 1 = CREATION - the | 2681 | | addition of a record to the endpoint's Software | 2682 | | Inventory Evidence Collection; 2 = DELETION - | 2683 | | the removal of a record from the endpoint's | 2684 | | Software Inventory Evidence Collection; 3 = | 2685 | | ALTERATION - There was an alteration to a record | 2686 | | within the endpoint's Software Inventory | 2687 | | Evidence Collection. All other values are | 2688 | | reserved for future use and MUST NOT be used | 2689 | | when sending attributes. In the case where a | 2690 | | SWIMA-PV receives an event record that uses an | 2691 | | action value other than the ones defined here, | 2692 | | it MUST ignore that event record but SHOULD | 2693 | | process other event records in this attribute as | 2694 | | normal. | 2695 | | | 2696 | Software | A 2-byte unsigned integer indicating the length | 2697 | Identifier | in bytes of the SW ID field. | 2698 | Length | | 2699 | | | 2700 | Software | A string containing the Software Identifier | 2701 | Identifier | value from a software inventory evidence record. | 2702 | | This field value MUST first be normalized to | 2703 | | Network Unicode format as described in Section | 2704 | | 5.5. This string MUST NOT be NULL terminated. | 2705 | | | 2706 | Software | A 2-byte unsigned integer indicating the length | 2707 | Locator Length | in bytes of the Software Locator field. | 2708 | | | 2709 | Software | A string containing the Software Locator value. | 2710 | Locator | This field value MUST first be normalized to | 2711 | | Network Unicode format, as described in Section | 2712 | | 5.5, and then encoded as a URI [RFC3986]. This | 2713 | | string MUST NOT be NULL terminated. | 2714 +----------------+--------------------------------------------------+ 2716 Table 4: Software Identifier Events Attribute Fields 2718 The first few fields in the Software Identifier Events attribute 2719 mirror those in the Software Identifier Inventory attribute. The 2720 primary difference is that, instead of conveying an inventory, the 2721 attribute conveys zero or more event records, consisting of the EID, 2722 timestamp, Record Identifier, action type, data model type, Software 2723 Identifier, and Software Locator of the affected software inventory 2724 evidence record. 2726 With regard to the Timestamp field, it is important to note that 2727 clock skew between the SWIMA-PC and SWIMA-PV as well as between 2728 different SWIMA-PCs within an enterprise might make correlation of 2729 timestamp values difficult. This specification does not attempt to 2730 resolve clock skew issues, although other mechanisms outside of this 2731 specification do exist to reduce the impact of clock skew and make 2732 the timestamp more useful for such correlation. Instead, SWIMA uses 2733 the Timestamp value primarily as a means to indicate the amount of 2734 time between two events on a single endpoint. For example, by taking 2735 the difference of the times for when a record was removed and then 2736 subsequently re-added, one can get an indication as to how long the 2737 system was without the given record (and, thus without the associated 2738 software). Since this will involve comparison of timestamp values 2739 all originating on the same system, clock skew between the SWIMA-PC 2740 and SWIMA-PV is not an issue. However, if the SWIMA-PC's clock was 2741 adjusted between two recorded events, it is possible for such a 2742 calculation to lead to incorrect understandings of the temporal 2743 distance between events. Users of this field need to be aware of the 2744 possibility for such occurrences. In the case where the Timestamp 2745 values of two events appear to contradict the EID ordering of those 2746 events (i.e., the later EID has an earlier timestamp) the recipient 2747 MUST treat the EID ordering as correct. 2749 All events recorded in a Software Identifier Events Attribute are 2750 required to be part of the same EID Epoch. Specifically, all 2751 reported events MUST have an EID from the same EID Epoch as each 2752 other, and which is the same as the EID Epoch of the Last EID and 2753 Last Consulted EID values. The SWIMA-PC MUST NOT report events with 2754 EIDs from different EID Epochs. 2756 The Last Consulted EID field contains the EID of the last event 2757 record considered for inclusion in this attribute. If this attribute 2758 contains a partial event set (as described in Section 3.7.5) this 2759 field value will be less than the Last EID value; if this attribute 2760 contains a complete event set, the Last EID and Last Consulted EID 2761 values are identical. 2763 If multiple events are sent in a Software Identifier Events 2764 attribute, the order in which they appear within the attribute is not 2765 significant. The EIDs associated with them are used for ordering the 2766 indicated events appropriately. Also note that a single software 2767 record might be reported multiple times in an attribute, such as if 2768 multiple events involving the associated record were being reported. 2770 5.10. Software Inventory 2772 A SWIMA-PC sends this attribute to a SWIMA-PV to convey a list of 2773 inventory records. A SWIMA-PV MUST NOT send this attribute. The 2774 SWIMA-PC either sends this attribute in fulfillment of an existing 2775 subscription where the establishing request had a Result Type of 0 2776 and the Earliest EID is zero, or in direct response to a SWIMA 2777 Request attribute where the Result Type is 0 and the Earliest EID is 2778 zero. 2780 1 2 3 2781 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2783 | Flags | Record Count | 2784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2785 | Request ID Copy / Subscription ID | 2786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2787 | EID Epoch | 2788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2789 | Last EID | 2790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2791 | | 2792 | SUB-BLOCK (Repeated "Record Count" times) | 2793 | | 2794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2796 Figure 12: Software Inventory Attribute 2797 1 2 3 2798 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2800 | Record Identifier | 2801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2802 | Data Model Type PEN |Data Model Type| 2803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2804 | Source Id Num | Software Identifier Length |Software Id (v)| 2805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2806 | Software Locator Length |Software Locator (variable len)| 2807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2808 | Record Length | 2809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2810 | Record (variable length) | 2811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2813 Figure 13: SWIMA Inventory Attribute SUB-BLOCK 2815 +----------------+--------------------------------------------------+ 2816 | Field | Description | 2817 +----------------+--------------------------------------------------+ 2818 | Flags: Bit 0 - | In the case that this attribute is sent in | 2819 | Subscription | fulfillment of a subscription this bit MUST be | 2820 | Fulfillment | set (1). In the case that this attribute is a | 2821 | | direct response to a SWIMA Request, this bit | 2822 | | MUST be unset (0). | 2823 | | | 2824 | Flags: Bit 1-7 | Reserved for future use. This field MUST be set | 2825 | - Reserved | to zero on transmission and ignored upon | 2826 | | reception. | 2827 | | | 2828 | Record Count | The number of records that follow. This field is | 2829 | | a 3-byte unsigned integer. The Record | 2830 | | Identifier, Data Model Type PEN, Data Model | 2831 | | Type, Source Identification Number, Software | 2832 | | Identifier Length, Software Identifier, Software | 2833 | | Locator Length, Software Locator, Record Length, | 2834 | | and Record fields are repeated, in order, the | 2835 | | number of times indicated in this field. This | 2836 | | field value MAY be 0 in which case there are no | 2837 | | instances of these fields. | 2838 | | | 2839 | Request ID | In the case where this attribute is in direct | 2840 | Copy / | response to a SWIMA Request attribute from a | 2841 | Subscription | SWIMA-PV, this field MUST contain an exact copy | 2842 | ID | of the Request ID field from that SWIMA Request. | 2843 | | In the case where this attribute is sent in | 2844 | | fulfillment of an active subscription, this | 2845 | | field MUST contain the Subscription ID of the | 2846 | | subscription being fulfilled by this attribute. | 2847 | | | 2848 | EID Epoch | The EID Epoch of the Last EID value. This field | 2849 | | is an unsigned 4-byte unsigned integer. | 2850 | | | 2851 | Last EID | The EID of the last event recorded by the SWIMA- | 2852 | | PC, or 0 if the SWIMA-PC has no recorded events. | 2853 | | This field is an unsigned 4-byte unsigned | 2854 | | integer. | 2855 | | | 2856 | Record | A 4-byte unsigned integer containing the Record | 2857 | Identifier | Identifier value from a software inventory | 2858 | | evidence record. | 2859 | | | 2860 | Data Model | A 3-byte unsigned integer containing the Private | 2861 | Type PEN | Enterprise Number (PEN) of the organization that | 2862 | | assigned the meaning of the Data Model Type | 2863 | | value. | 2864 | | | 2865 | Data Model | A 1-byte unsigned integer containing an | 2866 | Type | identifier number that identifies the data model | 2867 | | of the reported record. | 2868 | | | 2869 | Source | The Source Identification Number associated with | 2870 | Identification | the source from which this software installation | 2871 | Number | inventory instance was reported. | 2872 | | | 2873 | Software | A 2-byte unsigned integer indicating the length | 2874 | Identifier | in bytes of the SW ID field. | 2875 | Length | | 2876 | | | 2877 | Software | A string containing the Software Identifier | 2878 | Identifier | value from a software inventory evidence record. | 2879 | | This field value MUST first be normalized to | 2880 | | Network Unicode format as described in Section | 2881 | | 5.5. This string MUST NOT be NULL terminated. | 2882 | | | 2883 | Software | A 2-byte unsigned integer indicating the length | 2884 | Locator Length | in bytes of the Software Locator field. | 2885 | | | 2886 | Software | A string containing the Software Locator value. | 2887 | Locator | This field value MUST first be normalized to | 2888 | | Network Unicode format, as described in Section | 2889 | | 5.5, and then encoded as a URI [RFC3986]. This | 2890 | | string MUST NOT be NULL terminated. | 2891 | | | 2892 | Record Length | This is a 4-byte unsigned integer indicating the | 2893 | | length of the Record field in bytes. | 2894 | | | 2895 | Record | A software inventory evidence record as a | 2896 | | string. The record MUST be converted and | 2897 | | normalized to Network Unicode format as | 2898 | | described in Section 5.5. This string MUST NOT | 2899 | | be NULL terminated. | 2900 +----------------+--------------------------------------------------+ 2902 Table 5: Software Inventory Attribute Fields 2904 The Software Inventory attribute contains some number of software 2905 inventory evidence records along with the core response attribute 2906 fields. Given that the size of records can vary considerably, the 2907 length of this attribute is highly variable and, if transmitting a 2908 complete inventory, can be extremely large. Enterprises might wish 2909 to constrain the use of Software Inventory attributes to targeted 2910 requests to avoid over-burdening the network unnecessarily. 2912 When copying a software inventory evidence record into the Record 2913 field, the record MUST be converted and normalized to use Network 2914 Unicode format prior to its inclusion in the record field. 2916 5.11. Software Events 2918 A SWIMA-PC sends this attribute to a SWIMA-PV to convey a list of 2919 events that include software inventory evidence records. A SWIMA-PV 2920 MUST NOT send this attribute. The SWIMA-PC either sends this 2921 attribute in fulfillment of an existing subscription where the 2922 establishing request has a Result Type of 0 and the Earliest EID is 2923 non-zero, or in direct response to a SWIMA Request attribute where 2924 the Result Type is 0 and the Earliest EID is non-zero. 2926 1 2 3 2927 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2929 | Flags | Event Count | 2930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2931 | Request ID Copy / Subscription ID | 2932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2933 | EID Epoch | 2934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2935 | Last EID | 2936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2937 | Last Consulted EID | 2938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2939 | | 2940 | SUB-BLOCK (Repeated "Event Count" times) | 2941 | | 2942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2944 Figure 14: Software Events Attribute 2945 1 2 3 2946 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2948 | EID | 2949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2950 | | 2951 +- -+ 2952 | | 2953 +- -+ 2954 | Timestamp | 2955 +- -+ 2956 | | 2957 +- -+ 2958 | | 2959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2960 | Record Identifier | 2961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2962 | Data Model Type PEN |Data Model Type| 2963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2964 | Source Id Num | Action | Software Identifier Length | 2965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2966 | Software Identifier (variable length) | 2967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2968 | Software Locator Length |Software Locator (variable len)| 2969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2970 | Record Length | 2971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2972 | Record (variable Length) | 2973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2975 Figure 15: SWIMA Events Attribute SUB-BLOCK 2977 +----------------+--------------------------------------------------+ 2978 | Field | Description | 2979 +----------------+--------------------------------------------------+ 2980 | Flags: Bit 0 - | In the case that this attribute is sent in | 2981 | Subscription | fulfillment of a subscription this bit MUST be | 2982 | Fulfillment | set (1). In the case that this attribute is a | 2983 | | direct response to a SWIMA Request, this bit | 2984 | | MUST be unset (0). | 2985 | | | 2986 | Flags: Bit 1-7 | Reserved for future use. This field MUST be set | 2987 | - Reserved | to zero on transmission and ignored upon | 2988 | | reception. | 2989 | | | 2990 | Event Count | The number of events being reported in this | 2991 | | attribute. This field is a 3-byte unsigned | 2992 | | integer. The EID, Timestamp, Record Identifier, | 2993 | | Data Model Type PEN, Data Model Type, Source | 2994 | | Identification Number, Action, Software | 2995 | | Identifier Length, Software Identifier, Software | 2996 | | Locator Length, Software Locator, Record Length, | 2997 | | and Record fields are repeated, in order, the | 2998 | | number of times indicated in this field. This | 2999 | | field value MAY be 0, in which case there are no | 3000 | | instances of these fields. | 3001 | | | 3002 | Request ID | In the case where this attribute is in direct | 3003 | Copy / | response to a SWIMA Request attribute from a | 3004 | Subscription | SWIMA-PV, this field MUST contain an exact copy | 3005 | ID | of the Request ID field from that SWIMA Request. | 3006 | | In the case where this attribute is sent in | 3007 | | fulfillment of an active subscription, this | 3008 | | field MUST contain the Subscription ID of the | 3009 | | subscription being fulfilled by this attribute. | 3010 | | | 3011 | EID Epoch | The EID Epoch of the Last EID value. This field | 3012 | | is an unsigned 4-byte unsigned integer. | 3013 | | | 3014 | Last EID | The EID of the last event recorded by the SWIMA- | 3015 | | PC, or 0 if the SWIMA-PC has no recorded events. | 3016 | | This field contains the EID of the SWIMA-PC's | 3017 | | last recorded change event (which might or might | 3018 | | not be included as an event record in this | 3019 | | attribute). | 3020 | | | 3021 | Last Consulted | The EID of the last event record that was | 3022 | EID | consulted when generating the event record list | 3023 | | included in this attribute. This is different | 3024 | | from the Last EID field value if and only if | 3025 | | this attribute is conveying a partial list of | 3026 | | event records. See Section 3.7.5 for more on | 3027 | | partial list of event records. | 3028 | | | 3029 | EID | The EID of the event in this event record. | 3030 | | | 3031 | Timestamp | The timestamp associated with the event in this | 3032 | | event record. This timestamp is the SWIMA-PC's | 3033 | | best understanding of when the given event | 3034 | | occurred. Note that this timestamp might be an | 3035 | | estimate. The Timestamp date and time MUST be | 3036 | | represented as an RFC 3339 [RFC3339] compliant | 3037 | | ASCII string in Coordinated Universal Time (UTC) | 3038 | | time with the additional restrictions that the | 3039 | | 'T' delimiter and the 'Z' suffix MUST be | 3040 | | capitalized and fractional seconds (time- | 3041 | | secfrac) MUST NOT be included. This field | 3042 | | conforms to the date-time ABNF production from | 3043 | | section 5.6 of RFC 3339 with the above | 3044 | | restrictions. Leap seconds are permitted and | 3045 | | SWIMA-PVs MUST support them. The Timestamp | 3046 | | string MUST NOT be NULL terminated or padded in | 3047 | | any way. The length of this field is always 20 | 3048 | | octets. | 3049 | | | 3050 | Record | A 4-byte unsigned integer containing the Record | 3051 | Identifier | Identifier value from a software inventory | 3052 | | evidence record. | 3053 | | | 3054 | Data Model | A 3-byte unsigned integer containing the Private | 3055 | Type PEN | Enterprise Number (PEN) of the organization that | 3056 | | assigned the meaning of the Data Model Type | 3057 | | value. | 3058 | | | 3059 | Data Model | A 1-byte unsigned integer containing an | 3060 | Type | identifier number that identifies the data model | 3061 | | of the reported record. | 3062 | | | 3063 | Source | The Source Identification Number associated with | 3064 | Identification | the source from which this software installation | 3065 | Number | inventory instance was reported. | 3066 | | | 3067 | Action | The type of event that is recorded in this event | 3068 | | record. Possible values are: 1 = CREATION - the | 3069 | | addition of a record to the endpoint's Software | 3070 | | Inventory Evidence Collection; 2 = DELETION - | 3071 | | the removal of a record from the endpoint's | 3072 | | Software Inventory Evidence Collection; 3 = | 3073 | | ALTERATION - There was an alteration to a record | 3074 | | within the endpoint's Software Inventory | 3075 | | Evidence Collection. All other values are | 3076 | | reserved for future use and MUST NOT be used | 3077 | | when sending attributes. In the case where a | 3078 | | SWIMA-PV receives an event record that uses an | 3079 | | action value other than the ones defined here, | 3080 | | it MUST ignore that event record but SHOULD | 3081 | | process other event records in this attribute as | 3082 | | normal. | 3083 | | | 3084 | Software | A 2-byte unsigned integer indicating the length | 3085 | Identifier | in bytes of the Software Identifier field. | 3086 | Length | | 3087 | | | 3088 | Software | A string containing the Software Identifier | 3089 | Identifier | value from a software inventory evidence record. | 3090 | | This field value MUST first be normalized to | 3091 | | Network Unicode format as described in Section | 3092 | | 5.5. This string MUST NOT be NULL terminated. | 3093 | | | 3094 | Software | A 2-byte unsigned integer indicating the length | 3095 | Locator Length | in bytes of the Software Locator field. | 3096 | | | 3097 | Software | A string containing the Software Locator value. | 3098 | Locator | This field value MUST first be normalized to | 3099 | | Network Unicode format, as described in Section | 3100 | | 5.5, and then encoded as a URI [RFC3986]. This | 3101 | | string MUST NOT be NULL terminated. | 3102 | | | 3103 | Record Length | This is a 4-byte unsigned integer indicating the | 3104 | | length of the Record field in bytes. | 3105 | | | 3106 | Record | A software inventory evidence record as a | 3107 | | string. The record MUST be converted and | 3108 | | normalized to Network Unicode format as | 3109 | | described in Section 5.5. This string MUST NOT | 3110 | | be NULL terminated. | 3111 +----------------+--------------------------------------------------+ 3113 Table 6: Software Events Attribute Fields 3115 The fields of this attribute are used in the same way as the 3116 corresponding fields of the previous attributes. As with the 3117 Software Inventory attribute, a Software Events attribute can be 3118 quite large if many events have occurred following the event 3119 indicated by a request's Earliest EID. As such, it is recommended 3120 that the SWIMA Request attributes only request full records be sent 3121 (Result Type set to 0) in a targeted request, thus constraining the 3122 response just to records that match a given set of Software 3123 Identifiers. 3125 As with the Software Identifier Events Attribute, this attribute MUST 3126 only contain event records with EIDs coming from the current EID 3127 Epoch of the SWIMA-PC. 3129 As with the Software Inventory Attribute, the SWIMA-PC MUST perform 3130 conversion and normalization of the record. 3132 5.12. Subscription Status Request 3134 A SWIMA-PV sends this attribute to a SWIMA-PC to request a list of 3135 active subscriptions for which the requesting SWIMA-PV is the 3136 subscriber. A SWIMA-PC MUST NOT send this attribute. 3138 This attribute has no fields. 3140 A SWIMA-PC MUST respond to this attribute by sending a Subscription 3141 Status Response attribute (or a PA-TNC Error attribute if it is 3142 unable to correctly provide a response). 3144 5.13. Subscription Status Response 3146 A SWIMA-PC sends this attribute to a SWIMA-PV to report the list of 3147 active subscriptions for which the receiving SWIMA-PV is the 3148 subscriber. A SWIMA-PV MUST NOT send this attribute. 3150 1 2 3 3151 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3153 | Status Flags | Subscription Record Count | 3154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3155 | | 3156 | SUB-BLOCK (Repeated "Subscription Record Count" times) | 3157 | | 3158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3160 Figure 16: Subscription Status Response Attribute 3162 1 2 3 3163 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3165 | Flags | Software Identifier Count | 3166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3167 | Request ID | 3168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3169 | Earliest EID | 3170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3171 | | 3172 | SUB-SUB-BLOCK (Repeated "Software Identifier Count" times) | 3173 | | 3174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3176 Figure 17: SWIMA Status Response Attribute SUB-BLOCK 3177 1 2 3 3178 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3180 | Software Identifier Length | Software Identifier (var len) | 3181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3183 Figure 18: SWIMA Status Response Attribute SUB-SUB-BLOCK 3185 +--------------+----------------------------------------------------+ 3186 | Field | Description | 3187 +--------------+----------------------------------------------------+ 3188 | Status | Reserved for future use. This field MUST be set to | 3189 | Flags: Bit | zero on transmission and ignored upon reception. | 3190 | 0-7 - | | 3191 | Reserved | | 3192 | | | 3193 | Subscription | The number of subscription records that follow. | 3194 | Record Count | This field is a 3-byte unsigned integer. The | 3195 | | Flags, Software Identifier Count, Request ID, and | 3196 | | Earliest EID fields, and 0 or more instances of | 3197 | | Software Identifier Length and Software | 3198 | | Identifier, are repeated, in order, the number of | 3199 | | times indicated in this field. (The Software | 3200 | | Identifier Length and Software Identifier fields | 3201 | | within each of these sets of fields are repeated a | 3202 | | number of times equal to the preceding Software | 3203 | | Identifier Count value.) The Subscription Record | 3204 | | Count field value MAY be 0 in which case there are | 3205 | | no instances of these fields. | 3206 | | | 3207 | Flags, | For each active subscription, these fields contain | 3208 | Software | an exact copy of the fields with the same name as | 3209 | Identifier | provided in the subscription's establishing | 3210 | Count, | request. | 3211 | Request ID, | | 3212 | Earliest | | 3213 | EID, | | 3214 | Software | | 3215 | Identifier | | 3216 | Length, and | | 3217 | Software | | 3218 | Identifier | | 3219 +--------------+----------------------------------------------------+ 3221 Table 7: Subscription Status Response Fields 3223 A Subscription Status Response contains zero or more subscription 3224 records. Specifically, it MUST contain one subscription record for 3225 each active subscription associated with the party that sent the 3226 Subscription Status Request to which this attribute is a response. 3227 As described in Section 3.8.2, the SWIMA-PC MUST use the requester's 3228 Connection ID and its Posture Validator ID to determine which 3229 subscriptions are associated with the requester. 3231 A SWIMA-PC MUST send a Subscription Status Response attribute in 3232 response to a Subscription Status Request attribute. The only 3233 exception to this is if the SWIMA-PC experiences an error condition 3234 that prevents it from correctly populating the Subscription Status 3235 Response attribute, in which case it MUST respond with a PA-TNC Error 3236 attribute appropriate to the type of error experienced. If there are 3237 no active subscriptions associated with the requesting party, the 3238 Subscription Status Response attribute will consist of its Status 3239 Flags field, a Subscription Record Count field with a value of 0, and 3240 no additional fields. 3242 Each subscription record included in a Subscription Status Response 3243 attribute duplicates the fields of a SWIMA Request attribute that was 3244 the establishing request of a subscription. Note that the Request ID 3245 field in the record captures the Subscription ID associated with the 3246 given subscription record (since the Subscription ID is the same as 3247 the Request ID of the establishing request). Note also that if the 3248 establishing request is targeted, then its Record Count field will be 3249 non-zero and, within that subscription record, the Software 3250 Identifier Length and Software Identifier fields are repeated, in 3251 order, the number of times indicated in the Record Count field. As 3252 such, each subscription record can be different sizes. If the 3253 establishing request is not targeted (Record Count field is 0), the 3254 subscription record has no Software Identifier Length or Software 3255 Identifier fields. 3257 When a SWIMA-PV compares the information received in a Subscription 3258 Status Response to its own records of active subscriptions it should 3259 be aware that the SWIMA-PC might be unable to distinguish this SWIMA- 3260 PV from other SWIMA-PVs on the same NEA Server. As a result, it is 3261 possible that the SWIMA-PC will report more subscription records than 3262 the SWIMA-PV recognizes. For this reason, SWIMA-PVs SHOULD NOT 3263 automatically assume that extra subscriptions reported in a 3264 Subscription Status Response indicate a problem. 3266 5.14. Source Metadata Request 3268 A SWIMA-PV sends this attribute to a SWIMA-PC to request metadata 3269 about sources that the SWIMA-PC is using to collect software 3270 inventory information. A SWIMA-PC MUST NOT send this attribute. 3272 This attribute has no fields. 3274 A SWIMA-PC MUST respond to this attribute by sending a Sources 3275 Metadata Response attribute (or a PA-TNC Error attribute if it is 3276 unable to correctly provide a response). 3278 5.15. Source Metadata Response 3280 A SWIMA-PC sends this attribute to a SWIMA-PV to provide descriptive 3281 metadata about the sources of software inventory information used by 3282 the SWIMA-PC. A SWIMA-PV MUST NOT send this attribute. 3284 1 2 3 3285 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3287 | Reserved | Source Count | | 3288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3289 | | 3290 | SUB-BLOCK (Repeated "Source Count" times | 3291 | | 3292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3294 Source Metadata Response Attribute 3296 1 2 3 3297 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3299 | Source ID | Metadata Length | Metadata (var)| 3300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3302 Source Metadata Response Attribute SUB-BLOCK 3304 +----------+--------------------------------------------------------+ 3305 | Field | Description | 3306 +----------+--------------------------------------------------------+ 3307 | Reserved | Reserved for future use. This field MUST be set to | 3308 | | zero on transmission and ignored upon reception. | 3309 | | | 3310 | Source | The number of source records that follow. The Source | 3311 | Count | ID, Metadata Size, and Metadata fields are repeated, | 3312 | | in order, the number of times indicated by this field. | 3313 | | This field MAY be 0, in which case no fields follow | 3314 | | (but this would only be done to indicate that the | 3315 | | SWIMA-PC has no active sources, which would not be a | 3316 | | usual situation). | 3317 | | | 3318 | Source | The Source ID number associated with the described | 3319 | ID | source for any communications with the recipient | 3320 | | SWIMA-PV. | 3321 | | | 3322 | Metadata | A 2-byte unsigned integer indicating the length in | 3323 | Length | bytes of the Metadata field. | 3324 | | | 3325 | Metadata | A string containing descriptive metadata about the | 3326 | | indicated data source. This string MUST NOT be NULL | 3327 | | terminated. | 3328 +----------+--------------------------------------------------------+ 3330 Source Metadata Response Fields 3332 A Source Metadata Response attribute contains 0 or more records, each 3333 describing one of the data sources the SWIMA-PC uses to collect 3334 software inventory information. It SHOULD contain one metadata 3335 record for each source that the SWIMA-PC uses. (There might be 3336 reasons not to inform certain SWIMA-PVs of the presence of certain 3337 data sources.) The attribute MUST contain a metadata record for each 3338 source that has been identified in inventory or event messages to the 3339 given SWIMA-PV. 3341 A SWIMA-PC MUST send a Source Metadata Response attribute in response 3342 to a Source Metadata Request attribute. The only exception to this 3343 is if the SWIMA-PC experiences an error condition that prevents it 3344 from correctly populating the Source Metadata Response attribute, in 3345 which case it MUST respond with a PA-TNC Error attribute appropriate 3346 to the type of error experienced. 3348 The Source Count field indicates how many source metadata records are 3349 included in the attribute. Each included record consists of a Source 3350 Identifier, Metadata Length, and Metadata field. 3352 The Source Identifier corresponds to the Source Identifier field in 3353 inventory and event messages. In the case where the Source 3354 Identifier value in a Source Metadata Response attribute matches a 3355 Source Identifier associated with an event or inventory record and 3356 both the Source Metadata Response and the inventory/event record were 3357 sent to the same SWIMA-PV, the source described in the Metadata field 3358 MUST be the same source that provided the event or inventory record 3359 associated with the Source Identifier. Recall that a SWIMA-PC MAY 3360 use different Source Identifier associations with different SWIMA- 3361 PVs. As such, the association between a Source Identifier and the 3362 conveyed metadata is also only meaningful for communications between 3363 the sending SWIMA-PC and receiving SWIMA-PV. When sending to a given 3364 SWIMA-PV, the SWIMA-PC MUST use the recipient SWIMA-PVs Source 3365 Identifier associations. 3367 The Metadata Length indicates the length, in bytes, if the Metadata 3368 field. The Metadata field contains information about the indicated 3369 data source. This specification does not dictate a format for the 3370 contents of the Metadata field. This field MAY include machine- 3371 readable information. For broadest utility, the Metadata field 3372 SHOULD include human-readable, descriptive information about the data 3373 source. 3375 5.16. PA-TNC Error as Used by SWIMA 3377 The PA-TNC Error attribute is defined in the PA-TNC specification 3378 [RFC5792], and its use here conforms to that specification. A PA-TNC 3379 Error can be sent due to any error in the PA-TNC exchange and might 3380 also be sent in response to error conditions specific to the SWIMA 3381 exchange. The latter case utilizes error codes defined below. 3383 A PA-TNC Error MUST be sent by a SWIMA-PC in response to a SWIMA 3384 Request in the case where the SWIMA-PC encounters a fatal error 3385 (i.e., an error that prevents further processing of an exchange) 3386 relating to the attribute exchange. A SWIMA-PV MUST NOT send this 3387 attribute. In the case where the SWIMA-PV experiences a fatal error, 3388 it MUST handle the error without sending a PA-TNC Error attribute. 3389 The SWIMA-PV MAY take other actions in response to the error, such as 3390 logging the cause of the error, or even taking actions to isolate the 3391 endpoint. 3393 A PA-TNC Error attribute is sent instead of a SWIMA Response 3394 attribute due to factors that prevent the reliable creation of a 3395 SWIMA Response. As such, a SWIMA-PC MUST NOT send both a PA-TNC 3396 Error attribute and a SWIMA Response attribute in response to a 3397 single SWIMA Request attribute. 3399 Table 8 lists the Error Code values for the PA-TNC Error attribute 3400 specific to the SWIMA exchange. Error codes are shown in both 3401 hexadecimal and decimal format. In all of these cases, the Error 3402 Code Vendor ID field MUST be set to 0x000000, corresponding to the 3403 IETF SMI Private Enterprise Number. The Error Information structures 3404 for each error type are described in the following subsections. 3406 Note that a message with a SWIMA attribute might also result in an 3407 error condition covered by the Standard PA-TNC Error Codes defined in 3408 PA-TNC. For example, a SWIMA Attribute might have an invalid 3409 parameter, leading to an error code of "Invalid Parameter". In this 3410 case, the SWIMA-PC MUST use the appropriate PA-TNC Error Code value 3411 as defined in Section 4.2.8 of PA-TNC specification. 3413 +------------+------------------------------------------------------+ 3414 | Error Code | Description | 3415 | Value | | 3416 +------------+------------------------------------------------------+ 3417 | 0x00000004 | SWIMA_ERROR. This indicates a fatal error (i.e., an | 3418 | (4) | error that precludes the creation of a suitable | 3419 | | response attribute) other than the errors described | 3420 | | below but still specific to the processing of SWIMA | 3421 | | Attributes. The Description field SHOULD contain | 3422 | | additional diagnostic information. | 3423 | | | 3424 | 0x00000005 | SWIMA_SUBSCRIPTION_DENIED_ERROR. This indicates that | 3425 | (5) | the SWIMA-PC denied the SWIMA-PV's request to | 3426 | | establish a subscription. The Description field | 3427 | | SHOULD contain additional diagnostic information. | 3428 | | | 3429 | 0x00000006 | SWIMA_RESPONSE_TOO_LARGE_ERROR. This indicates that | 3430 | (6) | the SWIMA-PC's response to the SWIMA-PV's request | 3431 | | was too large to be serviced. The error information | 3432 | | structure indicates the largest possible size of a | 3433 | | response supported by the SWIMA-PC (see Section | 3434 | | 5.16.2). The Description field SHOULD contain | 3435 | | additional diagnostic information. | 3436 | | | 3437 | 0x00000007 | SWIMA_SUBSCRIPTION_FULFILLMENT_ERROR. This indicates | 3438 | (7) | that the SWIMA-PC experienced an error fulfilling a | 3439 | | given subscription. The error information includes | 3440 | | the Subscription ID of the relevant subscription, as | 3441 | | well as a sub-error that describes the nature of the | 3442 | | error the SWIMA-PC experienced. The SWIMA-PC and | 3443 | | SWIMA-PV MUST treat the identified subscription as | 3444 | | cancelled. | 3445 | | | 3446 | 0x00000008 | SWIMA_SUBSCRIPTION_ID_REUSE_ERROR. This indicates | 3447 | (8) | that the SWIMA-PC received a SWIMA Request from a | 3448 | | given SWIMA-PV where the Request ID of that SWIMA | 3449 | | Request is currently used as the Subscription ID of | 3450 | | an active subscription with that SWIMA-PV. This | 3451 | | error does not cancel the identified subscription. | 3452 +------------+------------------------------------------------------+ 3454 Table 8: PA-TNC Error Codes for SWIMA 3456 The following subsections describe the structures present in the 3457 Error Information fields. Note that all error structures include a 3458 variable-length field, but do not include any fields indicating the 3459 length of those fields. Such a field is unnecessary because all 3460 other fields in the PA-TNC Error attribute are fixed-length, and thus 3461 the length of the variable-length field can be found by subtracting 3462 the size of these fixed-length fields from the PA-TNC Attribute 3463 Length field in the PA-TNC Attribute Header. 3465 5.16.1. SWIMA_ERROR, SWIMA_SUBSCRIPTION_DENIED_ERROR and 3466 SWIMA_SUBSCRIPTION_ID_REUSE_ERROR Information 3468 The SWIMA_ERROR error code indicates that the sender (the SWIMA-PC) 3469 has encountered an error related to the processing of a SWIMA Request 3470 attribute but which is not covered by more specific SWIMA error 3471 codes. The SWIMA_SUBSCRIPTION_DENIED_ERROR is used when the SWIMA-PV 3472 requests to establish a subscription or clear all subscriptions from 3473 the given SWIMA-PV, but the SWIMA-PC is unable or unwilling to comply 3474 with this request. The SWIMA_SUBSCRIPTION_ID_REUSE_ERROR is used 3475 when the SWIMA-PC receives a SWIMA Request whose Request ID 3476 duplicates a Subscription ID of an active subscription with the 3477 request's sender. All of these error codes use the following error 3478 information structure. 3480 1 2 3 3481 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3483 | Copy of Request ID / Subscription ID | 3484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3485 | Description (variable length) | 3486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3488 Figure 19: SWIMA Error, Subscription Error, and Subscription ID Reuse 3489 Information 3491 +--------------+----------------------------------------------------+ 3492 | Field | Description | 3493 +--------------+----------------------------------------------------+ 3494 | Copy of | In the case that this error condition is generated | 3495 | Request ID / | in direct response to a SWIMA Request attribute, | 3496 | Subscription | this field MUST contain an exact copy of the | 3497 | ID | Request ID field in the SWIMA Request attribute | 3498 | | that caused this error. In the case that the | 3499 | | attribute in question is generated in fulfillment | 3500 | | of an active subscription, this field MUST contain | 3501 | | the Subscription ID of the subscription for which | 3502 | | the attribute was generated. (This is only | 3503 | | possible if the error code is SWIMA_ERROR as the | 3504 | | other errors are not generated by subscription | 3505 | | fulfillment.) Note that, in this case, the | 3506 | | indicated error appears as a sub-error for a | 3507 | | SWIMA_SUBSCRIPTION_FULFILLMENT_ERROR, as described | 3508 | | in Section 5.16.3. | 3509 | | | 3510 | Description | A UTF-8 [RFC3629] string describing the condition | 3511 | | that caused this error. This field MAY be | 3512 | | 0-length. However, senders SHOULD include some | 3513 | | description in all PA-TNC Error attributes of | 3514 | | these types. This field MUST NOT be NULL | 3515 | | terminated. | 3516 +--------------+----------------------------------------------------+ 3518 Table 9: SWIMA Error, Subscription Error, and Subscription ID Reuse 3519 Information Fields 3521 This error information structure is used with SWIMA_ERROR, 3522 SWIMA_SUBSCRIPTION_DENIED_ERROR, and 3523 SWIMA_SUBSCRIPTION_ID_REUSE_ERROR status codes to identify the SWIMA 3524 Request attribute that precipitated the error condition and to 3525 describe the error. The Description field contains text describing 3526 the error. The SWIMA-PC MAY encode machine-interpretable information 3527 in this field, but SHOULD also include a human-readable description 3528 of the error, since the receiving SWIMA-PV might not recognize the 3529 SWIMA-PC's encoded information. 3531 5.16.2. SWIMA_RESPONSE_TOO_LARGE_ERROR Information 3533 The SWIMA_RESPONSE_TOO_LARGE_ERROR error code indicates that a 3534 response generated by a SWIMA-PC in response to a SWIMA-PV's SWIMA 3535 Request attribute was too large to send. 3537 1 2 3 3538 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3540 | Copy of Request ID / Subscription I | 3541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3542 | Maximum Allowed Size | 3543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3544 | Description (variable length) | 3545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3547 Figure 20: SWIMA Response Too Large Error Information 3549 +--------------+----------------------------------------------------+ 3550 | Field | Description | 3551 +--------------+----------------------------------------------------+ 3552 | Copy of | In the case that the attribute in question is | 3553 | Request ID / | generated in direct response to a SWIMA Request, | 3554 | Subscription | this field MUST contain an exact copy of the | 3555 | ID | Request ID field in the SWIMA Request attribute | 3556 | | that caused this error. In the case that the | 3557 | | attribute in question is generated in fulfillment | 3558 | | of an active subscription, this field MUST contain | 3559 | | the Subscription ID of the subscription for which | 3560 | | the attribute was generated. Note that, in the | 3561 | | latter case, the SWIMA_RESPONSE_TOO_LARGE_ERROR | 3562 | | appears as a sub-error for a | 3563 | | SWIMA_SUBSCRIPTION_FULFILLMENT_ERROR, as described | 3564 | | in Section 5.16.3. | 3565 | | | 3566 | Maximum | This field MUST contain an unsigned integer | 3567 | Allowed Size | indicating the largest permissible size, in bytes, | 3568 | | of SWIMA Attribute that the SWIMA-PC is currently | 3569 | | willing to send in response to a SWIMA Request | 3570 | | attribute. | 3571 | | | 3572 | Description | A UTF-8 [RFC3629] string describing the condition | 3573 | | that caused this error. This field MAY be | 3574 | | 0-length. However, senders SHOULD include some | 3575 | | description in all PA-TNC Error attributes of | 3576 | | these types. This field MUST NOT be NULL | 3577 | | terminated. | 3578 +--------------+----------------------------------------------------+ 3580 Table 10: SWIMA Response Too Large Error Information Fields 3582 This error structure is used with the SWIMA_RESPONSE_TOO_LARGE_ERROR 3583 status code to identify the SWIMA Request attribute that precipitated 3584 the error condition and to describe the error. The Maximum Allowed 3585 Size field indicates the largest attribute the SWIMA-PC is willing to 3586 send in response to a SWIMA Request under the current circumstances. 3587 Note that under other circumstances, the SWIMA-PC might be willing to 3588 return larger or smaller responses than indicated (such as if the 3589 endpoint connects to the NEA Server using a different network 3590 protocol). The other fields in this error information structure have 3591 the same meanings as corresponding fields in the SWIMA_ERROR and 3592 SWIMA_SUBSCRIPTION_DENIED_ERROR information structure. 3594 5.16.3. SWIMA_SUBSCRIPTION_FULFILLMENT_ERROR Information 3596 The SWIMA_SUBSCRIPTION_FULFILLMENT_ERROR error code indicates that 3597 the SWIMA-PC encountered an error while fulfilling a subscription. 3598 The bytes after the first 4 octets duplicate a PA-TNC Error attribute 3599 (as described in Section 4.2.8 of PA-TNC) that is used to identify 3600 the nature of the encountered error. 3602 1 2 3 3603 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3605 | Subscription ID | 3606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3607 | Reserved | Sub Error Code Vendor ID | 3608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3609 | Sub Error Code | 3610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3611 | Sub Error Information (variable Length) | 3612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3614 Figure 21: SWIMA Subscription Fulfillment Error Information 3616 +--------------+----------------------------------------------------+ 3617 | Field | Description | 3618 +--------------+----------------------------------------------------+ 3619 | Subscription | This field MUST contain the Subscription ID of the | 3620 | ID | subscription whose fulfillment caused this error. | 3621 | | | 3622 | Reserved | This field MUST contain the value of the Reserved | 3623 | | field of a PA-TNC Error attribute that describes | 3624 | | the error condition encountered during | 3625 | | subscription processing. | 3626 | | | 3627 | Sub Error | This field MUST contain the value of the Error | 3628 | Code Vendor | Code Vendor ID field of a PA-TNC Error attribute | 3629 | ID | that describes the error condition encountered | 3630 | | during subscription processing. | 3631 | | | 3632 | Sub Error | This field MUST contain the value of the Error | 3633 | Code | Code field of a PA-TNC Error attribute that | 3634 | | describes the error condition encountered during | 3635 | | subscription processing. | 3636 | | | 3637 | Sub Error | This field MUST contain the value of the Error | 3638 | Information | Information field of a PA-TNC Error attribute that | 3639 | | describes the error condition encountered during | 3640 | | subscription processing. | 3641 +--------------+----------------------------------------------------+ 3643 Table 11: SWIMA Subscription Fulfillment Error Information Fields 3645 This error structure is used with the 3646 SWIMA_SUBSCRIPTION_FULFILLMENT_ERROR status code. The first 4 octets 3647 of this error structure contain the Subscription ID of the 3648 subscription that was being fulfilled when the error occurred. The 3649 remaining fields of this error structure duplicate the fields of a 3650 PA-TNC Error attribute, referred to as the "sub-error". The error 3651 code of the sub-error corresponds to the type of error that the 3652 SWIMA-PC encountered while fulfilling the given subscription. The 3653 sub-error MUST NOT have an error code of 3654 SWIMA_SUBSCRIPTION_FULFILLMENT_ERROR. 3656 The SWIMA-PC sending a PA-TNC Error attribute with this error code, 3657 and the SWIMA-PV receiving it, MUST treat the subscription identified 3658 by the Subscription ID field as cancelled. All other subscriptions 3659 are unaffected. 3661 6. Supported Data Models 3663 SWIMA supports an extensible list of data models for representing and 3664 transmitting software inventory information. This list of data 3665 models appears in the Software Data Model IANA registry (see 3666 Section 10.4). This document provides guidance for an initial set of 3667 data models. Other documents might provide guidance on the use of 3668 new data models by SWIMA, and will be referenced by extensions to the 3669 Software Data Model IANA registry. 3671 6.1. ISO 2015 SWID Tags using XML 3673 The International Organization for Standardization and the 3674 International Electrotechnical Commission (ISO/IEC) published the 3675 specification governing SWID tag construction and use in 2009 with a 3676 revised version published in 2015. [SWID15] Since that time, a 3677 growing number of vendors have integrated SWID tags into their 3678 software products. Doing so significantly simplifies the task of 3679 identifying these pieces of software: instead of relying on discovery 3680 processes that look for clues as to software presence, such as the 3681 presence of particular files or registry keys. A readily available 3682 list of SWID tags provides simple and immediate evidence as to the 3683 presence of the given piece of software. 3685 SWIMA has no reliance on the presence or management of SWID tags on 3686 an endpoint as described in the ISO specification. However, the data 3687 model for describing software that is presented in the ISO 3688 specification provides a robust and comprehensive way of describing 3689 software and is adopted here as a means of representing and 3690 transmitting software information. It should be emphasized, the use 3691 of the ISO SWID tag data model makes no assumption as to whether the 3692 source of the recorded information was, in fact, an ISO SWID tag 3693 harvested from the endpoint or whether the information was created 3694 using some other source and normalized to the SWID format. 3696 6.1.1. Guidance on Normalizing Source Data to ISO 2015 SWID Tags using 3697 XML 3699 Any record associated with this Software Data Model Type MUST conform 3700 to the ISO/IEC 19770-2-2015 [SWID15] specification. 3702 If generating a new ISO 2015 SWID tag, the software generating the 3703 tag MUST use a Tag Creator RegID that is associated with the 3704 generating software, unless this is impossible, in which case it MUST 3705 use the "http://invalid.unavailable" Tag Creator RegID value. (This 3706 conforms to conventions for an unknown Tag Creator in the ISO 2015 3707 SWID tag specification.) Do not use a RegID associated with any 3708 other party. In particular, it is incorrect to use a Tag Creator 3709 RegID associated with the software being described by the tag, the 3710 enterprise that is using the software, or any other entity except 3711 that of the party that built the tool that is generating the SWID 3712 tag. This reflects the requirement that the Tag Creator RegID 3713 identify the party that created the tag. Moreover, any generated 3714 tags SHOULD conform with guidance for tag creators provided NIST IR 3715 8060 [NIST8060], which provides additional recommendations to 3716 increase interoperable use of SWID tags. 3718 6.1.2. Guidance on Creation of Software Identifiers from ISO 2015 SWID 3719 Tags 3721 A Software Identifier generated from an ISO 2015 SWID tag is 3722 expressed as a concatenation of the value of the Tag Creator RegID 3723 field and the Unique ID field. Specifically, it MUST be of the form: 3724 TAG_CREATOR_REGID "_" "_" UNIQUE_ID. Specifically, the Software 3725 Identifier consists of, the Tag Creator RegID and the Unique ID from 3726 the tag connected with a double underscore (_), without any other 3727 connecting character or whitespace. 3729 6.2. ISO 2009 SWID Tags using XML 3731 As noted above, ISO's SWID tag specification provides a useful data 3732 model for representation of software information. As of the writing 3733 of this specification, while the 2015 specification is considered 3734 more comprehensive and addresses some issues with the 2009 3735 specification, 2009-format SWID tags remain far more common in 3736 deployments. For this reason, ISO 2009 SWID tags are included in the 3737 Software Data Model IANA table. 3739 6.2.1. Guidance on Normalizing Source Data to ISO 2009 SWID Tags using 3740 XML 3742 Any record associated with this Software Data Model Type MUST conform 3743 to the ISO/IEC 19770-2-2009 [SWID09] specification. Any such tag 3744 SHOULD use a UTF-8 encoding [RFC3629], but MUST NOT alter the 3745 existing encoding if doing so would invalidate digital signatures 3746 included in the tag. 3748 If generating a new ISO 2009 SWID tag, the software generating the 3749 tag MUST use a Tag Creator RegID that is associated with the 3750 generating software unless this is impossible, in which case it MUST 3751 use "unknown", which indicates the Tag Creator is unknown. (This 3752 conforms to conventions for an unknown Tag Creator in the ISO 2009 3753 SWID specification.) Do not use a RegID associated with any other 3754 party. In particular, it is incorrect to use a Tag Creator RegID 3755 associated with the software being described by the tag, the 3756 enterprise that is using the software, or any other entity except 3757 that of the party that built the tool that is generating the SWID 3758 tag. This reflects the requirement that the Tag Creator RegID 3759 identify the party that created the tag. 3761 6.2.2. Guidance on Creation of Software Identifiers from ISO 2009 SWID 3762 Tags 3764 A Software Identifier generated from an ISO 2009 SWID tag is 3765 expressed as a concatenation of the value of the Tag Creator RegID 3766 field and the Unique ID field. Specifically, it MUST be of the form: 3767 TAG_CREATOR_REGID "_" "_" UNIQUE_ID. Specifically, the Software 3768 Identifier consists of, the Tag Creator RegID and the Unique ID from 3769 the tag connected with a double underscore (_), without any other 3770 connecting character or whitespace. 3772 7. Relationship to Other Specifications 3774 This specification is expected to participate in a standard NEA 3775 architecture. As such, it is expected to be used in conjunction with 3776 the other protocols used in a NEA exchange. In particular, SWIMA 3777 Attributes are conveyed over PB-TNC [RFC5793], which is in turn 3778 conveyed over some variant of PT (either PT-TLS [RFC6876] or PT-EAP 3779 [RFC7171]). These protocols have an especially important role, as 3780 they are responsible for ensuring that attributes defined under this 3781 specification are delivered reliably, securely, and to the 3782 appropriate party. 3784 It is important to note that the Product Information, Numeric 3785 Version, and String Version attributes defined in the PA-TNC 3786 specification [RFC5792] are also meant to convey information about 3787 installed applications and the versions thereof. As such, there is 3788 some conceptual overlap between those attributes and the intent of 3789 this specification. However, PA-TNC was designed to respond to very 3790 specific queries about specific classes of products, while the SWIMA 3791 specification is able to convey a broader query, resulting in a more 3792 comprehensive set of evidence regarding an endpoint's installed 3793 software. As such, this specification provides important 3794 capabilities not present in the PA-TNC specification. 3796 The NEA architecture is intended to support a broad range of 3797 activities and, as such, might be employed by other specifications. 3798 For example, requirement T-001 in the SACM Requirements document 3799 [RFC8248] notes that NEA can support data collection from endpoints 3800 within the broader SACM architecture. (Other parts of the NEA 3801 architecture, which SWIMA uses, meet the other SACM data transport 3802 requirements.) In the SACM architecture, a SWIMA-PV corresponds to a 3803 "SACM Collector" and a SWIMA-PC corresponds to a "SACM Internal 3804 Collector". In the SACM architecture, the SWIMA specification can 3805 support activities relating to software inventory collection. 3806 Specifically, SWIMA supports the SACM "Endpoint Posture Attribute 3807 Value Collection" use case (section 2.1.3 in [RFC7632]) by describing 3808 a collection mechanism that enables event driven, scheduled, and ad- 3809 hoc data collection of software inventory information. SWIMA's 3810 flexibility with regard to the format of inventory data records means 3811 that it is compatible with virtually any data format that implements 3812 SACM's "Define, Publish, Query, and Retrieve Security Automation 3813 Data" (section 2.1.1 in [RFC7632]). This is just one example of how 3814 SWIMA can support broader security solution standards. Note that, 3815 while SWIMA can support these SACM use cases, SWIMA has no 3816 dependencies upon the SACM architecture or any other context in which 3817 NEA might reasonably be applied. 3819 8. Security Considerations 3821 This section discusses some of the security threats facing Posture 3822 Collectors and Posture Validators that implement the SWIMA protocol. 3823 This section primarily notes potential issues for implementers to 3824 consider, although it does contain a handful of normative 3825 requirements to address certain security issues. The issues 3826 identified below focus on capabilities specific to this document. 3827 Implementers are advised to consult other relevant NEA 3828 specifications, particularly [RFC5209] (the NEA Architecture) and 3829 [RFC5792] (PA-TNC), for security issues that are applicable to such 3830 components in general. 3832 8.1. Evidentiary Value of Software Inventory Evidence Records 3834 The degree to which an endpoint's Software Inventory Evidence 3835 Collection accurately reflects the endpoint's actual software load 3836 and any changes made to this software load is dependent on the 3837 accuracy of the tools used to populate and manage the software 3838 inventory evidence records in this collection. While the SWIMA-PC is 3839 required to detect changes to an endpoint's Software Inventory 3840 Evidence Collection in near real-time, some tools might not be 3841 designed to update records in the Software Inventory Evidence 3842 Collection in real time. This can result in a collection that is 3843 out-of-sync with actual system state. Moreover, tools might 3844 inaccurately characterize software, or fail to properly record its 3845 removal. Finally, it is likely that there will be software on the 3846 endpoint that is not tracked by any source and thus is not reflected 3847 in the Software Inventory Evidence Collection. Tools that implement 3848 SWIMA ought to be aware of these potential issues and minimize them, 3849 but completely eliminating such issues is likely impossible. Users 3850 of collected software inventory evidence records need to understand 3851 that the information provided by the SWIMA capability cannot be 3852 treated as completely accurate. Nonetheless, having endpoints report 3853 this information can still provide useful insights into the state of 3854 the endpoint's software load, and can alert administrators and policy 3855 tools of situations that require remediation. 3857 8.2. Sensitivity of Collected Records 3859 Collected software records can be sensitive in nature. This can 3860 include both security sensitivities and privacy sensitivities. 3861 Privacy sensitivities are discussed more in Section 9. With regard 3862 to security, inventory records represent a wealth of information 3863 about the endpoint in question and, for an adversary who does not 3864 already have access to the endpoint, a collection of the endpoint's 3865 inventory records might provide many details that are useful for 3866 mounting an attack. A list of the inventory records associated with 3867 an endpoint reveals a list of software installed on the endpoint. 3868 This list can be very detailed, noting specific versions and even 3869 patch levels, which an adversary can use to identify vulnerable 3870 software and design efficacious attacks. 3872 In addition, other information might also be gleaned from a 3873 collection of software inventory records: 3875 o An inventory record might include information about where the 3876 product was installed on a given endpoint. This can reveal 3877 details about the file organization of that endpoint that an 3878 attacker can utilize. 3880 o An inventory record might include information about how the 3881 software was provided to the endpoint, who in an organization 3882 signs off on the package release, and who packaged the product for 3883 installation. This information might be used as a starting point 3884 for the development of supply chain attacks. 3886 o Events affecting inventory records are reported with timestamps 3887 indicating when each given event occurred. This can give the 3888 attacker an indication of how quickly an organization distributes 3889 patches and updates, helping the attacker determine how long an 3890 attack window might remain open. 3892 Any consolidated software inventory is a potential risk, because such 3893 an inventory can provide an adversary an insight into the 3894 enterprise's configuration and management process. It is recommended 3895 that a centralized software inventory record collection be protected 3896 against unauthorized access. Mechanisms to accomplish this can 3897 include encrypting the data at rest, ensuring that access to the data 3898 is limited only to authorized individuals and processes, and other 3899 basic security precautions. 3901 8.3. Integrity of Endpoint Records 3903 SWIMA-PCs maintain records of detected changes to the endpoint's 3904 Software Inventory Evidence Collection. These records are used to 3905 respond to a SWIMA-PV's request for change events. The SWIMA-PV 3906 might use a list of reported events to update its understanding of 3907 the endpoint's Software Inventory Evidence Collection without needing 3908 to receive a full inventory report from the SWIMA-PC. For this 3909 reason, preserving the integrity of the SWIMA-PC's record of events 3910 is extremely important. If an attacker modifies the SWIMA-PC's 3911 record of changes to the endpoint's Software Inventory Evidence 3912 Collection, this might cause the SWIMA-PV's understanding of the 3913 endpoint's Software Inventory Evidence Collection to differ from its 3914 actual state. Results might include leading the SWIMA-PV to believe 3915 that absent software was present, that present software was absent, 3916 that patches have been installed even if this is not the case, or to 3917 be unaware of other changes to Software Inventory Evidence Records. 3918 As such, the SWIMA-PC MUST take steps to protect the integrity of its 3919 event records. 3921 In addition, records of established SWIMA-PV subscriptions also 3922 require protection against manipulation or corruption. If an 3923 attacker is able to modify or delete records of an established 3924 subscription by a SWIMA-PV, the SWIMA-PC might fail to correctly 3925 fulfill this subscription. The SWIMA-PV would not be aware that its 3926 subscription was not being correctly fulfilled unless it received 3927 additional information that indicated a discrepancy. For example, 3928 the SWIMA-PV might collect a full inventory and realize from this 3929 that certain events had not been correctly reported in accordance 3930 with an established subscription. For this reason, the SWIMA-PC MUST 3931 protect the integrity of subscription records. 3933 8.4. SWIMA-PC Access Permissions 3935 A SWIMA-PC requires sufficient permissions to collect Software 3936 Inventory Evidence Records from all of its supported sources, as well 3937 as sufficient permissions to interact with the endpoint's Posture 3938 Broker Client. With regard to the former, this might require 3939 permissions to read the contents of directories throughout the file 3940 system. Depending on the operating environment and other activities 3941 undertaken by a SWIMA-PC (or software that incorporates a SWIMA-PC as 3942 one of its capabilities) additional permissions might be required by 3943 the SWIMA-PC software. The SWIMA-PC SHOULD NOT be granted 3944 permissions beyond what it needs in order to fulfill its duties. 3946 8.5. Sanitization of Record Fields 3948 Not all sources of software inventory evidence are necessarily 3949 tightly controlled. For example, consider a source that gathers 3950 .swid files from the endpoint's file system. Any party could create 3951 a new .swid file that could be collected and turned into a Software 3952 Inventory Evidence Record. As a result, it is important that the 3953 contents of source information not be automatically trusted. In 3954 particular, tools that read source information and the Software 3955 Inventory Evidence Records derived therefrom, including SWIMA-PCs, 3956 need to be careful to sanitize input to prevent buffer overflow 3957 attacks, encoding attacks, and other weaknesses that might be 3958 exploited by an adversary who can control the contents of a record. 3960 8.6. PA-TNC Security Threats 3962 In addition to the aforementioned considerations the SWIMA protocol 3963 is subject to the same security threats as other PA-TNC transactions, 3964 as noted in Section 5.2 of PA-TNC [RFC5792]. These include, but are 3965 not limited to, attribute theft, message fabrication, attribute 3966 modification, attribute replay, attribute insertion, and denial of 3967 service. Implementers are advised to consult the PA-TNC 3968 specification to better understand these security issues. 3970 9. Privacy Considerations 3972 As noted in Section 8.2, if an adversary can gain an understanding of 3973 the software installed on an endpoint, they can utilize this to 3974 launch attacks and maintain footholds on this endpoint. For this 3975 reason, the NEA Server needs to ensure adequate safeguards are in 3976 place to prevent exposure of collected inventory records. For 3977 similar reasons, it is advisable that an endpoint only send records 3978 to a NEA Server that is authorized to receive this information and 3979 that can be trusted to safeguard this information after collection. 3981 In addition, software inventory information can lead to insights 3982 about the endpoint's primary user if that user is able to install 3983 software. (Note that users might be "able" to install their own 3984 software even if they are not "allowed" to do so.) This is 3985 especially true on endpoints that support "apps", as individual apps 3986 can be closely tied to specific groups or activities. This could 3987 conceivably allow inferences about things such as a user's hobbies, 3988 the banks and other financial institutions that they use, and 3989 information about the user's race, sex, or sexual orientation. 3991 Organizations that collect software inventory information from 3992 endpoints ought to make sure the endpoints' users are aware of this 3993 collection. In addition, organizations should be aware that a 3994 software inventory associated with an individual, such as the 3995 inventory of the individual's primary endpoint, could expose 3996 sensitive personal information. For this reason, privacy safeguards 3997 are necessary for collected inventory information. Such safeguards 3998 would require not only protection of the inventory's confidentiality, 3999 but also appropriate access controls so that only those trained in 4000 relevant privacy requirements are able to view the data. 4002 10. IANA Considerations 4004 This section extends multiple existing IANA registries. 4005 Specifically, it extends the PA-TNC Attribute Types and PA-TNC Error 4006 Codes defined in the PA-TNC specification [RFC5792] and the PA- 4007 Subtypes registry defined in the PB-TNC specification [RFC5793] and 4008 extended in PA-TNC. This specification only adds values to these 4009 registries and does not alter how these registries work or are 4010 maintained. Consult the appropriate specifications for details on 4011 the operations and maintenance of these registries. 4013 10.1. PA Subtypes 4015 The following is an extension to the PA Subtype registry [2] defined 4016 in section 7.2 of the PA-TNC specification [RFC5792]. 4018 +-----+---------+------------------+------------------------+ 4019 | PEN | Integer | Name | Defining Specification | 4020 +-----+---------+------------------+------------------------+ 4021 | 0 | 9 | SWIMA Attributes | [RFC-to-be] | 4022 +-----+---------+------------------+------------------------+ 4024 10.2. Registry for PA-TNC Attribute Types 4026 Section 5.4 of this specification defines several new PA-TNC 4027 attributes. The following values are added to the registry for PA- 4028 TNC Attribute Types defined in the PA-TNC specification. Note that 4029 Table 1 in Section 5.4 lists these attributes but uses a hexadecimal 4030 value to identify their associated integer. The integer values given 4031 in that table are identical to those provided here. Note also that 4032 Table 1 includes an entry for PA-TNC Error attributes, but the IANA 4033 information associated with that attribute is already defined in the 4034 PA-TNC specification and is not reproduced here. 4036 +-----+---------+----------------------------+----------------------+ 4037 | PEN | Integer | Name | Defining | 4038 | | | | Specification | 4039 +-----+---------+----------------------------+----------------------+ 4040 | 0 | 13 | SWIMA Request | [RFC-to-be] | 4041 | | | | | 4042 | 0 | 14 | Software Identifier | [RFC-to-be] | 4043 | | | Inventory | | 4044 | | | | | 4045 | 0 | 15 | Software Identifier Events | [RFC-to-be] | 4046 | | | | | 4047 | 0 | 16 | Software Inventory | [RFC-to-be] | 4048 | | | | | 4049 | 0 | 17 | Software Events | [RFC-to-be] | 4050 | | | | | 4051 | 0 | 18 | Subscription Status | [RFC-to-be] | 4052 | | | Request | | 4053 | | | | | 4054 | 0 | 19 | Subscription Status | [RFC-to-be] | 4055 | | | Response | | 4056 | | | | | 4057 | 0 | 20 | Source Metadata Request | [RFC-to-be] | 4058 | | | | | 4059 | 0 | 21 | Source Metadata Response | [RFC-to-be] | 4060 +-----+---------+----------------------------+----------------------+ 4062 10.3. Registry for PA-TNC Error Codes 4064 Section 5.16 of this specification defines several new PA-TNC Error 4065 Codes. The following values are added to the registry for PA-TNC 4066 Error Codes defined in the PA-TNC specification. Note that Table 8 4067 in Section 5.16 lists these codes but uses a hexadecimal value to 4068 identify their associated integer. The integer values given in that 4069 table are identical to those provided here. 4071 +----+--------+-------------------------------------+---------------+ 4072 | PE | Intege | Name | Defining | 4073 | N | r | | Specification | 4074 +----+--------+-------------------------------------+---------------+ 4075 | 0 | 4 | SWIMA_ERROR | [RFC-to-be] | 4076 | | | | | 4077 | 0 | 5 | SWIMA_SUBSCRIPTION_DENIED_ERROR | [RFC-to-be] | 4078 | | | | | 4079 | 0 | 6 | SWIMA_RESPONSE_TOO_LARGE_ERROR | [RFC-to-be] | 4080 | | | | | 4081 | 0 | 7 | SWIMA_SUBSCRIPTION_FULFILLMENT_ERRO | [RFC-to-be] | 4082 | | | R | | 4083 | | | | | 4084 | 0 | 8 | SWIMA_SUBSCRIPTION_ID_REUSE_ERROR | [RFC-to-be] | 4085 +----+--------+-------------------------------------+---------------+ 4087 10.4. Registry for Software Data Models 4089 The name for this registry is "Software Data Model Types". Each 4090 entry in this registry should include a human readable name, an SMI 4091 Private Enterprise Number, a decimal integer value between 1 and 4092 2^8-1 (inclusive), and a reference to the specification where the use 4093 of this data model is defined. This specification needs to provide 4094 both a description of the format used by the data model and the 4095 procedures by which Software Identifiers are derived from a record 4096 expressed using this data model. Note that a specification that just 4097 defines the data model structure and its use is generally not 4098 sufficient as it would likely lack the procedures for constructing a 4099 Software Identifier. This is why the table below references the 4100 current specification for ISO SWID tags, rather than using the actual 4101 ISO SWID tag specification. 4103 The following entries for this registry are defined in this document. 4104 They are the initial entries in the registry for Software Data Model 4105 Types. Additional entries to this registry are added by Expert 4106 Review with Specification Required, following the guidelines in 4107 [RFC8126]. 4109 +-----+---------+-----------------------------+---------------------+ 4110 | PEN | Integer | Name | Defining | 4111 | | | | Specification | 4112 +-----+---------+-----------------------------+---------------------+ 4113 | 0 | 0 | ISO 2015 SWID Tags using | [RFC-to-be] | 4114 | | | XML | | 4115 | | | | | 4116 | 0 | 1 | ISO 2009 SWID Tags using | [RFC-to-be] | 4117 | | | XML | | 4118 | | | | | 4119 | 0 | 192-255 | Reserved for local | N/A | 4120 | | | enterprise use | | 4121 +-----+---------+-----------------------------+---------------------+ 4123 11. References 4125 11.1. Normative References 4127 [NIST8060] 4128 Waltermire, D., Cheikes, B., Feldman, L., and G. Witte, 4129 "Guidelines for the Creation of Interoperable Software 4130 Identification (SWID) Tags", April 2016. 4132 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4133 Requirement Levels", BCP 14, RFC 2119, 4134 DOI 10.17487/RFC2119, March 1997, 4135 . 4137 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 4138 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 4139 . 4141 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 4142 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 4143 2003, . 4145 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 4146 Resource Identifier (URI): Generic Syntax", STD 66, 4147 RFC 3986, DOI 10.17487/RFC3986, January 2005, 4148 . 4150 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network 4151 Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, 4152 . 4154 [RFC5792] Sangster, P. and K. Narayan, "PA-TNC: A Posture Attribute 4155 (PA) Protocol Compatible with Trusted Network Connect 4156 (TNC)", RFC 5792, DOI 10.17487/RFC5792, March 2010, 4157 . 4159 [RFC8089] Kerwin, M., "The "file" URI Scheme", RFC 8089, 4160 DOI 10.17487/RFC8089, February 2017, 4161 . 4163 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 4164 Writing an IANA Considerations Section in RFCs", BCP 26, 4165 RFC 8126, DOI 10.17487/RFC8126, June 2017, 4166 . 4168 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 4169 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 4170 May 2017, . 4172 [SWID09] The International Organization for Standardization/ 4173 International Electrotechnical Commission, "Information 4174 Technology - Software Asset Management - Part 2: Software 4175 Identification Tag, ISO/IEC 19770-2", November 2009. 4177 [SWID15] The International Organization for Standardization/ 4178 International Electrotechnical Commission, "Information 4179 Technology - Software Asset Management - Part 2: Software 4180 Identification Tag, ISO/IEC 19770-2", October 2015. 4182 11.2. Informative References 4184 [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. 4185 Tardo, "Network Endpoint Assessment (NEA): Overview and 4186 Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008, 4187 . 4189 [RFC5793] Sahita, R., Hanna, S., Hurst, R., and K. Narayan, "PB-TNC: 4190 A Posture Broker (PB) Protocol Compatible with Trusted 4191 Network Connect (TNC)", RFC 5793, DOI 10.17487/RFC5793, 4192 March 2010, . 4194 [RFC6876] Sangster, P., Cam-Winget, N., and J. Salowey, "A Posture 4195 Transport Protocol over TLS (PT-TLS)", RFC 6876, 4196 DOI 10.17487/RFC6876, February 2013, 4197 . 4199 [RFC7171] Cam-Winget, N. and P. Sangster, "PT-EAP: Posture Transport 4200 (PT) Protocol for Extensible Authentication Protocol (EAP) 4201 Tunnel Methods", RFC 7171, DOI 10.17487/RFC7171, May 2014, 4202 . 4204 [RFC7632] Waltermire, D. and D. Harrington, "Endpoint Security 4205 Posture Assessment: Enterprise Use Cases", RFC 7632, 4206 DOI 10.17487/RFC7632, September 2015, 4207 . 4209 [RFC8248] Cam-Winget, N. and L. Lorenzin, "Security Automation and 4210 Continuous Monitoring (SACM) Requirements", RFC 8248, 4211 DOI 10.17487/RFC8248, September 2017, 4212 . 4214 11.3. URIs 4216 [1] https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml 4218 [2] https://www.iana.org/assignments/pb-tnc-parameters/pb-tnc- 4219 parameters.xhtml#pb-tnc-parameters-2 4221 Authors' Addresses 4223 Charles Schmidt 4224 The MITRE Corporation 4225 202 Burlington Road 4226 Bedford, MA 01730 4227 USA 4229 Email: cmschmidt@mitre.org 4231 Daniel Haynes 4232 The MITRE Corporation 4233 202 Burlington Road 4234 Bedford, MA 01730 4235 USA 4237 Email: dhaynes@mitre.org 4238 Chris Coffin 4239 The MITRE Corporation 4240 202 Burlington Road 4241 Bedford, MA 01730 4242 USA 4244 Email: ccoffin@mitre.org 4246 David Waltermire 4247 National Institute of Standards and Technology 4248 100 Bureau Drive 4249 Gaithersburg, Maryland 4250 USA 4252 Email: david.waltermire@nist.gov 4254 Jessica Fitzgerald-McKay 4255 United States National Security Agency 4256 9800 Savage Road 4257 Ft. Meade, Maryland 4258 USA 4260 Email: jmfitz2@radium.ncsc.mil