forked from oasis-tcs/openc2-oc2ls
-
Notifications
You must be signed in to change notification settings - Fork 0
/
oc2ls.html
3988 lines (3975 loc) · 193 KB
/
oc2ls.html
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
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" lang="" xml:lang="">
<head>
<meta name="description" content="This document defines Open Command and Control (OpenC2), a concise and extensible language to enable the command and control of cyber defense components, subsystems and/or systems.">
<meta charset="utf-8" />
<meta name="generator" content="pandoc" />
<meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes" />
<title>Open Command and Control (OpenC2) Language Specification Version 1.0</title>
<style type="text/css">
code{white-space: pre-wrap;}
span.smallcaps{font-variant: small-caps;}
span.underline{text-decoration: underline;}
div.column{display: inline-block; vertical-align: top; width: 50%;}
</style>
<style type="text/css">
a.sourceLine { display: inline-block; line-height: 1.25; }
a.sourceLine { pointer-events: none; color: inherit; text-decoration: inherit; }
a.sourceLine:empty { height: 1.2em; position: absolute; }
.sourceCode { overflow: visible; }
code.sourceCode { white-space: pre; position: relative; }
div.sourceCode { margin: 1em 0; }
pre.sourceCode { margin: 0; }
@media screen {
div.sourceCode { overflow: auto; }
}
@media print {
code.sourceCode { white-space: pre-wrap; }
a.sourceLine { text-indent: -1em; padding-left: 1em; }
}
pre.numberSource a.sourceLine
{ position: relative; }
pre.numberSource a.sourceLine:empty
{ position: absolute; }
pre.numberSource a.sourceLine::before
{ content: attr(data-line-number);
position: absolute; left: -5em; text-align: right; vertical-align: baseline;
border: none; pointer-events: all;
-webkit-touch-callout: none; -webkit-user-select: none;
-khtml-user-select: none; -moz-user-select: none;
-ms-user-select: none; user-select: none;
padding: 0 4px; width: 4em;
color: #aaaaaa;
}
pre.numberSource { margin-left: 3em; border-left: 1px solid #aaaaaa; padding-left: 4px; }
div.sourceCode
{ }
@media screen {
a.sourceLine::before { text-decoration: underline; }
}
code span.al { color: #ff0000; font-weight: bold; } /* Alert */
code span.an { color: #60a0b0; font-weight: bold; font-style: italic; } /* Annotation */
code span.at { color: #7d9029; } /* Attribute */
code span.bn { color: #40a070; } /* BaseN */
code span.bu { } /* BuiltIn */
code span.cf { color: #007020; font-weight: bold; } /* ControlFlow */
code span.ch { color: #4070a0; } /* Char */
code span.cn { color: #880000; } /* Constant */
code span.co { color: #60a0b0; font-style: italic; } /* Comment */
code span.cv { color: #60a0b0; font-weight: bold; font-style: italic; } /* CommentVar */
code span.do { color: #ba2121; font-style: italic; } /* Documentation */
code span.dt { color: #902000; } /* DataType */
code span.dv { color: #40a070; } /* DecVal */
code span.er { color: #ff0000; font-weight: bold; } /* Error */
code span.ex { } /* Extension */
code span.fl { color: #40a070; } /* Float */
code span.fu { color: #06287e; } /* Function */
code span.im { } /* Import */
code span.in { color: #60a0b0; font-weight: bold; font-style: italic; } /* Information */
code span.kw { color: #007020; font-weight: bold; } /* Keyword */
code span.op { color: #666666; } /* Operator */
code span.ot { color: #007020; } /* Other */
code span.pp { color: #bc7a00; } /* Preprocessor */
code span.sc { color: #4070a0; } /* SpecialChar */
code span.ss { color: #bb6688; } /* SpecialString */
code span.st { color: #4070a0; } /* String */
code span.va { color: #19177c; } /* Variable */
code span.vs { color: #4070a0; } /* VerbatimString */
code span.wa { color: #60a0b0; font-weight: bold; font-style: italic; } /* Warning */
</style>
<link rel="stylesheet" href="styles/markdown-styles-v1.6.css">
<!--[if lt IE 9]>
<script src="//cdnjs.cloudflare.com/ajax/libs/html5shiv/3.7.3/html5shiv-printshiv.min.js"></script>
<![endif]-->
</head>
<body>
<p><img src="http://docs.oasis-open.org/templates/OASISLogo-v2.0.jpg" alt="OASIS Logo" /></p>
<hr style="page-break-before: avoid" />
<h1 id="open-command-and-control-openc2-language-specification-version-10">Open Command and Control (OpenC2) Language Specification Version 1.0</h1>
<h2 id="committee-specification-draft-07---public-review-draft-01">Committee Specification Draft 07 /<br>Public Review Draft 01</h2>
<h2 id="17-october-2018">17 October 2018</h2>
<h3 id="specification-uris">Specification URIs</h3>
<h4 id="this-version">This version:</h4>
<ul type="none">
<li><a href="http://docs.oasis-open.org/openc2/oc2ls/v1.0/csprd01/oc2ls-v1.0-csprd01.md" class="uri">http://docs.oasis-open.org/openc2/oc2ls/v1.0/csprd01/oc2ls-v1.0-csprd01.md</a> (Authoritative)</li>
<li><a href="http://docs.oasis-open.org/openc2/oc2ls/v1.0/csprd01/oc2ls-v1.0-csprd01.html" class="uri">http://docs.oasis-open.org/openc2/oc2ls/v1.0/csprd01/oc2ls-v1.0-csprd01.html</a></li>
<li><a href="http://docs.oasis-open.org/openc2/oc2ls/v1.0/csprd01/oc2ls-v1.0-csprd01.pdf" class="uri">http://docs.oasis-open.org/openc2/oc2ls/v1.0/csprd01/oc2ls-v1.0-csprd01.pdf</a></li>
</ul>
<h4 id="previous-version">Previous version:</h4>
<ul type="none">
<li><a href="http://docs.oasis-open.org/openc2/oc2ls/v1.0/csd05/md/oc2ls-v1.0-wd07.md" class="uri">http://docs.oasis-open.org/openc2/oc2ls/v1.0/csd05/md/oc2ls-v1.0-wd07.md</a> (Authoritative)</li>
<li><a href="http://docs.oasis-open.org/openc2/oc2ls/v1.0/csd05/oc2ls-v1.0-csd05.html" class="uri">http://docs.oasis-open.org/openc2/oc2ls/v1.0/csd05/oc2ls-v1.0-csd05.html</a></li>
<li><a href="http://docs.oasis-open.org/openc2/oc2ls/v1.0/csd05/oc2ls-v1.0-csd05.pdf" class="uri">http://docs.oasis-open.org/openc2/oc2ls/v1.0/csd05/oc2ls-v1.0-csd05.pdf</a></li>
</ul>
<h4 id="latest-version">Latest version:</h4>
<ul type="none">
<li><a href="http://docs.oasis-open.org/openc2/oc2ls/v1.0/oc2ls-v1.0.md" class="uri">http://docs.oasis-open.org/openc2/oc2ls/v1.0/oc2ls-v1.0.md</a> (Authoritative)</li>
<li><a href="http://docs.oasis-open.org/openc2/oc2ls/v1.0/oc2ls-v1.0.html" class="uri">http://docs.oasis-open.org/openc2/oc2ls/v1.0/oc2ls-v1.0.html</a></li>
<li><a href="http://docs.oasis-open.org/openc2/oc2ls/v1.0/oc2ls-v1.0.pdf" class="uri">http://docs.oasis-open.org/openc2/oc2ls/v1.0/oc2ls-v1.0.pdf</a></li>
</ul>
<h4 id="technical-committee">Technical Committee:</h4>
<ul type="none">
<li><a href="https://www.oasis-open.org/committees/openc2/">OASIS Open Command and Control (OpenC2) TC</a></li>
</ul>
<h4 id="chairs">Chairs:</h4>
<ul type="none">
<li>Joe Brule (<a href="mailto:jmbrule@nsa.gov">jmbrule@nsa.gov</a>), <a href="https://www.nsa.gov/">National Security Agency</a></li>
<li>Sounil Yu (<a href="mailto:sounil.yu@bankofamerica.com">sounil.yu@bankofamerica.com</a>), <a href="http://www.bankofamerica.com/">Bank of America</a></li>
</ul>
<h4 id="editors">Editors:</h4>
<ul type="none">
<li>Jason Romano (<a href="mailto:jdroman@nsa.gov">jdroman@nsa.gov</a>), <a href="https://www.nsa.gov/">National Security Agency</a></li>
<li>Duncan Sparrell (<a href="mailto:duncan@sfractal.com">duncan@sfractal.com</a>), <a href="http://www.sfractal.com/">sFractal Consulting LLC</a></li>
</ul>
<h4 id="additional-artifacts">Additional artifacts:</h4>
<p>This prose specification is one component of a Work Product that also includes:</p>
<ul>
<li>OpenC2 Language Syntax JSON/JADN schema (<a href="#a1-openc2-language-syntax">Annex A.1</a>):
<ul>
<li><a href="http://docs.oasis-open.org/openc2/oc2ls/v1.0/csprd01/schemas/oc2ls.json" class="uri">http://docs.oasis-open.org/openc2/oc2ls/v1.0/csprd01/schemas/oc2ls.json</a></li>
<li><a href="http://docs.oasis-open.org/openc2/oc2ls/v1.0/csprd01/schemas/oc2ls.pdf" class="uri">http://docs.oasis-open.org/openc2/oc2ls/v1.0/csprd01/schemas/oc2ls.pdf</a></li>
</ul></li>
<li>JADN Syntax JSON/JADN schema (<a href="#a2-jadn-syntax">Annex A.2</a>):
<ul>
<li><a href="http://docs.oasis-open.org/openc2/oc2ls/v1.0/csprd01/schemas/jadn.json" class="uri">http://docs.oasis-open.org/openc2/oc2ls/v1.0/csprd01/schemas/jadn.json</a></li>
<li><a href="http://docs.oasis-open.org/openc2/oc2ls/v1.0/csprd01/schemas/jadn.pdf" class="uri">http://docs.oasis-open.org/openc2/oc2ls/v1.0/csprd01/schemas/jadn.pdf</a></li>
</ul></li>
</ul>
<h4 id="abstract">Abstract:</h4>
<p>Cyberattacks are increasingly sophisticated, less expensive to execute, dynamic and automated. The provision of cyberdefense via statically configured products operating in isolation is untenable. Standardized interfaces, protocols and data models will facilitate the integration of the functional blocks within a system and between systems. Open Command and Control (OpenC2) is a concise and extensible language to enable machine to machine communications for purposes of command and control of cyber defense components, subsystems and/or systems in a manner that is agnostic of the underlying products, technologies, transport mechanisms or other aspects of the implementation. It should be understood that a language such as OpenC2 is necessary but insufficient to enable coordinated cyber responses that occur within cyber relevant time. Other aspects of coordinated cyber response such as sensing, analytics, and selecting appropriate courses of action are beyond the scope of OpenC2.</p>
<h4 id="status">Status:</h4>
<p>This document was last revised or approved by the OASIS Open Command and Control (OpenC2) TC on the above date. The level of approval is also listed above. Check the "Latest version" location noted above for possible later revisions of this document. Any other numbered Versions and other technical work produced by the Technical Committee (TC) are listed at <a href="https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=openc2#technical" class="uri">https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=openc2#technical</a>.</p>
<p>TC members should send comments on this specification to the TC's email list. Others should send comments to the TC's public comment list, after subscribing to it by following the instructions at the "Send A Comment" button on the TC's web page at <a href="https://www.oasis-open.org/committees/openc2/" class="uri">https://www.oasis-open.org/committees/openc2/</a>.</p>
<p>This specification is provided under the <a href="https://www.oasis-open.org/policies-guidelines/ipr#Non-Assertion-Mode">Non-Assertion</a> Mode of the OASIS IPR Policy, the mode chosen when the Technical Committee was established. For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the TC's web page (<a href="https://www.oasis-open.org/committees/openc2/ipr.php" class="uri">https://www.oasis-open.org/committees/openc2/ipr.php</a>).</p>
<p>Note that any machine-readable content (<a href="https://www.oasis-open.org/policies-guidelines/tc-process#wpComponentsCompLang">Computer Language Definitions</a>) declared Normative for this Work Product is provided in separate plain text files. In the event of a discrepancy between any such plain text file and display content in the Work Product's prose narrative document(s), the content in the separate plain text file prevails.</p>
<h4 id="citation-format">Citation format:</h4>
<p>When referencing this specification the following citation format should be used:</p>
<p><strong>[OpenC2-Lang-v1.0]</strong></p>
<p><em>Open Command and Control (OpenC2) Language Specification Version 1.0</em>. Edited by Jason Romano and Duncan Sparrell. 17 October 2018. OASIS Committee Specification Draft 07 / Public Review Draft 01. <a href="http://docs.oasis-open.org/openc2/oc2ls/v1.0/csprd01/oc2ls-v1.0-csprd01.html" class="uri">http://docs.oasis-open.org/openc2/oc2ls/v1.0/csprd01/oc2ls-v1.0-csprd01.html</a>. Latest version: <a href="http://docs.oasis-open.org/openc2/oc2ls/v1.0/oc2ls-v1.0.html" class="uri">http://docs.oasis-open.org/openc2/oc2ls/v1.0/oc2ls-v1.0.html</a>.</p>
<hr />
<h2 id="notices">Notices</h2>
<p>Copyright © OASIS Open 2018. All Rights Reserved.</p>
<p>All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full <a href="https://www.oasis-open.org/policies-guidelines/ipr">Policy</a> may be found at the OASIS website.</p>
<p>This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.</p>
<p>The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.</p>
<p>This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.</p>
<p>OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification.</p>
<p>OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS may include such claims on its website, but disclaims any obligation to do so.</p>
<p>OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.</p>
<p>The name "OASIS" is a trademark of <a href="https://www.oasis-open.org/">OASIS</a>, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see <a href="https://www.oasis-open.org/policies-guidelines/trademark" class="uri">https://www.oasis-open.org/policies-guidelines/trademark</a> for above guidance.</p>
<hr />
<h1 id="table-of-contents">Table of Contents</h1>
<nav id="TOC">
<ul type="none">
<li><a href="#1-introduction">1 Introduction</a><ul type="none">
<li><a href="#11-ipr-policy">1.1 IPR Policy</a></li>
<li><a href="#12-terminology">1.2 Terminology</a></li>
<li><a href="#13-normative-references">1.3 Normative References</a></li>
<li><a href="#14-non-normative-references">1.4 Non-Normative References</a></li>
<li><a href="#15-document-conventions">1.5 Document Conventions</a><ul type="none">
<li><a href="#151-naming-conventions">1.5.1 Naming Conventions</a></li>
<li><a href="#152-font-colors-and-style">1.5.2 Font Colors and Style</a></li>
</ul></li>
<li><a href="#16-overview">1.6 Overview</a></li>
<li><a href="#17-goal">1.7 Goal</a></li>
<li><a href="#18-purpose-and-scope">1.8 Purpose and Scope</a></li>
</ul></li>
<li><a href="#2-openc2-language-description">2 OpenC2 Language Description</a><ul type="none">
<li><a href="#21-openc2-command">2.1 OpenC2 Command</a></li>
<li><a href="#22-openc2-response">2.2 OpenC2 Response</a></li>
</ul></li>
<li><a href="#3-openc2-language-definition">3 OpenC2 Language Definition</a><ul type="none">
<li><a href="#31-base-components-and-structures">3.1 Base Components and Structures</a><ul type="none">
<li><a href="#311-data-types">3.1.1 Data Types</a></li>
<li><a href="#312-derived-data-types">3.1.2 Derived Data Types</a></li>
<li><a href="#313-cardinality">3.1.3 Cardinality</a></li>
<li><a href="#314-derived-enumerations">3.1.4 Derived Enumerations</a></li>
<li><a href="#315-serialization">3.1.5 Serialization</a><ul type="none">
<li><a href="#3151-id-and-name-serialization">3.1.5.1 ID and Name Serialization</a></li>
<li><a href="#3152-integer-serialization">3.1.5.2 Integer Serialization</a></li>
</ul></li>
</ul></li>
<li><a href="#32-message">3.2 Message</a></li>
<li><a href="#33-content">3.3 Content</a><ul type="none">
<li><a href="#331-openc2-command">3.3.1 OpenC2 Command</a><ul type="none">
<li><a href="#3311-action">3.3.1.1 Action</a></li>
<li><a href="#3312-target">3.3.1.2 Target</a></li>
<li><a href="#3313-actuator">3.3.1.3 Actuator</a></li>
<li><a href="#3314-command-arguments">3.3.1.4 Command Arguments</a></li>
</ul></li>
<li><a href="#332-openc2-response">3.3.2 OpenC2 Response</a><ul type="none">
<li><a href="#3321-openc2-response-status-code">3.3.2.1 OpenC2 Response Status Code</a></li>
</ul></li>
<li><a href="#333-imported-data">3.3.3 Imported Data</a></li>
<li><a href="#334-extensions">3.3.4 Extensions</a><ul type="none">
<li><a href="#3341-private-enterprise-target">3.3.4.1 Private Enterprise Target</a></li>
<li><a href="#3342-private-enterprise-specifiers">3.3.4.2 Private Enterprise Specifiers</a></li>
<li><a href="#3343-private-enterprise-command-arguments">3.3.4.3 Private Enterprise Command Arguments</a></li>
<li><a href="#3344-private-enterprise-results">3.3.4.4 Private Enterprise Results</a></li>
</ul></li>
</ul></li>
<li><a href="#34-type-definitions">3.4 Type Definitions</a><ul type="none">
<li><a href="#341-target-types">3.4.1 Target Types</a><ul type="none">
<li><a href="#3411-artifact">3.4.1.1 Artifact</a></li>
<li><a href="#3413-device">3.4.1.3 Device</a></li>
<li><a href="#3414-domain-name">3.4.1.4 Domain Name</a></li>
<li><a href="#3415-email-address">3.4.1.5 Email Address</a></li>
<li><a href="#3416-features">3.4.1.6 Features</a></li>
<li><a href="#3417-file">3.4.1.7 File</a></li>
<li><a href="#3418-ip-address">3.4.1.8 IP Address</a></li>
<li><a href="#3419-ip-connection">3.4.1.9 IP Connection</a></li>
<li><a href="#34110-mac-address">3.4.1.10 MAC Address</a></li>
<li><a href="#34111-process">3.4.1.11 Process</a></li>
<li><a href="#34112-properties">3.4.1.12 Properties</a></li>
<li><a href="#34113-uri">3.4.1.13 URI</a></li>
</ul></li>
<li><a href="#342-data-types">3.4.2 Data Types</a><ul type="none">
<li><a href="#3421-request-identifier">3.4.2.1 Request Identifier</a></li>
<li><a href="#3422-date-time">3.4.2.2 Date-Time</a></li>
<li><a href="#3423-duration">3.4.2.3 Duration</a></li>
<li><a href="#3424-hashes">3.4.2.4 Hashes</a></li>
<li><a href="#3425-hostname">3.4.2.5 Hostname</a></li>
<li><a href="#3427-l4-protocol">3.4.2.7 L4 Protocol</a></li>
<li><a href="#3428-payload">3.4.2.8 Payload</a></li>
<li><a href="#3429-port">3.4.2.9 Port</a></li>
<li><a href="#34210-feature">3.4.2.10 Feature</a></li>
<li><a href="#34211-response-type">3.4.2.11 Response-Type</a></li>
<li><a href="#34212-version">3.4.2.12 Version</a></li>
<li><a href="#34214-key-value-pair">3.4.2.14 Key-Value Pair</a></li>
<li><a href="#34215-action-targets-array">3.4.2.15 Action-Targets Array</a></li>
</ul></li>
<li><a href="#343-schema-syntax">3.4.3 Schema Syntax</a><ul type="none">
<li><a href="#3431-meta">3.4.3.1 Meta</a></li>
<li><a href="#3432-import">3.4.3.2 Import</a></li>
<li><a href="#3433-bounds">3.4.3.3 Bounds</a></li>
<li><a href="#3434-type">3.4.3.4 Type</a></li>
<li><a href="#3435-jadn-type">3.4.3.5 JADN Type</a></li>
<li><a href="#3436-enum-field">3.4.3.6 Enum Field</a></li>
<li><a href="#3437-full-field">3.4.3.7 Full Field</a></li>
<li><a href="#3438-identifier">3.4.3.8 Identifier</a></li>
<li><a href="#3439-nsid">3.4.3.9 Nsid</a></li>
<li><a href="#34310-uname">3.4.3.10 Uname</a></li>
<li><a href="#34311-options">3.4.3.11 Options</a></li>
<li><a href="#34312-option">3.4.3.12 Option</a></li>
</ul></li>
</ul></li>
</ul></li>
<li><a href="#4-mandatory-commandsresponses">4 Mandatory Commands/Responses</a></li>
<li><a href="#5-conformance">5 Conformance</a><ul type="none">
<li><a href="#51-openc2-message-content">5.1 OpenC2 Message Content</a></li>
<li><a href="#52-openc2-producer">5.2 OpenC2 Producer</a></li>
<li><a href="#53-openc2-consumer">5.3 OpenC2 Consumer</a></li>
</ul></li>
<li><a href="#annex-a-schemas">Annex A. Schemas</a><ul type="none">
<li><a href="#a1-openc2-language-syntax">A.1 OpenC2 Language Syntax</a></li>
<li><a href="#a2-jadn-syntax">A.2 JADN Syntax</a></li>
</ul></li>
<li><a href="#annex-b-examples">Annex B. Examples</a><ul type="none">
<li><a href="#b1-example-1">B.1 Example 1</a><ul type="none">
<li><a href="#b11-command-message">B.1.1 Command Message</a></li>
<li><a href="#b12-response-message">B.1.2 Response Message</a></li>
</ul></li>
<li><a href="#b2-example-2">B.2 Example 2</a></li>
<li><a href="#b3-example-3">B.3 Example 3</a></li>
</ul></li>
<li><a href="#annex-c-acronyms">Annex C. Acronyms</a></li>
<li><a href="#annex-d-revision-history">Annex D. Revision History</a></li>
<li><a href="#annex-e-acknowledgments">Annex E. Acknowledgments</a></li>
</ul>
</nav>
<hr />
<h1 id="1-introduction">1 Introduction</h1>
<p>OpenC2 is a suite of specifications that enables command and control of cyber defense systems and components. OpenC2 typically uses a request-response paradigm where a command is encoded by an OpenC2 producer (managing application) and transferred to an OpenC2 consumer (managed device or virtualized function) using a secure transfer protocol. The consumer can respond with status and any requested information. The contents of both the command and the response are fully defined in schemas, allowing both parties to recognize the syntax constraints imposed on the exchange.</p>
<p>OpenC2 allows the application producing the commands to discover the set of capabilities supported by the managed devices. These capabilities permit the managing application to adjust its behavior to take advantage of the features exposed by the managed device. The capability definitions can be easily extended in a noncentralized manner, allowing standard and non-standard capabilities to be defined with semantic and syntactic rigor.</p>
<h2 id="11-ipr-policy">1.1 IPR Policy</h2>
<p>This specification is provided under the <a href="https://www.oasis-open.org/policies-guidelines/ipr#Non-Assertion-Mode">Non-Assertion</a> Mode of the <a href="https://www.oasis-open.org/policies-guidelines/ipr">OASIS IPR Policy</a>, the mode chosen when the Technical Committee was established. For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the TC's web page (<a href="https://www.oasis-open.org/committees/openc2/ipr.php" class="uri">https://www.oasis-open.org/committees/openc2/ipr.php</a>).</p>
<h2 id="12-terminology">1.2 Terminology</h2>
<ul>
<li><strong>Action</strong>: The task or activity to be performed.</li>
<li><strong>Actuator</strong>: The entity that performs the action.</li>
<li><strong>Command</strong>: A message defined by an action-target pair that is sent from a producer and received by a consumer.</li>
<li><strong>Consumer</strong>: A managed device / application that receives commands. Note that a single device / application can have both consumer and producer capabilities.</li>
<li><strong>Producer</strong>: A manager application that sends commands.</li>
<li><strong>Response</strong>: A message from a consumer to a producer acknowledging a command or returning the requested resources or status to a previously received request.</li>
<li><strong>Target</strong>: The object of the action, i.e., the action is performed on the target.</li>
</ul>
<p>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">RFC2119</a>] and [<a href="#rfc8174">RFC8174</a>].</p>
<h2 id="13-normative-references">1.3 Normative References</h2>
<h6 id="openc2-https-v10">[OpenC2-HTTPS-v1.0]</h6>
<p><em>Specification for Transfer of OpenC2 Messages via HTTPS Version 1.0</em>. Edited by David Lemire. Latest version: <a href="http://docs.oasis-open.org/openc2/open-impl-https/v1.0/open-impl-https-v1.0.html" class="uri">http://docs.oasis-open.org/openc2/open-impl-https/v1.0/open-impl-https-v1.0.html</a></p>
<h6 id="openc2-slpf-v10">[OpenC2-SLPF-v1.0]</h6>
<p><em>Open Command and Control (OpenC2) Profile for Stateless Packet Filtering Version 1.0</em>. Edited by Joe Brule, Duncan Sparrell, and Alex Everett. Latest version: <a href="http://docs.oasis-open.org/openc2/oc2slpf/v1.0/oc2slpf-v1.0.html" class="uri">http://docs.oasis-open.org/openc2/oc2slpf/v1.0/oc2slpf-v1.0.html</a></p>
<h6 id="rfc768">[RFC768]</h6>
<p>Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980, <a href="http://www.rfc-editor.org/info/rfc768" class="uri">http://www.rfc-editor.org/info/rfc768</a>.</p>
<h6 id="rfc792">[RFC792]</h6>
<p>Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981, <a href="http://www.rfc-editor.org/info/rfc792" class="uri">http://www.rfc-editor.org/info/rfc792</a>.</p>
<h6 id="rfc793">[RFC793]</h6>
<p>Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981, <a href="http://www.rfc-editor.org/info/rfc793" class="uri">http://www.rfc-editor.org/info/rfc793</a>.</p>
<h6 id="rfc1034">[RFC1034]</h6>
<p>Mockapetris, P. V., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987, <a href="http://www.rfc-editor.org/info/rfc1034" class="uri">http://www.rfc-editor.org/info/rfc1034</a>.</p>
<h6 id="rfc1123">[RFC1123]</h6>
<p>Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989, <a href="http://www.rfc-editor.org/info/rfc1123" class="uri">http://www.rfc-editor.org/info/rfc1123</a>.</p>
<h6 id="rfc1321">[RFC1321]</h6>
<p>Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992, <a href="http://www.rfc-editor.org/info/rfc1321" class="uri">http://www.rfc-editor.org/info/rfc1321</a>.</p>
<h6 id="rfc2119">[RFC2119]</h6>
<p>Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <a href="http://www.rfc-editor.org/info/rfc2119" class="uri">http://www.rfc-editor.org/info/rfc2119</a>.</p>
<h6 id="rfc3986">[RFC3986]</h6>
<p>Berners-Lee, T., Fielding, R., Masinter, L., "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005, <a href="http://www.rfc-editor.org/info/rfc3986" class="uri">http://www.rfc-editor.org/info/rfc3986</a>.</p>
<h6 id="rfc4122">[RFC4122]</h6>
<p>Leach, P., Mealling, M., Salz, R., "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, July 2005, <a href="http://www.rfc-editor.org/info/rfc4122" class="uri">http://www.rfc-editor.org/info/rfc4122</a>.</p>
<h6 id="rfc4648">[RFC4648]</h6>
<p>Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006, <a href="http://www.rfc-editor.org/info/rfc4648" class="uri">http://www.rfc-editor.org/info/rfc4648</a>.</p>
<h6 id="rfc4960">[RFC4960]</h6>
<p>Stewart, R. "Stream Control Transmission Protocol", RFC 4960, September 2007, <a href="http://www.rfc-editor.org/info/rfc4960" class="uri">http://www.rfc-editor.org/info/rfc4960</a>.</p>
<h6 id="rfc5237">[RFC5237]</h6>
<p>Arkko, J., Bradner, S., "IANA Allocation Guidelines for the Protocol Field", BCP 37, RFC 5237, February 2008, <a href="http://www.rfc-editor.org/info/rfc5237" class="uri">http://www.rfc-editor.org/info/rfc5237</a>.</p>
<h6 id="rfc5322">[RFC5322]</h6>
<p>Resnick, P., "Internet Message Format", RFC 5322, October 2008, <a href="http://www.rfc-editor.org/info/rfc5322" class="uri">http://www.rfc-editor.org/info/rfc5322</a>.</p>
<h6 id="rfc5612">[RFC5612]</h6>
<p>Eronen, P., Harrington, D., "Enterprise Number for Documentation Use", RFC 5612, August 2009, <a href="http://www.rfc-editor.org/info/rfc5612" class="uri">http://www.rfc-editor.org/info/rfc5612</a>.</p>
<h6 id="rfc6234">[RFC6234]</h6>
<p>Eastlake 3rd, D., Hansen, T., "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011, <a href="http://www.rfc-editor.org/info/rfc6234" class="uri">http://www.rfc-editor.org/info/rfc6234</a>.</p>
<h6 id="rfc6335">[RFC6335]</h6>
<p>Cotton, M., Eggert, L., Touch, J., Westerlund, M., Cheshire, S., "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, August 2011, <a href="http://www.rfc-editor.org/info/rfc6335" class="uri">http://www.rfc-editor.org/info/rfc6335</a>.</p>
<h6 id="rfc6838">[RFC6838]</h6>
<p>Freed, N., Klensin, J., Hansen, T., "Media Type Specifications and Registration Procedures, BCP 13, RFC 6838, January 2013, <a href="http://www.rfc-editor.org/info/rfc6838" class="uri">http://www.rfc-editor.org/info/rfc6838</a>.</p>
<h6 id="rfc7493">[RFC7493]</h6>
<p>Bray, T., "The I-JSON Message Format", RFC 7493, March 2015, <a href="http://www.rfc-editor.org/info/rfc7493" class="uri">http://www.rfc-editor.org/info/rfc7493</a>.</p>
<h6 id="rfc8174">[RFC8174]</h6>
<p>Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <a href="http://www.rfc-editor.org/info/rfc8174" class="uri">http://www.rfc-editor.org/info/rfc8174</a>.</p>
<h6 id="rfc8259">[RFC8259]</h6>
<p>Bray, T., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, December 2017, <a href="http://www.rfc-editor.org/info/rfc8259" class="uri">http://www.rfc-editor.org/info/rfc8259</a>.</p>
<h2 id="14-non-normative-references">1.4 Non-Normative References</h2>
<h6 id="iacd">[IACD]</h6>
<p>M. J. Herring, K. D. Willett, "Active Cyber Defense: A Vision for Real-Time Cyber Defense," Journal of Information Warfare, vol. 13, Issue 2, p. 80, April 2014.<br>Willett, Keith D., "Integrated Adaptive Cyberspace Defense: Secure Orchestration", International Command and Control Research and Technology Symposium, June 2015.</p>
<h2 id="15-document-conventions">1.5 Document Conventions</h2>
<h3 id="151-naming-conventions">1.5.1 Naming Conventions</h3>
<ul>
<li><a href="#rfc2119">RFC2119</a>/<a href="#rfc8174">RFC8174</a> key words (see <a href="#14-non-normative-references">section 1.4</a>) are in all uppercase.</li>
<li>All property names and literals are in lowercase, except when referencing canonical names defined in another standard (e.g., literal values from an IANA registry).</li>
<li>All words in structure component names are capitalized and are separated with a hyphen, e.g., ACTION, TARGET, TARGET-SPECIFIER.</li>
<li>Words in property names are separated with an underscore (_), while words in string enumerations and type names are separated with a hyphen (-).</li>
<li>The term "hyphen" used here refers to the ASCII hyphen or minus character, which in Unicode is "hyphen-minus", U+002D.</li>
<li>All type names, property names, object names, and vocabulary terms are between three and 40 characters long.</li>
</ul>
<h3 id="152-font-colors-and-style">1.5.2 Font Colors and Style</h3>
<p>The following color, font and font style conventions are used in this document:</p>
<ul>
<li>A fixed width font is used for all type names, property names, and literals.</li>
<li>Property names are in bold style – **<code>created_a**t</code></li>
<li>All examples in this document are expressed in JSON. They are in fixed width font, with straight quotes, black text and a light shaded background, and 4-space indentation. JSON examples in this document are representations of JSON Objects. They should not be interpreted as string literals. The ordering of object keys is insignificant. Whitespace before or after JSON structural characters in the examples are insignificant [<a href="#rfc8259">RFC8259</a>].</li>
<li>Parts of the example may be omitted for conciseness and clarity. These omitted parts are denoted with the ellipses (...).</li>
</ul>
<p>Example:</p>
<div class="sourceCode" id="cb1"><pre class="sourceCode javascript"><code class="sourceCode javascript"><a class="sourceLine" id="cb1-1" data-line-number="1"><span class="op">{</span> </a>
<a class="sourceLine" id="cb1-2" data-line-number="2"> <span class="st">"action"</span><span class="op">:</span> <span class="st">"contain"</span><span class="op">,</span></a>
<a class="sourceLine" id="cb1-3" data-line-number="3"> <span class="st">"target"</span><span class="op">:</span> <span class="op">{</span></a>
<a class="sourceLine" id="cb1-4" data-line-number="4"> <span class="st">"user_account"</span><span class="op">:</span> <span class="op">{</span></a>
<a class="sourceLine" id="cb1-5" data-line-number="5"> <span class="st">"user_id"</span><span class="op">:</span> <span class="st">"fjbloggs"</span><span class="op">,</span></a>
<a class="sourceLine" id="cb1-6" data-line-number="6"> <span class="st">"account_type"</span><span class="op">:</span> <span class="st">"windows-local"</span></a>
<a class="sourceLine" id="cb1-7" data-line-number="7"> <span class="op">}</span></a>
<a class="sourceLine" id="cb1-8" data-line-number="8"> <span class="op">}</span></a>
<a class="sourceLine" id="cb1-9" data-line-number="9"><span class="op">}</span></a></code></pre></div>
<h2 id="16-overview">1.6 Overview</h2>
<p>OpenC2 is a suite of specifications to command actuators that execute cyber defense functions in an unambiguous, standardized way. These specifications include the OpenC2 Language Specification, Actuator Profiles, and Transfer Specifications. The OpenC2 Language Specification and Actuator Profile specifications focus on the standard at the producer and consumer of the command and response while the transfer specifications focus on the protocols for their exchange.</p>
<ul>
<li>The OpenC2 Language Specification provides the semantics for the essential elements of the language, the structure for commands and responses, and the schema that defines the proper syntax for the language elements that represents the command or response.</li>
<li>OpenC2 Actuator Profiles specify the subset of the OpenC2 language relevant in the context of specific actuator functions. Cyber defense components, devices, systems and/or instances may (in fact are likely) to implement multiple actuator profiles. Actuator profiles extend the language by defining specifiers that identify the actuator to the required level of precision and may define command arguments that are relevant and/or unique to those actuator functions.</li>
<li>OpenC2 Transfer Specifications utilize existing protocols and standards to implement OpenC2 in specific environments. These standards are used for communications and security functions beyond the scope of the language, such as message transfer encoding, authentication, and end-to-end transfer of OpenC2 messages.</li>
</ul>
<p>The OpenC2 Language Specification defines a language used to compose messages for command and control of cyber defense systems and components. A message consists of a header and a payload (<em>defined</em> as a message body in the OpenC2 Language Specification Version 1.0 and <em>specified</em> in one or more actuator profiles).</p>
<p>In general, there are two types of participants involved in the exchange of OpenC2 messages, as depicted in Figure 1-1:</p>
<ol>
<li><strong>OpenC2 Producers</strong>: An OpenC2 Producer is an entity that creates commands to provide instruction to one or more systems to act in accordance with the content of the command. An OpenC2 Producer may receive and process responses in conjunction with a command.</li>
<li><strong>OpenC2 Consumers</strong>: An OpenC2 Consumer is an entity that receives and may act upon an OpenC2 command. An OpenC2 Consumer may create responses that provide any information captured or necessary to send back to the OpenC2 Producer.</li>
</ol>
<p>The language defines two payload structures:</p>
<ol>
<li><strong>Command</strong>: An instruction from one system known as the OpenC2 "Producer", to one or more systems, the OpenC2 "Consumer(s)", to act on the content of the command.</li>
<li><strong>Response</strong>: Any information captured or necessary to send back to the OpenC2 Producer that issued the Command, i.e., the OpenC2 Consumer’s response to the OpenC2 Producer.</li>
</ol>
<p><img src="images/image_1.png" alt="no alt title" /></p>
<p><strong>Figure 1-1. OpenC2 Message Exchange</strong></p>
<p>OpenC2 implementations integrate the related OpenC2 specifications described above with related industry specifications, protocols, and standards. Figure 1 depicts the relationships among OpenC2 specifications, and their relationships to other industry standards and environment-specific implementations of OpenC2. Note that the layering of implementation aspects in the diagram is notional, and not intended to preclude the use of any particular protocol or standard.</p>
<p><img src="images/image_2.png" alt="no alt title" /></p>
<p><strong>Figure 1-2. OpenC2 Documentation and Layering Model</strong></p>
<p>OpenC2 is conceptually partitioned into four layers as shown in Table 1-1.</p>
<p><strong>Table 1-1. OpenC2 Protocol Layers</strong></p>
<table>
<thead>
<tr class="header">
<th style="text-align: left;">Layer</th>
<th style="text-align: left;">Examples</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td style="text-align: left;">Function-Specific Content</td>
<td style="text-align: left;">Actuator Profiles<br>(standard and extensions)</td>
</tr>
<tr class="even">
<td style="text-align: left;">Common Content</td>
<td style="text-align: left;">Language Specification<br>(this document)</td>
</tr>
<tr class="odd">
<td style="text-align: left;">Message</td>
<td style="text-align: left;">Transfer Specifications<br>(OpenC2-over-HTTPS, OpenC2-over-CoAP, …)</td>
</tr>
<tr class="even">
<td style="text-align: left;">Secure Transfer</td>
<td style="text-align: left;">HTTPS, CoAP, MQTT, OpenDXL, ...</td>
</tr>
</tbody>
</table>
<ul>
<li>The <strong>Secure Transfer</strong> layer provides a communication path between the producer and the consumer. OpenC2 can be layered over any standard transfer protocol.</li>
<li>The <strong>Message</strong> layer provides a transfer- and content-independent mechanism for conveying requests, responses, and notifications. A transfer specification maps transfer-specific protocol elements to a transfer-independent set of message elements consisting of content and associated metadata.</li>
<li>The <strong>Common Content</strong> layer defines the structure of OpenC2 commands and responses and a set of common language elements used to construct them.</li>
<li>The <strong>Function-specific Content</strong> layer defines the language elements used to support a particular cyber defense function. An actuator profile defines the implementation conformance requirements for that function. OpenC2 Producers and Consumers will support one or more profiles.</li>
</ul>
<h2 id="17-goal">1.7 Goal</h2>
<p>The goal of the OpenC2 Language Specification is to provide a language for interoperating between functional elements of cyber defense systems. This language used in conjunction with OpenC2 Actuator Profiles and OpenC2 Transfer Specifications allows for vendor-agnostic cybertime response to attacks.</p>
<p>The Integrated Adaptive Cyber Defense (IACD) framework defines a collection of activities, based on the traditional OODA (Observe–Orient–Decide–Act) Loop [<a href="#iacd">IACD</a>]:</p>
<ul>
<li>Sensing: gathering of data regarding system activities</li>
<li>Sense Making: evaluating data using analytics to understand what's happening</li>
<li>Decision Making: determining a course-of-action to respond to system events</li>
<li>Acting: Executing the course-of-action</li>
</ul>
<p>The goal of OpenC2 is to enable coordinated defense in cyber-relevant time between decoupled blocks that perform cyber defense functions. OpenC2 focuses on the Acting portion of the IACD framework; the assumption that underlies the design of OpenC2 is that the sensing/ analytics have been provisioned and the decision to act has been made. This goal and these assumptions guides the design of OpenC2:</p>
<ul>
<li><strong>Technology Agnostic:</strong> The OpenC2 language defines a set of abstract atomic cyber defense actions in a platform and product agnostic manner</li>
<li><strong>Concise:</strong> An OpenC2 command is intended to convey only the essential information required to describe the action required and can be represented in a very compact form for communications-constrained environments</li>
<li><strong>Abstract:</strong> OpenC2 commands and responses are defined abstractly and can be encoded and transferred via multiple schemes as dictated by the needs of different implementation environments</li>
<li><strong>Extensible:</strong> While OpenC2 defines a core set of actions and targets for cyber defense, the language is expected to evolve with cyber defense technologies, and permits extensions to accommodate new cyber defense technologies.</li>
</ul>
<h2 id="18-purpose-and-scope">1.8 Purpose and Scope</h2>
<p>The OpenC2 Language Specification defines the set of components to assemble a complete command and control message and provides a framework so that the language can be extended. To achieve this purpose, the scope of this specification includes:</p>
<ol>
<li>the set of actions and options that may be used in OpenC2 commands</li>
<li>the set of targets and target specifiers</li>
<li>a syntax that defines the structure of commands and responses</li>
<li>a JSON serialization of OpenC2 commands and responses</li>
<li>the procedures for extending the language</li>
</ol>
<p>The OpenC2 language assumes that the event has been detected, a decision to act has been made, the act is warranted, and the initiator and recipient of the commands are authenticated and authorized. The OpenC2 language was designed to be agnostic of the other aspects of cyber defense implementations that realize these assumptions. The following items are beyond the scope of this specification:</p>
<ol>
<li>Language extensions applicable to some actuators, which may be defined in individual actuator profiles.</li>
<li>Alternate serializations of OpenC2 commands and responses.</li>
<li>The enumeration of the protocols required for transport, information assurance, sensing, analytics and other external dependencies.</li>
</ol>
<hr />
<h1 id="2-openc2-language-description">2 OpenC2 Language Description</h1>
<p>The OpenC2 language has two distinct content types: command and response. The command is sent from a producer to a consumer and describes an action to be performed by an actuator on a target. The response is sent from a consumer, usually back to the producer, and is a means to provide information (such as acknowledgement, status, etc.) as a result of a command.</p>
<h2 id="21-openc2-command">2.1 OpenC2 Command</h2>
<p>The command describes an action to be performed on a target and may include information identifying the actuator or actuators that are to execute the command.</p>
<p>A command has four main components: ACTION, TARGET, ARGUMENTS, and ACTUATOR. The following list summarizes the components of a command.</p>
<ul>
<li><strong>ACTION</strong> (required): The task or activity to be performed.</li>
<li><strong>TARGET</strong> (required): The object of the action. The ACTION is performed on the target.
<ul>
<li><strong>TARGET-NAME</strong> (required): The name of the object of the action.</li>
<li><strong>TARGET-SPECIFIERS</strong> (optional): The specifier further identifies the target to some level of precision, such as a specific target, a list of targets, or a class of targets.</li>
</ul></li>
<li><strong>ARGUMENTS</strong> (optional): Provide additional information on how the command is to be performed, such as date/time, periodicity, duration etc.</li>
<li><strong>ACTUATOR</strong> (optional): The ACTUATOR executes the command (the ACTION and TARGET). The ACTUATOR type will be defined within the context of an Actuator Profile.
<ul>
<li><strong>ACTUATOR-NAME</strong> (required): The name of the set of functions (e.g., "slpf") performed by the actuator, and the name of the profile defining commands applicable to those functions.</li>
<li><strong>ACTUATOR-SPECIFIERS</strong> (optional): The specifier identifies the actuator to some level of precision, such as a specific actuator, a list of actuators, or a group of actuators.</li>
</ul></li>
</ul>
<p>The ACTION and TARGET components are required and are populated by one of the actions in <a href="#3311-action">Section 3.3.1.1</a> and the targets in <a href="#3312-target">Section 3.3.1.2</a>. A particular target may be further refined by one or more TARGET-SPECIFIERS. Procedures to extend the targets are described in <a href="#334-extensions">Section 3.3.4</a>.</p>
<p>TARGET-SPECIFIERS provide additional precision to identify the target (e.g., 10.1.2.3) and may include a method of identifying multiple targets of the same type (e.g., 10.1.0.0/16).</p>
<p>The ARGUMENTS component, if present, is populated by one or more 'command arguments' that determine how the command is executed. ARGUMENTS influence the command by providing information such as time, periodicity, duration, or other details on what is to be executed. They can also be used to convey the need for acknowledgement or additional status information about the execution of a command. The valid ARGUMENTS defined in this specification are in <a href="#3314-command-arguments">Section 3.3.1.4</a>.</p>
<p>An ACTUATOR is an implementation of a cyber defense function that executes the command. An Actuator Profile is a specification that identifies the subset of ACTIONS, TARGETS and other aspects of this language specification that are mandatory to implement or optional in the context of a particular ACTUATOR. An Actuator Profile may extend the language by defining additional ARGUMENTS, ACTUATOR-SPECIFIERS, and/or TARGETS that are meaningful and possibly unique to the actuator.</p>
<p>The ACTUATOR optionally identifies the entity or entities that are tasked to execute the command. Specifiers for actuators refine the command so that a particular function, system, class of devices, or specific device can be identified.</p>
<p>The ACTUATOR component may be omitted from a command and typically will not be included in implementations where the identities of the endpoints are unambiguous or when a high-level effects-based command is desired and the tactical decisions on how the effect is achieved is left to the recipient.</p>
<h2 id="22-openc2-response">2.2 OpenC2 Response</h2>
<p>The OpenC2 Response is a message sent from the recipient of a command. Response messages provide acknowledgement, status, results from a query, or other information.</p>
<p>The following list summarizes the fields and subfields of an OpenC2 Response.</p>
<ul>
<li><strong>STATUS</strong> (required): An integer containing a numerical status code</li>
<li><strong>STATUS_TEXT</strong> (optional): A free-form string containing human-readable description of the response status. The string can contain more detail than is represented by the status code, but does not affect the meaning of the response.</li>
<li><strong>RESULTS</strong> (optional): Contains the data or extended status code that was requested from an OpenC2 Command.</li>
</ul>
<hr />
<h1 id="3-openc2-language-definition">3 OpenC2 Language Definition</h1>
<h2 id="31-base-components-and-structures">3.1 Base Components and Structures</h2>
<h3 id="311-data-types">3.1.1 Data Types</h3>
<p>The syntax of valid OpenC2 messages is defined using an information model constructed from the data types presented here:</p>
<table>
<thead>
<tr class="header">
<th style="text-align: left;">Type</th>
<th style="text-align: left;">Description</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td style="text-align: left;"><strong>Primitive Types</strong></td>
<td style="text-align: left;"></td>
</tr>
<tr class="even">
<td style="text-align: left;">Binary</td>
<td style="text-align: left;">A sequence of octets. Length is the number of octets.</td>
</tr>
<tr class="odd">
<td style="text-align: left;">Boolean</td>
<td style="text-align: left;">A logical entity that can have two values: <code>true</code> and <code>false</code>.</td>
</tr>
<tr class="even">
<td style="text-align: left;">Integer</td>
<td style="text-align: left;">A whole number.</td>
</tr>
<tr class="odd">
<td style="text-align: left;">Number</td>
<td style="text-align: left;">A real number.</td>
</tr>
<tr class="even">
<td style="text-align: left;">Null</td>
<td style="text-align: left;">Nothing, used to designate fields with no value.</td>
</tr>
<tr class="odd">
<td style="text-align: left;">String</td>
<td style="text-align: left;">A sequence of characters. Each character must have a valid Unicode codepoint. Length is the number of characters.</td>
</tr>
<tr class="even">
<td style="text-align: left;"><strong>Structures</strong></td>
<td style="text-align: left;"></td>
</tr>
<tr class="odd">
<td style="text-align: left;">Array</td>
<td style="text-align: left;">An ordered list of unnamed fields. Each field has an ordinal position and type.</td>
</tr>
<tr class="even">
<td style="text-align: left;">ArrayOf</td>
<td style="text-align: left;">An ordered list of unnamed fields of the same type. Each field has an ordinal position and the specified type.</td>
</tr>
<tr class="odd">
<td style="text-align: left;">Choice</td>
<td style="text-align: left;">One field selected from a set of named fields. The value has a name and type.</td>
</tr>
<tr class="even">
<td style="text-align: left;">Enumerated</td>
<td style="text-align: left;">A set of id:name pairs where id is an integer. The Enumerated.ID subtype is a set of ids only.</td>
</tr>
<tr class="odd">
<td style="text-align: left;">Map</td>
<td style="text-align: left;">An unordered set of named fields. Each field has an id, name and type.</td>
</tr>
<tr class="even">
<td style="text-align: left;">Record</td>
<td style="text-align: left;">An ordered list of named fields, e.g. a message, record, structure, or row in a table. Each field has an ordinal position, name, and type.</td>
</tr>
</tbody>
</table>
<h3 id="312-derived-data-types">3.1.2 Derived Data Types</h3>
<p>The following types are defined as value constraints applied to String (text string), Binary (octet string) or Integer values. The serialized representation of the base types is specified in <a href="#315-serialization">Section 3.1.5</a>, but there are no restrictions on how derived types are represented internally by an implementation.</p>
<table>
<thead>
<tr class="header">
<th style="text-align: left;">Type</th>
<th style="text-align: left;">Base</th>
<th style="text-align: left;">Description</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td style="text-align: left;">Domain-Name</td>
<td style="text-align: left;">String</td>
<td style="text-align: left;">RFC 1034 Section 3.5</td>
</tr>
<tr class="even">
<td style="text-align: left;">Date-Time</td>
<td style="text-align: left;">Integer</td>
<td style="text-align: left;">Milliseconds since 00:00:00 UTC, 1 January 1970.</td>
</tr>
<tr class="odd">
<td style="text-align: left;">Duration</td>
<td style="text-align: left;">Integer</td>
<td style="text-align: left;">Milliseconds.</td>
</tr>
<tr class="even">
<td style="text-align: left;">Email-Addr</td>
<td style="text-align: left;">String</td>
<td style="text-align: left;">RFC 5322 Section 3.4.1</td>
</tr>
<tr class="odd">
<td style="text-align: left;">Identifier</td>
<td style="text-align: left;">String</td>
<td style="text-align: left;">(TBD rules, e.g., initial alpha followed by alphanumeric or underscore)</td>
</tr>
<tr class="even">
<td style="text-align: left;">IP-Addr</td>
<td style="text-align: left;">Binary</td>
<td style="text-align: left;">32 bit IPv4 address or 128 bit IPv6 address</td>
</tr>
<tr class="odd">
<td style="text-align: left;">MAC-Addr</td>
<td style="text-align: left;">Binary</td>
<td style="text-align: left;">Media Access Control / Extended Unique Identifier address - EUI-48 or EUI-64.</td>
</tr>
<tr class="even">
<td style="text-align: left;">Port</td>
<td style="text-align: left;">Integer</td>
<td style="text-align: left;">16 bit RFC 6335 Transport Protocol Port Number</td>
</tr>
<tr class="odd">
<td style="text-align: left;">Request-Id</td>
<td style="text-align: left;">Binary</td>
<td style="text-align: left;">A value of up to 128 bits</td>
</tr>
<tr class="even">
<td style="text-align: left;">URI</td>
<td style="text-align: left;">String</td>
<td style="text-align: left;">RFC 3986</td>
</tr>
<tr class="odd">
<td style="text-align: left;">UUID</td>
<td style="text-align: left;">Binary</td>
<td style="text-align: left;">128 bit Universal Unique Identifier, RFC 4122 Section 4</td>
</tr>
</tbody>
</table>
<h3 id="313-cardinality">3.1.3 Cardinality</h3>
<p>Property tables for types based on Array, Choice, Map and Record include a cardinality column (#) that specifies the minimum and maximum number of values of a field. The most commonly used cardinalities are:</p>
<ul>
<li>1 Required and not repeatable</li>
<li>0..1 Optional and not repeatable</li>
<li>1..n Required and repeatable</li>
<li>0..n Optional and repeatable</li>
</ul>
<p>The cardinality column may also specify a range of sizes, e.g.,:</p>
<ul>
<li>3..5 Required and repeatable with a minimum of 3 and maximum of 5 values</li>
</ul>
<h3 id="314-derived-enumerations">3.1.4 Derived Enumerations</h3>
<p>An Enumerated field may be derived ("auto-generated") from the fields of a Choice, Map or Record type by appending ".*" to the type name.</p>
<p><strong><em>Type: Example-sel (Record)</em></strong></p>
<table>
<thead>
<tr class="header">
<th style="text-align: left;">ID</th>
<th style="text-align: left;">Name</th>
<th style="text-align: left;">Type</th>
<th style="text-align: left;">#</th>
<th style="text-align: left;">Description</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td style="text-align: left;">1</td>
<td style="text-align: left;">targets</td>
<td style="text-align: left;">Target.*</td>
<td style="text-align: left;">1..n</td>
<td style="text-align: left;">Enumeration auto-generated from a Choice</td>
</tr>
</tbody>
</table>
<h3 id="315-serialization">3.1.5 Serialization</h3>
<p>OpenC2 is agnostic of any particular serialization; however, implementations MUST support JSON serialization in accordance with RFC 7493 and additional requirements specified in the following table.</p>
<p><strong>JSON Serialization Requirements:</strong></p>
<table>
<thead>
<tr class="header">
<th style="text-align: left;">OpenC2 Data Type</th>
<th style="text-align: left;">JSON Serialization Requirement</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td style="text-align: left;"><strong>Binary</strong></td>
<td style="text-align: left;">JSON <strong>string</strong> containing Base64url encoding of the binary value as defined in Section 5 of RFC 4648.</td>
</tr>
<tr class="even">
<td style="text-align: left;"><strong>Boolean</strong></td>
<td style="text-align: left;">JSON <strong>true</strong> or <strong>false</strong></td>
</tr>
<tr class="odd">
<td style="text-align: left;"><strong>Integer</strong></td>
<td style="text-align: left;">JSON <strong>number</strong></td>
</tr>
<tr class="even">
<td style="text-align: left;"><strong>Number</strong></td>
<td style="text-align: left;">JSON <strong>number</strong></td>
</tr>
<tr class="odd">
<td style="text-align: left;"><strong>Null</strong></td>
<td style="text-align: left;">JSON <strong>null</strong></td>
</tr>
<tr class="even">
<td style="text-align: left;"><strong>String</strong></td>
<td style="text-align: left;">JSON <strong>string</strong></td>
</tr>
<tr class="odd">
<td style="text-align: left;"><strong>Array</strong></td>
<td style="text-align: left;">JSON <strong>array</strong></td>
</tr>
<tr class="even">
<td style="text-align: left;"><strong>ArrayOf</strong></td>
<td style="text-align: left;">JSON <strong>array</strong></td>
</tr>
<tr class="odd">
<td style="text-align: left;"><strong>Choice</strong></td>
<td style="text-align: left;">JSON <strong>object</strong> with one member. Member key is the field name.</td>
</tr>
<tr class="even">
<td style="text-align: left;">Choice.ID</td>
<td style="text-align: left;">JSON <strong>object</strong> with one member. Member key is the integer field id converted to string.</td>
</tr>
<tr class="odd">
<td style="text-align: left;"><strong>Enumerated</strong></td>
<td style="text-align: left;">JSON <strong>string</strong></td>
</tr>
<tr class="even">
<td style="text-align: left;"><strong>Enumerated.ID</strong></td>
<td style="text-align: left;">JSON <strong>integer</strong></td>
</tr>
<tr class="odd">
<td style="text-align: left;"><strong>Map</strong></td>
<td style="text-align: left;">JSON <strong>object</strong>. Member keys are field names.</td>
</tr>
<tr class="even">
<td style="text-align: left;"><strong>Map.ID</strong></td>
<td style="text-align: left;">JSON <strong>object</strong>. Member keys are integer field ids converted to strings.</td>
</tr>
<tr class="odd">
<td style="text-align: left;"><strong>Record</strong></td>
<td style="text-align: left;">JSON <strong>object</strong>. Member keys are field names.</td>
</tr>
</tbody>
</table>
<h4 id="3151-id-and-name-serialization">3.1.5.1 ID and Name Serialization</h4>
<p>Instances of Enumerated types and keys for Choice and Map types are serialized as ID values except when using serialization formats intended for human consumption, where Name strings are used instead. Defining a type using ".ID" appended to the base type (e.g., Enumerated.ID, Map.ID) indicates that:</p>
<ol>
<li>Type definitions and application values use only the ID. There is no corresponding name except as an optional part of the description.</li>
<li>Instances of Enumerated values and Choice/Map keys are serialized as IDs regardless of serialization format.</li>
</ol>
<h4 id="3152-integer-serialization">3.1.5.2 Integer Serialization</h4>
<p>For machine-to-machine serialization formats, integers are represented as binary data, e.g., 32 bits, 128 bits. But for human-readable serialization formats (XML and JSON), integers are converted to strings. For example, the JSON "number" type represents integers and real numbers as decimal strings without quotes, e.g., { "height": 68.2 }, and as noted in RFC 7493 Section 2.2, a sender cannot expect a receiver to treat an integer with an absolute value greater than 2^^53 as an exact value.</p>
<p>The default representation of Integer types in text serializations is the native integer type for that format, e.g., "number" for JSON. Integer fields with a range larger than the IEEE 754 exact range (e.g., 64, 128, 2048 bit values) are indicated by appending ".<bit-size>" or ".<em>" to the type, e.g. Integer.64 or Integer.</em>. All serializations ensure that large Integer types are transferred exactly, for example in the same manner as Binary types. Integer values support arithmetic operations; Binary values are not intended for that purpose.</p>
<h2 id="32-message">3.2 Message</h2>
<p>As described in Section 1.1, this language specification and one or more actuator profiles define the content of OpenC2 commands and responses, while transfer specifications define the on-the-wire format of a message over specific secure transport protocols. Transfer specifications are agnostic with regard to content, and content is agnostic with regard to transfer protocol. This decoupling is accomplished by defining a standard message interface used to transfer any type of content over any transfer protocol.</p>
<p>A message is a content- and transport-independent set of elements conveyed between consumers and producers. To ensure interoperability all transfer specifications must unambiguously define how the message elements in <a href="#table-3-1-common-message-elements">Table 3-1</a> are represented within the secure transport protocol. This does not imply that all message elements must be used in all messages. Content, content_type, and msg_type are required, while other message elements are not required by this specification but may be required by other documents.</p>
<h6 id="table-3-1-common-message-elements">Table 3-1. Common Message Elements</h6>
<table>
<thead>
<tr class="header">
<th style="text-align: left;">Name</th>
<th style="text-align: left;">Description</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td style="text-align: left;"><strong>content</strong></td>
<td style="text-align: left;">Message body as specified by content_type and msg_type.</td>
</tr>
<tr class="even">
<td style="text-align: left;"><strong>content_type</strong></td>
<td style="text-align: left;">String. Media Type that identifies the format of the content, including major version. Incompatible content formats must have different content_types. Content_type <strong>application/openc2</strong> identifies content defined by OpenC2 language specification versions 1.x, i.e., all versions that are compatible with version 1.0.</td>
</tr>
<tr class="odd">
<td style="text-align: left;"><strong>msg_type</strong></td>
<td style="text-align: left;">Message-Type. One of <strong>request</strong>, <strong>response</strong>, or <strong>notification</strong>. For the <strong>application/openc2</strong> content_type the request content is an OpenC2-Command and the response content is an OpenC2-Response. OpenC2 does not currently define any notification content.</td>
</tr>
<tr class="even">
<td style="text-align: left;"><strong>status</strong></td>
<td style="text-align: left;">Status-Code. Populated with a numeric status code in response messages. Not present in request or notification messages.</td>
</tr>
<tr class="odd">
<td style="text-align: left;"><strong>request_id</strong></td>
<td style="text-align: left;">Request-Id. A unique identifier value of up to 128 bits that is attached to request and response messages. This value is assigned by the sender and is copied unmodified into all responses to support reference to a particular command, transaction or event chain.</td>
</tr>
<tr class="even">
<td style="text-align: left;"><strong>created</strong></td>
<td style="text-align: left;">Date-Time. Creation date/time of the content, the number of milliseconds since 00:00:00 UTC, 1 January 1970.</td>
</tr>
<tr class="odd">
<td style="text-align: left;"><strong>from</strong></td>
<td style="text-align: left;">String. Authenticated identifier of the creator of or authority for execution of a message.</td>
</tr>
<tr class="even">
<td style="text-align: left;"><strong>to</strong></td>
<td style="text-align: left;">ArrayOf(String). Authenticated identifier(s) of the authorized recipient(s) of a message.</td>
</tr>
</tbody>
</table>
<p>Implementations may use environment variables, private APIs, data structures, class instances, pointers, or other mechanisms to represent messages within the local environment. However the internal representation of a message does not affect interoperability and is therefore beyond the scope of OpenC2. This means that the message content is a data structure in whatever form is used within an implementation, not a serialized representation of that structure. Content is the input provided to a serializer or the output of a de-serializer. Msg_type is a three-element enumeration whose protocol representation is defined in each transfer spec, for example as a string, an integer, or a two-bit field. The internal form of enumerations, like content, does not affect interoperability and is therefore unspecified.</p>
<h2 id="33-content">3.3 Content</h2>
<p>The scope of this specification is to define the ACTION and TARGET portions of an OpenC2 command and the common portions of an OpenC2 response. The properties of the OpenC2 command are defined in <a href="#331-openc2-command">Section 3.3.1</a> and the properties of the response are defined in <a href="#332-openc2-response">Section 3.3.2</a>.</p>
<p>In addition to the ACTION and TARGET, an OpenC2 command has an optional ACTUATOR. Other than identification of namespace identifier, the semantics associated with the ACTUATOR specifiers are beyond the scope of this specification. The actuators and actuator-specific results contained in a response are specified in ‘Actuator Profile Specifications’ such as StateLess Packet Filtering Profile, Routing Profile etc.</p>
<h3 id="331-openc2-command">3.3.1 OpenC2 Command</h3>
<p>The OpenC2 Command describes an action performed on a target.</p>
<p><strong><em>Type: OpenC2-Command (Record)</em></strong></p>
<table>
<thead>
<tr class="header">
<th style="text-align: left;">ID</th>
<th style="text-align: left;">Name</th>
<th style="text-align: left;">Type</th>
<th style="text-align: left;">#</th>
<th style="text-align: left;">Description</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td style="text-align: left;">1</td>
<td style="text-align: left;"><strong>action</strong></td>
<td style="text-align: left;">Action</td>
<td style="text-align: left;">1</td>
<td style="text-align: left;">The task or activity to be performed (i.e., the 'verb').</td>
</tr>
<tr class="even">
<td style="text-align: left;">2</td>
<td style="text-align: left;"><strong>target</strong></td>
<td style="text-align: left;">Target</td>
<td style="text-align: left;">1</td>
<td style="text-align: left;">The object of the action. The action is performed on the target.</td>
</tr>
<tr class="odd">
<td style="text-align: left;">3</td>
<td style="text-align: left;"><strong>args</strong></td>
<td style="text-align: left;">Args</td>
<td style="text-align: left;">0..1</td>
<td style="text-align: left;">Additional information that applies to the command.</td>
</tr>
<tr class="even">
<td style="text-align: left;">4</td>
<td style="text-align: left;"><strong>actuator</strong></td>
<td style="text-align: left;">Actuator</td>
<td style="text-align: left;">0..1</td>
<td style="text-align: left;">The subject of the action. The actuator executes the action on the target.</td>
</tr>
</tbody>
</table>
<h4 id="3311-action">3.3.1.1 Action</h4>
<p><strong><em>Type: Action (Enumerated)</em></strong></p>
<table>
<thead>
<tr class="header">
<th style="text-align: left;">ID</th>
<th style="text-align: left;">Name</th>
<th style="text-align: left;">Description</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td style="text-align: left;">1</td>
<td style="text-align: left;"><strong>scan</strong></td>
<td style="text-align: left;">Systematic examination of some aspect of the entity or its environment.</td>
</tr>
<tr class="even">
<td style="text-align: left;">2</td>
<td style="text-align: left;"><strong>locate</strong></td>
<td style="text-align: left;">Find an object physically, logically, functionally, or by organization.</td>
</tr>
<tr class="odd">
<td style="text-align: left;">3</td>
<td style="text-align: left;"><strong>query</strong></td>
<td style="text-align: left;">Initiate a request for information.</td>
</tr>
<tr class="even">
<td style="text-align: left;">6</td>
<td style="text-align: left;"><strong>deny</strong></td>
<td style="text-align: left;">Prevent a certain event or action from completion, such as preventing a flow from reaching a destination or preventing access.</td>
</tr>
<tr class="odd">
<td style="text-align: left;">7</td>
<td style="text-align: left;"><strong>contain</strong></td>
<td style="text-align: left;">Isolate a file, process, or entity so that it cannot modify or access assets or processes.</td>
</tr>
<tr class="even">
<td style="text-align: left;">8</td>
<td style="text-align: left;"><strong>allow</strong></td>
<td style="text-align: left;">Permit access to or execution of a target.</td>
</tr>
<tr class="odd">
<td style="text-align: left;">9</td>
<td style="text-align: left;"><strong>start</strong></td>
<td style="text-align: left;">Initiate a process, application, system, or activity.</td>
</tr>
<tr class="even">
<td style="text-align: left;">10</td>
<td style="text-align: left;"><strong>stop</strong></td>
<td style="text-align: left;">Halt a system or end an activity.</td>
</tr>
<tr class="odd">
<td style="text-align: left;">11</td>
<td style="text-align: left;"><strong>restart</strong></td>
<td style="text-align: left;">Stop then start a system or an activity.</td>
</tr>
<tr class="even">
<td style="text-align: left;">14</td>
<td style="text-align: left;"><strong>cancel</strong></td>
<td style="text-align: left;">Invalidate a previously issued action.</td>
</tr>
<tr class="odd">
<td style="text-align: left;">15</td>
<td style="text-align: left;"><strong>set</strong></td>
<td style="text-align: left;">Change a value, configuration, or state of a managed entity.</td>
</tr>
<tr class="even">
<td style="text-align: left;">16</td>
<td style="text-align: left;"><strong>update</strong></td>
<td style="text-align: left;">Instruct a component to retrieve, install, process, and operate in accordance with a software update, reconfiguration, or other update.</td>
</tr>
<tr class="odd">
<td style="text-align: left;">18</td>
<td style="text-align: left;"><strong>redirect</strong></td>
<td style="text-align: left;">Change the flow of traffic to a destination other than its original destination.</td>
</tr>
<tr class="even">
<td style="text-align: left;">19</td>
<td style="text-align: left;"><strong>create</strong></td>
<td style="text-align: left;">Add a new entity of a known type (e.g., data, files, directories).</td>
</tr>
<tr class="odd">
<td style="text-align: left;">20</td>
<td style="text-align: left;"><strong>delete</strong></td>
<td style="text-align: left;">Remove an entity (e.g., data, files, flows).</td>
</tr>
<tr class="even">
<td style="text-align: left;">22</td>
<td style="text-align: left;"><strong>detonate</strong></td>
<td style="text-align: left;">Execute and observe the behavior of a target (e.g., file, hyperlink) in an isolated environment.</td>
</tr>
<tr class="odd">
<td style="text-align: left;">23</td>
<td style="text-align: left;"><strong>restore</strong></td>
<td style="text-align: left;">Return a system to a previously known state.</td>
</tr>
<tr class="even">
<td style="text-align: left;">28</td>
<td style="text-align: left;"><strong>copy</strong></td>
<td style="text-align: left;">Duplicate an object, file, data flow or artifact.</td>
</tr>
<tr class="odd">
<td style="text-align: left;">30</td>
<td style="text-align: left;"><strong>investigate</strong></td>
<td style="text-align: left;">Task the recipient to aggregate and report information as it pertains to a security event or incident.</td>
</tr>
<tr class="even">
<td style="text-align: left;">32</td>
<td style="text-align: left;"><strong>remediate</strong></td>
<td style="text-align: left;">Task the recipient to eliminate a vulnerability or attack point.</td>
</tr>
</tbody>
</table>
<p>The following actions are under consideration for use in future versions of the Language Specification. Implementers may use these actions with the understanding that they may not be in future versions of the language.</p>
<ul>
<li><strong>report</strong> - Task an entity to provide information to a designated recipient</li>
<li><strong>pause</strong> - Cease operation of a system or activity while maintaining state.</li>
<li><strong>resume</strong> - Start a system or activity from a paused state</li>
<li><strong>move</strong> - Change the location of a file, subnet, network, or process</li>
<li><strong>snapshot</strong> - Record and store the state of a target at an instant in time</li>
<li><strong>save</strong> - Commit data or system state to memory</li>
<li><strong>throttle</strong> - Adjust the rate of a process, function, or activity</li>
<li><strong>delay</strong> - Stop or hold up an activity or data transmittal</li>
<li><strong>substitute</strong> - Replace all or part of the payload</li>
<li><strong>sync</strong> - Synchronize a sensor or actuator with other system components</li>
<li><strong>mitigate</strong> - Task the recipient to circumvent a problem without necessarily eliminating the vulnerability or attack point</li>
</ul>
<p><strong>Usage Requirements:</strong></p>
<ul>
<li>Each command MUST contain exactly one action.</li>
<li>All commands MUST only use actions from this section (either the table or the list)</li>
<li>Actions defined external to this section SHALL NOT be used.</li>
</ul>
<h4 id="3312-target">3.3.1.2 Target</h4>
<p><strong><em>Type: Target (Choice)</em></strong></p>
<table>
<thead>
<tr class="header">
<th style="text-align: left;">ID</th>
<th style="text-align: left;">Name</th>
<th style="text-align: left;">Type</th>
<th style="text-align: left;">#</th>
<th style="text-align: left;">Description</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td style="text-align: left;">1</td>
<td style="text-align: left;"><strong>artifact</strong></td>
<td style="text-align: left;">Artifact</td>
<td style="text-align: left;">1</td>
<td style="text-align: left;">An array of bytes representing a file-like object or a link to that object.</td>
</tr>
<tr class="even">
<td style="text-align: left;">2</td>
<td style="text-align: left;"><strong>command</strong></td>