-
Notifications
You must be signed in to change notification settings - Fork 1
/
draft-camwinget-sacm-information-model-01.xml
1142 lines (1016 loc) · 57.3 KB
/
draft-camwinget-sacm-information-model-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"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.0.30 -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3635 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3635.xml">
<!ENTITY RFC1573 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1573.xml">
<!ENTITY RFC7632 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7632.xml">
<!ENTITY I-D.ietf-sacm-requirements SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-sacm-requirements.xml">
]>
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc comments="yes"?>
<rfc ipr="trust200902" docName="draft-cam-winget-sacm-information-model-01" category="std">
<front>
<title>SACM Information Model</title>
<author initials="H." surname="Birkholz" fullname="Henk Birkholz">
<organization abbrev="Fraunhofer SIT">Fraunhofer SIT</organization>
<address>
<postal>
<street>Rheinstrasse 75</street>
<city>Darmstadt</city>
<code>64295</code>
<country>Germany</country>
</postal>
<email>henk.birkholz@sit.fraunhofer.de</email>
</address>
</author>
<author initials="N." surname="Cam-Winget" fullname="Nancy Cam-Winget">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>3550 Cisco Way</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>ncamwing@cisco.com</email>
</address>
</author>
<date year="2016" month="May" day="02"/>
<area>security</area>
<workgroup>SACM Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>This document defines the information elements that are transported between SACM components and their interconnected relationships. The primary purpose of the Secure Automation and Continuous Monitoring (SACM) Information Model is to ensure the interoperability of corresponding SACM data models and addresses the use cases defined by SACM. The information elements and corresponding types are maintained as the IANA “SACM Information Elements” registry.</t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t><spanx style="strong">replaces Introduction in the WG IM</spanx></t>
<t>The SACM Information Model (IM) serves multiple purposes:</t>
<t><list style="symbols">
<t>to ensure interoperability between SACM data models that are used as transport encoding,</t>
<t>to provide a standardized set on information elements - the SACM Vocabulary - to enable the exchange of content vital to automated security posture assessment, and</t>
<t>to enable secure information sharing in a scalable and extensible fashion in order to support the tasks conducted by SACM components.</t>
</list></t>
<t>A complete set of requirements imposed on the IM can be found in <xref target="I-D.ietf-sacm-requirements"/>. The SACM IM is intended to be used for standardized data exchange between SACM components (data in motion). Nevertheless, the information elements (IE) and their relationships defined in this document can be leveraged to create and align corresponding data models for data at rest.</t>
<t>The information model expresses, for example, target endpoint (TE) attributes, guidance or evaluation results. The corresponding information elements are consumed and produced by SACM components as they carry out tasks.</t>
<t>The primary tasks that this information model supports (on data,control and management plane) are:</t>
<t><list style="symbols">
<t>TE Discovery</t>
<t>TE Characterization</t>
<t>TE Classification</t>
<t>Collection</t>
<t>Evaluation</t>
<t>Information Sharing</t>
<t>SACM Component Discovery</t>
<t>SACM Component Authentication</t>
<t>SACM Component Authorization</t>
<t>SACM Component Registration</t>
</list></t>
</section>
<section anchor="requirements-notation" title="Requirements notation">
<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”,
“SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and
“OPTIONAL” in this document are to be interpreted as described in RFC
2119, BCP 14 <xref target="RFC2119"/>.</t>
</section>
<section anchor="information-elements" title="Information Elements">
<t><spanx style="strong">to be inserted between section 2 and section 3</spanx></t>
<t>The Information Elements (IE) defined in this document comprise the building blocks by which all SACM Content is composed. They are consumed and provided by SACM components on the data plane. Every information element has a unique label: its name. Every type of IE defined by the SACM IM is registered as a type at the IANA registry. The Integer Index of the IANA SMI number tables can be used by SACM data models.</t>
<section anchor="context-of-information-elements" title="Context of Information Elements">
<t>The IE in this information model represent information related to the following areas (based on the use cases described in <xref target="RFC7632"/>):</t>
<t><list style="symbols">
<t>Endpoint Management</t>
<t>Software Inventory Management</t>
<t>Hardware Inventory Management</t>
<t>Configuration Management</t>
<t>Vulnerability Management</t>
</list></t>
</section>
<section anchor="extensibility-of-information-elements" title="Extensibility of Information Elements">
<t>A SACM data model based on this information model MAY include additional information elements that are not defined here. The labels of additional information elements included in different SACM data models MUST NOT conflict with the labels of the information elements defined by this information model, and the names of additional information elements MUST NOT conflict with each other or across multiple data models. In order to avoid naming conflicts, the labels of additional IEs SHOULD be prefixed to avoid collision across extensions. The prefix MUST include an organizational identifier and therefore, for example, MAY be an IANA enterprise number, a (partial) name space URI or an organization name abbreviation.</t>
</section>
</section>
<section anchor="structure-of-information-elements" title="Structure of Information Elements">
<t><spanx style="strong">replaces beginning text of Information Model Framework and 3.1-3.4, will move syntax 3.1.1 and 3.2.1 to aggregated sub-section, will also privacy sub-section 3.5 and label sub-section 3.6</spanx></t>
<t>A SACM data model based on this information model MAY include additional information elements that are not defined here. The labels of additional information elements included in different SACM data models MUST NOT conflict with the labels of the information elements defined by this information model, and the names of additional information elements MUST NOT conflict with each other or across multiple data models. In order to avoid naming conflicts, the labels of additional IEs SHOULD be prefixed to avoid collision across extensions. The prefix MUST include an organizational identifier and therefore, for example, MAY be an IANA enterprise number, a (partial) name space URI or an organization name abbreviation.
VIER
There are two basic types of IE:</t>
<t><list style="symbols">
<t>Attributes: an instance of an attribute type is the simplest IE structure comprised of a unique attribute name and an attribute value (attributes are listed in Section {{AIE}).</t>
<t>Subjects: a subject is a richer structure that has a unique subject name and one or more attributes or subjects (subjects are listed in Section {{CIE}). In essence, instances of a subject type are defined (and differentiated) by the attribute values and subjects associated with it.</t>
</list></t>
<t>The notation the SACM IM is defined in is based on the IPFIX information model syntax described in FIXME. The examples presented in this section use simplified pseudo-code to illustrate the basic structure.</t>
<t>Example: an instance of an attribute and an instance of a subject</t>
<figure><artwork type="pseudo-code"><![CDATA[
hostname = "arbutus"
coordinates = (
latitude = N27.99619,
longitude = E86.92761
)
]]></artwork></figure>
<t>In general, every piece of information that enables security posture assessment or further enriches the quality of the assessment process can be associated with metadata. In the SACM IM, metadata is represented by specific subjects and is bundled with other attributes or subjects to provide additional information about them. The IM explicitly defines two kinds of metadata: metadata focusing on the data origin (the SACM component that provides the information to the SACM domain) and metadata focusing on the data source (the target endpoint that is assessed). Metadata can also include relationships that refer to other associated IE (or SACM content in general) by using referencing labels that have to be included in the metadata of the associated IE.</t>
<t>Subjects can be nested and the SACM IM allows for circular or recursive nesting. The association of IE via nesting results in a tree-like structure wherein subjects compose the root and intermediary nodes and attributes the leaves of the tree. This semantic structure does not impose a specific structure on SACM data models regarding data in motion or data repository schemata for data at rest.</t>
<t>The SACM IM provides two top-level subjects that are used to ensure a homogeneous structure for SACM content and its associated metadata: SACM statements and SACM content-elements. Every set of IE that is provided by a SACM component in order to be consumed by another SACM component uses these top-level subjects.</t>
<section anchor="sacm-content-elements" title="SACM Content Elements">
<t>Every piece of information that is provided by a SACM component is always associated with a set of metadata, for example, the timestamp at which this set of information was produced (e.g. by a collection task) or what target endpoint this set of information is about (e.g. the data-source or a target endpoint identifier, respectively). The subject that associates content IE with content-metadata IE is called a content-element. Content metadata can also include relationships that express associations with other content-elements.</t>
<t>Example: a set of IE associated with a timestamp and a target endpoint label</t>
<figure><artwork type="pseudo-code"><![CDATA[
content-element = (
content-metadata = (
collection-timestamp = 146193322,
data-source = fb02e551-7101-4e68-8dec-1fde6bd10981
),
hostname = "arbutus",
coordinates = (
latitude = N27.99619,
longitude = E86.92761
)
)
]]></artwork></figure>
</section>
<section anchor="sacm-statements" title="SACM Statements">
<t>SACM Statements</t>
<t>One or more SACM content elements are bundled in a SACM statement. In contrast to content-metadata, statement-metatdata focuses on the providing SACM component instead of the target endpoint the content is about. The only content-specific metadata included in the SACM statement is the content-type IE. Therefore, multiple content-elements that share the same statement metadata and are of the same content-type can be included in a single SACM statement.
A SACM statement functions similar to an envelope or a header. Its purpose is to enable the tracking of the origin of data inside a SACM domain and more importantly to enable the mitigation of conflicting information that my originate from different SACM components. How a consuming SACM component actually deals with conflicting information is out-of-scope of the SACM IM. Semantically, the term statement implies that the SACM content provided by a SACM component might not be correct in every context, but rather is the result of an best-effort to produce correct information.</t>
<t>Example: A simple SACM statement including a single content-element.</t>
<figure><artwork type="pseudo-code"><![CDATA[
sacm-statement = (
statement-metadata = (
publish-timestamp = 1461934031,
data-origin = 24e67957-3d31-4878-8892-da2b35e121c2,
content-type = observation
),
content-element = (
content-metadata = (
collection-timestamp = 146193322,
data-source = fb02e551-7101-4e68-8dec-1fde6bd10981
),
hostname = "arbutus"
),
)
]]></artwork></figure>
<t>Example: Conflicting information originating from different SACM components</t>
<figure><artwork type="pseudo-code"><![CDATA[
sacm-statement = (
statement-metadata = (
publish-timestamp = 1461934031,
data-origin = 24e67957-3d31-4878-8892-da2b35e121c2
content-type = observation,
),
content-element = (
content-metadata = (
collection-timestamp = 146193322,
data-source = fb02e551-7101-4e68-8dec-1fde6bd10981
),
coordinates = (
latitude = N27.99619,
longitude = E86.92761
)
),
)
sacm-statement = (
statement-metadata = (
publish-timestamp = 1461934744,
data-origin = e42885a1-0270-44e9-bb5c-865cf6bd4800,
content-type = observation
),
content-element = (
content-metadata = (
collection-timestamp = 146193821,
te-label = fb02e551-7101-4e68-8dec-1fde6bd10981
),
coordinates = (
latitude = N16.67622,
longitude = E141.55321
),
),
)
]]></artwork></figure>
</section>
<section anchor="relationship-types" title="Relationship Types">
<t>An IE can be associated with another IE, e.g. a user-name attribute can be associated with a content-authorization subject. These references are expressed via the relationships subject, which can be included in a corresponding content-metadata subject. The relationships subject includes a list of one ore more references.
The SACM IM does not enforce a SACM domain to use unique identifiers as references. Therefore, there are at least two ways to reference another content-element:</t>
<t><list style="symbols">
<t>the value of a reference represents a specific content-label that is unique in a SACM domain (and has to be included in the corresponding content-element metadata in order to be referenced), or</t>
<t>the reference is a subject that includes an appropriate amount of IE in order to identify the referenced content-element by its actual content.</t>
</list></t>
<t>It is recommended to provide unique identifiers in a SACM domain and the SACM IM provides a corresponding naming-convention as a reference in section FIXME.
The alternative highlighted above summarizes a valid approach that does not require unique identifiers and is similar to the approach of referencing target endpoints via identifying attributes included in a characterization record (FIXME REF arch).</t>
<t>Example: an instance of a content-element subject associated with another subject via its content metadata</t>
<figure><artwork type="pseudo-code"><![CDATA[
content-element = (
content-metadata = (
collection-timestamp = 1461934031,
te-label = fb02e551-7101-4e68-8dec-1fde6bd10981
relationships = (
associated-with-user-account = f3d70ef4-7e18-42af-a894-8955ba87c95d
)
),
hostname = "arbutus"
)
content-element = (
content-metadata = (
content-label = f3d70ef4-7e18-42af-a894-8955ba87c95d
),
user-account = (
username = romeo
authentication = local
)
)
]]></artwork></figure>
</section>
<section anchor="events" title="Events">
<t>Event subjects provide a structure to represent the change of IE values that was detected by a collection task at a specific point of time. It is mandatory to include the new values in an event subject and it is recommended to include the past values that were replaced by the new IE values. Every event can be associated with a subject-specific event-timestamp and a lastseen-timestamp that might differ from the corresponding collection-timestamps. If these are omitted the collection-timestamp that is included in the content-metadata subject is used instead.</t>
<t>Example: A SACM statement containing an event</t>
<figure><artwork type="pseudo-code"><![CDATA[
sacm-statement = (
statement-metadata = (
publish-timestamp = 1461934031,
data-origin = 24e67957-3d31-4878-8892-da2b35e121c2,
content-type = event
)
event = (
event-attributes = (
event-name = "host-name change"
content-element = (
content-metadata = (
collection-timestamp = 146193322,
data-source = fb02e551-7101-4e68-8dec-1fde6bd10981
event-component = past-state
),
hostname = "arbutus"
),
content-element = (
content-metadata = (
collection-timestamp = 146195723,
data-source = fb02e551-7101-4e68-8dec-1fde6bd10981
event-component = current-state
),
hostname = "lilac"
),
),
)
]]></artwork></figure>
</section>
</section>
<section anchor="information-element-vocabulary" title="Information Element Vocabulary">
<t><spanx style="strong">to be inserted in section 5 as candidates</spanx></t>
<t>The vocabulary of Information Element names standardized by the SACM IM does not prescribe the use of these exact same names in every SACM data model. If terms diverge, a mapping has to be provided in the corresponding SACM data model document.</t>
<t>A subset of the names of the information elements defined in this document are appended with “-type”. This indicates that the IM defines a set of values for these information elements (e.g. the interface types defined by the IANA registry or the relationship types).</t>
<section anchor="vocabulary-of-categories" title="Vocabulary of Categories">
<t>Categories are special Information Elements that enable to refer to multiple types of IE via just one name. Therefore, they are similar to a type-choice. A prominent example of a category is network-address. Network-address is a category that every kind of network address is associated with, e.g. mac-address, ipv4-address, ipv6-address, or typed-network-address. If a CIE includes network-address as one of its components, any of that categories members is valid to be used in its stead.</t>
<t>Another prominent example is EndpointIdentifier. Some IE can be used to identify (and over time re-recognize) target endpoints - those are associated with the category endpoint-identifier.</t>
<t><list style="hanging">
<t hangText='content:'>
this is a very broad category. Content is the payload of a content element in a SACM statement. Formally, metadata is the complement to content and everything that is not part of SACM statement metadata or content element metadata is therefore considered to be content. Every IE can be content (although the same type of IE can be used in the metadata at the same time - and those would not be content as described before). Annotating every IE with this category would be highly redundant and is therefore omitted for brevity.</t>
<t hangText='network-address: (work-in-progress)'>
ipv4-address</t>
<t>ipv6-address</t>
<t>mac-address</t>
</list></t>
<t>endpoint-identifier: (work-in-progress)</t>
<t>software-component: (work-in-progress)</t>
<t>software-label: (work-in-progress)</t>
</section>
<section anchor="AIE" title="Vocabulary of Atomic Information Elements">
<t>The content of every Atomic Information Element is expressed in a single value. If an alternative representation via a Composite Information Element is also defined by the SACM IM, the names of both variants are distinguished by a prefixed “a.” and “c.” (e.g. a.timestamp and c.timestamp).</t>
<t><list style="hanging">
<t hangText='access-privilege-type:'>
a set of types that represents access privileges (e.g. read, write, none)</t>
<t>References: none</t>
<t hangText='account-name:'>
a label that uniquely identifies an account that can require some form of (user) authentication to access</t>
<t>References: none</t>
<t hangText='a.administrative-domain:'>
a label the is supposed to uniquely identify an administrative domain</t>
<t>References <xref target="IFMAP"/></t>
<t hangText='address-association-type:'>
a set of types that defines the type of address associations (e.g. broadcast-domain-member-list, ip-subnet-member-list, ip-mac, shared-backhaul-interface, etc.)</t>
<t>References: none</t>
<t hangText='address-mask-value:'>
a value that expresses a generic address subnetting bitmask</t>
<t hangText='address-type:'>
a set of types that specifies the type of address that is expressed in an address CIE (e.g. ethernet, modbus, zigbee)</t>
<t>References: none</t>
<t hangText='address-value:'>
a value that expresses a generic network address</t>
<t>References: none</t>
<t>Category: network-address</t>
<t hangText='application-component:'>
a label that references a “sub”-application that is part of the application (e.g. an add-on, a chiper-suite, a library)</t>
<t>References: <xref target="SWID"/></t>
<t>Category: software-component</t>
<t hangText='application-label:'>
a label that is supposed to uniquely reference an application</t>
<t>References: <xref target="SWID"/></t>
<t>Category: software-label</t>
<t hangText='application-type:'>
a set of types (FIXME maybe a finite set is not realistic here - value not enumerator?) that identifies the type of (user-space) application (e.g. text-editor, policy-editor, service-client, service-server, calender, rouge-like RPG)</t>
<t>References: <xref target="SWID"/></t>
<t>Category: software-type</t>
<t hangText='application-manufacturer:'>
the name of the vendor that created the application</t>
<t>References: <xref target="SWID"/></t>
<t>Category: software-manufacturer</t>
<t hangText='application-name:'>
a value that represents the name of an application given by the manufacturer</t>
<t>References: <xref target="SWID"/></t>
<t hangText='application-version:'>
a version string that identifies a specific version of an application</t>
<t>References: <xref target="SWID"/></t>
<t>Category: software-version</t>
<t hangText='authenticator:'>
a label that references a SACM component that can authenticate target endpoints (can be used in a target-endpoint CIE to express that the te was authenticated by that SACM component)</t>
<t>References: none</t>
<t hangText='attribute-name:'>
a value that can express the attribute name of generic Attribute-Value-Pair CIE</t>
<t>References: none</t>
<t hangText='attribute-value:'>
a value that can express the attribute value of generic Attribute-Value-Pair CIE</t>
<t>References: none</t>
<t hangText='authentication-type:'>
a set of types that expresses which type of authentication was used to enable a network interaction/connection</t>
<t>References: <xref target="PXGRID"/></t>
<t hangText='birthdate:'>
a label for the registered day of birth of a natural person (e.g. the date of birth of a person as an ISO date string http://rs.tdwg.org/ontology/voc/Person#birthdate)</t>
<t>References: <xref target="SCAP-AI"/></t>
<t hangText='bytes-received:'>
a value that represents a number of octets received on a network interface</t>
<t>Reference : <xref target="PXGRID"/></t>
<t hangText='bytes-sent:'>
a value that represents a number of octets sent on a network interface</t>
<t>Reference : <xref target="PXGRID"/></t>
<t hangText='certificate:'>
a value that expresses a certificate that can be collected from a target endpoint</t>
<t>References: none</t>
<t>Category: endpoint-identifier</t>
<t hangText='collection-task-type:'>
a set of types that defines how collected SACM content was acquired (e.g. network-observation, remote-acquisition, self-reported)</t>
<t>Reference: none</t>
<t hangText='confidence:'>
a representation of the subjective probability that the assessed value is correct. If no confidence value is given it is assumed that the confidence is 1 (limits confidence values to the range between zero and one)</t>
<t>References: <xref target="ARF"/></t>
<t hangText='content-action:'>
a set of types that expresses a type of action (e.g. add, delete, update). Can be associated, for instance, with an event CIE or with an network observation</t>
<t>References: <xref target="ARF"/></t>
<t hangText='content-elements:'>
a value that represents the number of content-elements included in a SACM statement</t>
<t>References: none</t>
<t hangText='content-topic:'>
a set of types that defines what kind of concept the information is included in a content element (e.g. Session, User, Interface, PostureProfile, Flow, PostureAssessment, TargetEndpoint)</t>
<t>References: none</t>
<t hangText='content-type:'>
a set of types that defines what kind of information is included in a content element (e.g. EndpointConfiguration, EndpointState, DirectoryEntry, Event, Incident)</t>
<t>References: none</t>
<t hangText='country-code:'>
a set of types according to ISO 3166-1 trigraphic codes of countries</t>
<t>References: FIXME</t>
<t hangText='data-origin:'>
a label that uniquely identifies a SACM component in and across SACM domains</t>
<t>References: none</t>
<t>Aliases: sacm-component-id</t>
<t hangText='a.data-source:'>
a label that is supposed to uniquely identify the data source (e.g. a target endpoint or sensor) that provided an initial endpoint attribute record</t>
<t>References: <xref target="ARF"/></t>
<t>Aliases: te-id (work-in-progress)</t>
<t hangText='decimal-fraction-denominator:'>
a denominator value to express a decimal fraction time stamp (e.g. in c.timestamp)</t>
<t>References: none</t>
<t hangText='decimal-fraction-numerator:'>
a numerator value to express a decimal fraction time stamp (e.g. in c.timestamp)</t>
<t hangText='default-depth:'>
a value that expresses how often a circular reference of CIE is allowed to repeat, or how deep a recursive nesting may occour, respectively.</t>
<t>References: none</t>
<t hangText='discoverer:'>
a label that refers to the SACM component that discovered a target endpoint (can be used in a target-endpoint CIE to express, for example, that the te was authenticated by that SACM component)</t>
<t>References: none</t>
<t hangText='email-address:'>
a value that expresses an email-address</t>
<t>References: none</t>
<t hangText='event-type:'>
a set of types that define the categories of an event (e.g. access-level-change, change-of-priviledge, change-of-authorization, environmental-event, or provisioning-event)</t>
<t>Reference: none</t>
<t hangText='event-threshold:'>
if applicable, a value that can be included in an event CIE to indicate what numeric threshold value was crossed to triggered that event</t>
<t>Reference: none</t>
<t hangText='event-threshold-name:'>
if an event is created due to a crossed threshold, the threshold might have a name associated with it that can be expressed via this value</t>
<t>References: none</t>
<t hangText='event-trigger:'>
this value is used to express more complex trigger conditions that may cause the creation of an event.</t>
<t hangText='firmware-id:'>
a label that represents the BIOS or firmware ID of a specific target endpoint</t>
<t>Reference: none</t>
<t>Category: endpoint-identifier</t>
<t hangText='hardware-serial-number:'>
a value that identifies a piece of hardware that is a component of a composite target endpoint (in essence, every target endpoint is a composite) and can be acquired from a target endpoint by a collection task</t>
<t>Reference: none</t>
<t>Category: endpoint-identifier</t>
<t hangText='host-name:'>
a label typically associated with an endpoint but not always intended to be unique in a given scope</t>
<t>References <xref target="ARF"/>, <xref target="SCAP-AI"/></t>
<t>Category: endpoint-identifier</t>
<t hangText='interface-label:'>
a unique label a network interface can be referenced with</t>
<t>Reference: none</t>
<t hangText='ipv6-address-subnet-mask-cidrnot:'>
an IPv6 subnet bit mask in CIDR notation</t>
<t>References: TBD</t>
<t hangText='ipv6-address-value:'>
an IPv4 address value</t>
<t>References: TBD</t>
<t>Category: endpoint-identifier, network-address</t>
<t hangText='ipv4-address-subnet-mask-cidrnot:'>
an IPv4 subnet bit mask in CIDR notation</t>
<t>References: TBD</t>
<t hangText='ipv4-address-subnet-mask:'>
an IPv4 subnet mask</t>
<t>References: TBD</t>
<t hangText='ipv4-address-value:'>
an IPv4 address value</t>
<t>References: TBD</t>
<t>Category: endpoint-identifier, network-address</t>
<t hangText='layer2-interface-type:'>
a set of types referenced by IANA ifType</t>
<t>References: <xref target="RFC3635"/>, <xref target="RFC1573"/></t>
<t hangText='layer4-port-address:'>
a layer 4 port address (typically used, for example, with TCP and UDP)</t>
<t>References: none</t>
<t>Category: network-address</t>
<t hangText='layer4-protocol:'>
a set of types that express a layer 4 protocol (e.g. UDP or TCP)</t>
<t hangText='location-name:'>
a value that represents a named region of space FIXME</t>
<t>References: <xref target="IFMAP"/>, <xref target="ARF"/>, <xref target="SCAP-AI"/></t>
<t hangText='mac-address:'>
a value that expresses an Ethernet address</t>
<t>References: <xref target="IFMAP"/>, <xref target="ARF"/>, <xref target="SCAP-AI"/></t>
<t>Category: endpoint-identifier, network-address</t>
<t hangText='method-label:'>
a label that references a specific method registered and used in a SACM domain (e.g. method to match and re-identify target endpoints via identifying attributes)</t>
<t>References: none</t>
<t hangText='method-repository:'>
a label that references a SACM component methods can be registered at and that can provide guidance in the form of registered methods to other SACM components</t>
<t>References: none</t>
<t hangText='network-access-level-type:'>
a set of types that expresses categories of network access-levels (e.g. block, quarantine, etc.)</t>
<t>References: <xref target="IFMAP"/></t>
<t hangText='network-id:'>
most networks, such as AS, an OSBF domains, or vlans, can have an ID that is represented via this AIE</t>
<t>References: none</t>
<t hangText='network-interface-name:'>
a label that uniquely identifies an interface associated with a distinguishable endpoint</t>
<t>References: FIXME</t>
<t hangText='network-layer:'>
a set of layers that express the specific network layer an interface operate on (typically layer 2-4)</t>
<t>References: FIXME</t>
<t hangText='network-name:'>
a label that is associated with a network. Some networks, for example effective layer2-broadcast-domains, are difficult to “grasp” and therefore quite complicated to name</t>
<t>References: none</t>
<t hangText='organization-id:'>
a label that is supposed to uniquely identify an organization</t>
<t>References: <xref target="ARF"/></t>
<t hangText='organization-name:'>
a value that represents the name of an organization</t>
<t>References: <xref target="ARF"/></t>
<t hangText='os-component:'>
a label that references a “sub-component” that is part of the operating system (e.g. a kernel module, microcode, or ACPI table)</t>
<t>References: <xref target="SWID"/></t>
<t>Category: software-component</t>
<t hangText='os-label:'>
a label that references a specific version of an operating system, including patches and hotfixes</t>
<t>References: <xref target="SWID"/></t>
<t>Category: software-label</t>
<t hangText='os-manufacturer:'>
the name of the manufacturer of an operating system</t>
<t>References: <xref target="IFMAP"/></t>
<t>Category: software-manufacturer</t>
<t hangText='os-name:'>
the name of an operating system</t>
<t>References: <xref target="IFMAP"/></t>
<t>Category: software-name</t>
<t hangText='os-type:'>
a set of types that identifies the type of an operating system (e.g. real-time, security-enhanced, consumer, server)</t>
<t>References: none</t>
<t>Category: software-type</t>
<t hangText='os-version:'>
a value that represents the version of an operating-system</t>
<t>Category: software-version</t>
<t hangText='patch-id:'>
a label the uniquely identifies a specific software patch</t>
<t>References: <xref target="ARF"/></t>
<t hangText='patch-name:'>
the vendor’s name of a software patch</t>
<t>References: <xref target="ARF"/>, <xref target="SWID"/></t>
<t hangText='person-first-name:'>
the first name of a natural person</t>
<t>References: <xref target="ARF"/>, <xref target="SCAP-AI"/></t>
<t hangText='person-last-name:'>
the last name of a natural person</t>
<t>References: <xref target="ARF"/>, <xref target="SCAP-AI"/></t>
<t hangText='person-middle-name:'>
the first name of a natural person</t>
<t>References: <xref target="ARF"/>, <xref target="SCAP-AI"/></t>
<t hangText='phone-number:'>
a label that expresses the u.s. national phone number (e.g. pattern value=”((\d{3}) )?\d{3}-\d{4}”)</t>
<t>References: <xref target="ARF"/>, <xref target="SCAP-AI"/></t>
<t hangText='phone-number-type:'>
a set of types that express the type of a phone number (e.g. DSN, Fax, Home, Mobile, Pager, Secure, Unsecure, Work, Other)</t>
<t>References: <xref target="ARF"/></t>
<t hangText='privilege-name:'>
the attribute-name of the privilege represented as an AVP</t>
<t>References: none</t>
<t hangText='privilege-value:'>
the value-content of the privilege represented as an AVP</t>
<t>References: none</t>
<t hangText='protocol:'>
a set of types that defines specific protocols above layer 4 (e.g. http, https, dns, ipp, or unknown)</t>
<t>References: none</t>
<t hangText='public-key:'>
the value of a public key (regardless of its method of creation, crypto-system, or signature scheme) that can be collected from a target endpoint</t>
<t>Reference: none</t>
<t>Category: endpoint-identifier</t>
<t hangText='relationship-content-element-guid:'>
a reference to a specific content element used in a relationship CIE</t>
<t>References: none</t>
<t hangText='relationship-statement-guid:'>
a reference to a specific SACM statement used in a relationship CIE</t>
<t>References: none</t>
<t hangText='relationship-object-label:'>
a reference to a specific label used in content (e.g. a te-label or a user-id). This reference is typically used if matching content AIE can be done efficiantly and can also be included in addition to a relationship-content-element-guid reference.</t>
<t>References: none</t>
<t hangText='relationship-type:'>
a set of types that is in every instance of a relationship CIE to highlight what kind of relationship exists between the CIE the relationship is included in (e.g. associated_with_user, applies_to_session, seen_on_interface, associated_with_flow, contains_virtual_device)</t>
<t>References: none</t>
<t hangText='role-name:'>
a label that references a collection of privileges assigned to a specific entity (identity? FIXME)</t>
<t>References: FIXME</t>
<t hangText='session-state-type:'>
a set of types a discernible session (an ongoing network interaction) can be in (e.g. Authenticating, Authenticated, Postured, Started, Disconnected)</t>
<t>References: <xref target="PXGRID"/></t>
<t hangText='statement-guid:'>
a label that expresses a global unique ID referencing a specific SACM statement that was produced by a SACM component</t>
<t>References: none</t>
<t hangText='statement-type:'>
a set of types that define the type of content that is included in a SACM statement (e.g. Observation, DirectoryContent, Correlation, Assessment, Guidance)</t>
<t>References: none</t>
<t hangText='status:'>
a set of types that defines possible result values for a finding in general (e.g. true, false, error, unknown, not applicable, not evaluated)</t>
<t>References: <xref target="ARF"/></t>
<t hangText='sub-administrative-domain:'>
a label for related child domains an administrative domain can be composed of (used in the CIE c.administrative-domain)</t>
<t>References: none</t>
<t hangText='sub-interface-label:'>
a unique label a sub network interface (e.g. a tagged vlan on a trunk) can be referenced with</t>
<t>References: none</t>
<t hangText='super-administrative-domain:'>
a label for related parent domains an administrative domain is part of (used in the CIE c.administrative-domain)</t>
<t>References: none</t>
<t hangText='super-interface-label:'>
a unique label a super network interface (e.g. a physical interface a tunnel interface terminates on) can be referenced with</t>
<t>References: none</t>
<t hangText='te-assessment-state:'>
a set of types that defines the state of assessment of a target-endpoint (e.g. in-discovery, discovered, in-classification, classified, in-assessment, assessed)</t>
<t>References: <xref target="ARF"/></t>
<t hangText='te-label:'>
an identifying label created from a set of identifying attributes used to reference a specific target endpoint</t>
<t>References: none</t>
<t hangText='te-id:'>
an identifying label that is created randomly, is supposed to be unique, and used to reference a specific target endpoint</t>
<t>References: <xref target="ARF"/>, <xref target="SWID"/></t>
<t>Aliases: data-source</t>
<t hangText='a.timestamp:'>
a timestamp the expresses a specific point in time</t>
<t>References: <xref target="IFMAP"/>, <xref target="ARF"/></t>
<t hangText='timestamp-type:'>
a set of types that express what type of action or event happened at that point of time (e.g. discovered, classified, collected, published). Can be included in a generic c.timestamp CIE</t>
<t>References: none</t>
<t hangText='units-received:'>
a value that represents a number of units (e.g. frames, packets, cells or segments) received on a network interface</t>
<t>Reference : <xref target="PXGRID"/></t>
<t hangText='units-sent:'>
a value that represents a number of units (e.g. frames, packets, cells or segments) sent on a network interface</t>
<t>Reference : <xref target="PXGRID"/></t>
<t hangText='username:'>
a part of the credentials required to access an account that can be collected from a target endpoint</t>
<t>References: none</t>
<t>Category: endpoint-identifier</t>
<t hangText='user-directory:'>
a label that identifies a specific type of user-directory (e.g. ldap, active-directory, local-user)</t>
<t>Reference: <xref target="PXGRID"/></t>
<t hangText='user-id:'>
a label that references a specific user known in a SACM domain</t>
<t>References: <xref target="PXGRID"/></t>
<t hangText='web-site:'>
a URI that references a web-site</t>
<t>References: <xref target="ARF"/></t>
<t hangText='WGS84-longitude:'>
a label that represents WGS 84 rev 2004 longitude</t>
<t>References: <xref target="SCAP-AI"/></t>
<t hangText='WGS84-latitude:'>
a label that represents WGS 84 rev 2004 latitude</t>
<t>References: <xref target="SCAP-AI"/></t>
<t hangText='WGS84-altitude:'>
a label that represents WGS 84 rev 2004 altitude</t>
<t>References: <xref target="SCAP-AI"/></t>
</list></t>
</section>
<section anchor="CIE" title="Vocabulary of Composite Information Elements">
<t>The content of every Composite Information Element is expressed by the mandatory and optional IE it can be composed of. The components of an CIE can have a cardinality associated with them:</t>
<t><list style="symbols">
<t>(*): zero to unbounded occurrences</t>
<t>(+): one to unbounded occurrences</t>
<t>(?): zero or one occurrence</t>
<t>(n*m): between n and m occurrences</t>
<t>no cardinality: one occurrence</t>
</list></t>
<t>If there is no cardinality highlighted or the cardinality (+) or (n*m) is used, including this IE in the CIE is mandatory. In contrast, optional IE are expressed via the cardinality (?) or (*).
An CIE can prescribe a strict sequence to the component IE it contains. This in indicated by an (s).
CIE that are prefixed with “c.” have a simplified AIE counterpart that is prefixed with “a.”</t>
<t><list style="hanging">
<t hangText='address-association (s):'>
some addresses are associated with each other, e.g. a mac-address can be associated with a number of IP addresses or a sensor address can be associated with the external address of its two redundant IP gateways. The first address is the address a number of addresses with the same type is associated with. An address type SHOULD be included and the addresses associated with the first address entry MUST be of the same type. NANCY FIXME</t>
<t>address</t>
<t>address-type (?)</t>
<t>address (+)</t>
<t>address-type (?)</t>
<t hangText='c.administrative-domain:'>
this CIE is intended to express more complex setups of interconnected administrative domains</t>
<t>a.administrative-domain</t>
<t>sub-administrative-domain (*)</t>
<t>super-administrative-domain (?)</t>
<t>location (?)</t>
<t hangText='application:'>
an application is software that is not part of the kernel space (therefore typically runs in the user space. An application can depend on specfific running party of an operating system.</t>
<t>application-label (?)</t>
<t>application-name</t>
<t>application-type (*)</t>
<t>application-component (*)</t>
<t>application-manufacturer (?)</t>
<t>application-version (?)</t>
<t hangText='application-instance:'>
a specific instance of an application that is installed on an endpoint. The application-label is used to refer to corresponding information stored in an application CIE</t>
<t>application-label</t>
<t>target-endpoint</t>
<t hangText='attribute-value-pair:'>
a generic CIE that is used to express various AVP (e.g. Radius Attributes)</t>
<t>attribute-name</t>
<t>attribute-value</t>
<t hangText='content-creation-timestamp:'>
a decimal fraction timestamp that specifies the point in time the content element was created by a SACM component</t>
<t>decimal-fraction-denominator</t>
<t>decimal-fraction-numerator</t>
<t hangText='content-element:'>
content produced by a SACM component is encapsulated in content-elements that also include content-metadata regarding that content</t>
<t>content-metadata (+)</t>
<t>content (+)</t>
<t hangText='content-metadata:'>
metadata regarding the content included in a specific content-element. The content the metadata annotates can be initially collected content - in this case a data-source has to be included in the metadata. Content can also be the product of a SACM component (e.g. an evaluator), which requires a data-origin IE instead that references the producer of information.</t>
<t>content-element-guid</t>
<t>content-creation-timestamp</t>
<t>content-topic</t>
<t>content-type</t>
<t>c.data-source (?)</t>
<t>data-origin (?)</t>
<t>relationship (*)</t>
<t hangText='c.data-source:'>
a CIE that refers to a target endpoint that is the source of SACM content - either via a label (a.data-source, which could also be used without this CIE), or via a list of endpoint-identifiers (category). Both can be included at the same time but MUST NOT conflict.</t>
<t>a.data-source (?)</t>
<t>endpoint-identifier (*)</t>
<t hangText='dst-flow-element:'>
identifies the destination of a flow. The port number SHOULD be included if the network-address is an IP-address.</t>
<t>network-address</t>
<t>layer4-port-address (?)</t>
<t hangText='ethernet-interface:'>
the only two mandatory component of this CIE is the mac-address and the generated label (to distinguish non-unique addresses). This acknowledges the fact that in many cases this is the only information available about an Ethernet interface. If there is more detail information available it MUST be included to avoid ambiguity and to increase the usefulness for consumer of information. The exception are sub-interface-labels and super-interface-labels, which SHOULD be included.</t>
<t>interface-label</t>
<t>network-interface-name (?)</t>
<t>mac-address</t>
<t>network-name (?)</t>
<t>network-id (?)</t>
<t>layer2-interface-type (?)</t>
<t>sub-interface-label (*)</t>
<t>super-interface-label (*)</t>
<t hangText='event (s):'>
this a special purpose CIE that represents the change of content. As with content-elements basically every content can be included in the two content entries. The mandatory content entry represents the “after” state of the content and the optional content entry can represent the “before” state if available or required.</t>
<t>event-type (?)</t>
<t>event-threshold (?)</t>
<t>event-threshold-name (?)</t>
<t>event-trigger (?)</t>
<t>typed-timestamp</t>
<t>content</t>
<t>content (?)</t>
<t hangText='flow-record:'>
a composite that expresses a single flow and its statistics. If applicable, protocol and layer4-protocol SHOULD be included</t>
<t>src-flow-element</t>
<t>dst-flow-element</t>
<t>protocol (?)</t>
<t>layer4-protocol (?)</t>
<t>flow-statistics</t>
<t hangText='flow-statistics:'>
this CIE aggregates bytes and units send and received</t>
<t>bytes-received</t>
<t>bytes-sent</t>
<t>units-received</t>
<t>units-sent</t>
<t hangText='group:'>
insert text here (work in progress)</t>
<t hangText='ipv4-address:'>
an IPv4 address is always associated with a subnet. This CIE combines these both tightly nit values. Either a subnet mask or a CIDR notation bitmask SHOULD be included.</t>
<t>ipv4-address-value</t>
<t>ipv4-address-subnet-mask-cidrnot (?)</t>
<t>ipv4-address-subnet-mask (?)</t>
<t hangText='ipv6-address:'>
an IPv6 address is always associated with a subnet. This CIE combines these both tightly nit values. A CIDR notation bitmask SHOULD be included.</t>
<t>ipv6-address-value</t>
<t>ipv6-address-subnet-mask-cidrnot (?)</t>
<t hangText='location:'>
a CIE that aggregates potential details about a location</t>
<t>location-name</t>
<t>WGS84-longitude</t>
<t>WGS84-latitude</t>
<t>WGS84-altitude</t>
<t hangText='operation-system:'>
an operation-system is software that is directly interacting with the hardware, provides the runtime environment for the user-space and corresponding interfaces to hardware functions.</t>
<t>os-label (?)</t>
<t>os-name</t>
<t>os-type (*)</t>
<t>os-component (*)</t>
<t>os-manufacturer (?)</t>
<t>os-version (?)</t>
<t hangText='organization:'>
this CIE aggregates information about an organization and can be references via its id</t>
<t>organization-id</t>
<t>organization-name</t>
<t>location (?)</t>
<t hangText='person:'>
a CIE that aggregates the details about a person and combines it with a identifier unique to SACM domains</t>
<t>person-first-name</t>
<t>person-last-name</t>
<t>person-middle-name (*)</t>
<t>phone-contact (*)</t>
<t>email-address (*)</t>
<t hangText='phone-contact:'>
this CIE can be used to reference a phone number and how it fucntions as a contact</t>
<t>phone-number</t>
<t>phone-number-type (?)</t>
<t hangText='priviledge:'>
a CIE to express priviledges via a specific name/value pair</t>
<t>privilege-name</t>
<t>privilege-value</t>
<t hangText='relationship:'>
the relationship CIE enables to associate the CIE it is included in with other CIE if they contain a unique identifier or label - providing an alternative to including attributes of other content CIE as a means to map them (which remains a valid alternative, though). The relationship CIE MUST at least reference one relationship object (either a SACM statement iden</t>
<t>relationship-type</t>
<t>relationship-content-element-guid (*)</t>
<t>relationship-statement-guid (*)</t>
<t>relationship-object-label (*)</t>
<t hangText='sacm-statement:'>
every SACM components produces information in this format. This CIE can be considered the root IE for every SACM message generated. There MUST be at least one content element included in a SACM statement and if there are more than one, they are ordered in a sequence.</t>
<t>statement-metadata</t>
<t>content-element (+)(s)</t>
<t hangText='session:'>
represents an ongoing network interaction that can be in various states of authentication or assessement</t>
<t>session-state-type</t>
<t>(work-in-progress)</t>
<t hangText='src-flow-element:'>
identifies the source of a flow. The port number SHOULD be included if the network-address is an IP-address.</t>
<t>network-address</t>
<t>layer4-port-address (?)</t>
<t hangText='statement-creation-timestamp:'>
a decimal fraction timestamp that specifies the point in time the SACM statement was created by a SACM component</t>
<t>decimal-fraction-denominator</t>
<t>decimal-fraction-numerator</t>
<t hangText='statement-publish-timestamp:'>
a decimal fraction timestamp that specifies the point in time the SACM component attempted to publish the SACM statement (if successful, this will result in the publish-timestamp send with the SACM statement).</t>
<t>decimal-fraction-denominator</t>
<t>decimal-fraction-numerator</t>
<t hangText='statement-metadata:'>
every SACM statement includes statement metadata about the SACM component it was produced by and a general category that indicates what this statement is about</t>
<t>statement-guid</t>
<t>data-origin</t>
<t>statement-creation-timestamp (?)</t>
<t>statement-publish-timestamp</t>
<t>statement-type</t>
<t>content-elements</t>
<t hangText='target-endpoint:'>
this is a central CIE used in the process chains a SACM domain can compose. Theoretically every kind of information can be associated with a target endpoint CIE via its corresponding content element. A few select IE can be stored in the CIE itself to reduce the overhead of following references that would occur in most scenarios. If the hostname is unknown the value has to be set as an equivalent to “not available” (e.g. NULL). Comment from the authors: This is “work in progress” an a good basis for discussion</t>
<t>host-name</t>
<t>te-label</t>
<t>c.administrative-domain (?)</t>
<t>application-instance (*)</t>
<t>ethernet-interface (*)</t>
<t>address-association (*)</t>
<t>c.data-source (?)</t>
<t>operation-system (?)</t>
<t hangText='te-profile:'>
a set of expected states, policies and pieces of guidance that can be matched to a target endpoint (or a class of target endpoints “work in progress”)</t>
<t hangText='typed-timestamp:'>
a flexible timestamp CIE that can express the specific type of timestamp via its content. This is an alternative to the “named” timestamps that do not include a timestamp-type</t>
<t>decimal-fraction-denominator</t>
<t>decimal-fraction-numerator</t>
<t>timestamp-type</t>
<t hangText='user:'>
a CIE that references details of a specific user known in a SACM domain active on a specific target endpoint</t>
<t>user-id</t>
<t>username (?)</t>
<t>data-source (?)</t>
<t>user-directory (?)</t>
</list></t>
</section>
</section>
<section anchor="example-composition-of-sacm-statements" title="Example composition of SACM statements">
<t>This section illustrates examples how SACM statements are composed of content elements, how relationship CIE can be used in content metadata and gives an impression how the categories statement-type, content-topic and content-type are intended to be used.</t>
<t>The SACM statements instances are written in pseudo code. AIE end with a colon. Some AIE include exemplary values to, for example, present how references to guid and labels can be used. For the sake of brevity, not all mandatory IE that are part of a CIE are always included (e.g. as it is the case with target-endpoint).</t>
<t>The example shows three SACM statements that were produced by three different SACM components that overall include four related content elements.</t>
<t>This is (work in progress).</t>
<figure><artwork><![CDATA[
sacm statement
statement-metadata
statement-guid: example-sguid-one
data-origin: SACM-component-label-one
statement-publish-timestamp: exmample-TS-one
statement-type: Observation
content-element
content-metadata
content-element-guid: example-cguid-one
content-creation-timestamp:
content-topic: Flow
content-type: EndpointState
relationship
relationship-type: is-associated-with-user
relationship-content-object: example-cguid-three
relationship
relationship-type: is-associated-with-te
relationship-content-object: example-cguid-two
relationship
relationship-type: is-associated-with-te
relationship-content-object: example-te-label
flow-record
src-flow-element
network-address (ipv4-address)
ipv4-address-value:
ipv4-address-subnet-mask-cidrnot:
layer4-port-address: 23111
dst-flow-element
network-address (IPv4-address)
ipv4-address-value:
ipv4-address-subnet-mask-cidrnot:
layer4-port-address: 22
protocol: ssh
layer4-protocol: tcp
flow-statistics
bytes-received:
bytes-sent:
units-received:
units-sent:
content-element
content-metadata
content-element-guid: example-cguid-two
content-creation-timestamp:
content-topic: TargetEndpoint
content-type: EndpointConfiguration
target-endpoint
te-label: example-te-label
host-name: example-host-name
ethernet-interface: example-interface
sacm statement
statement-metadata
statement-guid: example-sguid-two
data-origin: SACM-component-label-two
statement-publish-timestamp: exmample-TS-two
statement-type: DirectoryContent
content-element
content-metadata
content-element-guid: example-cguid-three
content-creation-timestamp:
content-topic: User
content-type: DirectoryEntry
user
user-name: example-username
user-directory: component-id
sacm statement
statement-metadata