forked from sacmwg/draft-ietf-sacm-information-model
-
Notifications
You must be signed in to change notification settings - Fork 0
/
draft-ietf-sacm-information-model-01.xml
3501 lines (3108 loc) · 243 KB
/
draft-ietf-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"?>
<!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 RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.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 RFC3444 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3444.xml">
<!ENTITY RFC3580 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3580.xml">
<!ENTITY RFC3954 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3954.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 RFC5201 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5201.xml">
<!ENTITY RFC5209 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5209.xml">
<!ENTITY RFC5280 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5280.xml">
<!ENTITY RFC5424 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5424.xml">
<!ENTITY RFC5792 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5792.xml">
<!ENTITY RFC5793 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5793.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 RFC6876 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6876.xml">
<!ENTITY RFC7171 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7171.xml">
<!ENTITY I-D.ietf-sacm-use-cases SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sacm-use-cases.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 I-D.salowey-sacm-xmpp-grid SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-salowey-sacm-xmpp-grid-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="info" docName="draft-ietf-sacm-information-model-01" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- 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>david.waltermire@nist.gov</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>kimberly.watson@hq.dhs.gov</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>cliffordk@pulsesecure.net</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>llorenzin@pulsesecure.net</email>
</address>
</author>
<date year="2014"/>
<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 proposes an information model
for SACM.</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="INTRO">
<t>This document defines a notional information model for endpoint posture assessment. It
describes the information needed to perform certain assessment activities. The scope
of the information model is to describe the structure of the information carried to
realize the assessment. It is meant to be a basis for the development of specific data
models. The terms information model and data model loosely align with the definitions
in RFC3444 <xref target="RFC3444"/>.</t>
<t>The four primary activities to support this information model are:<list
style="numbers">
<t>Endpoint Identification</t>
<t>Endpoint Characterization</t>
<t>Endpoint Attribute Expression/Representation</t>
<t>Policy evaluation expression and results reporting</t>
</list></t>
<t>These activities are aimed at the level of the technology that performs operations to
support collection, evaluation, and reporting.</t>
<t>Review of the SACM Use Case <xref target="I-D.ietf-sacm-use-cases"/> usage scenarios
show a common set of business process areas that are critical to understanding
endpoint posture such that appropriate policies, security capabilities, and
decisions can be developed and implemented.</t>
<t>For this information model we have chosen to focus on the following business process
areas:<list style="symbols">
<t>Endpoint Management</t>
<t>Software Management</t>
<t>Configuration Management</t>
<t>Vulnerability Management</t>
</list></t>
<t>These management process areas are a way to connect the SACM use cases and building
blocks <xref target="I-D.ietf-sacm-use-cases"/> to the organizational needs such
that the definition of information requirements has a clearly understood
context.(/wandw)</t>
<t>The SACM information model offers a loose coupling between providers and
consumers of security information. A provider can relay what it observes or infers,
without knowing which consumers will use the information, or how they will use it. A
consumer need not know exactly which provider generated a piece of information, or
by what method.</t>
<t>At the same time, a consumer *can* know these things, if necessary.</t>
<t>As things evolve, a provider can relay supplemental information. Some consumers will
understand and benefit from the supplemental information; other consumers will not
understand and will disregard it.</t>
<section title="Changes in Revision 01">
<t>Renamed "credential" to "identity", following industry usage. A credential includes
proof, such as a key or password. A username or a distinguished name is called an
"identity".</t>
<t>Removed Session, because an endpoint's network activity is not SACM's initial focus</t>
<t>Removed Authorization, for the same reason</t>
<t>Added many-to-many relationship between Hardware Component and Endpoint, for clarity</t>
<t>Added many-to-many relationship between Software Component and Endpoint, for clarity</t>
<t>Added "contains" relationship between Network Interface and Network Interface</t>
<t>Removed relationship between Network Interface and Account. The endpoint knows the identity it used to gain network access. The PDP also knows that. But they probably do not know the account.</t>
<t>Added relationship between Network Interface and Identity. The endpoint and the PDP will typically know the identity.</t>
<t>Made identity-to-account a many-to-one relationship.</t>
</section>
</section>
<section title="Problem Statement">
<t>TODO: revise</t>
<t>(wandw)SACM requires a large and broad set of mission and business processes, and to make
the most effective of use of technology, the same data must support multiple
processes. The activities and processes described within this document tend to build off
of each other to enable more complex characterization and assessment. In an effort
to create an information model that serves a common set of management processes
represented by the usage scenarios in the SACM Use Cases document, we have narrowed
down the scope of this model.(/wandw) [What does "narrowed down the scope of this model" mean? - LL]</t>
<t>Administrators can't get technology from disparate
sources to work together; they need information to make decisions, but the information
is not available. Everyone is collecting the same data, but storing it as different
information. Administrators therefore need to collect data and craft their own information,
which may not be accurate or interoperable because it's customized by each administrator, not
shared. A standard information model enables flexibility in collecting, storing, and sharing
information despite platform differences.</t>
<t>A way is needed to exchange
information that (a) has breadth, meaning the pieces of the notation are useful about a
variety of endpoints and software components, and (b) has longevity, meaning that the
pieces of the notation will stay useful over time.</t>
<t>When creating standards, it's not sufficient to go from requirements directly to protocol;
the standards must eliminate ambiguity in the information transported. This is
the purpose of information models generally. The SACM problem space is about integrating
many information sources. This information model addresses the need to integrate security
components, support multiple data models, and provide interoperability in a way that is
platform agnostic, scales, and works over time.</t>
<section title="Mapping to SACM Use Cases">
<t>TODO: revise</t>
<t>(wandw)This information model directly corresponds to all four use cases defined in the
SACM Use Cases draft <xref target="I-D.ietf-sacm-use-cases"/>. It uses these use
cases in coordination to achieve a small set of well-defined tasks.</t>
<t>Sections [removed] thru [removed] address each of the process areas. For each
process area, a "Process Area Description" sub-section represent an end state
that is consistent with all the General Requirements and many of the Use Case
Requirements identified in the requirements draft <xref
target="I-D.ietf-sacm-requirements"/>.</t>
<t>The management process areas and supporting operations defined in this memo
directly support REQ004 Endpoint Discovery; REQ005-006 Attribute and Information
Based Queries, and REQ0007 Asynchronous Publication.</t>
<t>In addition, the operations that defined for each business process in this memo
directly correlate with the typical workflow identified in the SACM Use Case
document.(/wandw)</t>
</section>
<section title="Referring to an Endpoint">
<t>How to refer to an endpoint is problematic. Ideally, an endpoint would have a unique identifier. These identifiers would have a one-to-one relationship with endpoints. Every observation of an endpoint, or inference about an endpoint would be labeled with its identifier. </t>
<t>However:
<list style="symbols">
<t> An external posture attribute collector typically cannot observe the unique identifier directly. An external posture attribute collector should be able to report exactly what it has observed, unembellished. It should not have to *infer* which endpoint it has observed; that inference should be leavable to other SACM components. So, SACM cannot require that every observation include the unique endpoint identifier.</t>
<t>Internal posture attribute collectors are not present on all endpoints. They are not present on "dumb" devices such as Internet of Things (IoT) devices, or on Bring Your Own Device (BYOD) devices. In these cases, *no* observers have direct access to the unique endpoint identifier.</t>
<t>An endpoint identifier is generally subject to cloning, when a system image is cloned. Then it is no longer unique.</t>
<t>Suppose the endpoint identifier is highly clone resistant -- such a unique certificate within a trusted platform module TPM). Even so, it is possible to replace all of the software -- for example, changing a Windows machine to a Linux machine. Is it still the same endpoint? For SACM purposes, it isn't really the same endpoint. </t>
</list>
</t>
<t>So SACM components must be able to put disparate observations together and form a picture of an endpoint -- somewhat like a detective. The SACM information model must facilitate this.</t>
</section>
<section title="Dealing with Uncertainty">
<t>With many information models, the information is considered certain. So it is OK to blur the difference between the representation and the thing represented.</t>
<t>In SACM, information is not certain. Attackers may develop countermeasures to fool some SACM components. Attackers may compromise some SACM components.</t>
<t>So the model must let SACM components and humans reason with uncertainty. There are no facts, only assertions. </t>
<t>SACM components must be able to cross check observations and inferences against each other. They should be able to give weight if an observation or inference is corroborated by more than one method. Although SACM will probably not prescribe *how* to do this cross checking, SACM should provide the components with provenance information.</t>
<t>SACM components must be able to consider the reputation of the observer or inferrer. That reputation should account for the method of observing or inferring, the implementer of the SACM component that made the observation or inference, and the compliance status of the endpoint on which the observation or inference was made. For example, if some observers are found to be vulnerable to a Day 1 exploit, observations from those observers deserve less weight. The details of reputation technology may be out of scope for SACM. However, again, SACM should provide components with provenance information.</t>
</section>
</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>
<section title="Elements of the SACM Information Model">
<t>The SACM Information Model contains several elements
of the architecture, including:<list style="symbols">
<t>SACM Components, which may be Collectors, Evaluators, etc.
Collectors may be internal (performed within the
endpoint itself) or external (performed outside of the endpoint,
such as by a hypervisor or remote sensor)</t>
<t>Guidance, which tells SACM components what to do</t>
<t>Posture, in the form of posture attributes and evaluation results</t>
<t>Additional information about the endpoint, such as a representation
of a software component, endpoint identity, user identity, address,
location, and authorization constraining the endpoint</t>
</list></t>
<t>The SACM Information Model does not (in this draft) specify
how long information is retained. Historical information is
modeled the same way as current information. Historical information
may be represented
differently in an implementation, but that difference would be in data models,
not in the information model.
</t>
<t><xref target="figure-elements-and-multiplicity"/> the
the information model.</t>
<figure title="Elements and Multiplicity"
anchor="figure-elements-and-multiplicity">
<artwork><![CDATA[
+---------+*______in>_______*+-----+
|Hardware | |! !|
|Component| +---------+ |! !| +--------+*________________
+---------+ |Software |in> |! !|*_____*|Location|___________ <in|
1| |Component|____|! !| in> +--------+* <in *| |
| +---------+* *|! !| +-------+ |
| 1| |! !| |Account| |
| *| | | +----------+ +-------+ |
| +---------+ |End- |*_____*| Identity |_________|0..1 |
*| |Software |in> |point| acts +----------+* belongs |
+---------+ |Instance |____| | for> 0..1|^ to> |
|Hardware | +---------+* 1|! !| |acts |
|Instance |__________________|! !| *|for |*
+---------+* in> 1|! !|_______+---------+ +-------+
|! !|1 <in *|Network |1_______*|Address|
|! !|____ |Interface| <bound +-------+
|! !|0..1| +---------+ to
+-----+ | *| |0..1
1| |* | |___|
____________________| |_______| in>
| in>
.......|..............................................................
| |0..1
| |
| |*
| +-----+ +---------+___________________
| | AVP |____________|Endpoint |* <based-on |
^| +-----+1..* 1|Attribute|________ |
hosted-by| *| |Assertion|* | |
| | +---------+ | |
| |produced-using |* |* | *|
| 1|V | |__________| +-------+
| +--------+ | <based-on |Summary|
| | Method | | +-------+
| +--------+ |produced-by *|
|____________________ |V |
|* 1| |
+--------+1____________*+-----------+ |
| | guides> | SACM |__________________________|
|Guidance| | Component |1 <produced-by
+--------+*____________1+-----------+
<produced-by
-------------------------------------------------------------
..... Above this line is the monitorable world
-------------------------------------------------------------
]]></artwork>
</figure>
<t>Note: UML 2 is specified by <xref target="UML"/>.</t>
<t>TODO: update text to match new figure:</t>
<t>Need to be clear in the description that - of some of
the relationships, will need some language and guidance to
the interfaces and relationships we expect to have happen,
MUSTs and SHOULDs, as well as explaining the extensibility
that other relationships can exist, show examples of how
that can happen. Others that we haven't thought of yet, might
be added by another RFC or in another way</t>
<t>CEK: >>> I suddenly wonder whether all of the relationships in the upper right corner of the diagram are needed. At present, AVPs mostly mention instances of the classes in the upper half. The only relationship an endpoint attribute assertion expresses is that a set of AVPs are all true of some endpoint. We dont have a way to say that an address is bound to a particular interface. Such structures *can* be modeled, using YANG, for example. But do we require that? If we do, why? I do think we need to be able to relate a software instance to the software component, and a hardware instance to the hardware component.</t>
<t>The following subsections discuss <xref target="figure-elements-and-multiplicity"/>.</t>
<section title="Software Component">
<t>An endpoint contains and runs software components.</t>
<t>Relationship:<list style="symbols">
<t>If an endpoint has an instance of a software component, we say that the software component is in the endpoint. This is a shorthand.</t>
</t>
<t>Some software components are assets.
"Asset" is defined in RFC4949 <xref target="RFC4949"/> as "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>An examination of software needs to
consider both (a) software assets and (b) software that may
do harm. A posture attribute collector may not know (a) from (b). It is useful
to define Software Component as the union of (a) and (b).</t>
<t>Examples of Software Assets:<list style="symbols">
<t>An application</t>
<t>A patch</t>
<t>The operating system kernel</t>
<t>A boot loader</t>
<t>Firmware that controls a disk drive</t>
<t>A piece of JavaScript found in a web page the user visits</t>
</list></t>
<t>Examples of harmful software components:<list style="symbols">
<t>A malicious entertainment app</t>
<t>A malicious executable</t>
<t>A web page that contains malicious JavaScript</t>
<t>A business application that shipped with a virus</t>
</list></t>
<t>Software components SHOULD be disjoint from each other. In other words,
software componennts SHOULD be so defined that
a given byte of software on an endpoint
belongs to only one software component.</t>
<t>Different versions of the same piece of software MUST be modeled as
different components. Software versioning is not built into the
information model.</t>
<t>Each separately installable piece of software SHOULD be modeled as a
component. Sometimes it may be better to divide more finely: what an installer installs MAY be modeled as several components.</t>
<t>A data model MAY identify a software component by parts of an ISO SWID tag.</t>
</section>
<section title="Software Instance">
<t>Each copy of a piece of software is called a software instance. The configuration of a software instance is regarded as part of the software instance. Configuration can strongly affect security posture.</t>
<t>A data model MUST support the following relationships:<list style="symbols">
<t>A software instance is an instance of a software component.</t>
<t>A software instance is in an endpoint.</t>
</list></t>
<t>A data model MAY use ISO SWID tags to describe software instances.</t>
</section>
<section title="Hardware Component">
<t>Hardware components may also be assets and/or harmful. For example,
a USB port on a system may be disabled to prevent information flow
into our out of a particular system; this provides an additional
layer of protection that can complement software based protections.
Other such assets may include access to or modification of storage
media, hardware key stores, microphones and cameras. Like software
assets, we can consider these hardware components both from the
perspective of (a) an asset that needs protection and (b) an asset
that can be compromised in some way to do harm.</t>
<t>A data model MAY designate a hardware component by its manufacturer and a part number. </t>
</section>
<section title="Hardware Instance">
<t>A hardware instance is just an instance of a particular
component.</t>
<t>A data model MUST support the following relationships:<list style="symbols">
<t>A hardware instance is an instance of a hardware component.</t>
<t>A hardware instance is in an endpoint.</t>
<t>Hardware instances may need to be modeled because (a) an endpoint may have multiple instances of a hardware component, (b) a hardware instance may be compromised, whereas other instances may remain intact.</t>
<t>A data model MAY designate a hardware instance
by its component and a unique serial number.</t>
</section>
<section title="Network Interface">
<t>CEK: >>> I am not sure how to use network interfaces for endpoint identification. As for compliance, is this too advanced for SACM at this time?</t>
<t>An endpoint generally has at least one network interface.</t>
<t>Interfaces nest. A virtual interface can nest in a physical interface.</t>
<t>A data model MUST support the following relationships:<list style="symbols">
<t>A network interface is in an endpoint.</t>
<t>A network interface is in another network interface; this
is for a nested interface. CEK: >>> And this allows representing
compliance policies that are worthwhile. But is this too advanced
for the initial set of SACM RFCs?</t>
<t>A network interface acts for an identity. This occurs, for example, when the network interface is online because of successful 802.1X. An internal
collector may be aware of the identity. An external collector (such as a RADIUS server) will be aware of the identity.</t>
</list></t>
</section>
<section title="Address">
<t>An address SHALL BE any of:<list style="symbols">
<t>A layer 2 address; a data model MUST support MAC addresses,
and MAY support others</t>
<t>A layer 3 address; a data model MUST support IPv4 and IPv6
addresses, and MAY support others</t>
<t>A layer 4 address; a data model MUST support
an IP-address-protocol-port combination, where protocol is TCP or UDP.
It MAY support others</t>
</list></t>
<t>Addresses from other layers may be added in the future.</t>
<t>These addresses are not necessarily globally unique. Therefore, a data model SHOULD allow an address to be qualified with a scope.<list style="symbols">
<t>A data model SHOULD allow qualifying a MAC address with its
layer-2 broadcast domain. This MAY take the form of a VLAN ID
and an administratively assigned string denoting the LAN.</t>
<t>A data model SHOULD allow qualifying an IP address with an
administratively assigned string denoting the IP routing domain.</t>
<t>A data model MUST support the following relationships:<list style="symbols">
<t>An address is bound to a network interface.</t>
<t>An address is considered bound to an endpoint just if the
address is bound to an interface that is in the endpoint.<t>
<t>An address may be in one or more locations.<t>
</list></t>
</section>
<section title="Identity">
<t>An identity is the non-secret part of a credential. Examples are a username,
an X.500 distinguished name, and a public key. Passwords, private keys,
and other secrets are not considered part of an identity.</t>
<t>A data model MUST support the following relationships:<list style="symbols">
<t>An endpoint may act for an identity. This SHALL mean that the endpoint claims or proves that it has this identity. For example, if the endpoint is part of an Active Directory domain and Alice logs into the endpoint with her AD username (alice) and password, the endpoint "acts for alice. An endpoint MAY "act for more than one identity, such as a machine identity and a user identity.</t>
<t>A identity may belong to an account. For example, an enterprise may have a database that maps identities to accounts. CEK: >>> Is this relevant? I dont see how wed use the notion of an account in identifying an endpoint or in specifying compliance measurements to be taken.</t>
</list></t>
</section>
<section title="Location">
<t>Location can be logical or physical.
Location can be a clue to an endpoint's identity.</t>
<t>A data model MUST support the following relationships:<list style="symbols">
<t>One or more endpoints may be in a location</t>
<t>A location may be in one or more locations</t>
<t>A network address may be in a location</t>
<t>An account may be in a location; this would happen
if the account represents a user, and a physical access
control system reports on the users location
</list></t>
<t>Examples of location:<list style="symbols">
<t>The switch, access point, VPN gateway, or cell tower to which the endpoint is
linked</t>
<t>The switch port where the endpoint is plugged in</t>
<t>The location of the endpoint's IP address in the network
topology</t>
<t>The geographic location of the endpoint (which is often
self-reported)</t>
<t>A user location (may be reported by a physical access control
system)</t>
</list></t>
<t>CEK: >>> The last three examples seem too advanced for the first set of SACM RFCs.
I do not know a notation that would be interoperable and
useful for endpoint identification. Should we drop them?</t>
<t>CEK: If we do drop them, all we have left is the device and port at which the
endpoint is linked to the network. Maybe we should regard that as a kind
of address.</t>
<t>A data model MUST support switch + port number,
access point, and VPN gateway as locations.
The other examples are optional.</t>
<t>More than one of kind of location may pertain to an endpoint. Endpoint has a
many-to-many relationship with Location.</t>
</section>
<section title="Endpoint">
<t>An endpoint is the hollow center of the model. An endpoint is an abstract ideal. Any endpoint attribute assertion that mentions an endpoint mentions it by specifying identifying attributes. Even if there is one preferred endpoint identity, that is modeled as an identity. We do not anticipate any AVP whose attribute type is endpoint.</t>
</section>
<section title="Endpoint Attribute Assertion">
<section title="Form and Precise Meaning">
<t>An endpoint attribute assertion has:
<list style="symbols">
<t>One or more attribute-value pairs (AVPs)</t>
<t>A time interval over which the assertion holds</t>
<t>Endpoint uniquely identified? True or false</t>
<t>Provenance, including:
<list style="symbols">
<t>The SACM component that made the assertion</t>
<t>The endpoint attribute assertions (if any)
on which this assertion is based</t>
<t>Information about the method used to derive the assertion</t>
</list>
</t>
</list>
</t>
<t>It means that over the specified time interval, there was an endpoint for which all of the listed attribute-value pairs were true.</t>
<t>If the "Endpoint uniquely identified" is true, the set of attributes-value
pairs together make this assertion apply to only one endpoint.</t>
<t>The attributes can include posture attributes and
identification attributes. The model does not make a
rigid distinction between the two uses of attributes.</t>
<t>Some of the attributes may be multi-valued.
</t>
<t>One of the AVPs may be a unique endpoint identifier.
Not every endpoint will have one. If there is one, the SACM component that produces
the Endpoint Attribute Assertion will not necessarily know what it is.</t>
</section>
<section title="Asserter">
<t>An Endpoint Attribute Assertion may come from an
attribute collector or an evaluator. It may come from a SACM component that derives
it from out-of-band sources, such as
a physical inventory system. A SACM component may derive it
from other Endpoint Attribute Assertions.</t>
</section>
<section title="Example">
<t> For example, an attribute assertion might have these attribute-value pairs:<list>
<t>mac-address = 01:23:45:67:89:ab</t>
<t>os = OS X</t>
<t>os-version = 10.6.8</t>
</list></t>
<t>This asserts that an endpoint with MAC address 01:23:45:67:89:ab ran OS X 10.6.8 throughout the specified time interval. A profiler might have provided this assertion.</t>
</section>
<section title="A Use Case">
<t>For example, Endpoint Attribute Assertions should help SACM components to track an endpoint as it roams or stays stationary. They must track endpoints because they must track endpoints' postures over time. Tracking of an endpoint can employ many clues, such as:<list>
<t>The endpoint's MAC address</t>
<t>The authenticated identity (even if it identifies a user)</t>
<t>The location of the endpoint and the user</t>
</list></t>
</section>
<section title="Event">
<t>An event is represented as a Posture Attribute Assertion
whose time interval has length zero.</t>
<t>Some potential kinds of events are:<list style="symbols">
<t>A structured syslog message <xref target="RFC5424"/></t>
<t>IF-MAP event metadata <xref
target="TNC-IF-MAP-NETSEC-METADATA"/></t>
<t>A NetFlow message <xref target="RFC3954"/></t>
</list></t>
</section>
<section title="Difference between Attribute and Event">
<t>Author: Henk Birkholz</t>
<t>"Attribute" and "event" are often used fairly interchangeably. A
clear distinction makes the words more useful.</t>
<t>An *attribute* tends not to change until something causes a change. In
contrast, an *event* occurs at a moment in time.</t>
<t>For a nontechnical example, let us consider "openness" as an attribute of a door, with two values, "open" and "closed". A
closed door tends to stay closed until something opens it (a breeze,
a person, or a dog).</t>
<t>The door's opening or closing is an event.</t>
<t>Similarly, "Host firewall enabled" may be modeled as a true/false attribute of an endpoint.
Enabling or disabling the host firewall may be modeled as
an event. An endpoint's crashing also may be modeled as an
event.</t>
<t>Although events are not attributes,
we use one kind of information element,
the "Endpoint Attribute Assertion",
to describe both attributes and events.</t>
</section>
</section> <!-- Endpoint Attribute Assertion -->
<section title="Attribute-Value Pair">
<t>The set of attribute types must be extensible, by other IETF standards, by other standards groups, and by vendors. How to express attribute types is not defined here, but is left to data models.</t>
<t>The value may be structured. For example, it may something like XML.</t>
<t>The information model requires a standard attribute type (or possibly more than one) for each box in
the upper half of <xref target="figure-elements-and-multiplicity"/>:
<list style="symbols">
<t>Hardware Component: the value identifies the hardware type. For example, it may consist of the make and model number.</t>
<t>Hardware Instance: the value, together with the Hardware Component value, uniquely identifies the hardware instance. For example, it may be a manufacturer-assigned
serial number. This notion might not apply to all virtual hardware components.</t>
<t>Software Component: the value identifies a unit of software. Each
installable piece of software should be separately identifiable.
For example, this might be a Software Identifier (SWID). Therefore, a software inventory for an endpoint should be expressed as an Endpoint Attribute Assertion.</t>
<t>Software Instance: the value describes how the software component is installed and configured.</t>
<t>Endpoint: The value is a unique endpoint identifier.</t>
<t>Location</t>
<t>Identity: The value is the non-secret part of a credential.
For example, it may be a certificate, or just a subject Distinguished Name extracted from a certificate. It may be a username.</t>
<t>Network Interface: TBD</t>
<t>User: [cek: Do we want this? If one user uses different
credentials at different times, do we think SACM components
will need know that it's the same user?]</t>
<t>Address: The value is an IP, MAC, or other network address,
possibly qualified with its scope.</t>
</list></t>
<section title="Unique Endpoint Identifier">
<t>An organization should try to uniquely identify and label an endpoint, whether the endpoint is enrolled or is discovered in the operational environment. The identifier should be assigned by or used in the enrollment process. </t>
<t>Here "unique" means one-to-one. In practice, uniqueness is not always attainable. Even if an endpoint has a unique identifier, an attribute collector may not always know it.</t>
<t>If the attribute type of an AVP is "endpoint", the value
is a unique identifier of the endpoint.</t>
</section>
<section title="Posture Attribute">
<t>Some AVPs will be posture attributes.</t>
<t>See the definition in the SACM Terminology for Security Assessment
<xref target="I-D.ietf-sacm-terminology"/>.</t>
<t>Some potential kinds of posture attributes are:<list style="symbols">
<t>A NEA posture attribute (PA) <xref target="RFC5209"/></t>
<t>A YANG model <xref target="RFC6020"/></t>
<t>An IF-MAP device-characteristics metadata item <xref
target="TNC-IF-MAP-NETSEC-METADATA"/></t>
</list></t>
</section>
<section title="Evaluation Result">
<t>Evaluation Results (see <xref
target="I-D.ietf-sacm-terminology"/>) are modeled as Endpoint Attribute Assertions.</t>
<t>An Evaluation
Result derives from one or more other Endpoint Attribute Assertions.</t>
<t>An example is: a NEA access recommendation <xref target="RFC5793"/></t>
<t>An evaluator may be able to evaluate better if history is
available. This is a use case for retaining Endpoint Attribute Assertions for a time.</t>
<t>An Evaluation Result may be retained longer than the Endpoint Attribute Assertions from which it derives. (<xref
target="figure-elements-and-multiplicity"/> does not show this.) In the
limiting case, Endpoint Attribute Assertions are not retained. When
as an Endpoint Attribute Assertion arrives, an evaluator produces
an Evaluation Result. These mechanics are out of the scope of the Information Model.</t>
</section>
</section>
<section title="Report">
<t>An Endpoint Attribute Assertion concerns a single endpoint.
Assertions about a set of endpoints are also needed -- for example, for trend analysis and for reports read by humans. These assertions are termed "reports". SACM components will consume Endpoint Attribute Assertions
and generate reports.</t>
<t>A report contains its provenance, with the same form and meaning
as the provenance of an Endpoint Attribute Assertion.</t>
<t>A Report summarizes:<list style="symbols">
<t>Endpoint Attribute Assertions, which may include Evaluation Results</t>
<t>Other Reports</t>
</list></t>
<t>A Report may routine or ad hoc.</t>
<t>Some reports may be machine readable. Machine readable reports may be
consumable by SACM components and by automatic response systems (not specified by SACM).</t>
</section>
<section title="SACM Component">
<t>Although SACM components are mainly covered by the SACM architecture, we have some remarks. TODO: Move them?</t>
<section title="External Attribute Collector">
<t>An external collector is a collector
that observes endpoints from
outside. [kkw-many of these [collectors] are
actually configured and operated to manage assets for reasons other
than posture assessments. it is critical to bring them into this, so
i like it...but does it matter if the [collector] isn't intended to support
posture assessment, but happens to have information that can be
used by posture assessment collection consumers? do we lump them
together with collectors that are intended to support posture
assessment but run external to the endpoint?]
[jmf: ditto. The exampled below are of things that would perform external collection].
</t>
<t>[cek-to kkw's comment, I think the purpose here is to capture their
contribution to continuous monitoring. I don't see the need to separate
things whose primary job is monitoring from things whose primary job is
something else. Is there a need?]</t>
<t>[cek-to jmf's comment, that is what they are examples of; is a text
change needed?]</t>
<t>Examples:<list style="symbols">
<t>A RADIUS server whereby an endpoint has logged onto the
network</t>
<t>A network profiling system, which discovers and classifies
network nodes</t>
<t>A Network Intrusion Detection System (NIDS) sensor</t>
<t>A vulnerability scanner</t>
<t>A hypervisor that peeks into the endpoint, the endpoint being a
virtual machine</t>
<t>A management system that configures and installs software on the
endpoint</t>
</list></t>
</section>
<section title="Evaluator">
<t>An evaluator can consume
endpoint attribute assertions, previous evaluations of posture attributes,
or previous reports of evaluation results. [kkw-i don't think this
conflicts with the definition in the terminology doc re: that
evaluation tasks evaluate posture attributes.]</t>
<t>[cek-I like the change. I think it *does* require a change in the terminology doc, though.]</t>
<t>Example: a NEA posture validator <xref target="RFC5209"/></t>
<t>[jmf- a NEA posture validator is not an example of this definition. A NEA posture assessment is, maybe?]</t>
<t>[cek-Why isn't a NEA posture validator an example?]</t>
</section>
<section title="Report Generator">
<t>A report generator makes reports based on:<list style="symbols">
<t>Endpoint Attribute Assertions, including Evaluation Results</t>
<t>Other Reports (a weekly report may be created from daily
reports)</t>
</list></t>
<t>It may summarize data continually, as the data arrives. It also may
summarize data in response to an ad hoc query.</t>
</section>
</section>
<section title="Organization?">
<t>[kkw-from a reporting standpoint there needs to be
some concept like organization or system. without this, there is no
way to produce result reports that can be acted upon to provide the
insight or accountability that almost all continuous monitoring
instances are trying to achieve. from a scoring or grading
standpoint, an endpoint needs to be associated with exactly one
organization or system. it can have a many to many relationship
with other types of results reporting "bins". is this important
to include here? we had organization as a core asset type for this
reason, so i think it is a key information element. but i also
know that i do not want to define all the different reporting
types, so i am unsure.]</t>
<t>[cek-I had not thought of this at all. Would it make sense to treat the organization and the bins
as part of the guidance for creating reports? Maybe not. We should discuss.]</t>
</section>
<section title="Guidance">
<t>[jmf- the guidance sections need more detail. . .]</t>
<t>[cek - What is missing? We would welcome a critique or text.]</t>
<t>Guidance is generally configurable by human administrators.</t>
<section title="Internal Collection Guidance">
<t>An internal collector may need guidance to govern what it
collects and when.</t>
</section>
<section title="External Collection Guidance">
<t>An external collector may need guidance to govern what it
collects and when.</t>
</section>
<section title="Evaluation Guidance">
<t>An evaluator typically needs Evaluation Guidance to govern
what it considers to be a good or bad security posture.</t>
</section>
<section title="Retention Guidance">
<t>A SACM deployment may retain posture attributes, events, or
evaluation results for some time. Retention supports ad hoc
reporting and other use cases.</t>
<t>If information is retained, retention guidance controls what is
retained and for how long.</t>
<t>If two or more pieces of retention guidance apply to a piece of information,
the guidance calling for the longest retention should take
precedence.</t>
</section>
<section title="Reporting Guidance">
<t>A Report Generator typically needs Reporting Guidance to govern the
reports it generates.</t>
</section>
</section>
<section title="Provenance of Information">
<t>Each Endpoint Attribute Assertion and Report needs to be
labeled with its provenance.</t>
</section>
<section title="Endpoint">
<t>See the definition in the SACM Terminology for Security Assessment <xref
target="I-D.ietf-sacm-terminology"/>.</t>
<t>In the model, an endpoint can be part of another endpoint.
This covers cases where multiple physical endpoints act as one endpoint. The constituent endpoints may not be distinguishable by external observation of network behavior.</t>
<t>For example, a hosting center may maintain a redundant set (redundancy group) of
multi-chassis setups to provide active redundancy and load distribution
on network paths to WAN gateways. Multi-chassis link aggregation
groups make the chassis appear as one endpoint.
Traditional security controls must be applied either to
physical endpoints or the redundancy groups they compose (and
occasionally both). Loss of redundancy is difficult to detect or
mitigate without specific posture information about the current state of
redundancy groups. Even if a physical endpoint (e.g. router) that is
part of a redundancy group is replaced, the redundancy group can remain
the same.
</t>
<section title="Endpoint Identity">
<t>An endpoint identity provides both identification and
authentication of the endpoint. For example, an identity may be an
X.509 certificate <xref target="RFC5280"/> and corresponding private
key.
[jmf- this example should be formatted like the other examples in this section]
</t>
<t>Not all kinds of identities are guaranteed to be unique.</t>
</section>
<section title="Software Component">
<t>An endpoint contains and runs software components.</t>
<t>Some of the software components are assets.
"Asset" is defined in RFC4949 <xref target="RFC4949"/> as "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>An examination of software needs to
consider both (a) software assets and (b) software that may
do harm. A posture attribute collector may not know (a) from (b). It is useful
to define Software Component as the union of (a) and (b).</t>
<t>Examples of Software Assets:<list style="symbols">
<t>An application</t>
<t>A patch</t>
<t>The operating system kernel</t>
<t>A boot loader</t>
<t>Firmware that controls a disk drive</t>
<t>A piece of JavaScript found in a web page the user visits</t>
</list></t>
<t>Examples of harmful software components:<list style="symbols">
<t>A malicious entertainment app</t>