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
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
|
<pre>Internet Engineering Task Force (IETF) T. Takahashi
Request for Comments: 7203 NICT
Category: Standards Track K. Landfield
ISSN: 2070-1721 McAfee
Y. Kadobayashi
NAIST
April 2014
<span class="h1">An Incident Object Description Exchange Format (IODEF) Extension</span>
<span class="h1">for Structured Cybersecurity Information</span>
Abstract
This document extends the Incident Object Description Exchange Format
(IODEF) defined in <a href="./rfc5070">RFC 5070</a> to exchange enriched cybersecurity
information among security experts at organizations and facilitate
their operations. It provides a well-defined pattern to consistently
embed structured information, such as identifier- and XML-based
information.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc7203">http://www.rfc-editor.org/info/rfc7203</a>.
<span class="grey">Takahashi, et al. Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc7203">RFC 7203</a> IODEF-SCI April 2014</span>
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-3">3</a>
<a href="#section-2">2</a>. Terminology .....................................................<a href="#page-3">3</a>
<a href="#section-3">3</a>. Applicability ...................................................<a href="#page-4">4</a>
<a href="#section-4">4</a>. Extension Definition ............................................<a href="#page-5">5</a>
<a href="#section-4.1">4.1</a>. IANA Table for Structured Cybersecurity Information ........<a href="#page-5">5</a>
<a href="#section-4.2">4.2</a>. Extended Data Type: XMLDATA ................................<a href="#page-6">6</a>
<a href="#section-4.3">4.3</a>. Extending IODEF ............................................<a href="#page-6">6</a>
<a href="#section-4.4">4.4</a>. Basic Structure of the Extension Classes ...................<a href="#page-8">8</a>
<a href="#section-4.5">4.5</a>. Defining Extension Classes .................................<a href="#page-9">9</a>
<a href="#section-4.5.1">4.5.1</a>. AttackPattern .......................................<a href="#page-9">9</a>
<a href="#section-4.5.2">4.5.2</a>. Platform ...........................................<a href="#page-10">10</a>
<a href="#section-4.5.3">4.5.3</a>. Vulnerability ......................................<a href="#page-11">11</a>
<a href="#section-4.5.4">4.5.4</a>. Scoring ............................................<a href="#page-11">11</a>
<a href="#section-4.5.5">4.5.5</a>. Weakness ...........................................<a href="#page-12">12</a>
<a href="#section-4.5.6">4.5.6</a>. EventReport ........................................<a href="#page-13">13</a>
<a href="#section-4.5.7">4.5.7</a>. Verification .......................................<a href="#page-14">14</a>
<a href="#section-4.5.8">4.5.8</a>. Remediation ........................................<a href="#page-15">15</a>
<a href="#section-5">5</a>. Mandatory-to-Implement Features ................................<a href="#page-15">15</a>
<a href="#section-5.1">5.1</a>. An Example XML Document ...................................<a href="#page-16">16</a>
<a href="#section-5.2">5.2</a>. An XML Schema for the Extension ...........................<a href="#page-18">18</a>
<a href="#section-6">6</a>. Security Considerations ........................................<a href="#page-20">20</a>
<a href="#section-6.1">6.1</a>. Transport-Specific Concerns ...............................<a href="#page-20">20</a>
<a href="#section-6.2">6.2</a>. Protection of Sensitive and Private Information ...........<a href="#page-21">21</a>
<a href="#section-6.3">6.3</a>. Application and Server Security ...........................<a href="#page-22">22</a>
<a href="#section-7">7</a>. IANA Considerations ............................................<a href="#page-22">22</a>
<a href="#section-8">8</a>. Acknowledgments ................................................<a href="#page-24">24</a>
<a href="#section-9">9</a>. References .....................................................<a href="#page-24">24</a>
<a href="#section-9.1">9.1</a>. Normative References ......................................<a href="#page-24">24</a>
<a href="#section-9.2">9.2</a>. Informative References ....................................<a href="#page-26">26</a>
<span class="grey">Takahashi, et al. Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc7203">RFC 7203</a> IODEF-SCI April 2014</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The number of incidents in cyber society is growing day by day.
Incident information needs to be reported, exchanged, and shared
among organizations in order to cope with the situation. IODEF is
one of the tools already in use that enables such an exchange.
To more efficiently run security operations, information exchanged
between organizations needs to be machine readable. IODEF provides a
means to describe the incident information, but it often needs to
include various non-structured types of incident-related data in
order to convey more specific details about what is occurring.
Further structure within IODEF increases the machine-readability of
the document, thus providing a means for better automating certain
security operations.
Within the security community there exist various means for
specifying structured descriptions of cybersecurity information, such
as [<a href="#ref-CAPEC" title=""Common Attack Pattern Enumeration and Classification (CAPEC)"">CAPEC</a>], [<a href="#ref-CCE" title=""Common Configuration Enumeration (CCE)"">CCE</a>], [<a href="#ref-CCSS" title=""The Common Configuration Scoring System (CCSS): Metrics for Software Security Configuration Vulnerabilities"">CCSS</a>], [<a href="#ref-CEE" title=""Common Event Expression (CEE)"">CEE</a>], [<a href="#ref-CPE" title=""Common Platform Enumeration"">CPE</a>], [<a href="#ref-CVE" title=""Common Vulnerabilities and Exposures (CVE)"">CVE</a>], [<a href="#ref-CVRF" title=""The Common Vulnerability Reporting Framework (CVRF)"">CVRF</a>], [<a href="#ref-CVSS" title=""The Common Vulnerability Scoring System (CVSS) and Its Applicability to Federal Agency Systems"">CVSS</a>],
[<a href="#ref-CWE" title=""Common Weakness Enumeration (CWE)"">CWE</a>], [<a href="#ref-CWSS" title=""Common Weakness Scoring System (CWSS(TM))"">CWSS</a>], [<a href="#ref-MAEC" title=""Malware Attribute Enumeration and Characterization"">MAEC</a>], [<a href="#ref-OCIL" title=""Specification for the Open Checklist Interactive Language (OCIL) Version 2.0"">OCIL</a>], [<a href="#ref-OVAL" title=""Open Vulnerability and Assessment Language (OVAL)"">OVAL</a>], [<a href="#ref-SCAP" title=""The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2"">SCAP</a>], and [<a href="#ref-XCCDF" title=""Specification for the Extensible Configuration Checklist Description Format (XCCDF) version 1.2 (DRAFT)"">XCCDF</a>]. In this
context, cybersecurity information encompasses a broad range of
structured data representation types that may be used to assess or
report on the security posture of an asset or set of assets. Such
structured descriptions facilitate a better understanding of an
incident while enabling more streamlined automated security
operations. Because of this, it would be beneficial to embed and
convey these types of information inside IODEF documents.
This document extends IODEF to embed and convey various types of
structured information. Since IODEF defines a flexible and
extensible format and supports a granular level of specificity, this
document defines an extension to IODEF instead of defining a new
report format. For clarity, and to eliminate duplication, only the
additional structures necessary for describing the exchange of such
structured information are provided.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terminology</span>
The terminology used in this document follows the terminology defined
in <a href="./rfc5070">RFC 5070</a> [<a href="./rfc5070" title=""The Incident Object Description Exchange Format"">RFC5070</a>].
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 <a href="./rfc2119">RFC 2119</a> [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="grey">Takahashi, et al. Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc7203">RFC 7203</a> IODEF-SCI April 2014</span>
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Applicability</span>
To maintain awareness of the continually changing security threat
landscape, organizations need to exchange cybersecurity information,
which includes the following information: attack pattern, platform
information, vulnerability and weakness, countermeasure instruction,
computer event logs, and severity assessments. IODEF provides a
scheme to describe and exchange such information among interested
parties. However, it does not define the detailed formats to specify
such information.
There already exist structured and detailed formats for describing
these types of information that can be used in facilitating such an
exchange. They include [<a href="#ref-CAPEC" title=""Common Attack Pattern Enumeration and Classification (CAPEC)"">CAPEC</a>], [<a href="#ref-CCE" title=""Common Configuration Enumeration (CCE)"">CCE</a>], [<a href="#ref-CCSS" title=""The Common Configuration Scoring System (CCSS): Metrics for Software Security Configuration Vulnerabilities"">CCSS</a>], [<a href="#ref-CEE" title=""Common Event Expression (CEE)"">CEE</a>], [<a href="#ref-CPE" title=""Common Platform Enumeration"">CPE</a>], [<a href="#ref-CVE" title=""Common Vulnerabilities and Exposures (CVE)"">CVE</a>],
[<a href="#ref-CVRF" title=""The Common Vulnerability Reporting Framework (CVRF)"">CVRF</a>], [<a href="#ref-CVSS" title=""The Common Vulnerability Scoring System (CVSS) and Its Applicability to Federal Agency Systems"">CVSS</a>], [<a href="#ref-CWE" title=""Common Weakness Enumeration (CWE)"">CWE</a>], [<a href="#ref-CWSS" title=""Common Weakness Scoring System (CWSS(TM))"">CWSS</a>], [<a href="#ref-MAEC" title=""Malware Attribute Enumeration and Characterization"">MAEC</a>], [<a href="#ref-OCIL" title=""Specification for the Open Checklist Interactive Language (OCIL) Version 2.0"">OCIL</a>], [<a href="#ref-OVAL" title=""Open Vulnerability and Assessment Language (OVAL)"">OVAL</a>], [<a href="#ref-SCAP" title=""The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2"">SCAP</a>], and
[<a href="#ref-XCCDF" title=""Specification for the Extensible Configuration Checklist Description Format (XCCDF) version 1.2 (DRAFT)"">XCCDF</a>]. By embedding them into the IODEF document, the document can
convey more detailed context information to the receivers, and the
document can be easily reused.
The use of formats for structured information facilitates more
advanced security operations on the receiver side. Since the
information is machine readable, the data can be processed by
computers, thus allowing better automation of security operations.
For instance, an organization wishing to report a security incident
wants to describe what vulnerability was exploited. In this case,
the sender can simply use IODEF, where an XML-based [<a href="#ref-XML1.0" title=""Extensible Markup Language (XML) 1.0 (Fifth Edition)"">XML1.0</a>] attack
pattern record that follows the syntax and vocabulary defined by an
industry specification is embedded, instead of describing everything
in free-form text. The receiver can identify the needed details of
the attack pattern by looking up some of the XML tags defined by the
specification. The receiver can accumulate the attack pattern record
in its database and could distribute it to the interested parties as
needed, all without requiring human intervention.
In another example, an administrator is investigating an incident and
has detected a configuration problem that he wishes to share with a
partner organization to prevent the same event from occurring at the
partner organization. To confirm that the configuration was in fact
vulnerable, he uses an internal repository to access configuration
information that was gathered prior to the initial attack and that is
specific to a new vulnerability alert. He uses this information to
automatically generate an XML-based software configuration
description, embed it in an IODEF document, and send the resulting
IODEF document to the partner organization.
<span class="grey">Takahashi, et al. Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc7203">RFC 7203</a> IODEF-SCI April 2014</span>
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Extension Definition</span>
This document extends IODEF to embed structured information by
introducing new classes that can be embedded consistently inside an
IODEF document as element contents of the AdditionalData and
RecordItem classes [<a href="./rfc5070" title=""The Incident Object Description Exchange Format"">RFC5070</a>].
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. IANA Table for Structured Cybersecurity Information</span>
This extension embeds structured cybersecurity information (SCI)
defined by other specifications. The list of supported
specifications is managed by IANA, and this document defines the
needed fields for the list's entry.
Each entry for each specification has the namespace [<a href="#ref-XMLNames">XMLNames</a>],
specification name, version, reference URI, and applicable classes.
Arbitrary URIs that may help readers understand the specification
could be embedded inside the Reference URI field, but it is
recommended that a standard/informational URI describing the
specification be prepared and embedded here.
The initial IANA table has only one entry, as follows:
Namespace: urn:ietf:params:xml:ns:mile:mmdef:1.2
Specification Name: Malware Metadata Exchange Format
Version: 1.2
Reference URI: <<a href="http://standards.ieee.org/develop/indconn/icsg/mmdef.html">http://standards.ieee.org/develop</a>
<a href="http://standards.ieee.org/develop/indconn/icsg/mmdef.html">/indconn/icsg/mmdef.html</a>>,
<<a href="http://grouper.ieee.org/groups/malware/malwg/Schema1.2/">http://grouper.ieee.org/groups</a>
<a href="http://grouper.ieee.org/groups/malware/malwg/Schema1.2/">/malware/malwg/Schema1.2/</a>>
Applicable Classes: AttackPattern
Note that the specification was developed by The Institute of
Electrical and Electronics Engineers, Incorporated (IEEE), through
the Industry Connections Security Group (ICSG) of its Standards
Association.
The table is managed by IANA, following the allocation policy
specified in <a href="#section-7">Section 7</a>.
The SpecID attributes of extension classes (<a href="#section-4.5">Section 4.5</a>) must allow
the values of the specifications' namespace fields, but
implementations are otherwise not required to support all
specifications of the IANA table and may choose which specifications
to support. However, at a minimum, the specification listed in the
initial IANA table needs to be supported, as described in <a href="#section-5">Section 5</a>.
If an implementation received data that it does not support, it may
expand its functionality by looking up the IANA table or notify the
<span class="grey">Takahashi, et al. Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc7203">RFC 7203</a> IODEF-SCI April 2014</span>
sender of its inability to parse the data. Note that the lookup
could be done manually or automatically, but automatic download of
data from IANA's website is not recommended, since it is not designed
for mass retrieval of data by multiple devices.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Extended Data Type: XMLDATA</span>
This extension inherits all of the data types defined in the IODEF
data model. One data type is added: XMLDATA. Embedded XML data is
represented by the XMLDATA data type. This type is defined as the
extension to the iodef:ExtensionType [<a href="./rfc5070" title=""The Incident Object Description Exchange Format"">RFC5070</a>], whose dtype attribute
is set to "xml".
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. Extending IODEF</span>
This document defines eight extension classes, namely AttackPattern,
Platform, Vulnerability, Scoring, Weakness, EventReport,
Verification, and Remediation. Figure 1 describes the relationships
between the IODEF Incident class [<a href="./rfc5070" title=""The Incident Object Description Exchange Format"">RFC5070</a>] and the newly defined
classes. It is expressed in Unified Modeling Language (UML) syntax
per <a href="./rfc5070">RFC 5070</a> [<a href="./rfc5070" title=""The Incident Object Description Exchange Format"">RFC5070</a>]. The UML representation is for illustrative
purposes only; elements are specified in XML as defined in
<a href="#section-5.2">Section 5.2</a>.
<span class="grey">Takahashi, et al. Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc7203">RFC 7203</a> IODEF-SCI April 2014</span>
+---------------+
| Incident |
+---------------+
| ENUM purpose |<>---------[IncidentID]
| STRING |<>--{0..1}-[AlternativeID]
| ext-purpose |<>--{0..1}-[RelatedActivity]
| ENUM lang |<>--{0..1}-[DetectTime]
| ENUM |<>--{0..1}-[StartTime]
| restriction |<>--{0..1}-[EndTime]
| |<>---------[ReportTime]
| |<>--{0..*}-[Description]
| |<>--{1..*}-[Assessment]
| |<>--{0..*}-[Method]
| | |<>--{0..*}-[AdditionalData]
| | |<>--{0..*}-[AttackPattern]
| | |<>--{0..*}-[Vulnerability]
| | |<>--{0..*}-[Weakness]
| |<>--{1..*}-[Contact]
| |<>--{0..*}-[EventData]
| | |<>--{0..*}-[Flow]
| | | |<>--{1..*}-[System]
| | | |<>--{0..*}-[AdditionalData]
| | | |<>--{0..*}-[Platform]
| | |<>--{0..*}-[Expectation]
| | |<>--{0..1}-[Record]
| | |<>--{1..*}-[RecordData]
| | |<>--{1..*}-[RecordItem]
| | |<>--{0..*}-[EventReport]
| |<>--{0..1}-[History]
| |<>--{0..*}-[AdditionalData]
| | |<>--{0..*}-[Verification]
| | |<>--{0..*}-[Remediation]
+---------------+
Figure 1: Incident Class
<span class="grey">Takahashi, et al. Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc7203">RFC 7203</a> IODEF-SCI April 2014</span>
<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>. Basic Structure of the Extension Classes</span>
Figure 2 shows the basic structure of the extension classes. Some of
the extension classes have extra elements as defined in <a href="#section-4.5">Section 4.5</a>,
but the basic structure is the same.
+---------------------+
| New Class Name |
+---------------------+
| ENUM SpecID |<>--(0..*)-[ RawData ]
| STRING ext-SpecID |<>--(0..*)-[ Reference ]
| STRING ContentID |
+---------------------+
Figure 2: Basic Structure
Three attributes are defined as indicated below:
SpecID: REQUIRED. ENUM. A specification's identifier that
specifies the format of structured information. The value should
be chosen from the namespaces [<a href="#ref-XMLNames">XMLNames</a>] listed in the IANA table
(<a href="#section-4.1">Section 4.1</a>) or "private". The value "private" is prepared for
conveying structured information based on a format that is not
listed in the table. This is usually used for conveying data
formatted according to an organization's private schema. When the
value "private" is used, ext-SpecID element MUST be used.
ext-SpecID: OPTIONAL. STRING. A specification's identifier that
specifies the format of structured information. This is usually
used to support a private schema that is not listed in the IANA
table (<a href="#section-4.1">Section 4.1</a>). This attribute MUST be used only when the
value of the SpecID element is "private."
ContentID: OPTIONAL. STRING. An identifier of structured
information. Depending on the extension classes, the content of
the structured information differs. This attribute enables IODEF
documents to convey the identifier of the structured information
instead of conveying the information itself.
Likewise, two elements are defined as indicated below:
RawData: Zero or more. XMLDATA. An XML document of structured
information. This is a complete document that is formatted
according to the specification and its version identified by the
SpecID/ext-SpecID. When this element is used, writers/senders
MUST ensure that the namespace specified by SpecID/ext-SpecID and
<span class="grey">Takahashi, et al. Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc7203">RFC 7203</a> IODEF-SCI April 2014</span>
the schema of the XML are consistent; if not, the namespace
identified by SpecID SHOULD be preferred, and the inconsistency
SHOULD be logged so a human can correct the problem.
Reference: Zero or more of iodef:Reference [<a href="./rfc5070" title=""The Incident Object Description Exchange Format"">RFC5070</a>]. A reference
to structured information. This element allows an IODEF document
to include a link to structured information instead of directly
embedding it into a RawData element.
Though ContentID is an optional attribute, and RawData and Reference
are optional elements, one of them MUST be used to convey structured
information. Note that, in order to avoid confusing the receiver,
only one of them SHOULD be used.
<span class="h3"><a class="selflink" id="section-4.5" href="#section-4.5">4.5</a>. Defining Extension Classes</span>
This document defines eight extension classes, as described in the
subsections that follow.
<span class="h4"><a class="selflink" id="section-4.5.1" href="#section-4.5.1">4.5.1</a>. AttackPattern</span>
An AttackPattern is an extension class to the
Incident.Method.AdditionalData element with a dtype of "xml". It
describes attack patterns of incidents or events. It is RECOMMENDED
that the Method class [<a href="./rfc5070" title=""The Incident Object Description Exchange Format"">RFC5070</a>] contain the extension elements
whenever available. An AttackPattern class is structured as follows:
+---------------------+
| AttackPattern |
+---------------------+
| ENUM SpecID |<>--(0..*)-[ RawData ]
| STRING ext-SpecID |<>--(0..*)-[ Reference ]
| STRING ContentID |<>--(0..*)-[ Platform ]
+---------------------+
Figure 3: AttackPattern Class
This class has the following attributes:
SpecID: REQUIRED. ENUM. See <a href="#section-4.4">Section 4.4</a>.
ext-SpecID: OPTIONAL. STRING. See <a href="#section-4.4">Section 4.4</a>.
ContentID: OPTIONAL. STRING. An identifier of attack pattern
information. See <a href="#section-4.4">Section 4.4</a>.
<span class="grey">Takahashi, et al. Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc7203">RFC 7203</a> IODEF-SCI April 2014</span>
Likewise, this class has the following elements:
RawData: Zero or more. XMLDATA. An XML document of attack pattern
information. See <a href="#section-4.4">Section 4.4</a>.
Reference: Zero or more. A reference to attack pattern information.
See <a href="#section-4.4">Section 4.4</a>.
Platform: Zero or more. An identifier of the software platform
involved in the specific attack pattern. See <a href="#section-4.5.2">Section 4.5.2</a>.
<span class="h4"><a class="selflink" id="section-4.5.2" href="#section-4.5.2">4.5.2</a>. Platform</span>
A Platform is an extension class that identifies a software platform.
It is RECOMMENDED that the AttackPattern, Vulnerability, Weakness,
and System [<a href="./rfc5070" title=""The Incident Object Description Exchange Format"">RFC5070</a>] classes contain the extension elements whenever
available. A Platform element is structured as follows:
+---------------------+
| Platform |
+---------------------+
| ENUM SpecID |<>--(0..*)-[ RawData ]
| STRING ext-SpecID |<>--(0..*)-[ Reference ]
| STRING ContentID |
+---------------------+
Figure 4: Platform Class
This class has the following attributes:
SpecID: REQUIRED. ENUM. See <a href="#section-4.4">Section 4.4</a>.
ext-SpecID: OPTIONAL. STRING. See <a href="#section-4.4">Section 4.4</a>.
ContentID: OPTIONAL. STRING. An identifier of platform
information. See <a href="#section-4.4">Section 4.4</a>.
Likewise, this class has the following elements:
RawData: Zero or more. XMLDATA. An XML document of platform
information. See <a href="#section-4.4">Section 4.4</a>.
Reference: Zero or more. A reference to platform information. See
<a href="#section-4.4">Section 4.4</a>.
<span class="grey">Takahashi, et al. Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc7203">RFC 7203</a> IODEF-SCI April 2014</span>
<span class="h4"><a class="selflink" id="section-4.5.3" href="#section-4.5.3">4.5.3</a>. Vulnerability</span>
A Vulnerability is an extension class to the
Incident.Method.AdditionalData element with a dtype of "xml". The
extension describes the vulnerabilities that are exposed or were
exploited in incidents. It is RECOMMENDED that the Method class
contain the extension elements whenever available. A Vulnerability
element is structured as follows:
+---------------------+
| Vulnerability |
+---------------------+
| ENUM SpecID |<>--(0..*)-[ RawData ]
| STRING ext-SpecID |<>--(0..*)-[ Reference ]
| STRING ContentID |<>--(0..*)-[ Platform ]
| |<>--(0..*)-[ Scoring ]
+---------------------+
Figure 5: Vulnerability Class
This class has the following attributes:
SpecID: REQUIRED. ENUM. See <a href="#section-4.4">Section 4.4</a>.
ext-SpecID: OPTIONAL. STRING. See <a href="#section-4.4">Section 4.4</a>.
ContentID: OPTIONAL. STRING. An identifier of vulnerability
information. See <a href="#section-4.4">Section 4.4</a>.
Likewise, this class has the following elements:
RawData: Zero or more. XMLDATA. An XML document of vulnerability
information. See <a href="#section-4.4">Section 4.4</a>.
Reference: Zero or more. A reference to vulnerability information.
See <a href="#section-4.4">Section 4.4</a>.
Platform: Zero or more. An identifier of the software platform
affected by the vulnerability. See <a href="#section-4.5.2">Section 4.5.2</a>.
Scoring: Zero or more. An indicator of the severity of the
vulnerability. See <a href="#section-4.5.4">Section 4.5.4</a>.
<span class="h4"><a class="selflink" id="section-4.5.4" href="#section-4.5.4">4.5.4</a>. Scoring</span>
A Scoring is an extension class that describes the severity scores in
terms of security. It is RECOMMENDED that the Vulnerability and
Weakness classes contain the extension elements whenever available.
<span class="grey">Takahashi, et al. Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc7203">RFC 7203</a> IODEF-SCI April 2014</span>
A Scoring class is structured as follows:
+---------------------+
| Scoring |
+---------------------+
| ENUM SpecID |<>--(0..*)-[ RawData ]
| STRING ext-SpecID |<>--(0..*)-[ Reference ]
| STRING ContentID |
+---------------------+
Figure 6: Scoring Class
This class has the following attributes:
SpecID: REQUIRED. ENUM. See <a href="#section-4.4">Section 4.4</a>.
ext-SpecID: OPTIONAL. STRING. See <a href="#section-4.4">Section 4.4</a>.
ContentID: OPTIONAL. STRING. An identifier of a score set. See
<a href="#section-4.4">Section 4.4</a>.
Likewise, this class has the following elements:
RawData: Zero or more. XMLDATA. An XML document of a score set.
See <a href="#section-4.4">Section 4.4</a>.
Reference: Zero or more. A reference to a score set. See
<a href="#section-4.4">Section 4.4</a>.
<span class="h4"><a class="selflink" id="section-4.5.5" href="#section-4.5.5">4.5.5</a>. Weakness</span>
A Weakness is an extension class to the
Incident.Method.AdditionalData element with a dtype of "xml". The
extension describes the weakness types that are exposed or were
exploited in incidents. It is RECOMMENDED that the Method class
contain the extension elements whenever available. A Weakness
element is structured as follows:
+---------------------+
| Weakness |
+---------------------+
| ENUM SpecID |<>--(0..*)-[ RawData ]
| STRING ext-SpecID |<>--(0..*)-[ Reference ]
| STRING ContentID |<>--(0..*)-[ Platform ]
| |<>--(0..*)-[ Scoring ]
+---------------------+
Figure 7: Weakness Class
<span class="grey">Takahashi, et al. Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc7203">RFC 7203</a> IODEF-SCI April 2014</span>
This class has the following attributes:
SpecID: REQUIRED. ENUM. See <a href="#section-4.4">Section 4.4</a>.
ext-SpecID: OPTIONAL. STRING. See <a href="#section-4.4">Section 4.4</a>.
ContentID: OPTIONAL. STRING. An identifier of weakness
information. See <a href="#section-4.4">Section 4.4</a>.
Likewise, this class has the following elements:
RawData: Zero or more. XMLDATA. An XML document of weakness
information. See <a href="#section-4.4">Section 4.4</a>.
Reference: Zero or more. A reference to weakness information. See
<a href="#section-4.4">Section 4.4</a>.
Platform: Zero or more. An identifier of the software platform
affected by the weakness. See <a href="#section-4.5.2">Section 4.5.2</a>.
Scoring: Zero or more. An indicator of the severity of the
weakness. See <a href="#section-4.5.4">Section 4.5.4</a>.
<span class="h4"><a class="selflink" id="section-4.5.6" href="#section-4.5.6">4.5.6</a>. EventReport</span>
An EventReport is an extension class to the
Incident.EventData.Record.RecordData.RecordItem element with a dtype
of "xml". The extension embeds structured event reports. It is
RECOMMENDED that the RecordItem class contain the extension elements
whenever available. An EventReport element is structured as follows:
+---------------------+
| EventReport |
+---------------------+
| ENUM SpecID |<>--(0..*)-[ RawData ]
| STRING ext-SpecID |<>--(0..*)-[ Reference ]
| STRING ContentID |
+---------------------+
Figure 8: EventReport Class
This class has the following attributes:
SpecID: REQUIRED. ENUM. See <a href="#section-4.4">Section 4.4</a>.
ext-SpecID: OPTIONAL. STRING. See <a href="#section-4.4">Section 4.4</a>.
<span class="grey">Takahashi, et al. Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc7203">RFC 7203</a> IODEF-SCI April 2014</span>
ContentID: OPTIONAL. STRING. An identifier of an event report.
See <a href="#section-4.4">Section 4.4</a>.
Likewise, this class has the following elements:
RawData: Zero or more. XMLDATA. An XML document of an event
report. See <a href="#section-4.4">Section 4.4</a>.
Reference: Zero or more. A reference to an event report. See
<a href="#section-4.4">Section 4.4</a>.
<span class="h4"><a class="selflink" id="section-4.5.7" href="#section-4.5.7">4.5.7</a>. Verification</span>
A Verification is an extension class to the Incident.AdditionalData
element with a dtype of "xml". The extension elements describe
information on verifying security, e.g., a checklist, to cope with
incidents. It is RECOMMENDED that the Incident class contain the
extension elements whenever available. A Verification class is
structured as follows:
+---------------------+
| Verification |
+---------------------+
| ENUM SpecID |<>--(0..*)-[ RawData ]
| STRING ext-SpecID |<>--(0..*)-[ Reference ]
| STRING ContentID |
+---------------------+
Figure 9: Verification Class
This class has the following attributes:
SpecID: REQUIRED. ENUM. See <a href="#section-4.4">Section 4.4</a>.
ext-SpecID: OPTIONAL. STRING. See <a href="#section-4.4">Section 4.4</a>.
ContentID: OPTIONAL. STRING. An identifier of verification
information. See <a href="#section-4.4">Section 4.4</a>.
Likewise, this class has the following elements:
RawData: Zero or more. XMLDATA. An XML document of verification
information. See <a href="#section-4.4">Section 4.4</a>.
Reference: Zero or more. A reference to verification information.
See <a href="#section-4.4">Section 4.4</a>.
<span class="grey">Takahashi, et al. Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc7203">RFC 7203</a> IODEF-SCI April 2014</span>
<span class="h4"><a class="selflink" id="section-4.5.8" href="#section-4.5.8">4.5.8</a>. Remediation</span>
A Remediation is an extension class to the Incident.AdditionalData
element with a dtype of "xml". The extension elements describe
incident remediation information, including instructions. It is
RECOMMENDED that the Incident class contain the extension elements
whenever available. A Remediation class is structured as follows:
+---------------------+
| Remediation |
+---------------------+
| ENUM SpecID |<>--(0..*)-[ RawData ]
| STRING ext-SpecID |<>--(0..*)-[ Reference ]
| String ContentID |
+---------------------+
Figure 10: Remediation Class
This class has the following attributes:
SpecID: REQUIRED. ENUM. See <a href="#section-4.4">Section 4.4</a>.
ext-SpecID: OPTIONAL. STRING. See <a href="#section-4.4">Section 4.4</a>.
ContentID: OPTIONAL. STRING. An identifier of remediation
information. See <a href="#section-4.4">Section 4.4</a>.
Likewise, this class has the following elements:
RawData: Zero or more. XMLDATA. An XML document of remediation
information. See <a href="#section-4.4">Section 4.4</a>.
Reference: Zero or more. A reference to remediation information.
See <a href="#section-4.4">Section 4.4</a>.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Mandatory-to-Implement Features</span>
Implementations compliant with this document MUST be capable of
sending and receiving the extended IODEF documents that contain XML
documents conforming to the specification listed in the initial IANA
table described in <a href="#section-4.1">Section 4.1</a> without error. The extended IODEF
document is an XML document that MUST be well-formed and MUST be
valid according to schemata, including extension schemata, available
to the validator and applicable to the XML document. Note that the
receiver can look up the namespace in the IANA table to understand
what specifications the embedded XML documents follow.
<span class="grey">Takahashi, et al. Standards Track [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc7203">RFC 7203</a> IODEF-SCI April 2014</span>
For the purpose of facilitating the understanding of mandatory-to-
implement features, the following subsections provide an XML document
conformant to this memo, and a corresponding schema.
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. An Example XML Document</span>
An example IODEF document for checking an implementation's conformity
with mandatory-to-implement features is provided here. The document
carries Malware Metadata Exchange Format (MMDEF) metadata. Note that
the metadata is generated by genMMDEF [<a href="#ref-MMDEF" title=""Malware Metadata Exchange Format"">MMDEF</a>] with EICAR [<a href="#ref-EICAR" title=""Anti-Malware Testfile"">EICAR</a>]
files. Due to the limit of 72 characters per line, some line breaks
were added in this example.
<?xml version="1.0" encoding="UTF-8"?>
<IODEF-Document version="1.00" lang="en"
xmlns="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:sci="urn:ietf:params:xml:ns:iodef-sci-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Incident purpose="reporting">
<IncidentID name="sci.example.com">189493</IncidentID>
<ReportTime>2013-06-18T23:19:24+00:00</ReportTime>
<Description>a candidate security incident</Description>
<Assessment>
<Impact completion="failed" type="admin" />
</Assessment>
<Method>
<Description>A candidate attack event</Description>
<AdditionalData dtype="xml">
<sci:AttackPattern SpecID=
"urn:ietf:params:xml:ns:mile:mmdef:1.2">
<sci:RawData dtype="xml">
<malwareMetaData xmlns="http://xml/metadataSharing.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xml/metadataSharing.xsd
file:metadataSharing.xsd" version="1.200000" id="10000">
<company>N/A</company>
<author>MMDEF Generation Script</author>
<comment>Test MMDEF v1.2 file generated using genMMDEF
</comment>
<timestamp>2013-03-23T15:12:50.726000</timestamp>
<objects>
<file id="6ce6f415d8475545be5ba114f208b0ff">
<md5>6ce6f415d8475545be5ba114f208b0ff</md5>
<sha1>da39a3ee5e6b4b0d3255bfef95601890afd80709</sha1>
<sha256>e3b0c44298fc1c149afbf4c8996fb92427ae41e464
9b934ca495991b7852b855</sha256>
<span class="grey">Takahashi, et al. Standards Track [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc7203">RFC 7203</a> IODEF-SCI April 2014</span>
<sha512>cf83e1357eefb8bdf1542850d66d8007d620e4050b
5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff83
18d2877eec2f63b931bd47417a81a538327af927
da3e</sha512>
<size>184</size>
<filename>eicar_com.zip</filename>
<MIMEType>application/zip</MIMEType>
</file>
<file id="44d88612fea8a8f36de82e1278abb02f">
<md5>44d88612fea8a8f36de82e1278abb02f</md5>
<sha1>3395856ce81f2b7382dee72602f798b642f14140</sha1>
<sha256>275a021bbfb6489e54d471899f7db9d1663fc695ec
2fe2a2c4538aabf651fd0f</sha256>
<sha512>cc805d5fab1fd71a4ab352a9c533e65fb2d5b88551
8f4e565e68847223b8e6b85cb48f3afad842726d99
239c9e36505c64b0dc9a061d9e507d833277ada3
36ab</sha512>
<size>68</size>
<crc32>1750191932</crc32>
<filename>eicar.com</filename>
<filenameWithinInstaller>eicar.com
</filenameWithinInstaller>
</file>
</objects>
<relationships>
<relationship type="createdBy" id="1">
<source>
<ref>file[@id="6ce6f415d8475545be5ba114f208b0ff"]
</ref>
</source>
<target>
<ref>file[@id="44d88612fea8a8f36de82e1278abb02f"]
</ref>
</target>
<timestamp>2013-03-23T15:12:50.744000</timestamp>
</relationship>
</relationships>
</malwareMetaData>
</sci:RawData>
</sci:AttackPattern>
</AdditionalData>
</Method>
<Contact role="creator" type="organization">
<ContactName>sci.example.com</ContactName>
<RegistryHandle registry="arin">sci.example-com
</RegistryHandle>
<Email>contact@csirt.example.com</Email>
</Contact>
<span class="grey">Takahashi, et al. Standards Track [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc7203">RFC 7203</a> IODEF-SCI April 2014</span>
<EventData>
<Flow>
<System category="source">
<Node>
<Address category="ipv4-addr">192.0.2.200</Address>
<Counter type="event">57</Counter>
</Node>
</System>
<System category="target">
<Node>
<Address category="ipv4-net">192.0.2.16/28</Address>
</Node>
<Service ip_protocol="4">
<Port>80</Port>
</Service>
</System>
</Flow>
<Expectation action="block-host" />
<Expectation action="other" />
</EventData>
</Incident>
</IODEF-Document>
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. An XML Schema for the Extension</span>
An XML schema describing the elements defined in this document is
given here.
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema targetNamespace="urn:ietf:params:xml:ns:iodef-sci-1.0"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:sci="urn:ietf:params:xml:ns:iodef-sci-1.0"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xsd:import namespace="urn:ietf:params:xml:ns:iodef-1.0" schemaLocation=
"<a href="http://www.iana.org/assignments/xml-registry/schema/iodef-1.0.xsd">http://www.iana.org/assignments/xml-registry/schema/iodef-1.0.xsd</a>"/>
<xsd:complexType name="XMLDATA">
<xsd:complexContent>
<xsd:restriction base="iodef:ExtensionType">
<xsd:sequence>
<xsd:any namespace="##any" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="dtype" type="iodef:dtype-type"
use="required" fixed="xml"/>
<span class="grey">Takahashi, et al. Standards Track [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc7203">RFC 7203</a> IODEF-SCI April 2014</span>
<xsd:attribute name="ext-dtype" type="xsd:string"
use="prohibited"/>
<xsd:attribute name="meaning" type="xsd:string"/>
<xsd:attribute name="formatid" type="xsd:string"/>
<xsd:attribute name="restriction" type="iodef:restriction-type"/>
</xsd:restriction>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="BasicStructure">
<xsd:sequence>
<xsd:choice>
<xsd:element name="RawData" type="sci:XMLDATA"
minOccurs="0" maxOccurs="unbounded"/>
<xsd:element ref="iodef:Reference" minOccurs="0"
maxOccurs="unbounded"/>
</xsd:choice>
</xsd:sequence>
<xsd:attribute name="SpecID" type="xsd:string" use="required"/>
<xsd:attribute name="ext-SpecID" type="xsd:string"/>
<xsd:attribute name="ContentID" type="xsd:string"/>
</xsd:complexType>
<xsd:element name="Scoring" type="sci:BasicStructure"/>
<xsd:element name="Platform" type="sci:BasicStructure"/>
<xsd:element name="EventReport" type="sci:BasicStructure"/>
<xsd:element name="Verification" type="sci:BasicStructure"/>
<xsd:element name="Remediation" type="sci:BasicStructure"/>
<xsd:element name="AttackPattern">
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="sci:BasicStructure">
<sequence>
<xsd:element ref="sci:Platform" minOccurs="0"
maxOccurs="unbounded"/>
</sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
<xsd:element name="Vulnerability">
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="sci:BasicStructure">
<sequence>
<xsd:element ref="sci:Platform" minOccurs="0"
maxOccurs="unbounded"/>
<xsd:element ref="sci:Scoring" minOccurs="0"
maxOccurs="unbounded"/>
<span class="grey">Takahashi, et al. Standards Track [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc7203">RFC 7203</a> IODEF-SCI April 2014</span>
</sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
<xsd:element name="Weakness">
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="sci:BasicStructure">
<sequence>
<xsd:element ref="sci:Platform" minOccurs="0"
maxOccurs="unbounded"/>
<xsd:element ref="sci:Scoring" minOccurs="0"
maxOccurs="unbounded"/>
</sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
</xsd:schema>
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
This document specifies a format for encoding a particular class of
security incidents appropriate for exchange across organizations. As
merely a data representation, it does not directly introduce security
issues. However, it is guaranteed that parties exchanging instances
of this specification will have certain concerns. For this reason,
the underlying message format and transport protocol used MUST ensure
the appropriate degree of confidentiality, integrity, and
authenticity for the specific environment. Specific security
considerations are detailed in the messaging and transport documents,
where the exchange of formatted information is automated; see
Sections <a href="#section-9">9</a> and <a href="#section-10">10</a> of "Real-time Inter-network Defense (RID)"
[<a href="./rfc6545" title=""Real-time Inter-network Defense (RID)"">RFC6545</a>] and <a href="#section-4">Section 4</a> of "Transport of Real-time Inter-network
Defense (RID) Messages over HTTP/TLS" [<a href="./rfc6546" title=""Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS"">RFC6546</a>] for a detailed
overview of security requirements and considerations.
It is RECOMMENDED that organizations that exchange data using this
document develop operating procedures that consider, at a minimum,
the following areas of concern.
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Transport-Specific Concerns</span>
The underlying messaging format, IODEF, provides data markers to
indicate the sensitivity level of specific classes within the
structure as well as for the entire XML document. The "restriction"
<span class="grey">Takahashi, et al. Standards Track [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc7203">RFC 7203</a> IODEF-SCI April 2014</span>
attribute accomplishes this with four attribute values in IODEF
[<a href="./rfc5070" title=""The Incident Object Description Exchange Format"">RFC5070</a>]. These values are RECOMMENDED for use at the application
level, prior to transport, to protect data as appropriate. A
standard mechanism to apply XML encryption using these attribute
values as triggers is defined in RID <a href="./rfc6545#section-9.1">[RFC6545], Section 9.1</a>. This
mechanism may be used whether or not the RID protocol [<a href="./rfc6545" title=""Real-time Inter-network Defense (RID)"">RFC6545</a>] and
its associated transport binding [<a href="./rfc6546" title=""Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS"">RFC6546</a>] are used in the exchange
to provide object-level security on the data to prevent possible
intermediary systems or middleboxes from having access to the data
being exchanged. In areas where transmission security or secrecy is
questionable, the application of an XML digital signature [<a href="#ref-XMLDSIG" title=""XML Signature Syntax and Processing (Second Edition)"">XMLDSIG</a>]
and/or encryption on each report will counteract both of these
concerns. The data markers are RECOMMENDED for use by applications
for managing access controls; however, access controls and management
of those controls are out of scope for this document. Options such
as the usage of a standard language (e.g., eXtensible Access Control
Markup Language [<a href="#ref-XACML" title=""eXtensible Access Control Markup Language (XACML) Version 3.0"">XACML</a>]) for the expression of authorization policies
can be used to enable source and destination systems to better
coordinate and align their respective policy expressions.
Any transport protocol used to exchange instances of IODEF documents
MUST provide appropriate guarantees of confidentiality, integrity,
and authenticity. The use of a standardized security protocol is
encouraged. The RID protocol [<a href="./rfc6545" title=""Real-time Inter-network Defense (RID)"">RFC6545</a>] and its associated transport
binding [<a href="./rfc6546" title=""Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS"">RFC6546</a>] provide such security with options for mutual
authentication session encryption and include application-level
concerns such as policy and workflow.
The critical security concerns are that structured information may be
falsified, accessed by unintended entities, or become corrupt during
transit. We expect that each exchanging organization will determine
the need, and mechanism, for transport protection.
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Protection of Sensitive and Private Information</span>
For a complete review of privacy considerations when transporting
incident-related information, please see RID <a href="./rfc6545#section-9.5">[RFC6545], Section 9.5</a>.
Whether or not the RID protocol is used, the privacy considerations
are important to consider, as incident information is often sensitive
and may contain privacy-related information about individuals/
organizations or endpoints involved. Organizations will often
require the establishment of legal reviews and formal policies that
outline specific details of what information can be exchanged with
specific entities. Typically, identifying information is anonymized
where possible and appropriate. In some cases, information brokers
are used to further anonymize the source of exchanged information so
that other entities are unaware of the origin of a detected threat,
whether or not that threat was realized.
<span class="grey">Takahashi, et al. Standards Track [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc7203">RFC 7203</a> IODEF-SCI April 2014</span>
It is RECOMMENDED that policies and procedures for the exchange of
cybersecurity information be established prior to participation in
data exchanges. Policy and workflow procedures for the exchange of
cybersecurity information often require executive-level approvals and
legal reviews to appropriately establish limits on what information
can be exchanged with specific organizations. RID <a href="./rfc6545#section-9.6">[RFC6545],
Section 9.6</a> outlines options and considerations for application
developers to consider for policy and workflow design.
<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>. Application and Server Security</span>
The cybersecurity information extension is merely a data format.
Applications and transport protocols that store or exchange IODEF
documents using information that can be represented through this
extension will be a target for attacks. It is RECOMMENDED that
systems and applications storing or exchanging this information be
properly secured, have minimal services enabled, and maintain access
controls and monitoring procedures.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. IANA Considerations</span>
This document uses URNs to describe XML namespaces and XML schemata
[<a href="#ref-XMLschemaPart1">XMLschemaPart1</a>] [<a href="#ref-XMLschemaPart2">XMLschemaPart2</a>] conforming to a registry mechanism
described in [<a href="./rfc3688" title=""The IETF XML Registry"">RFC3688</a>].
The following IODEF structured cybersecurity information extension
namespace has been registered:
URI: urn:ietf:params:xml:ns:iodef-sci-1.0
Registrant Contact: Refer to the Authors' Addresses section of
this document.
XML: None.
The following IODEF structured cybersecurity information extension
XML schema has been registered:
URI: urn:ietf:params:xml:schema:iodef-sci-1.0
Registrant Contact: Refer to the Authors' Addresses section of
this document.
XML: Refer to the XML schema in <a href="#section-5.2">Section 5.2</a> of this document.
<span class="grey">Takahashi, et al. Standards Track [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc7203">RFC 7203</a> IODEF-SCI April 2014</span>
This memo creates the following registry, which is managed by IANA:
Name of the registry: "Structured Cybersecurity Information (SCI)
Specifications"
Name of its parent registry: "Incident Object Description Exchange
Format (IODEF)"
URL of the registry: <<a href="http://www.iana.org/assignments/iodef">http://www.iana.org/assignments/iodef</a>>
Namespace details: A registry entry for a Structured Cybersecurity
Information Specification (SCI specification) consists of:
Namespace: A URI [<a href="./rfc3986" title=""Uniform Resource Identifier (URI): Generic Syntax"">RFC3986</a>] that identifies the XML namespace
used by the registered SCI specification. In the case where
the registrant does not request a particular URI, the IANA will
assign it a Uniform Resource Name (URN) that follows <a href="./rfc3553">RFC 3553</a>
[<a href="./rfc3553" title=""An IETF URN Sub-namespace for Registered Protocol Parameters"">RFC3553</a>].
Specification Name: A string containing the spelled-out name of
the SCI specification in human-readable form.
Reference URI: A list of one or more of the URIs [<a href="./rfc3986" title=""Uniform Resource Identifier (URI): Generic Syntax"">RFC3986</a>] from
which the registered specification can be obtained. The
registered specification MUST be readily and publicly available
from that URI.
Applicable Classes: A list of one or more of the extension
classes specified in <a href="#section-4.5">Section 4.5</a> of this document. The
registered SCI specification MUST only be used with the
extension classes in the registry entry.
Information that must be provided to assign a new value: The above
list of information.
Fields to record in the registry: Namespace/Specification Name/
Version/Reference URI/Applicable Classes. Note that it is not
necessary to include a defining reference for all assignments in
this new registry.
Initial registry contents: Only one entry, with the following
values:
Namespace: urn:ietf:params:xml:ns:mile:mmdef:1.2
Specification Name: Malware Metadata Exchange Format
Version: 1.2
<span class="grey">Takahashi, et al. Standards Track [Page 23]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
<span class="grey"><a href="./rfc7203">RFC 7203</a> IODEF-SCI April 2014</span>
Reference URI:
<<a href="http://standards.ieee.org/develop/indconn/icsg/mmdef.html">http://standards.ieee.org/develop/indconn/icsg/mmdef.html</a>>,
<<a href="http://grouper.ieee.org/groups/malware/malwg/Schema1.2/">http://grouper.ieee.org/groups/malware/malwg/Schema1.2/</a>>
Applicable Classes: AttackPattern
Allocation policy: Specification Required (which includes Expert
Review) [<a href="./rfc5226" title="">RFC5226</a>].
The Designated Expert is expected to consult with the MILE (Managed
Incident Lightweight Exchange) working group, or its successor if any
such working group exists (e.g., via email to the working group's
mailing list). The Designated Expert is expected to retrieve the SCI
specification from the provided URI in order to check the public
availability of the specification and verify the correctness of the
URI. An important responsibility of the Designated Expert is to
ensure that the registered applicable classes are appropriate for the
registered SCI specification.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Acknowledgments</span>
We would like to acknowledge David Black from EMC, who kindly
provided generous support, especially on the IANA registry issues.
We also would like to thank Jon Baker from MITRE, Eric Burger from
Georgetown University, Paul Cichonski from NIST, Panos Kampanakis
from Cisco, Ivan Kirillov from MITRE, Pearl Liang from IANA, Robert
Martin from MITRE, Alexey Melnikov from Isode, Thomas Millar from
US-CERT, Kathleen Moriarty from EMC, Lagadec Philippe from NATO, Sean
Turner from IECA, Inc., Anthony Rutkowski from Yaana Technology,
Brian Trammell from ETH Zurich, David Waltermire from NIST, James
Wendorf from IEEE, and Shuhei Yamaguchi from NICT, for their sincere
discussion and feedback on this document.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. References</span>
<span class="h3"><a class="selflink" id="section-9.1" href="#section-9.1">9.1</a>. Normative References</span>
[<a id="ref-MMDEF">MMDEF</a>] ICSG Malware Metadata Exchange Format Working Group,
"Malware Metadata Exchange Format", IEEE Standards
Association, November 2011,
<<a href="http://grouper.ieee.org/groups/malware/malwg/Schema1.2/">http://grouper.ieee.org/groups/malware/malwg/Schema1.2/</a>>.
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
<span class="grey">Takahashi, et al. Standards Track [Page 24]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-25" ></span>
<span class="grey"><a href="./rfc7203">RFC 7203</a> IODEF-SCI April 2014</span>
[<a id="ref-RFC3986">RFC3986</a>] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
<a href="./rfc3986">RFC 3986</a>, January 2005.
[<a id="ref-RFC5070">RFC5070</a>] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident
Object Description Exchange Format", <a href="./rfc5070">RFC 5070</a>,
December 2007.
[<a id="ref-RFC5226">RFC5226</a>] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", <a href="https://www.rfc-editor.org/bcp/bcp26">BCP 26</a>, <a href="./rfc5226">RFC 5226</a>,
May 2008.
[<a id="ref-RFC6545">RFC6545</a>] Moriarty, K., "Real-time Inter-network Defense (RID)",
<a href="./rfc6545">RFC 6545</a>, April 2012.
[<a id="ref-RFC6546">RFC6546</a>] Trammell, B., "Transport of Real-time Inter-network
Defense (RID) Messages over HTTP/TLS", <a href="./rfc6546">RFC 6546</a>,
April 2012.
[<a id="ref-XML1.0">XML1.0</a>] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and
F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth
Edition)", W3C Recommendation, November 2008,
<<a href="http://www.w3.org/TR/xml/">http://www.w3.org/TR/xml/</a>>.
[<a id="ref-XMLschemaPart1">XMLschemaPart1</a>]
Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn,
"XML Schema Part 1: Structures Second Edition", W3C
Recommendation, October 2004,
<<a href="http://www.w3.org/TR/xmlschema-1/">http://www.w3.org/TR/xmlschema-1/</a>>.
[<a id="ref-XMLschemaPart2">XMLschemaPart2</a>]
Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes
Second Edition", W3C Recommendation, October 2004,
<<a href="http://www.w3.org/TR/xmlschema-2/">http://www.w3.org/TR/xmlschema-2/</a>>.
[<a id="ref-XMLNames">XMLNames</a>]
Bray, T., Hollander, D., Layman, A., Tobin, R., and H.
Thompson, "Namespaces in XML 1.0 (Third Edition)", W3C
Recommendation, December 2009,
<<a href="http://www.w3.org/TR/xml-names/">http://www.w3.org/TR/xml-names/</a>>.
<span class="grey">Takahashi, et al. Standards Track [Page 25]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-26" ></span>
<span class="grey"><a href="./rfc7203">RFC 7203</a> IODEF-SCI April 2014</span>
<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>. Informative References</span>
[<a id="ref-RFC3553">RFC3553</a>] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An
IETF URN Sub-namespace for Registered Protocol
Parameters", <a href="https://www.rfc-editor.org/bcp/bcp73">BCP 73</a>, <a href="./rfc3553">RFC 3553</a>, June 2003.
[<a id="ref-RFC3688">RFC3688</a>] Mealling, M., "The IETF XML Registry", <a href="https://www.rfc-editor.org/bcp/bcp81">BCP 81</a>, <a href="./rfc3688">RFC 3688</a>,
January 2004.
[<a id="ref-CAPEC">CAPEC</a>] The MITRE Corporation, "Common Attack Pattern Enumeration
and Classification (CAPEC)", <<a href="http://capec.mitre.org/">http://capec.mitre.org/</a>>.
[<a id="ref-CCE">CCE</a>] National Institute of Standards and Technology, "Common
Configuration Enumeration (CCE)",
<<a href="http://nvd.nist.gov/cce/index.cfm">http://nvd.nist.gov/cce/index.cfm</a>>.
[<a id="ref-CCSS">CCSS</a>] Scarfone, K. and P. Mell, "The Common Configuration
Scoring System (CCSS): Metrics for Software Security
Configuration Vulnerabilities", NIST Interagency
Report 7502, December 2010, <<a href="http://csrc.nist.gov/publications/nistir/ir7502/nistir-7502_CCSS.pdf">http://csrc.nist.gov/</a>
<a href="http://csrc.nist.gov/publications/nistir/ir7502/nistir-7502_CCSS.pdf">publications/nistir/ir7502/nistir-7502_CCSS.pdf</a>>.
[<a id="ref-CEE">CEE</a>] The MITRE Corporation, "Common Event Expression (CEE)",
<<a href="http://cee.mitre.org/">http://cee.mitre.org/</a>>.
[<a id="ref-CPE">CPE</a>] National Institute of Standards and Technology, "Common
Platform Enumeration", June 2011,
<<a href="http://scap.nist.gov/specifications/cpe/">http://scap.nist.gov/specifications/cpe/</a>>.
[<a id="ref-CVE">CVE</a>] The MITRE Corporation, "Common Vulnerabilities and
Exposures (CVE)", <<a href="http://cve.mitre.org/">http://cve.mitre.org/</a>>.
[<a id="ref-CVRF">CVRF</a>] ICASI, "The Common Vulnerability Reporting Framework
(CVRF)", <<a href="http://www.icasi.org/cvrf">http://www.icasi.org/cvrf</a>>.
[<a id="ref-CVSS">CVSS</a>] Mell, P., Scarfone, K., and S. Romanosky, "The Common
Vulnerability Scoring System (CVSS) and Its Applicability
to Federal Agency Systems", NIST Interagency Report 7435,
August 2007, <<a href="http://csrc.nist.gov/publications/nistir/ir7435/NISTIR-7435.pdf">http://csrc.nist.gov/publications/nistir/</a>
<a href="http://csrc.nist.gov/publications/nistir/ir7435/NISTIR-7435.pdf">ir7435/NISTIR-7435.pdf</a>>.
[<a id="ref-CWE">CWE</a>] The MITRE Corporation, "Common Weakness Enumeration
(CWE)", <<a href="http://cwe.mitre.org/">http://cwe.mitre.org/</a>>.
[<a id="ref-CWSS">CWSS</a>] The MITRE Corporation, "Common Weakness Scoring System
(CWSS(TM))", <<a href="http://cwe.mitre.org/cwss/">http://cwe.mitre.org/cwss/</a>>.
<span class="grey">Takahashi, et al. Standards Track [Page 26]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-27" ></span>
<span class="grey"><a href="./rfc7203">RFC 7203</a> IODEF-SCI April 2014</span>
[<a id="ref-EICAR">EICAR</a>] EICAR - European Expert Group for IT-Security,
"Anti-Malware Testfile", 2003,
<<a href="http://www.eicar.org/86-0-Intended-use.html">http://www.eicar.org/86-0-Intended-use.html</a>>.
[<a id="ref-MAEC">MAEC</a>] The MITRE Corporation, "Malware Attribute Enumeration and
Characterization", <<a href="http://maec.mitre.org/">http://maec.mitre.org/</a>>.
[<a id="ref-OCIL">OCIL</a>] Waltermire, D., Scarfone, K., and M. Casipe,
"Specification for the Open Checklist Interactive Language
(OCIL) Version 2.0", NIST Interagency Report 7692,
April 2011, <<a href="http://csrc.nist.gov/publications/nistir/ir7692/nistir-7692.pdf">http://csrc.nist.gov/publications/nistir/</a>
<a href="http://csrc.nist.gov/publications/nistir/ir7692/nistir-7692.pdf">ir7692/nistir-7692.pdf</a>>.
[<a id="ref-OVAL">OVAL</a>] The MITRE Corporation, "Open Vulnerability and Assessment
Language (OVAL)", <<a href="http://oval.mitre.org/">http://oval.mitre.org/</a>>.
[<a id="ref-SCAP">SCAP</a>] Waltermire, D., Quinn, S., Scarfone, K., and A.
Halbardier, "The Technical Specification for the Security
Content Automation Protocol (SCAP): SCAP Version 1.2",
NIST Special Publication 800-126 Revision 2,
September 2011, <<a href="http://csrc.nist.gov/publications/nistpubs/800-126-rev2/SP800-126r2.pdf">http://csrc.nist.gov/publications/</a>
<a href="http://csrc.nist.gov/publications/nistpubs/800-126-rev2/SP800-126r2.pdf">nistpubs/800-126-rev2/SP800-126r2.pdf</a>>.
[<a id="ref-XACML">XACML</a>] Rissanen, E., "eXtensible Access Control Markup Language
(XACML) Version 3.0", January 2013,
<<a href="http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.pdf">http://docs.oasis-open.org/xacml/3.0/</a>
<a href="http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.pdf">xacml-3.0-core-spec-os-en.pdf</a>>.
[<a id="ref-XCCDF">XCCDF</a>] Waltermire, D., Schmidt, C., Scarfone, K., and N. Ziring,
"Specification for the Extensible Configuration Checklist
Description Format (XCCDF) version 1.2 (DRAFT)", NIST
Interagency Report 7275, Revision 4, September 2011,
<<a href="http://csrc.nist.gov/publications/nistir/ir7275-rev4/NISTIR-7275r4.pdf">http://csrc.nist.gov/publications/nistir/ir7275-rev4/</a>
<a href="http://csrc.nist.gov/publications/nistir/ir7275-rev4/NISTIR-7275r4.pdf">NISTIR-7275r4.pdf</a>>.
[<a id="ref-XMLDSIG">XMLDSIG</a>] W3C Recommendation, "XML Signature Syntax and Processing
(Second Edition)", June 2008,
<<a href="http://www.w3.org/TR/xmldsig-core/">http://www.w3.org/TR/xmldsig-core/</a>>.
<span class="grey">Takahashi, et al. Standards Track [Page 27]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-28" ></span>
<span class="grey"><a href="./rfc7203">RFC 7203</a> IODEF-SCI April 2014</span>
Authors' Addresses
Takeshi Takahashi
National Institute of Information and Communications Technology
4-2-1 Nukui-Kitamachi Koganei
184-8795 Tokyo
Japan
Phone: +80 423 27 5862
EMail: takeshi_takahashi@nict.go.jp
Kent Landfield
McAfee, Inc.
5000 Headquarters Drive
Plano, TX 75024
USA
EMail: Kent_Landfield@McAfee.com
Youki Kadobayashi
Nara Institute of Science and Technology
8916-5 Takayama, Ikoma
630-0192 Nara
Japan
EMail: youki-k@is.aist-nara.ac.jp
Takahashi, et al. Standards Track [Page 28]
</pre>
|
