-
Notifications
You must be signed in to change notification settings - Fork 6
/
draft-ietf-sacm-information-model.xml
7506 lines (7298 loc) · 276 KB
/
draft-ietf-sacm-information-model.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 "http://xml2rfc.ietf.org/authoring/rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC0791 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.0791.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2434 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2434.xml">
<!ENTITY RFC3411 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3411.xml">
<!ENTITY RFC3416 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3416.xml">
<!ENTITY RFC3418 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3418.xml">
<!ENTITY RFC3580 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3580.xml">
<!ENTITY RFC3580 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3580.xml">
<!ENTITY RFC3587 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3587.xml">
<!ENTITY RFC4949 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4949.xml">
<!ENTITY RFC4287 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4287.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 RFC6020 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6020.xml">
<!ENTITY RFC6241 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6241.xml">
<!ENTITY RFC6313 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6313.xml">
<!ENTITY RFC6876 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6876.xml">
<!ENTITY RFC7012 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7012.xml">
<!ENTITY RFC7013 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7013.xml">
<!ENTITY RFC7171 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7171.xml">
<!ENTITY RFC7632 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7632.xml">
<!ENTITY I-D.ietf-sacm-terminology SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-sacm-terminology-05.xml">
<!ENTITY I-D.ietf-sacm-requirements SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-sacm-requirements-01.xml">
<!ENTITY I-D.ietf-sacm-architecture SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-sacm-architecture-00.xml">
<!ENTITY W3C.REC-soap12-part1-20070427 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml4/reference.W3C.REC-soap12-part1-20070427.xml">
<!ENTITY W3C.REC-rdf11-concepts-20140225 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml4/reference.W3C.REC-rdf11-concepts-20140225.xml">
]>
<?xml-stylesheet type='text/xsl' href='http://xml2rfc.ietf.org/authoring/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 <xref target="TNC-Architecture"/> -->
<?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="yes" ?>
<!-- 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 -->
<rfc category="std" docName="draft-ietf-sacm-information-model-10" 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>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="SACM Information Model">SACM Information Model</title>
<author fullname="David Waltermire" initials="D." surname="Waltermire" role="editor">
<organization abbrev="NIST">National Institute of Standards and
Technology</organization>
<address>
<postal>
<street>100 Bureau Drive</street>
<city>Gaithersburg</city>
<region>Maryland</region>
<code>20877</code>
<country>USA</country>
</postal>
<phone/>
<email>[email protected]</email>
</address>
</author>
<author fullname="Kim Watson" initials="K.K." surname="Watson">
<organization abbrev="DHS">United States Department of Homeland Security</organization>
<address>
<postal>
<street>DHS/CS&C/FNR</street>
<street>245 Murray Ln. SW, Bldg 410</street>
<street>MS0613</street>
<city>Washington</city>
<region>DC</region>
<code>20528</code>
<country>USA</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author fullname="Clifford Kahn" initials="C." surname="Kahn">
<organization>Pulse Secure, LLC</organization>
<address>
<postal>
<street>2700 Zanker Road, Suite 200</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author fullname="Lisa Lorenzin" initials="L." surname="Lorenzin">
<organization>Pulse Secure, LLC</organization>
<address>
<postal>
<street>2700 Zanker Road, Suite 200</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author fullname="Michael Cokus"
initials="M.C." surname="Cokus">
<organization>The MITRE
Corporation</organization>
<address>
<postal>
<street>903 Enterprise Parkway, Suite 200</street>
<!-- Reorder these if your country does things differently -->
<city>Hampton</city>
<region>VA</region>
<code>23666</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="Henk Birkholz" initials="H.B." surname="Birkholz">
<organization>Fraunhofer SIT</organization>
<address>
<postal>
<street>Rheinstrasse 75</street>
<!-- Reorder these if your country does things differently -->
<city>Darmstadt</city>
<code>64295</code>
<country>Germany</country>
</postal>
<phone/>
<email>[email protected]</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date month="April" year="2017"/>
<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>todo</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 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 title="Introduction" anchor="INTRO">
<t>The SACM Information Model (IM) serves multiple purposes:
<list style="symbols">
<t>to ensure interoperability between SACM data models that are used as transport
encodings,</t>
<t>to provide a standardized set of 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,
and 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:
<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>
<t>These tasks are defined in <xref target="I-D.ietf-sacm-terminology"/>.</t>
</section>
<section title="Conventions used in this document">
<section title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in <xref target="RFC2119">RFC 2119</xref>.</t>
</section>
<section title="Information Element Examples">
<t>The notation used to define the SACM Information
Elements (IEs) is based on a customized version of
the IPFIX information model syntax <xref
target="RFC7012"/> which is described in <xref target="information-element-specification-template"/>.
However, there are several examples presented throughout the document that use a simplified
pseudo-code to illustrate the basic structure. It should be noted that while
they include actual names of subjects and attributes as well as values, they
are not intended to influence how corresponding SACM IEs should be defined
in <xref target="information-model-elements"/>. The examples are provided for
demonstration purposes only.</t>
</section>
</section>
<section title="Information Elements">
<t>The IEs 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 title="Context of Information Elements" anchor="context-of-information-elements">
<t>The IEs in this information model represent information related to assets in the following
areas (based on the use cases described in <xref
target="RFC7632"/>):
<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 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 collisions 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 title="Structure of Information Elements" anchor="structure-of-information-elements">
<t>There are two basic types of IEs:
<list style="symbols">
<t>Attributes: Atomic information elements that are equivalent to name-value-pairs
and can be components of Subjects.</t>
<t>Subjects: Composite information elements that have a name and are made up of
Attributes and/or other Subjects. Every IE that is part of a Subject can have a
quantity associated with it (e.g. zero-one, none-unbounded). The content IEs of
a Subject can be ordered or unordered.</t>
</list>
</t>
<figure title="Example instance of an attribute and subject."
anchor="attribute-subject-example">
<artwork>
Example Instance of an Attribute:
hostname = "arbutus"
Example Instance of a Subject:
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:
<list style="symbols">
<t>Metadata focusing on the data origin (the SACM component that provides the
information to the SACM domain)</t>
<t>Metadata focusing on the data source (the target endpoint that is assessed)</t>
</list>
Metadata can also include relationships that refer to other associated IEs (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 IEs 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 conceptual 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 IEs
that is provided by a SACM component must provide the information contained in these two
subjects although it is up to the implementer whether or not the subjects are explicitly
defined in a data model.</t>
<t>The notation the SACM IM is defined in is based on a modified
version of the IP Information Flow Export (IPFIX) Information
Model syntax described in Section 2.1 of <xref target="RFC7012"/>.
The customized syntax used by the SACM IM is defined below in
<xref target="information-element-specification-template"/>.</t>
<figure
title="Information Element Specification Template"
anchor="information-element-specification-template">
<artwork>
elementId (required): The numeric identifier of the
Information Element. It is used
for the compact identification
of an Information Element. If
this identifier is used without
an enterpriseID, then the
elementId must be unique, and
the description of allowed values
is administrated by IANA. The
value "TBD" may be used during
development of the information
model until an elementId is
assigned by IANA and filled
in at publication time.
enterpriseId (optional): Enterprises may wish to define
Information Elements without
registering them with IANA, for
example, for enterprise-internal
purposes. For such Information
Elements, the elementId is
not sufficient when used
outside the enterprise. If
specifications of enterprise-
specific Information Elements
are made public and/or if
enterprise-specific identifiers
are used by SACM components
outside the enterprise, then the
enterprise-specific identifier
MUST be made globally unique by
combining it with an enterprise
identifier. Valid values for the
enterpriseId are defined by IANA
as Structure of Management
Information (SMI) network management
private enterprise numbers.
name (required): A unique and meaningful name for
the Information Element.
dataType (required): There are two kinds of datatypes:
simple and structured. Attributes are
defined using simple datatypes
and subjects are defined using
structured datatypes. The contents of
the datatype field will be either
a reference to one of the simple
datatypes listed in Section
5.1, or the specification of
structured datatype as defined in
Section 5.2.
status (required): The status of the specification
of the Information Element.
Allowed values are "current" and
"deprecated". All newly defined
Information Elements have "current"
status. The process for moving
Information Elements to the
"deprecated" status is TBD.
description (required): Describes the meaning of the
Information Element, how it is
derived, conditions for its use,
etc.
structure (optional): A parsable property that provides
details about the definition of
structured Information Elements as
described in Section 5.2.
references (optional): Identifies other RFCs or documents
outside the IETF which provide
additional information or context
about the Information Element.
</artwork>
</figure>
<section title="Information Element Naming Convention"
anchor="naming-convention">
<t>SACM Information Elements must adhere to the following naming conventions.
<list style="symbols">
<t>Names SHOULD be descriptive</t>
<t>Names MUST be unique within the SACM registry. Enterprise-specific names
SHOULD be prefixed with a Private Enterprise Number <xref target="PEN"/>.</t>
<t>Names MUST start with lowercase letters unless it begins with a Private
Enterprise Number</t>
<t>Composed names MUST use capital letters for the first letter of each part</t>
</list>
</t>
</section>
<section title="SACM Content Elements"
anchor="sacm-content-elements">
<t>Every piece of information that is provided by a SACM Component is always associated
with a set of data source metadata (e.g. the timestamp when the information was collected, the target
endpoint from which the this set of information is about, etc.) which is provided in the SACM Content
Element Metadata. The SACM Content Element is the subject information element that associates the
information with the SACM Content Element Metadata. The SACM Content Element Metadata may also include
relationships that express associations with other SACM Content Elements.</t>
<figure title="Example set of IEs associated with a timestamp and a
target endpoint label." anchor="sacm-content-element-example">
<artwork>
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 title="SACM Statements"
anchor="sacm-statements">
<t>One or more SACM Content Elements are bundled in a SACM Statement. In contrast to
SACM Content Element Metadata, SACM Statement Metadata focuses on the providing information
about the SACM Component that provided it rather than the target endpoint that the content
is about. The only content-specific metadata included in the SACM Statement is the
statement-type IE. Therefore, multiple SACM Content Elements that share the same SACM Statement
Metadata and are of the same statement-type can be included in a single SACM Statement. A SACM
Statement functions similar to an envelope or a header and is the subject information element
that associates SACM Statement Metadata with security automation information provided in its
SACM Content Element(s). 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 may
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 a best-effort to produce correct information.</t>
<figure title="Example of a simple SACM statement including a single content-element." anchor="sacm-statement-example-1">
<artwork>
sacm-statement = (
statement-metadata = (
publish-timestamp = 1461934031,
data-origin = 24e67957-3d31-4878-8892-da2b35e121c2,
statement-type = observation
),
content-element = (
content-metadata = (
collection-timestamp = 146193322,
data-source = fb02e551-7101-4e68-8dec-1fde6bd10981
),
hostname = "arbutus"
)
)
</artwork>
</figure>
<figure title="Example of conflicting information originating from different SACM components." anchor="sacm-statement-example-2">
<artwork>
sacm-statement = (
statement-metadata = (
publish-timestamp = 1461934031,
data-origin = 24e67957-3d31-4878-8892-da2b35e121c2
statement-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,
statement-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 title="Relationships">
<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 or 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
<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 number
of IEs 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 <xref target="naming-convention"/>. 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.</t>
<figure title="Example instance of a content-element subject associated with
another subject via its content metadata." anchor="sacm-relationship-example">
<artwork>
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 title="Event" anchor="event">
<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 and the collection timestamp in an event subject and
it is recommended to include the past values and a collection
timestamp that were replaced by the new IE values. Every
event can also 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>
<figure title="Example of a SACM statement containing an event." anchor="sacm-event-example">
<artwork>
sacm-statement = (
statement-metadata = (
publish-timestamp = 1461934031,
data-origin = 24e67957-3d31-4878-8892-da2b35e121c2,
statement-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 title="Categories" anchor="categories">
<t>Categories are special IEs that refer to multiple
types of IEs via just one name. Therefore, they are similar
to a type-choice. A prominent example of a category is
when identifying a target endpoint. In some cases, a target
endpoint will be identified by a set of identifying attributes
and in other cases a target endpoint will be identified by a
target endpoint label which is unique within a SACM domain.
If a subject includes the targetEndpoint information element
as one of its components, any of the category members (targetEndpointIdentifier
or targetEndpointLabel) are valid to be used in its place.</t>
</section>
</section>
<section title="Abstract Data Types" anchor="abstract-data-types">
<t>This section describes the set of valid abstract data types that
can be used for the specification of the SACM
Information Elements in <xref target="information-model-elements"/>.
SACM currently supports two classes of datatypes that can be used to
define Information Elements.
<list style="symbols">
<t>Simple: Datatypes that are atomic and are used to define the type of data represented by an attribute Information Element.</t>
<t>Structured: Datatypes that can be used to define the type of data represented by a subject Information Element.</t>
</list>
</t>
<t>Note that further abstract data types may be specified by future extensions of the SACM information model.</t>
<section title="Simple Datatypes" anchor="simple-datatypes">
<section title="IPFIX Datatypes" anchor="ipfix-datatypes">
<t>To facilitate the use of existing work, SACM supports the following
abstract data types defined in Section 3 of <xref target="RFC7012"/>.
<list style="symbols">
<t>unsigned8, unsigned16, unsigned32, unsigned64</t>
<t>signed8, signed16, signed32, signed64</t>
<t>float32, float64</t>
<t>boolean</t>
<t>macAddress</t>
<t>octetArray</t>
<t>string</t>
<t>dateTimeSeconds, dateTimeMilliseconds, dateTimeMicroseconds, dateTimeNanoSeconds</t>
<t>ipv4Address, ipv6Address</t>
</list>
</t>
</section>
</section>
<section title="Structured Datatypes" anchor="structured-datatypes">
<section title="List Datatypes" anchor="list-datatypes">
<t>SACM defines the following abstract list data types that are used to
represent the structured data associated with subjects.
<list style="symbols">
<t>list: indicates that the Information Element order is not significant but
MAY be preserved.</t>
<t>orderedList: indicates that Information Element order is significant and
MUST be preserved.</t>
</list>
</t>
<t>The notation for defining a SACM structured datatype is based on regular
expressions, which are composed of the keywords "list" or "orderedList"
and an Information Element expression. IE expressions use some of the regular
expression syntax and operators, but the terms in the expression are
the names of defined Information Elements instead of character classes. The
syntax for defining list and orderedList datatypes is described below, using
BNF:</t>
<figure title="Syntax for Defining List Datatypes" anchor="list-datatype-bnf">
<artwork>
<list-def> -> ("list"|"orderedList") "(" <ie-expression> ")"
<ie-expression> -> <ie-name> <cardinality>?
( ("," | "|") <ie-name> <cardinality>?)*
<cardinality> -> "*" | "+" | "?" |
( "(" <non-neg-int> ("," <non-neg-int>)? ")" )
</artwork>
</figure>
<t>As seen above, multiple occurrences of an Information Element may be
present in a structured datatype. The cardinality of an Information Element
within a structured Information Element definition is defined by the following
operators:</t>
<figure title="Specifying Cardinality for Structured Datatypes"
anchor="specifying-cardinality-for-structured-datatypes">
<artwork>
* - zero or more occurrences
+ - one or more occurrences
? - zero or one occurrence
(m,n) - between m and n occurrences
</artwork>
</figure>
<t>The absence of a cardinality operator implies one mandatory occurrence of the
Information Element.</t>
<t>Below is an example of a structured Information Element definition.</t>
<figure title="Example of Defining a Structured List Datatype" anchor="example-of-defining-a-structured-list-datatype">
<artwork>
personInfo = list(firstName, middleNames?, lastName)
firstName = string
middleNames = orderedList(middleName+)
middleName = string
lastName = string
As an example, consider the name "John Ronald Reuel Tolkien".
Below are instances of this name, structured according to the
personInfo definition.
personInfo = (firstName="John", middleNames(middleName="Ronald",
middleName="Reuel"), lastName="Tolkien")
personInfo = (middleNames(middleName="Ronald", middleName=" Reuel"),
lastName="Tolkien", firstName="John")
The instance below is not legal with respect to the definition
of personInfo because the order in middleNames is not preserved.
personInfo = (firstName="John", middleNames(middleName=" Reuel",
middleName="Ronald"), lastName="Tolkien")
</artwork>
</figure>
</section>
<section title="Enumeration Datatype" anchor="enumeration-datatype">
<t>SACM defines the following abstract enumeration datatype that is used to
represent the restriction of an attribute value to a set of values.</t>
<figure title="Syntax for Defining an Enumeration Datatype" anchor="enumeration-datatype-bnf">
<artwork>
name, hex-value, description
<enumeration-def> -> -> <name> ";" <hex-value> ";" <description>
<name> -> [0-9a-zA-Z]+
<hex-value> -> 0x[0-9a-fA-F]+
<description> -> [0-9a-zA-Z\.\,]+
</artwork>
</figure>
<t>Below is an example of a structured Information Element definition for an enumeration.</t>
<figure title="Example of Defining a Structured Enumeration Datatype" anchor="example-of-defining-a-structured-enumeration-datatype">
<artwork>
Red ; 0x1 ; The color is red.
Orange ; 0x2 ; The color is orange.
Yellow ; 0x3 ; The color is yellow.
Green ; 0x4 ; The color is green.
...
</artwork>
</figure>
</section>
<section title="Category Datatype" anchor="category-datatype">
<t>SACM defines the following abstract category datatype that is used to
represent a type-choice between a set of information elements.</t>
<figure title="Syntax for Defining an Category Datatype" anchor="category-datatype-bnf">
<artwork>
<category-def> -> "category(" <ie-expression> ")"
<ie-expression> -> <ie-name> ("|" <ie-name>)*
<name> -> [0-9a-zA-Z]+
</artwork>
</figure>
<t>Below is an example of a structured Information Element definition for a category.</t>
<figure title="Example of Defining a Structured Category Datatype" anchor="example-of-defining-a-structured-category-datatype">
<artwork>
targetEndpoint = category(targetEndpointIdentifier |
targetEndpointLabel)
</artwork>
</figure>
</section>
</section>
</section>
<section title="Information Model Assets" anchor="information-model-assets">
<t>In order to represent the Information Elements related to the areas listed
in <xref target="context-of-information-elements"/>, the information model
defines the information needs (or metadata about those information needs)
related to following types of assets which are defined in
<xref target="I-D.ietf-sacm-terminology"/> (and included below
for convenience) which are of interest to SACM.
Specifically:<list style="symbols">
<t>Endpoint</t>
<t>Software Component</t>
<t>Hardware Component</t>
<t>Identity</t>
<t>Guidance</t>
<t>Evaluation Results</t>
</list>
</t>
<t>The following figure shows the make up of an Endpoint asset which contains
zero or more hardware components and zero or more software components each of
which may have zero or more instances running an endpoint at any given time as
well as zero or more identities that act on behalf of the endpoint when interfacing
with other endpoints, tools, or services. An endpoint may also contain other
endpoints in the case of a virtualized environment.</t>
<figure title="Model of an Endpoint"
anchor="figure-model-of-an-endpoint">
<artwork>
<![CDATA[
+---------+*______in>_______*+-----+
|Hardware | |! !|
|Component| +---------+ |! !|
+---------+ |Software |in> |! !|
|Component|____|! !|
+---------+* *|! !|
1| |! !|
*| | | +----------+
+---------+ |End- |*_____*| Identity |
|Software |in> |point| acts +----------+
|Instance |____| | for>
+---------+* 1|! !|
|! !|
|! !|
|! !|
|! !|____
|! !|0..1|
+-----+ |
|* |
|_______|
in>
]]>
</artwork>
</figure>
<section title="Asset">
<t>As defined in <xref target="RFC4949"/>, an asset is a system resource that
is (a) required to be protected by an information system's security policy,
(b) intended to be protected by a countermeasure, or (c) required for a
system's mission.</t>
<t>In the scope of SACM, an asset can be composed of other assets. Examples of
Assets include: Endpoints, Software, Guidance, or Identity. Furthermore, an
asset is not necessarily owned by an organization.</t>
</section>
<section title="Endpoint">
<t>From <xref target="RFC5209"/>, an endpoint is any computing device that can
be connected to a network. Such devices normally are associated with a
particular link layer address before joining the network and potentially
an IP address once on the network. This includes: laptops, desktops,
servers, cell phones, or any device that may have an IP address.</t>
<t>To further clarify, an endpoint is any physical or virtual device that
may have a network address. Note that, network infrastructure devices
(e.g. switches, routers, firewalls), which fit the definition, are also
considered to be endpoints within this document.</t>
<t>Physical endpoints are always composites that are composed of hardware
components and software components. Virtual endpoints are composed entirely
of software components and rely on software components that provide
functions equivalent to hardware components.</t>
<t>The SACM architecture differentiates two essential categories of endpoints:
Endpoints whose security posture is intended to be assessed (target endpoints)
and endpoints that are specifically excluded from endpoint posture
assessment (excluded endpoints).</t>
</section>
<section title="Hardware Component">
<t>Hardware components are the distinguishable physical components that compose an
endpoint. The composition of an endpoint can be changed over time by adding
or removing hardware components. In essence, every physical endpoint is
potentially a composite of multiple hardware components, typically resulting
in a hierarchical composition of hardware components. The composition of hardware
components is based on interconnects provided by specific hardware types (e.g.
mainboard is a hardware type that provides local busses as an interconnect). In
general, a hardware component can be distinguished by its serial number.</t>
<t>Examples of a hardware components include: motherboards, network interfaces, graphics
cards, hard drives, etc.</t>
</section>
<section title="Software Component">
<t>A software package installed on an endpoint (including the operating system) as
well as a unique serial number if present (e.g. a text editor associated with
a unique license key).</t>
<t>It should be noted that this includes both benign and harmful software packages. Examples
of benign software components include: applications, patches, operating system kernel, boot
loader, firmware, code embedded on a webpage, etc. Examples of malicious software components
include: malware, trojans, viruses, etc.</t>
<section title="Software Instance">
<t>A running instance of the software component (e.g. on a multi-user system, one logged-in
user has one instance of a text editor running and another logged-in user has another
instance of the same text editor running, or on a single-user system, a user could have
multiple independent instances of the same text editor running).</t>
</section>
</section>
<section title="Identity">
<t>Any mechanism that can be used to identify an asset during an authentication process. Examples
include usernames, user and device certificates, etc. Note, that this is different than the
identity of assets in the context of designation as described in <xref target="endpoint-designation"/>.</t>
</section>
<section title="Guidance">
<t>Guidance is input instructions to processes and tasks, such as collection or evaluation. Guidance influences
the behavior of a SACM component and is considered content of the management plane. Guidance can be manually
or automatically generated or provided. Typically, the tasks that provide guidance to SACM components have
a low-frequency and tend to be sporadic. A prominent example of guidance are target endpoint profiles,but
guidance can have many forms, including:
<list style="symbol">
<t>Configuration, e.g. a SACM component's name, or a CMDB's IPv6 address.</t>
<t>Profiles, e.g. a set of expected states for network behavior associated with target endpoints
employed by specific users.</t>
<t>Policies, e.g. an interval to refresh the registration of a SACM component, or a list of
required capabilities for SACM components in a specific location.</t>
</list>
</t>
<section title="Collection Guidance">
<t>A collector may need guidance to govern what it collects and when. Collection Guidance provides
instructions for a Collector that specifies which endpoint attributes to collect, when to collect
them, and how to collect them. Collection Guidance is composed of Target Endpoint Attribute
Guidance, Frequency Guidance, and Method Guidance.<list style="symbols">
<t>Target Endpoint Attribute Guidance: Set of endpoint attributes that are supposed to be
collected from a target endpoint. The definition of the set of endpoint attributes is
typically based on an endpoint characterization record.</t>
<t>Frequency Guidance: Specifies when endpoint attributes are to be collected.</t>
<t>Method Guidance: Indicates how endpoint attributes are to be collected.</t>
</list>
</t>
</section>
<section title="Evaluation Guidance">
<t>An evaluator typically needs guidance to govern what it considers to be a good or bad security
posture. Evaluation Guidance provides instructions for an Evaluator that specifies which endpoint
attributes to evaluate, the desired state of those endpoint attributes, and any special requirements
that enable an Evaluator to determine if the endpoint attributes can be used in the evaluation
(e.g. freshness of data, how it was collected, etc.). Evaluation Guidance is composed of Target
Endpoint Attribute Guidance, Expected Endpoint Attribute Value Guidance, and Frequency Guidance.
<list style="symbols">
<t>Target Endpoint Attribute Guidance: Set of target endpoint attributes that are supposed to
be used in an evaluation as well as any requirements on the endpoint attributes. The
definition of the set of endpoint attributes is typically based on an endpoint
characterization record.</t>
<t>Expected Endpoint Attribute Value Guidance: The expected values of the endpoint attributes
described in the Target Endpoint Attribute Guidance.</t>
<t>Frequency Guidance: Specifies when endpoint attributes are to be evaluated.</t>
<t>Method Guidance: Indicates how endpoint attributes are to be collected.</t>
</list>
</t>
</section>
<section title="Classification Guidance">
<t>A SACM Component carrying out the Target Endpoint Classification Task may need guidance on how to