-
Notifications
You must be signed in to change notification settings - Fork 2
/
Copy pathdraft-ietf-sacm-nea-swid-patnc-01.xml
3326 lines (3116 loc) · 226 KB
/
draft-ietf-sacm-nea-swid-patnc-01.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC5209 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5209.xml">
<!ENTITY RFC5792 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5792.xml">
<!ENTITY RFC6876 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6876.xml">
<!ENTITY RFC7171 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7171.xml">
<!ENTITY RFC5198 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5198.xml">
<!ENTITY RFC5793 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5793.xml">
<!ENTITY RFC3339 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3339.xml">
<!ENTITY RFC3986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml">
<!ENTITY RFC5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="no" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<?xml-stylesheet type="text/css" href="rfc7749.css"?>
<rfc category="std" docName="draft-ietf-sacm-nea-swid-patnc-01" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<title abbrev="SW M&A for PA-TNC">Software Inventory Message and Attributes (SWIMA) for PA-TNC</title>
<!-- Another author who claims to be an editor -->
<author fullname="Charles Schmidt" initials="C.S." surname="Schmidt">
<organization>The MITRE Corporation</organization>
<address>
<postal>
<street>202 Burlington Road</street>
<!-- Reorder these if your country does things differently -->
<city>Bedford</city>
<region>MA</region>
<code>01730</code>
<country>USA</country>
</postal>
<phone/>
<email>[email protected]</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Daniel Haynes" initials="D.H." surname="Haynes">
<organization>The MITRE Corporation</organization>
<address>
<postal>
<street>202 Burlington Road</street>
<!-- Reorder these if your country does things differently -->
<city>Bedford</city>
<region>MA</region>
<code>01730</code>
<country>USA</country>
</postal>
<phone/>
<email>[email protected]</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Chris Coffin" initials="C.C." surname="Coffin">
<organization>The MITRE Corporation</organization>
<address>
<postal>
<street>202 Burlington Road</street>
<!-- Reorder these if your country does things differently -->
<city>Bedford</city>
<region>MA</region>
<code>01730</code>
<country>USA</country>
</postal>
<phone/>
<email>[email protected]</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="David Waltermire" initials="D.W."
surname="Waltermire">
<organization>National Institute of Standards and Technology</organization>
<address>
<postal>
<street>100 Bureau Drive</street>
<city>Gaithersburg</city>
<region>Maryland</region>
<country>USA</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author fullname="Jessica Fitzgerald-McKay" initials="J.M."
surname="Fitzgerald-McKay">
<organization>Department of Defense</organization>
<address>
<postal>
<street>9800 Savage Road</street>
<city>Ft. Meade</city>
<region>Maryland</region>
<country>USA</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<date day="13" month="March" year="2017"/>
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>SACM</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>SWID</keyword>
<keyword>PA-TNC</keyword>
<keyword>NEA</keyword>
<keyword>Software inventory</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>This document extends the PA-TNC specification <xref
target="RFC5792"/> by providing specific attributes and
message exchanges to allow endpoints to report their installed
software inventory information to a NEA server (as described in
<xref target="RFC5209"/>).</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>Knowing the list of the software installed on endpoints is
useful to understand and maintain the security state of a
network. For example, if an enterprise policy requires the
presence of certain software and prohibits the
presence of other software, reported software installation
information can be used to indicate compliance and
non-compliance with these requirements. When reported endpoint
software installation inventory lists, shortened to "software
inventories" for the remainder of this document, contain patch
level data for identified software, further comparison to
vulnerability or threat alerts can be used to determine an
endpoint's exposure to attack. These are some of the highly
useful management use cases supported by software inventory data
provided by this specification.</t>
<t>There is a need for a standardized method for exchanging software
inventory data that includes a unique software identifier
associated with a specific version of a software product.
In some cases, it may also be necessary to
convey observable installation information and
characterization information for a software product
including metadata about the product beyond its identifier.
These "Messages and
Attributes" enable software identification, installation, and
characterization information to be provided for any software
installed on any endpoint that supports this specification. Such
information can come from multiple sources, including tag files
(such as ISO SWID tags <xref target="SWID15"/>), reports from
third party inventory tools, output from package managers, and
other sources.</t>
<t>This specification is designed to only report software that is
installed on an endpoint. In particular, it does not monitor or
report information about what software is running on the
endpoint. Likewise, it is not intended to report individual
files, libraries, installation packages, or similar artifacts.
While all of this information has its uses, this information
requires different metadata and monitoring methods. As a result,
this specification focuses solely on software inventory
information, leaving reporting of other classes of endpoint
information to other specifications. </t>
<t>This specification defines a new set of PA-TNC
attributes, which are used to
communicate requests for software inventory information and software
installation change events. The exchange of these messages allows
software inventory information to be sent to a NEA Server, which
can make this information available to other applications.</t>
<section title="Network Endpoint Assessment (NEA)">
<t>The Network Endpoint Assessment (NEA) Working Group
defines an open solution architecture that enables network
operators to collect and utilize information about endpoint
configuration and state. This information can be used to
enforce policies, monitor endpoint health, and for many other
activities. Information about the software present on an
endpoint is an important consideration for such activities.
The attributes defined in this document are used to
communicate software inventory evidence, collected from a
range of possible sources, from the posture collector on the
endpoint to the posture validator on a NEA Server using the
PA-TNC interface, as shown in <xref
target="NEA-reference-model"/> below.</t>
<figure anchor="NEA-reference-model" title="NEA Reference Model">
<artwork>
<![CDATA[
+-------------+ +--------------+
| Posture | <--------PA--------> | Posture |
| Collectors | | Validators |
| (1 .. N) | | (1 .. N) |
+-------------+ +--------------+
| |
| |
| |
+-------------+ +--------------+
| Posture | | Posture |
| Broker | <--------PB--------> | Broker |
| Client | | Server |
+-------------+ +--------------+
| |
| |
+-------------+ +--------------+
| Posture | | Posture |
| Transport | <--------PT--------> | Transport |
| Client | | Server |
| (1 .. N) | | (1 .. N) |
+-------------+ +--------------+
NEA CLIENT NEA SERVER
]]>
</artwork>
</figure>
<t>To better understand this specification, the reader should review the NEA reference
architecture as described in the Network Endpoint Assessment (NEA): Overview and
Requirements <xref target="RFC5209"/>.
The reader should also
review the PA-TNC interfaces as defined in
RFC 5792 <xref target="RFC5792"/>.</t>
<t>This document is based on standards published by the Trusted Computing Group's Trusted Network
Communications (TNC)
workgroup. The TNC and NEA architectures are interoperable and the following components are equivalent:</t>
<texttable
anchor="TNC-NEA-equivalence"
title="Equivalent components in TNC and NEA architectures">
<ttcol>TNC Component</ttcol>
<ttcol>NEA Component</ttcol>
<c>Integrity Measurement Verifier (IMV)</c>
<c>Posture Validator</c>
<c>Integrity Measurement Collector (IMC)</c>
<c>Posture Collector</c>
<c>TNC Server (TNCS)</c>
<c>Posture Broker Server</c>
<c>TNC Client (TNCC)</c>
<c>Posture Broker Client</c>
</texttable>
</section>
<section title="Keywords">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be
interpreted as described in RFC 2119 <xref target="RFC2119"/>. This specification does not distinguish blocks of informative
comments and normative requirements. Therefore, for the sake of clarity, note that lower case
instances of must, should, etc. do not indicate normative requirements.</t>
</section>
<section title="Definitions">
<t>This section defines terms with special meaning within this document.</t>
<t>SW-PC - A Posture Collector (PC) that conforms to this specification. Note that
such a posture collector might also support other PA-TNC exchanges beyond those defined herein.</t>
<t>SW-PV - A Posture Validator (PV) that conforms to this specification. Note that
such a posture verifier might also support other PA-TNC exchanges beyond those defined herein.</t>
<t>SW Attribute - This is a PA-TNC attribute (as defined in RFC 5792 <xref target="RFC5792"/> extension
for conveying software inventory information. This specification defines several new attribute types.</t>
<t>Endpoint's Software Inventory Evidence Collection - The set of information regarding the set of
software installed on an endpoint.
An endpoint's software inventory evidence
collection might include information created by or derived from
multiple sources, including but not limited to SWID tag files deposited on the file system during
software installation, information generated to report output from software discovery tools, and information
dynamically generated by a software or package management system on an endpoint.</t>
<t>Software Inventory Evidence Record - The endpoint's Software Inventory Evidence Collection is composed
of "records". Each record corresponds to one installed instance of a particular software product as reported by some
data source. It is
possible for a single installed instance to have multiple software inventory evidence records in an endpoint's
Software Inventory Evidence Collection - this can happen if multiple sources all report the same software
installation instance.</t>
<t>Software Identifier - A string associated with a specific version of a specific software product.
Each supported SWIMA data model has its own rules for how a software
identifier (see <xref target="software-identifiers"/>) is derived from the representation of the
given software product using that data model,
and different sources for this information might populate relevant information differently. As such,
while each software identifier uniquely identifies a specific software product, the same software product
might be associated with multiple software identifiers reflecting differences between different data
sources and supported data models.</t>
</section>
</section>
<section title="Background">
<section anchor="supported-use-cases" title="Supported Use Cases">
<t>This section describes the use cases supported by this
specification. The primary use of exchanging software inventory information over the PA-TNC interface is to
enable a challenger (e.g. NEA Server) to obtain inventory evidence about some system in a way that
conforms to NEA procedures and expressed using a standard format.
Collected software information can support a range of security activities including determining whether an
endpoint is permitted to connect to the enterprise, determining which endpoints contain software that
requires patching, and similar activities.</t>
<section title="Use Software Inventory as an Access Control Factor">
<t>Some enterprises might define security policies that
require connected endpoints to have certain pieces of
security software installed. By contrast, some security
policies might prevent access to resources by endpoints that
have certain prohibited pieces of software installed, since
such applications might pose a security risk. To support
such policies, the NEA Server needs to collect software
inventory evidence from an endpoint that is seeking to
initiate or continue connectivity to the enterprise
resource.</t>
<t>Based on this specification, the SW-PC can provide a
complete or partial inventory to the SW-PV as required to
determine policy compliance. The SW-PV can then use this as
evidence of compliance or non-compliance to make a
policy-based access decision.</t>
</section>
<section title="Central Stores of Up-to-Date Endpoint Software Inventory Data">
<t>Many tools use information about an endpoint's software
inventory to monitor and enforce the security of a network.
For example, a software patching tool needs to determine if there is
out-of-date software installed that needs to be updated. A vulnerability
management tool needs to identify endpoints with known
vulnerable software installed (patched or otherwise) to gauge
an endpoint's relative exposure to attack. A license management tool
needs to verify that all installed software within the enterprise is accounted for.
A central repository representing an up-to-date
understanding of each endpoint's software inventory
facilitates these activities. Multiple tools can share such a repository
ensuring that software inventory
information is collected more frequently and efficiently,
leading to a more complete and consistent understanding of
installed software state as compared to each tool collecting the
same inventory information from endpoints individually.</t>
<t>This specification supports these activities through a
number of mechanisms. As noted above, a SW-PC can provide a
complete list of software present in an endpoint's Software
Inventory Evidence Collection to the SW-PV, which can then
pass this information on to a central repository, such as a
Configuration Management Database (CMDB) or similar
application. In addition, SW-PCs are required to be able to
monitor for changes to an endpoint's Software Inventory
Evidence Collection in near real-time and immediately push
reports of detected changes to the SW-PV. Thus any central
repository fed by a SW-PV receiving inventory information
can be updated quickly after a change occurs. Keeping a
central repository synchronized with current software
inventory information in this way allows tools to make
efficient decisions based on up-to-date, consistent
information.</t>
</section>
<section title="PA-TNC Use Cases">
<t>Software Inventory Message and Attributes for PA-TNC are intended to operate over the PA-TNC interface and, as such,
are intended to meet the use cases set out in the PA-TNC specification.</t>
</section>
</section>
<section title="Non-supported Use Cases">
<t>Some use cases not covered by this specification
include:<list style="symbols">
<t>Addressing how the endpoint's Software Inventory Evidence
Collection is populated. In particular, NEA components are
not expected to perform software discovery activities
beyond compiling information in an endpoint's Software
Inventory Evidence Collection. This collection might come
from multiple sources on the endpoint (e.g., information
generated dynamically by package management tools or
discovery tools, as well as SWID tag files discovered on
the file system). While an enterprise might make use of
software discovery capabilities to identify installed
software, such capabilities are outside the scope of this
specification.</t>
<t>Converting inventory information expressed in a
proprietary format into formats used in the attributes
described in this specification. Instead, this
specification focuses exclusively on defining interfaces
for the transportation of software information expecting
that reporting tools will converge around some set of
standardized formats for this information.</t>
<t>Mechanisms for a posture validator to request a specific
list of software information based on arbitrary software
properties. For example, requesting only information about
software from a particular vendor is not supported. After
the endpoint's Software Inventory Evidence Collection has
been copied to some central location, such as the CMDB,
processes there can perform queries based on any criteria
present in the collected information, but this
specification does not address using such queries to
constrain the initial collection of this information from
the endpoint.</t>
<t>Use of properties of certain sources of software
information that might facilitate local tests (i.e., on
the endpoint) of endpoint state. For example, the optional
package_footprint field of an ISO SWID tag can contain a
list of files and hash values associated with the software
indicated by the tag. Tools on the endpoint can use the
values in this field to test for the presence of the
indicated files. Successful evaluation of such tests leads
to greater assurance that the indicated software is
present on the endpoint. Currently, most SWID tag creators
do not provide values for tag fields that support local
testing. For this reason, the added complexity of
supporting endpoint testing using these fields is out of
scope for this specification, but may be considered in a
future version.</t>
</list>
</t>
</section>
<section title="Specification Requirements">
<t>Below are the requirements that the Software Inventory Message and Attributes for PA-TNC specification is required
to meet in order to successfully play its role in the NEA architecture.<list style="hanging">
<t hangText="Efficient:">The NEA architecture enables delay of network access until the endpoint is determined not
to pose a security threat to the network based on its asserted integrity information. To
minimize user frustration, the Software Inventory Message and Attributes for PA-TNC ought to minimize
overhead delays and make PA-TNC communications as rapid and efficient as possible.</t>
<t>Efficiency is also important when one considers that some network endpoints are small and
low powered, some networks are low bandwidth and/or high latency, and some transport protocols
(such as PT-EAP, Posture Transport (PT) Protocol for Extensible Authentication Protocol (EAP)
Tunnel Methods <xref target="RFC7171"/>) or their underlying carrier protocol might allow
only one packet in flight at a time or only one roundtrip. However, when the underlying PT
protocol imposes fewer constraints on communications, this protocol ought to be capable of
taking advantage of more robust communication channels (e.g. using larger messages or
multiple roundtrips).</t>
<t hangText="Scalable:">Software Inventory Message and Attributes for PA-TNC needs to be usable in enterprises that contain tens
of thousands of endpoints or more. As such, it needs to allow a security tools to make decisions based
on up-to-date information about an endpoint's software inventory without creating an
excessive burden on the enterprise's network.</t>
<t hangText="Interoperable:">This specification defines the protocol for how PCs and PVs can exchange and use software information
to provide a NEA Server with information about an endpoint's software inventory. Therefore, a
key goal for this specification is ensuring that all SW PCs and PVs, regardless of the
vendor who created them, are able to interoperate in their performance of these duties.</t>
<t hangText="Support precise and complete historical reporting:">This specification outlines capabilities that support real-time understanding of
the state of endpoint in a network in a way that can be used by other tools.
One means of facilitating such an outcome is for a
CMDB to be able to contain information about all endpoints connected to the enterprise for all
points in time between the endpoint's first connection and the present. In such a scenario, it is necessary
that any PC be able to report any changes to its software inventory evidence
collection in near real-time while connected and, upon reconnection to the enterprise, be able
to update the NEA Server (and through it the CMDB) with regard to the state of its software inventory
evidence collection throughout the entire interval when it was not connected.</t>
</list>
</t>
</section>
<section title="Non-Requirements">
<t>There are certain requirements that the Software Inventory Message and Attributes for PA-TNC specification explicitly
is not required to meet. This list is not exhaustive.</t>
<t><list style="hanging">
<t hangText="End to End Confidentiality:">This specification does not define a mechanism for confidentiality, nor is this property automatically
provided by using the PA-TNC interface. In the NEA architecture, confidentiality is generally provided by the underlying
transport protocols, such as the PT Binding to TLS <xref target="RFC6876"/> or
PT-EAP Posture Transport for Tunneled EAP Methods
<xref target="RFC7171"/> - see <xref target="Relationship"/> for more information on related
standards. Should users wish
to protect the confidentiality of assessment instructions or results, then an appropriate transport needs to be used.</t>
</list>
</t>
</section>
<section title="Assumptions">
<t>The Posture Broker Client and Posture Broker Server are assumed to provide reliable delivery for PA-TNC messages
and attributes sent between the SW-PCs and the SW-PVs. In the event
that reliable delivery cannot be provided, the Posture Collector or Posture Validator is expected to
terminate the connection.</t>
</section>
<section title="Non-Assumptions">
<t>This specification explicitly does not assume that software inventory information exchanges
reflect the software installation
state of the endpoint. This specification does not attempt to detect when the endpoint is
providing false information, either through malice or error, but instead focuses on correctly
and reliably providing the reported Software Inventory Evidence Collection to the NEA Server.
Similarly, this specification makes
no assumption about the completeness of the Software Inventory Evidence Collection's coverage of the
total set of software installed on the endpoint. It is possible, and even likely, that some
installed software is not represented by a record in an endpoints Software Inventory Evidence Collection. See
<xref target="Security"/> for more on this security consideration.</t>
</section>
</section>
<section title="System Requirements">
<t>The Software Inventory Message and Attributes for PA-TNC specification facilitates the exchange of software
inventory and event information. Specifically, each application supporting Software Inventory Message and
Attributes for PA-TNC includes a component known as the SW-PC that receives messages sent with
the SW Attributes component type. The SW-PC is also responsible for sending appropriate
SW Attributes back to the SW-PV in response. This section outlines what
software inventories and events are and the requirements
on SW-PCs and SW-PVs in order to support the stated use cases of this specification.</t>
<section title="Data Sources" anchor="information-sources">
<t>The records in an endpoint's software inventory evidence collection come from one or more "sources".
A source represents one collection of software inventory information about the endpoint. Examples of
sources include, but are not limited to, ISO SWID tags deposited on the filesystem and collected
therefrom, information derived from package managers (e.g., RPM or YUM), and the output of software
inventory scanning tools. </t>
<t>There is no expectation that any one source of inventory information will have either perfect
or complete software inventory information. For this reason, this specification supports the simultaneous
use of multiple sources of software inventory information. Each source might have its own "sphere of expertise"
and report the software within that sphere. For example, a package manager would have excellent understanding
of the software that it managed, but would not necessarily have any information about software installed
via other means.</t>
<t>A SW-PC is not required to utilize every possible source of software
information on its endpoint. Some SW-PCs might be explicitly tied
only to one or a handful of software inventory sources, or it could be designed to
dynamically accommodate new sources. For all
software inventory evidence sources that a particular SW-PC supports,
it MUST completely support all requirements of this specification
with regard to those sources. A potential source that cannot support some set of required
functionality (e.g. it is unable to monitor the software it reports for change events, as discussed
in <xref target="Monitoring-changes-in-an-endpoint"/>) MUST NOT be used as a
source of endpoint software inventory information, even
if it could provide some information. In other words, a source either supports full functionality
as described in this specification, or it cannot be used at all.</t>
<t>When sending information about installed software the SW-PC MUST include
the complete set of relevant data from all supported sources of
software inventory evidence. In other words, sources need to be used consistently. This is
because, if a particular source is included in an initial inventory, but excluded from a
later inventory, the SW-PV receiving this information might reasonably conclude that the software
reported by that source was no longer installed on the endpoint. As such, it is important that
all supported sources be used every time the SW-PC provides information to a SW-PV.</t>
<t>Note that, if a SW-PC collects data from multiple sources, it is
possible that some software products might be "double counted". This
can happen if both sources of inventory evidence provide a record for
a single installation of a software product. When a SW-PC reports information or records
events from multiple inventory evidence sources, it MUST use the
information those sources provide, rather than attempting to perform
some form of reduction. In other words, if multiple sources report
records corresponding to a single installation of a software product,
all such records from each source are required to be part of the SW-
PC's processing even if this might lead to multiple reporting, and
the SW-PC is not to ignore some records to avoid such multiple
reporting.</t>
<t>All inventory records reported by a SW-PC include a Source Identifier linking them
to a particular source. Source Identifiers are discussed more in <xref target="source_identifiers"/>.</t>
</section>
<section title="Data Models">
<t>Software Inventory Message and Attributes supports an open set of data models by which installed
software instances can be described. This reflects the fact that, as of the writing of this
specification, no one software description data model has come to dominate use, and new models
are being developed regularly. As a result, information available to SW-PCs might come in a
variety of formats, and a SW-PC could have little control over the format of the data it is
able to collect.</t>
<t>The format of the data model used to convey software inventory information had very little
impact on the behavior of the components defined in this specification. The SW-PV has no dependency
on the data model conveyed in SWIMA messages. For this reason, it MUST NOT reject a record or respond
with a PA-TNC Error due to the data model used in attributes it receives. (Note that the SW-PV might
serve as the front-end of other functionality that does have a dependency on the data model used to
express software information, but any such dependency is beyond the scope of this specification and
needs to be addressed outside the behaviors specified in this document. This specification is only
concerned with collection and delivery of software inventory information; components that consume
and use this information are a separate concern.)</t>
<t>The SW-PC does have one functional dependency on the data models used in the software records it
delivers, but only insofar as it is required to deterministically create a Software Identifier (described in
<xref target="software-identifiers"/>) based on each record it delivers. The SW-PC MUST be able
to generate a Software Identifier for each record it delivers, and if the SW-PC cannot do so the
record cannot be delivered by the SW-PC. All SW-PCs MUST at least be able to generate Software Identifiers
for the data model types specified in <xref target="supported-data-models"/> of this document.
A SW-PC MAY include the ability to generate Software Identifiers for other data model types, and thus
be able to support them as well.</t>
</section>
<section anchor="Basic-exchange" title="Basic Attribute Exchange">
<t>In the most basic exchange supported by this specification, a SW-PV sends a request to the
SW-PC requesting some type of information about the endpoint's software inventory. This simple
exchange is shown in <xref target="Basic-sw-message-exchange"/>.</t>
<figure anchor="Basic-sw-message-exchange" title="Basic SW Attribute Exchange">
<artwork>
<![CDATA[
+-------------+ +--------------+
| SW-PC | | SW-PV | Time
+-------------+ +--------------+ |
| | |
|<--------------SW Request----------------| |
| | |
|---------------SW Response-------------->| |
| | V
]]>
</artwork>
</figure>
<t>Upon receiving such a SW Request from the SW-PV, the SW-PC is expected to collect all
the relevant software inventory
information from the endpoint's software evidence collection and place it within its
response attribute.</t>
<t>SW-PVs MUST discard without error any SW Response attributes that they receive for which
they do not know the SW Request parameters that led to this SW Response. This is due to the
fact that the SW Request includes parameters that control the nature of the response (as will be
described in the following sections) and without knowing those parameters the SW Response
cannot be reliably interpreted. Most often receiving an unsolicited SW Response attribute happens
when a NEA Server has multiple SW-PVs; one SW-PV sends a SW Request but, unless exclusive
delivery is used by the SW-PC in sending the response, both SW-PVs receive copies of the
resulting SW Response. In this case, the SW-PV that didn't send the SW Request would lack
the context necessary to correctly interpret the SW Response it received and would simply discard
it. Note, however, that proprietary measures might allow a SW-PV to discover the SW Request
parameters for a SW Response even if that SW-PV did not send the given SW Request. As
such, there is no blanket requirement for a SW-PV to discard all SW Responses to SW
Request the SW-PV did not generate itself, only that SW-PVs are required to discard SW
Responses for which they cannot get the necessary context to interpret.</t>
<t>In the case that it is possible to do so, the SW-PC SHOULD send its SW Response attribute to the
SW-PV that requested it using exclusive delivery as described in section 4.5 of RFC 5793
(PB-TNC) <xref target="RFC5793"/>. Exclusive delivery ensures that only the sender of the SW Request receives the
resulting SW Response.</t>
</section>
<section title="Core Software Reporting Information">
<t>Different parameters in the SW Request can influence what information is returned in the SW
Response. However, while each SW Response provides different
additional information about this installed software, they all share a common set of fields that
support reliable software identification on an endpoint. These fields include: Software Identifiers, the Data Model Type,
Record Identifiers, Software Locators, and Source Identifiers. These fields are present for each reported piece of
software in each type of SW Response. The following sections examine these three types of
information in more detail.
</t>
<section anchor="software-identifiers" title="Software Identifiers">
<t>A Software Identifier uniquely identifies a specific version of a specific software product.
The Software Inventory Message and Attributes for PA-TNC specification does not dictate the structure of a
Software Identifier (beyond stating that it is a string) or define how it is created. Instead,
each data model described in the Software Data Model IANA table (<xref target="IANA_Software_Data_Models"/>)
includes its own rules for how a Software Identifier is created based on a record in the Endpoint's
Software Inventory Evidence Collection expressed in that data model. Other data models will have their
own procedures for the creation of associated Software Identifiers. Within the Software Inventory Message and
Attributes for PA-TNC specification, the Software Identifier is simply an opaque string and there
is never any need to unpack any information that might be part of that identifier.</t>
<t>A Software Identifier is a fraction
of the size of the inventory record from which it is derived. For some combinations
of data models and sources, the full record might never be necessary as the identifier can be
directly correlated to the contents of the full record. This is possible with authoritative
SWID tags, since these tags always have the same contents and thus a Software Identifier derived
from these tags can be used as a lookup to a local copy of the full tag. For other combinations of
source and data model, a server might not be able to determine the specific software product and
version associated with the identifier without requesting delivery of the full record. However, even in
those cases, downstream consumers of this information might never need the full record as long as
the Software Identifiers they receive can be tracked reliably.
A SW-PV can use Software Identifiers to track the presence of specific software products on
an endpoint over time in a bandwidth-efficient manner.</t>
<t>There are two important limitations of Software Identifiers to keep in mind:
<list style="numbers">
<t> The identifiers do not necessarily change when the associated record changes. In some
situations, a record in the endpoint's Software Inventory Evidence Collection will change
due to new information becoming available or in order to correct prior errors in that information.
Such changes might or might not result in changes to the Software Identifier, depending on the
nature of the changes and the rules governing how Software Identifiers are derived from records
of the appropriate data model. </t>
<t>It is possible that a single software product is installed on a single endpoint multiple times.
If both of these installation instances are reported by the same source using the same data format,
then this can result in identical Software Identifiers for each installation instances. In other
words, Software Identifiers might not uniquely identify installation instances; they just are intended to uniquely
identify software products (which might have more than one installation instance). Instead,
to reliably distinguish between multiple instances of a single software product, one needs to make use
of Record Identifiers, described in the following section.</t>
</list></t>
</section>
<section title="Data Model Type" anchor="data-model-type">
<t>The Data Model Type consists of two fields: the Data Model Type PEN and the Data Model Type. The combination
of these fields is used to identify the type of data model of the associated software inventory record.
The data model is significant not only because it informs the recipient of the data model
of the associated record, but because the Software Identifier of the record is derived directly from
the data recorded in that data model. As a result, Software Identifiers for the same software product
but expressed via different data models might be different. Clearly identifying the type of data
model from with the Software Identifier was derived thus provides useful context for that value.</t>
<t>The PEN (or Private Enterprise Number) identifies the organization that assigns meaning to the
Data Model Type field value. PENs are managed by IANA in the Private Enterprise Numbers registry.
PENs allow vendors to designate
their own set of data models for software inventory description. IANA reserves the PEN of 0x000000.
Data Model Types associated with this PEN are defined in the Software Data Model IANA table, created
in <xref target="IANA_Software_Data_Models"/> of this specification. Note that this IANA table reserves
all values greater than or equal to 0xC0 (192) for enterprise use. This means that local enterprises can
use custom data formats and indicate them with the IANA PEN and a Data Model Type value between 0xC0 and
0XFF, inclusive. Those enterprises are responsible for configuring their SW-PCs to correctly report
those custom data models.</t>
</section>
<section title="Record Identifiers" anchor="record_identifiers">
<t>A Record Identifier is a 4-byte integer generated by the SW-PC that is uniquely associated with a specific
record within the Endpoint's Software Inventory Evidence Collection. The SW-PC MUST assign a unique
identifier to each record when it is added to the Endpoint's Software Inventory Evidence Collection.
The Record Identifier SHOULD remain unchanged if that record is modified. The SWID-PC might wish to
assign Record Identifiers sequentially, but any scheme is acceptable provided that no two records receive
the same identifier.</t>
<t>Servers can use Record Identifiers to distinguish between multiple instances of a single software
product installed on an endpoint. Since each installation instance of a software product is associated
with a separate record, servers can use the record identifier to distinguish between instances. For
example, if an event is reported (as described in <xref target="Reporting-change-events"/>), the record
identifier will allow the server to discern which instance of a software product is involved.</t>
</section>
<section title="Software Locators" anchor="software-locator">
<t>In addition to the need to identify software products, many use cases of inventory information
need to know where software is located on the endpoint. This information might be needed to
direct remediation actions or similar processes. For this reason, every reported software product
also includes a Software Locator to identify where the software is installed on the endpoint.
</t>
<t>If the location is not provided directly by the record source the SW-PC is responsible for
attempting to determine the location of the software product. The "location" of a product SHOULD
be the directory in which the software products executables are kept. However, if that directory
is shared by other software products, the "location" SHOULD be the location of the primary executable
associated with the software product. The source and/or SW-PC MUST be
consistent in reporting the location of a software product (i.e., it cannot use the executable
location in one report and the directory location in another).
</t>
<t>The location is expressed as a URI string consisting of a scheme and path. <xref target="RFC3986"/>
The location URI does not include an authority part. The URI schema describes the context of the
described location. For example, in most cases the location of the installed software product
will be expressed in terms of its path in the filesystem. For such locations, the location URI
scheme MUST be "file". It is possible that other schemes could be used to represent other location
contexts. Apart from reserving the "file" and "unknown" (described below) scheme to indicate an
installation location expressed using a path in the endpoint's file system, this specification
does not reserve schemes. When representing software products in other location contexts, tools
MUST be consistent in their use of schemes, but the exact string used in those schemes is not normatively defined here.
</t>
<t>It is possible, that a SW-PC is unable to determine the location of a reported software product.
In this case, the SW-PC MUST assign that software product a location of "unknown:". (I.e., the "unknown"
scheme and an empty path.) However, SW-PCs SHOULD only make such an assignment as a last resort. Even
a probable location for a software product is preferable to using the unknown indicator.
</t>
</section>
<section title="Source Identifiers" anchor="source_identifiers">
<t>All SW-PCs MUST track the source of each piece of software information they report. Each
time a SW-PC gets information to send to a given SW-PV from a new source (from the perspective
of that SW-PV), the SW-PC MUST assign that source a Source Identification Number, which is an
8-bit unsigned integer. Each item reported includes the Source Identification Number that provided
that information. All information that is provided by
that source, MUST be delivered with this same Source Identification Number. This MUST be done
for each source used. If the SW-PC ever is unclear as to whether a given source is new or not,
it MUST assume that this is a new source and assign it a new Source Identification Number.
Source Identification Numbers can help with (although will not completely eliminate) the challenges
posed by multiple reporting of a single software instance: since a single source would only report
an instance or event once, if multiple reports of a similar instance come from multiple sources,
this might be an instance of multiple reporting (although it still might not be so). On the other
hand, if multiple instances are reported by a single source, this almost certainly means that
there are actually multiple instance that are being legitimately reported.</t>
<t>The SW-PC is responsible for tracking associations between Source Identifiers and the given
data source. This association MUST remain consistent with regard to a given SW-PV while there is
an active PB-TNC session with that SW-PV. The SW-PC MAY have a different Source Identifier association
for different SW-PVs. Likewise, the SW-PC MAY change the Source Identifier association for a given
SW-PV if the PB-TNC session terminates. However, implementers of SW-PCs will probably find it easier
to manage associations by maintaining the same association for all SW-PVs and across multiple sessions.</t>
<t>Of special note, events records reported from the SW-PC's event log (discussed in <xref target="Reporting-change-events"/>)
also
need to be sent with their associated data source. The Source Identifier reported with events MUST be
the current (i.e., at the time the event is sent) Source Identifier associated with the data source
that produced the event, regardless of how long ago that event occurred. Event logs are likely to
persist far longer than a single PB-TNC session. SW-PCs MUST ensure that each event can be linked
to the appropriate data source, even if the Source Identifiers used when the event was created have
since been reassigned. In other words, when sending an event, it needs to be sent with the Source
Identifier currently linked to the data source that produced it, regardless of whether a different
Source Identifier would have been associated with the event when the event was first created.</t>
<t>Note that the Source Identification Number is primarily used to support recognition, rather than
identification, of sources. That is to say, a Software Identification Number can tell a recipient
that two events were reported by the same source, but will not necessarily help that recipient
determine which source was used. Moreover, different SW-PCs will not necessarily use the same
Source Identification Numbers for the same sources. SW-PCs MUST track the assignment of Source
Identification Numbers to ensure consistent application thereof. SW-PCs MUST also track which Source
Identification Numbers have been used with each SW-PV with which they communicate.</t>
</section>
<section anchor="Using-record-identifiers-in-SW-attributes" title="Using Software and Record Identifiers in SW Attributes">
<t>A SW Attribute reporting an endpoint's Software Inventory Evidence Collection always contains the Software
Identifiers associated with the identified software products. A SW Attribute might or might not also contain
copies of software inventory evidence records. The attribute exchange is identical to the diagram
shown in <xref target="Basic-sw-message-exchange"/> regardless of whether software inventory evidence records are included.
The SW Request attribute indicates whether the response is required to include software inventory evidence records.
Excluding software inventory evidence records can reduce the attribute size of the response
by multiple orders of magnitude when compared to sending the same inventory with full records. </t>
</section>
</section>
<section anchor="Targeted-requests" title="Targeted Requests">
<t>Sometimes a SW-PV does not require information about every piece of software on an endpoint but only needs
to receive updates about certain software instances. For example, enterprise endpoints might be required to
have certain software products installed and to keep these updated. Instead of requesting a complete inventory
just to see if these products are present, the SW-PV can make a "targeted request" for the software in question.</t>
<t>Targeted requests follow the same attribute exchange described in <xref target="Basic-sw-message-exchange"/>.
The SW-PV targets
its request by providing one or more Software Identifiers in its SW Request attribute. The SW-PC
MUST then limit its response to contain only records that match the indicated Software Identifier(s). This
allows the network exchange to exclude information that is not relevant to a given policy question,
thus reducing unnecessary bandwidth consumption. The SW-PC's response might or might not include software inventory
evidence records, depending on the parameters of the SW Request.</t>
<t>Note that targeted requests identify the software relevant to the request only through Software
Identifiers. This specification does not support arbitrary, parameterized querying of
records. For example, one cannot request all records from a certain software publisher, or all records created
by a particular record source. Targeted requests only allow a requestor to request specific software (as
identified by their Software Identifiers) and receive a response that is limited to the named software.</t>
<t>There is
no assumption that a SW-PC will recognize "synonymous records" - that is, records from different sources
for the same software. Recall that different sources and data models may use different Software Identifier
strings for the same software product. The SW-PC returns only records that match the Software Identifiers
in the SW Request, even if there might be other records in the endpoint's Software Inventory Evidence Collection
for the same software product. This is necessary because SW-PCs might not have the ability to determine
that two Software Identifiers refer to the same product.</t>
<t>Targeted requests do not include Record Identifiers or Software Locators. The response to a targeted request MUST
include all records associated with the named Software Identifiers, including the case where
there are multiple records associated with a single Software Identifier.</t>
<t>SW-PCs MUST accept targeted requests and process them correctly as described above. SW-PVs
MUST be capable of making targeted requests and processing the responses thereto.</t>
</section>
<section anchor="Monitoring-changes-in-an-endpoint"
title="Monitoring Changes in an Endpoint's Software Inventory Evidence Collection">
<t>The software collection on an endpoint is not static. As software is installed, uninstalled, patched, or
updated, the Software Inventory Evidence Collection is expected to change to reflect the new software state on the
endpoint. Different record sources might update the evidence collection at different rates. For example, a
package manager might update its records in the Software Inventory Evidence Collection immediately whenever
it is used to add or remove a software product. By contrast, sources that perform periodic examination of the
endpoint would likely only update their records in the Software Inventory Evidence Collection after each
examination.</t>
<t>All SW-PCs MUST be able to be able to detect changes to the Software Inventory Evidence Collection.
Specifically, SW-PCs MUST be able to detect:</t>
<t>
<list style="symbols">
<t>The creation of records</t>
<t>The deletion of records</t>
<t>The alteration of records</t>
</list>
</t>
<t>An "alteration" is anything that modifies the contents of a record (or would modify it, if the record
is dynamically generated on demand) in any way, regardless of whether the change is functionally
meaningful. </t>
<t>SW-PCs MUST detect such changes to the endpoint's Software Inventory Evidence Collection in close to real-time
(i.e., within seconds) when the Posture Collector is operating. In addition, in the case where there is a period during
which the SW-PC is not operating, the SW-PC MUST be able to determine the net change to
the endpoint's Software Inventory Evidence Collection over the period it was not operational. Specifically, the "net
change" represents the difference between the state of the endpoint's Software Inventory Evidence Collection when the
SW-PC was last operational and monitoring its state, and the state of the endpoint's software inventory evidence
collection when the SW-PC resumed operation. Note that a net change might not reflect the total
number of change events over this interval. For example, if a record was altered three times
during a period when the SW-PC was unable to monitor for changes, the net change of this interval
might only note that there was an alteration to the record, but not how many individual alteration events
occurred. It is sufficient for a SW-PC's determination of a net change to note that there was a
difference between the earlier and current state rather than enumerating all the individual events that
allowed the current state to be reached.</t>
<t>The SW-PC MUST assign a time to each detected change in the endpoint's Software Inventory Evidence Collection.
These timestamps correspond to the SW-PC's best understanding as to when the detected
change occurred. These timestamps MUST be as accurate as possible. For changes to the
endpoint's Software Inventory Evidence Collection that occur while the SW-PC is operating, the SW-PC ought to
be able to assign a time to the event that is accurate to within a few seconds. For changes to the
endpoint's Software Inventory Evidence Collection that occur while the SW-PC is not operational, upon becoming
operational the SW-PC needs to make a best guess as to the time of the relevant events (possibly
by looking at timestamps on files), but these values might be off. In the case of dynamically
generated records, the time of change is the time at which the data from which the records are
generate changes, not the time at which a changed record is generated. For example, if records
are dynamically generated based on data in an RPM database, the time of change would be
when the RPM database changed.</t>
<t>With regard to deletions of records, the SW-PC needs to detect the deletion and MUST retain
a copy of the full deleted record along with the associated Record Identifier and Software Locator so that the record
and associated information can
be provided to the SW-PV upon request.
This copy of the record MUST be retained for a reasonable amount of time. Vendors and
administrators determine what "reasonable" means, but a copy of the record SHOULD be retained for
as long as the event recording the deletion of the record remains in the SW-PC's event log (as
described in <xref target="Reporting-change-events"/>). This is
recommended because, as long as the event is in the SW-PC's change logs, the SW-PC might
send an event attribute (described in <xref target="Reporting-change-events"/>) that references this record,
and a copy of the record is
needed if the SW-PV wanted a full copy of the relevant records.</t>
<t>With regard to alterations to a record, SW-PCs MUST detect any alterations to the contents
of a record. Alterations need to be detected even if they have no functional impact on the record. A
good guideline is that any alteration to a record that might change the value of a hash taken on the record's
contents needs to be detected by the SW-PC. A SW-PC might be unable to distinguish
modifications to the content of a record from modifications to the metadata the file system associates
with the record. For example, a SW-PC might use the "last modification" timestamp as an
indication of alteration to a given record, but a record's last modification time can change for reasons
other than modifications to the record contents. A SW-PC is still considered compliant with this
specification if it also reports metadata change events that do not change the record itself as
alterations to the record. In other words, while SW-PC authors are encouraged to exclude
modifications that do not affect the bytes within the record, discriminating between modifications
to file contents and changes to file metadata can be
difficult and time consuming on some systems. As such, as long as the alterations detected by a
SW-PC always cover all modifications to the contents of record, the SW-PC is considered
compliant even if it also registers alterations that do not modify the contents of a record as well. When
recording an alteration to a record, the SW-PC is only required to note that an alteration occurred.
The SW-PC is not required to note or record how the record altered, nor is it possible to include
such details in SW Attributes reporting the change to a SW-PV. There is no need to retain a copy of the original record.</t>
<t>When a record changes it SHOULD retain the same Record Identifier. The Software Locator might or
might not change, depending on whether the software changed locations during the changes that led
to the record change. A record change MUST retain the same Software Identifier. This means that any
action that changes a software product (e.g., application of a patch that results in a change to
the product's version) MUST NOT be reflected by a record change but instead MUST result in the
deletion of the old record and the creation of a new record. This reflects the requirement that a
record in the endpoint's Software Inventory Evidence Collection correspond directly with an
instance of a specific software product.
</t>
</section>
<section anchor="Reporting-change-events" title="Reporting Change Events">
<t>As noted in the preceding section, SW-PCs MUST be able to detect changes to the endpoints Software Inventory
Evidence Collection (creation, deletion, and alteration) in near real-time while the SW-PC is
operational, and MUST be able to account for any net change to the endpoint's Software Inventory Evidence Collection
that occurs when the SW-PC is not operational. However, to be of use to the enterprise, the NEA Server
needs to be able to receive these events and be able to understand how new changes relate to earlier
changes. In Software Inventory Message and Attributes for PA-TNC, this is facilitated by reporting change events. All
SW-PCs MUST be capable of receiving requests for change events and sending change event
attributes. All SW-PVs MUST be capable of requesting and receiving change event attributes.</t>
<section anchor="Change-event-records" title="Event Identifiers">
<t>To be useful, change events need to be correctly ordered. Ordering of events is
facilitated by two pieces of information: an Event Identifier (EID) value and an EID Epoch value.</t>
<t>An EID is a 4-byte unsigned integer that the SW-PC assigns sequentially to each observed event
(whether detected in real-time or deduced by looking for net changes over a period of SW-PC
inactivity). All EIDs exist within the context of some "EID Epoch", which is also represented as a
4-byte unsigned integer. EID Epochs are used to ensure synchronization between the SW-PC and
any SW-PVs with which it communicates. EID Epoch values SHOULD be generated randomly
and in such a way that it is unlikely that the same EID Epoch is generated twice, even if the SW-PC
reverted to an earlier state (e.g., resetting it to factory defaults). In the case where a SW-PC
needs to reset its EID counter, either because it has exhausted all available EID values or because
the SW-PC's event log becomes corrupted, then a new EID Epoch MUST be selected.</t>
<t>Within an Epoch, EIDs MUST be assigned sequentially, so that if a particular event is assigned an
EID of N, the next observed event is given an EID of N+1. In some cases, events might occur
simultaneously, or the SW-PC might not otherwise be able to determine an ordering for events.
In these cases, the SW-PC creates an arbitrary ordering of the events and assigns EIDs according
to this ordering. Two change events MUST NOT ever be assigned the same EID within the same EID
Epoch. No meaningful comparison can be made between EID values of different Epochs.</t>
<t>The EID value of 0 is reserved and MUST NOT be associated with any event. Specifically, an EID of
0 in a SW Request attribute indicates that a SW-PV wants an inventory response rather than
an event response, while an EID of 0 in a SW Response is used to indicate the initial state of the
endpoint's Software Inventory Evidence Collection prior to the observation of any events. Thus the very first recorded
event in a SW-PC's records within an EID Epoch MUST be assigned a value of 1 or greater.
Note that EID and EID Epoch values are assigned by the SW-PC without regard to whether events
are being reported to one or more SW-PVs. The SW-PC records events and assigns EIDs
during its operation. Any and all SW-PVs that request event information from the SW-PC will
have those requests served from the same event records and thus will see the same EIDs and EID Epochs
for the same events.</t>
<t>If a SW-PC uses multiple sources, a SW-PC's assignment of EIDs
MUST reflect the presence and order of all events on the endpoint (at
least for supported sources) regardless of the source. This means
that if source A experiences an event, and then source B experiences
two events, and then source A experiences another two events, the SW-
PC is required to capture five events with consecutive EID values
reflecting the order in which the events occur.</t>
<t>The SW-PC MUST ensure there is no coverage gap (i.e., change events that are not recorded in
the SW-PC's records) in its change event records. This is necessary because a coverage gap
might give a SW-PV a false impression of the endpoint's state. For example, if a SW-PV saw
an event indicating that a particular record had been added to the endpoint's software inventory
evidence collection, and saw no subsequent events
indicating that record had been deleted, it might reasonably assume that this record was still present
and thus that the indicated software was still installed
(assuming the Epoch has not changed). If there is a coverage gap in the SW-PC's event records,
however, this assumption could be false. For this reason, the SW-PC's event records MUST NOT contain
gaps. In the case where there are periods where it is possible that changes occurred without the
SW-PC detecting or recording them, the SW-PC MUST either compute a net change and
update its event records appropriately, or pick a new EID Epoch to indicate a discontinuity with previous
event records.</t>
<t>Within a given Epoch, once a particular event has been assigned an EID, this association MUST
NOT be changed. That is, within an Epoch, once an EID is assigned to an event, that EID cannot be
reassigned to a different event, and the event cannot be assigned a different EID. When the SW-PC's
Epoch changes, all of these associations between EIDs and events are cancelled, and EID
values once again become free for assignment.</t>
</section>
<section title="Core Event Tracking Information">
<t>Whether reporting events or full inventories it is important to know how the reported information
fits into the overall timeline of change events. This is why all SW Response attributes include fields
to place that response within the sequence of detected events. Specifically, all SW Responses include
a Last EID and EID Epoch field. The EID Epoch field identifies the EID Epoch in which the SW Response
was sent. If the SW Response is reporting events, all reported events occurred within the named EID Epoch.
The Last EID (which is also always from the named EID Epoch) indicates the EID of the last recorded change
event at the time that the SW Response was sent. These two fields allow any response to be placed in the
context of the complete set of detected change events within a given EID Epoch.
</t>
</section>
<section title="Updating Inventory Knowledge Based on Events">
<t>Modern endpoints can have hundreds of software products installed, most of which are unlikely to
change from one day to the next. As such, instead of exchanging a complete list of an endpoint's
inventory on a regular basis, one might wish to only identify changes since some earlier known state
of this inventory. This is readily facilitated by the use of EIDs to place change events in a context
relative to earlier state.</t>
<t>As noted above, every SW Response sent by a SW-PC to a SW-PV (as described in <xref target="Basic-exchange"/> through
<xref target="Targeted-requests"/>)
includes the EID Epoch and EID of the last event recorded prior to that response being compiled.