-
Notifications
You must be signed in to change notification settings - Fork 5
/
Copy pathoc2arch-v1.0-cs01.html
1055 lines (1054 loc) · 91.7 KB
/
oc2arch-v1.0-cs01.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 describes the abstract architecture of OpenC2 to provide a common understanding of the messages and interactions for all bindings and serializations.">
<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) Architecture Specification Version 1.0</title>
<link rel="stylesheet" href="styles/markdown-styles-v1.8-cn.css" />
</head>
<body>
<p><img src="https://docs.oasis-open.org/templates/OASISLogo-v3.0.png" alt="OASIS Logo" /></p>
<hr style="page-break-before: avoid" />
<h1big id="open-command-and-control-openc2-architecture-specification-version-10">Open Command and Control (OpenC2) Architecture Specification Version 1.0</h1big>
<h2 id="committee-specification-01">Committee Specification 01</h2>
<h2 id="30-september">30 September</h2>
<p> </p>
<h4 id="this-stage">This stage:</h4>
<p><a href="https://docs.oasis-open.org/openc2/oc2arch/v1.0/cs01/oc2arch-v1.0-cs01.md">https://docs.oasis-open.org/openc2/oc2arch/v1.0/cs01/oc2arch-v1.0-cs01.md</a> (Authoritative) <br />
<a href="https://docs.oasis-open.org/openc2/oc2arch/v1.0/cs01/oc2arch-v1.0-cs01.html">https://docs.oasis-open.org/openc2/oc2arch/v1.0/cs01/oc2arch-v1.0-cs01.html</a> <br />
<a href="https://docs.oasis-open.org/openc2/oc2arch/v1.0/cs01/oc2arch-v1.0-cs01.pdf">https://docs.oasis-open.org/openc2/oc2arch/v1.0/cs01/oc2arch-v1.0-cs01.pdf</a></p>
<h4 id="previous-stage">Previous stage:</h4>
<p><a href="https://docs.oasis-open.org/openc2/oc2arch/v1.0/csd02/oc2arch-v1.0-csd02.md">https://docs.oasis-open.org/openc2/oc2arch/v1.0/csd02/oc2arch-v1.0-csd02.md</a> (Authoritative) <br />
<a href="https://docs.oasis-open.org/openc2/oc2arch/v1.0/csd02/oc2arch-v1.0-csd02.html">https://docs.oasis-open.org/openc2/oc2arch/v1.0/csd02/oc2arch-v1.0-csd02.html</a> <br />
<a href="https://docs.oasis-open.org/openc2/oc2arch/v1.0/csd02/oc2arch-v1.0-csd02.pdf">https://docs.oasis-open.org/openc2/oc2arch/v1.0/csd02/oc2arch-v1.0-csd02.pdf</a></p>
<h4 id="latest-stage">Latest stage:</h4>
<p><a href="https://docs.oasis-open.org/openc2/oc2arch/v1.0/oc2arch-v1.0.md">https://docs.oasis-open.org/openc2/oc2arch/v1.0/oc2arch-v1.0.md</a> (Authoritative) <br />
<a href="https://docs.oasis-open.org/openc2/oc2arch/v1.0/oc2arch-v1.0.html">https://docs.oasis-open.org/openc2/oc2arch/v1.0/oc2arch-v1.0.html</a> <br />
<a href="https://docs.oasis-open.org/openc2/oc2arch/v1.0/oc2arch-v1.0.pdf">https://docs.oasis-open.org/openc2/oc2arch/v1.0/oc2arch-v1.0.pdf</a></p>
<h4 id="technical-committee">Technical Committee:</h4>
<p><a href="https://www.oasis-open.org/committees/openc2/">OASIS Open Command and Control (OpenC2) TC</a></p>
<h4 id="chairs">Chairs:</h4>
<p>Duncan Sparrell (<a href="mailto:[email protected]">[email protected]</a>), <a href="https://www.sfractal.com/">sFractal Consulting LLC</a> <br />
Michael Rosa (<a href="mailto:[email protected]">[email protected]</a>), <a href="https://www.nsa.gov/">National Security Agency</a></p>
<h4 id="editor">Editor:</h4>
<p>Duncan Sparrell (<a href="mailto:[email protected]">[email protected]</a>), <a href="http://www.sfractal.com/">sFractal Consulting LLC</a></p>
<h4 id="related-work">Related work:</h4>
<p>This specification is related to:</p>
<ul>
<li><em>Open Command and Control (OpenC2) Language Specification Version 1.0</em>. Edited by Jason Romano and Duncan Sparrell. Latest stage: <a href="https://docs.oasis-open.org/openc2/oc2ls/v1.0/oc2ls-v1.0.html">https://docs.oasis-open.org/openc2/oc2ls/v1.0/oc2ls-v1.0.html</a>.</li>
</ul>
<h4 id="abstract">Abstract:</h4>
<p>Cyberattacks are increasingly sophisticated, less expensive to execute, dynamic and automated. The provision of cyber defense 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.</p>
<p>This document describes the abstract architecture of OpenC2 to define a common understanding of the messages and interactions for all bindings and serializations.</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 stage" 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">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 "<a href="https://www.oasis-open.org/committees/comments/index.php?wg_abbrev=openc2">Send A Comment</a>" button on the TC's web page at <a href="https://www.oasis-open.org/committees/openc2/">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 <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">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-2017-05-26/#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="key-words">Key words:</h4>
<p>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [<a href="#rfc2119">RFC2119</a>] and [<a href="#rfc8174">RFC8174</a>] when, and only when, they appear in all capitals, as shown here.</p>
<h4 id="citation-format">Citation format:</h4>
<p>When referencing this specification the following citation format should be used:</p>
<p><strong>[OpenC2-Arch-v1.0]</strong></p>
<p><em>Open Command and Control (OpenC2) Architecture Specification Version 1.0</em>. Edited by Duncan Sparrell. 30 September 2022. OASIS Committee Specification 01. <a href="https://docs.oasis-open.org/openc2/oc2arch/v1.0/cs01/oc2arch-v1.0-cs01.html">https://docs.oasis-open.org/openc2/oc2arch/v1.0/cs01/oc2arch-v1.0-cs01.html</a>. Latest stage: <a href="https://docs.oasis-open.org/openc2/oc2arch/v1.0/oc2arch-v1.0.html">https://docs.oasis-open.org/openc2/oc2arch/v1.0/oc2arch-v1.0.html</a>.</p>
<h4 id="notices">Notices</h4>
<p>Copyright © OASIS Open 2022. All Rights Reserved.</p>
<p>Distributed under the terms of the <a href="https://www.oasis-open.org/policies-guidelines/ipr/">OASIS IPR Policy</a>.</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.</p>
<p>For complete copyright information please see the full Notices section in <a href="#appendix-g-notices">Appendix G</a> below.</p>
<hr />
<h1 id="table-of-contents">Table of Contents</h1>
<ul type="none">
<li><a href="#1-introduction">1 Introduction</a>
<ul type="none">
<li><a href="#11-changes-from-earlier-versions">1.1 Changes from earlier versions</a></li>
<li><a href="#12-goal">1.2 Goal</a></li>
<li><a href="#13-glossary">1.3 Glossary</a>
<ul type="none">
<li><a href="#131-definitions-of-terms">1.3.1 Definitions of terms</a></li>
<li><a href="#132-acronyms-and-abbreviations">1.3.2 Acronyms and abbreviations</a></li>
</ul></li>
</ul></li>
<li><a href="#2-openc2-architecture">2 OpenC2 Architecture</a>
<ul type="none">
<li><a href="#21-commands">2.1 Commands</a></li>
<li><a href="#22-responses">2.2 Responses</a></li>
<li><a href="#23-design-patterns">2.3 Design Patterns</a>
<ul type="none">
<li><a href="#231-producers-consumers-and-devices">2.3.1 Producers, Consumers, and Devices</a></li>
<li><a href="#232-action-target-model">2.3.2 Action-Target Model</a></li>
<li><a href="#233-introspection-model">2.3.3 Introspection Model</a></li>
</ul></li>
<li><a href="#24-implementations">2.4 Implementations</a></li>
</ul></li>
<li><a href="#3-conformance">3 Conformance</a>
<ul type="none">
<li><a href="#31-conformance-related-definitions">3.1 Conformance-Related Definitions</a></li>
<li><a href="#32-openc2-producer-conformance-clauses">3.2 OpenC2 Producer Conformance Clauses</a></li>
<li><a href="#33-openc2-consumer-conformance-clauses">3.3 OpenC2 Consumer Conformance Clauses</a></li>
<li><a href="#34-openc2-cap-conformance-clauses">3.4 OpenC2 CAP Conformance Clauses</a></li>
</ul></li>
<li><a href="#appendix-a-references">Appendix A. References</a>
<ul type="none">
<li><a href="#a1-normative-references">A.1 Normative References</a></li>
<li><a href="#a2-informative-references">A.2 Informative References</a></li>
</ul></li>
<li><a href="#appendix-b-safety-security-and-privacy-considerations">Appendix B. Safety, Security and Privacy Considerations</a>
<ul type="none">
<li><a href="#b1-overview">B.1 Overview</a></li>
<li><a href="#b2-threats">B.2 Threats</a></li>
<li><a href="#b3-security-services">B.3 Security Services</a></li>
<li><a href="#b4-network-topologies">B.4 Network Topologies</a></li>
</ul></li>
<li><a href="#appendix-c-acknowledgments">Appendix C. Acknowledgments</a></li>
<li><a href="#appendix-d-revision-history">Appendix D. Revision History</a></li>
<li><a href="#appendix-e-examples">Appendix E. Examples</a>
<ul type="none">
<li><a href="#e1-application-of-actuator-profiles-and-transfer-specifications">E.1 Application of Actuator Profiles and Transfer Specifications</a></li>
<li><a href="#e2-actuator-profile-typical-content">E.2 Actuator Profile Typical Content</a></li>
<li><a href="#e3-transfer-specification-typical-content">E.3 Transfer Specification Typical Content</a></li>
</ul></li>
<li><a href="#appendix-f-openc2-namespace-registry">Appendix F. OpenC2 Namespace Registry</a></li>
<li><a href="#appendix-g-notices">Appendix G. Notices</a></li>
</ul>
<hr />
<h1 id="1-introduction">1 Introduction</h1>
<p><em>The content in this section is non-normative, except where it is marked normative.</em></p>
<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 <em>Command</em> is encoded by a <em>Producer</em> (managing application) and transferred to a <em>Consumer</em> (managed device or virtualized function) using a secure transfer protocol, and the Consumer can respond with status and any requested information.</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>
<p>OpenC2 is defined across a family of specifications of several types:</p>
<ul>
<li><p>The <strong>OpenC2 Architecture Specification</strong> (this document) describes the fundamental structures of OpenC2 and provides a blueprint for developing Actuator Profiles and Transfer Specifications.</p></li>
<li><p>The <strong>OpenC2 Language Specification</strong> 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. The Language Specification also defines the mechanisms for extending the OpenC2 language. <a href="#openc2-lang-v10">[OpenC2-Lang-v1.0]</a></p></li>
<li><p><strong>OpenC2 Actuator Profiles</strong> 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 profiles. A profile refines the meaning of language elements (actions, targets, command arguments, results) used to perform the actuator function, and often defines additional elements that are relevant and/or unique to that function.</p></li>
<li><p><strong>OpenC2 Transfer Specifications</strong> utilize existing protocols and standards to implement OpenC2 message transfer 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 transport of OpenC2 Messages.</p></li>
</ul>
<p>The OpenC2 language is described in the Language Specification using an abstract information model that does not specify any particular message encoding form (i.e., serialization). The most common encoding of OpenC2 messages is in JSON and the OpenC2 family of specifications presents examples in JSON format. Other encodings are permitted and are defined in their respective documents (e.g., a transfer specification). Similarly, OpenC2 messages can be conveyed using a variety of transfer mechanisms, using both point-to-point (e.g., HTTPS) and publish/subscribe (e.g., MQTT) communication models. The selection of message content encoding is determined by a combination of the environment where OpenC2 is being applied and the capabilities and limitations of the chosen transfer specification.</p>
<h2 id="11-changes-from-earlier-versions">1.1 Changes from earlier versions</h2>
<ul>
<li>Updated conformance section from preliminary draft and refined language</li>
<li>Added example message exchange in JSON format</li>
<li>Populated revision history and acknowledgements</li>
</ul>
<h2 id="12-goal">1.2 Goal</h2>
<p>OpenC2 is developing 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 guide the design of OpenC2:</p>
<ul>
<li><p><strong>Technology Agnostic:</strong> The OpenC2 language defines a set of abstract atomic cyber defense actions in a platform- and implementation-agnostic manner</p></li>
<li><p><strong>Concise:</strong> A 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</p></li>
<li><p><strong>Abstract:</strong> Commands and Responses are defined abstractly and can be encoded and transferred via multiple schemes as dictated by the needs of different implementation environments</p></li>
<li><p><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.</p></li>
</ul>
<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.</p>
<h2 id="13-glossary">1.3 Glossary</h2>
<h3 id="131-definitions-of-terms">1.3.1 Definitions of terms</h3>
<p><em>This section is normative.</em></p>
<ul>
<li><p><strong>Action</strong>: The task or activity to be performed (e.g., 'deny').</p></li>
<li><p><strong>Actuator</strong>: The Consumer that executes the Command.</p></li>
<li><p><strong>Actuator Profile</strong>: The document that defines a category of operations performed by an Actuator (e.g., 'Stateless Packet Filtering').</p></li>
<li><p><strong>Argument</strong>: A property of a Command that provides additional information on how to perform the Command, such as date/time, periodicity, duration, etc.</p></li>
<li><p><strong>Command</strong>: A Message defined by an Action-Target pair that is sent from a Producer and received by a Consumer.</p></li>
<li><p><strong>Consumer</strong>: A managed device / application that receives Commands. Note that a single device / application can have both Consumer and Producer capabilities.</p></li>
<li><p><strong>Message</strong>: A content- and transport-independent set of elements conveyed between Consumers and Producers.</p></li>
<li><p><strong>Producer</strong>: A manager application that sends Commands.</p></li>
<li><p><strong>Request</strong>: A Message from a Producer to a Consumer used to convey a Command.</p></li>
<li><p><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 Command.</p></li>
<li><p><strong>Specifier</strong>: A property or field that identifies a Target to some level of precision.</p></li>
<li><p><strong>Target</strong>: The object of the Action, i.e., the Action is performed on the Target (e.g., IP Address).</p></li>
</ul>
<h3 id="132-acronyms-and-abbreviations">1.3.2 Acronyms and abbreviations</h3>
<table>
<thead>
<tr class="header">
<th>Acronym</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td>API</td>
<td>Application Programming Interface</td>
</tr>
<tr class="even">
<td>AP</td>
<td>Actuator Profile</td>
</tr>
<tr class="odd">
<td>ASCII</td>
<td>American Standard Code for Information Interchange</td>
</tr>
<tr class="even">
<td>BCP</td>
<td>Best Current Practice</td>
</tr>
<tr class="odd">
<td>CBOR</td>
<td>Concise Binary Object Representation</td>
</tr>
<tr class="even">
<td>CIDR</td>
<td>Classless Inter-Domain Routing</td>
</tr>
<tr class="odd">
<td>CoAP</td>
<td>Constrained Application Protocol</td>
</tr>
<tr class="even">
<td>COSE</td>
<td>CBOR Object Signing and Encryption</td>
</tr>
<tr class="odd">
<td>DOI</td>
<td>Digital Object Identifier</td>
</tr>
<tr class="even">
<td>ER</td>
<td>Endpoint Response</td>
</tr>
<tr class="odd">
<td>EUI</td>
<td>Extended Unique Identifier</td>
</tr>
<tr class="even">
<td>HTTP</td>
<td>Hyper Text Transfer Protocol</td>
</tr>
<tr class="odd">
<td>HTTPS</td>
<td>Hyper Text Transfer Protocol Secure</td>
</tr>
<tr class="even">
<td>IACD</td>
<td>Integrated Adaptive Cyber Defense</td>
</tr>
<tr class="odd">
<td>IANA</td>
<td>Internet Assigned Numbers Authority</td>
</tr>
<tr class="even">
<td>ICMP</td>
<td>Internet Control Message Protocol</td>
</tr>
<tr class="odd">
<td>ID</td>
<td>Identifier</td>
</tr>
<tr class="even">
<td>IP</td>
<td>Internet Protocol</td>
</tr>
<tr class="odd">
<td>IoT</td>
<td>Internet of Things</td>
</tr>
<tr class="even">
<td>IPR</td>
<td>Intellectual Property Rights</td>
</tr>
<tr class="odd">
<td>JOSE</td>
<td>JSON Object Signing and Encryption</td>
</tr>
<tr class="even">
<td>JSON</td>
<td>JavaScript Object Notation</td>
</tr>
<tr class="odd">
<td>LS</td>
<td>Language Specification</td>
</tr>
<tr class="even">
<td>MAC</td>
<td>Media Access Control</td>
</tr>
<tr class="odd">
<td>MQTT</td>
<td>Message Queuing Telemetry Transfer</td>
</tr>
<tr class="even">
<td>OASIS</td>
<td>Organization for the Advancement of Structured Information Standards</td>
</tr>
<tr class="odd">
<td>OODA</td>
<td>Observe-Orient-Decide-Act</td>
</tr>
<tr class="even">
<td>OOBM</td>
<td>Out-of-Band Management</td>
</tr>
<tr class="odd">
<td>OpenC2</td>
<td>Open Command and Control</td>
</tr>
<tr class="even">
<td>OpenDXL</td>
<td>Open Data eXchange Layer</td>
</tr>
<tr class="odd">
<td>PDF</td>
<td>Portable Document Format</td>
</tr>
<tr class="even">
<td>RFC</td>
<td>Request for Comment</td>
</tr>
<tr class="odd">
<td>SCTP</td>
<td>Stream Control Transmission Protocol</td>
</tr>
<tr class="even">
<td>SHA</td>
<td>Secure Hash Algorithms</td>
</tr>
<tr class="odd">
<td>SLPF</td>
<td>StateLess Packet Filtering</td>
</tr>
<tr class="even">
<td>STD</td>
<td>Standard</td>
</tr>
<tr class="odd">
<td>TC</td>
<td>Technical Committee</td>
</tr>
<tr class="even">
<td>TCP</td>
<td>Transmission Control Protocol</td>
</tr>
<tr class="odd">
<td>UDP</td>
<td>User Datagram Protocol</td>
</tr>
<tr class="even">
<td>UML</td>
<td>Unified Modeling Language</td>
</tr>
<tr class="odd">
<td>URI</td>
<td>Uniform Resource Identifier</td>
</tr>
<tr class="even">
<td>UTC</td>
<td>Coordinated Universal Time</td>
</tr>
<tr class="odd">
<td>UUID</td>
<td>Universally Unique IDentifier</td>
</tr>
<tr class="even">
<td>VLAN</td>
<td>Virtual Local Area Network</td>
</tr>
<tr class="odd">
<td>XML</td>
<td>eXtensible Markup Language</td>
</tr>
</tbody>
</table>
<hr />
<h1 id="2-openc2-architecture">2 OpenC2 Architecture</h1>
<p>OpenC2 is a suite of specifications for Producers and Consumers to command and execute cyber defense functions. These specifications include the OpenC2 Language Specification, Actuator Profiles (APs), and Transfer Specifications. The OpenC2 <a href="#openc2-lang-v10">Language Specification</a> and Actuator Profile specifications focus on the language content and meaning at the Producer and Consumer level of Command and Response while the transfer specifications focus on the protocols for their exchange. The language is defined abstractly in the Language Specification, permitting flexibility of message serialization and transfer protocol choices when implementing OpenC2. Interoperability between specific OpenC2 implementations is dependent on the selection of common serialization and transfer mechanisms.</p>
<p>In general, there are two types of participants involved in the exchange of OpenC2 Messages, as depicted in Figure 2-1:</p>
<ol>
<li><strong>Producers</strong>: A Producer is an entity that creates and transmits Commands instructing one or more systems to execute Actions as specified in the Command. A Producer may receive and process Responses in conjunction with a Command.</li>
<li><strong>Consumers</strong>: A Consumer is an entity that receives and may act upon a Command. A Consumer may create Responses that provide any information captured or necessary to send back to the Producer.</li>
</ol>
<p><strong>Figure 2-1. OpenC2 Message Exchange</strong></p>
<p><img src="images/MessageFlow.png" alt="OpenC2 Message Exchange" /></p>
<p>The Language Specification defines two distinct content types (i.e., payload structures): Command and Response. The following example, drawn from the AP for Stateless Packet Filtering [<a href="#openc2-slpf-v10">SLPF</a>], illustrates the general structure of OpenC2 Command and Response message payloads, using the common JSON serialization. The example action permits <code>ftp</code> data transfers to <code>3ffe:1900:4545:3::f8ff:fe21:67cf</code> from any source.</p>
<p><strong>Command:</strong></p>
<div class="sourceCode" id="cb1"><pre class="sourceCode json"><code class="sourceCode json"><a class="sourceLine" id="cb1-1" title="1"><span class="fu">{</span></a>
<a class="sourceLine" id="cb1-2" title="2"> <span class="dt">"action"</span><span class="fu">:</span> <span class="st">"allow"</span><span class="fu">,</span></a>
<a class="sourceLine" id="cb1-3" title="3"> <span class="dt">"target"</span><span class="fu">:</span> <span class="fu">{</span></a>
<a class="sourceLine" id="cb1-4" title="4"> <span class="dt">"ipv6_connection"</span><span class="fu">:</span> <span class="fu">{</span></a>
<a class="sourceLine" id="cb1-5" title="5"> <span class="dt">"protocol"</span><span class="fu">:</span> <span class="st">"tcp"</span><span class="fu">,</span></a>
<a class="sourceLine" id="cb1-6" title="6"> <span class="dt">"dst_addr"</span><span class="fu">:</span> <span class="st">"3ffe:1900:4545:3::f8ff:fe21:67cf"</span><span class="fu">,</span></a>
<a class="sourceLine" id="cb1-7" title="7"> <span class="dt">"src_port"</span><span class="fu">:</span> <span class="dv">21</span></a>
<a class="sourceLine" id="cb1-8" title="8"> <span class="fu">}</span></a>
<a class="sourceLine" id="cb1-9" title="9"> <span class="fu">},</span></a>
<a class="sourceLine" id="cb1-10" title="10"> <span class="dt">"actuator"</span><span class="fu">:</span> <span class="fu">{</span></a>
<a class="sourceLine" id="cb1-11" title="11"> <span class="dt">"slpf"</span><span class="fu">:</span> <span class="fu">{}</span></a>
<a class="sourceLine" id="cb1-12" title="12"> <span class="fu">}</span></a>
<a class="sourceLine" id="cb1-13" title="13"><span class="fu">}</span></a></code></pre></div>
<p>In this case the Actuator returns a rule number associated with the allowed interaction.</p>
<p><strong>Response:</strong></p>
<div class="sourceCode" id="cb2"><pre class="sourceCode json"><code class="sourceCode json"><a class="sourceLine" id="cb2-1" title="1"><span class="fu">{</span></a>
<a class="sourceLine" id="cb2-2" title="2"> <span class="dt">"status"</span><span class="fu">:</span> <span class="dv">200</span><span class="fu">,</span></a>
<a class="sourceLine" id="cb2-3" title="3"> <span class="dt">"results"</span><span class="fu">:</span> <span class="fu">{</span></a>
<a class="sourceLine" id="cb2-4" title="4"> <span class="dt">"slpf"</span><span class="fu">:</span> <span class="fu">{</span></a>
<a class="sourceLine" id="cb2-5" title="5"> <span class="dt">"rule_number"</span><span class="fu">:</span> <span class="dv">1234</span></a>
<a class="sourceLine" id="cb2-6" title="6"> <span class="fu">}</span></a>
<a class="sourceLine" id="cb2-7" title="7"> <span class="fu">}</span></a>
<a class="sourceLine" id="cb2-8" title="8"><span class="fu">}</span></a></code></pre></div>
<h2 id="21-commands">2.1 Commands</h2>
<p><strong>Command</strong>: An instruction from one system, known as the Producer, to one or more systems, the Consumer(s), to act on the content of the Command.</p>
<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. A Command can also contain an optional Command identifier, if necessary. The following list summarizes the main four 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. Properties of the Target, called <em>Target Specifiers</em>, further identify the Target to some level of precision, such as one specific Target, a list of Targets, or a class of Targets.</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>Profile</strong> (optional): Specifies the Actuator Profile that defines the function to be performed by the command.</li>
</ul>
<p>The Action and Target components are required. A particular Target may be further refined by the Target type. The <a href="#openc2-lang-v10">Language Specification</a> defines procedures to extend the set of OpenC2 Targets.</p>
<p>Command Arguments, if present, influence the Command by providing information such as timing, periodicity, duration, or other details on what is to be executed. They can also be used to convey the need for acknowledgment or additional status information about the execution of a Command.</p>
<p>The Profile field, if present, specifies the profile that defines the function to be performed. A Consumer executes the command if it supports the specified profile, otherwise the command is ignored. The Profile field may be omitted and typically will not be included in implementations where the functions of the recipients are unambiguous or when a high-level effects-based command is desired and tactical decisions on how the effect is achieved is left to the recipient. If Profile is omitted and the recipient supports multiple profiles, the command will be executed in the context of each profile that supports the command's combination of action and target.</p>
<h2 id="22-responses">2.2 Responses</h2>
<p><strong>Response</strong>: Any information sent back to the Producer as a result of the Command.</p>
<p>The Response is sent from a Consumer, usually back to the Producer, and is a means to provide information (such as acknowledgment, status, etc.) regarding the results of executing a Command. At a minimum, a Response will contain a status code to indicate the result of performing the Command. Additional status text and response fields optionally provide more detailed information that is specific to or requested by the Command.</p>
<h2 id="23-design-patterns">2.3 Design Patterns</h2>
<p>This section describes a number of OpenC2 concepts related to creating working systems using OpenC2 specifications.</p>
<h3 id="231-producers-consumers-and-devices">2.3.1 Producers, Consumers, and Devices</h3>
<p>This section discusses four representative configurations for an OpenC2 Consumer device:</p>
<ol>
<li><p>The Consumer implements a single function, and therefore supports a Actuator Profile (AP).</p></li>
<li><p>The Consumer implements multiple functions, and therefore supports multiple APs, which may be all different, all the same, or a mixture.</p></li>
<li><p>The Consumer is a manager for a collection of devices, providing an indirect means for the Producer to use OpenC2 Commands to influence the operations of those devices. The managed devices in the collection may or may not be identical, and the interface to them is not assumed to use OpenC2.</p></li>
<li><p>The Consumer is a manager for a collection of devices that are managed using OpenC2, making the device a combined Consumer / Producer.</p></li>
</ol>
<p>In all of these configurations, "device" is a collective term for the processing element that is the OpenC2 Consumer. A device could be a physical or virtual entity in any number of computing environments. The essential characteristics are that it is a network-accessible, addressable entity that operates as an OpenC2 Consumer.</p>
<p>In configurations 1 and 2, the Producer has direct, explicit knowledge of the APs implemented by the Consumer. OpenC2 Commands issued by the Producer directly affect the operation of the Consumer device.</p>
<p>In configurations 3 and 4, the Producer has knowledge of the capabilities supported by the Consumer manager, but only indirectly affect the operation of the managed devices. In configuration 3 there is no assumption that the interface between the Consumer manager and the managed devices uses OpenC2 Commands and Responses, whereas in configuration 4 that interface is explictly OpenC2-based. Implementations with a mixture of OpenC2- and non-OpenC2-based interactions with the managed devices are also possible.</p>
<h4 id="2311-single-function-device">2.3.1.1 Single Function Device</h4>
<p>Figure 2-2 illustrates the situation with a Producer commanding an OpenC2 Consumer that implements a single cybersecurity function, and its corresponding AP.</p>
<p><strong>Figure 2-2. Single Function Device</strong> <img src="images/Single-Function-Device.drawio.png" alt="Single Function Device" /></p>
<h4 id="2312-multiple-function-device">2.3.1.2 Multiple Function Device</h4>
<p>Figure 2-3 illustrates the situation with a Producer commanding an OpenC2 Consumer that implements multiple cybersecurity functions, and their corresponding APs. The cybersecurity functions may be all different, all the same, or a mixture. An example of different functions could be an end-user computer system with anti-virus (AV), endpoint response (ER) and packet filtering (PF) capabilities. An example of multiple instances of the same AP in configuration 2 would be packet filtering functions on multiple, distinct network interfaces.</p>
<p><strong>Figure 2-3. Multiple Function Device</strong> <img src="images/Multiple-Function-Device.drawio.png" alt="Multiple Function Device" /></p>
<h4 id="2313-actuator-manager-device">2.3.1.3 Actuator Manager Device</h4>
<p>Figure 2-4 illustrates the situation where the Consumer fronts a set of managed devices implementing cybersecurity functions. The managed devices may implement any mixture of cybersecurity functions, and the Actuator Manager's interface to those devices is not using OpenC2.</p>
<p><strong>Figure 2-4. Actuator Manager Device</strong> <img src="images/Actuator-Manager-Device.drawio.png" alt="Actuator Manager Device" /></p>
<h4 id="2314-intermediate-consumer--producer-device">2.3.1.4 Intermediate Consumer / Producer Device</h4>
<p>Figure 2-5 illustrates the situation where the Consumer fronts a set of managed devices implementing cybersecurity functions. The managed devices may implement any mixture of cybersecurity functions, but in this case the Manager's interface to those devices explicitly does use OpenC2, making the device an intermediate, combined Consumer / Producer.</p>
<p><strong>Figure 2-5. Actuator Manager Device Using OpenC2</strong> <img src="images/Actuator-Manager-Device-OpenC2.drawio.png" alt="Actuator Manager Device using OpenC2" /></p>
<h3 id="232-action-target-model">2.3.2 Action-Target Model</h3>
<p>The OpenC2 Language Specification defines a <em>standard</em> set of actions and a <em>baseline</em> collection of targets for those actions. An action-target pair defines a command, as described in <a href="#21-commands">Section 2.1</a>.</p>
<p>The available set of actions for creating OpenC2 commands is limited to those defined in the Language Specification in order to encourage commonality and interoperability of implementations. The function of each action is defined in the Language Specification, and the set of actions can only be expanded by modifying the Language Specification. Specifically, the set of OpenC2 actions cannot be expanded by defining new actions in an Actuator Profile.</p>
<p>In contrast the baseline set of targets in the Language Specification is a usable set, but is also explicitly extensible. This recognizes the diversity of cybersecurity functions and the corresponding need for function-specific targets beyond the general purpose set provided in the Language Specification.</p>
<p>There are other automation capabilities (e.g, Microsoft Powershell) that implement a verb-noun model similar to that used by OpenC2. Future expansions to the OpenC2 action set should take advantage of prior work from similar capabilities in selecting names for actions. This will encourage commonality of usage and understanding of verbs in automation systems.</p>
<h3 id="233-introspection-model">2.3.3 Introspection Model</h3>
<p>A common situation in OpenC2 interactions is the need for a Producer to determine the capabilities of a Consumer in order to scope the range of commands that can usefully be sent to that Consumer. The approach is demonstrated in the Language Specification's provision of the <code>"query" : "features"</code> and <code>"query" : "properties"</code> commands. This "introspection" capability, defined for OpenC2 as the ability of a Consumer to inform a Producer of the Consumer's capabilities, enables a degree of flexible self-configuration of the interactions between Producers and Consumers.</p>
<p>Any situation where a Consumer may potentially provide a range of responses to a Producer's command is a candidate to apply the introspection technique. For example, where a Consumer may return a response in any of several data formats or serializations, it is appropriate to consider a two-stage interaction:</p>
<ul>
<li><p><strong>Stage 1:</strong> the Producer identifies the information of interest and queries regarding the Consumer's capabilities to provide that information. The Consumer responds with a list, possibly prioritized, of the ways it can supply the required information.</p></li>
<li><p><strong>Stage 2:</strong> the Producer selects from among the options provided by the Consumer and sends a Command specifying the desired packaging of the information. The Consumer responds with the required information packaged as specified.</p></li>
</ul>
<p>The information provided by the Consumer in stage 1 enables the Producer to proceed with confidence about the outcome of the interaction in stage 2.</p>
<h2 id="24-implementations">2.4 Implementations</h2>
<p>OpenC2 implementations integrate the OpenC2 specifications described above with related industry specifications, protocols, and standards. Figure 2-3 depicts the relationships among the family of 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 any particular approach to implementing the needed functionality (for example, the use of an application-layer message signature function to provide message source authentication and integrity).</p>
<p><strong>Figure 2-3. OpenC2 Documentation and Layering Model</strong> <img src="images/OC2-Docs-and-Layers.drawio.png" alt="OpenC2 Documentation and Layering Model" /></p>
<p>OpenC2 is conceptually partitioned into four layers as described in Table 2-1.</p>
<p><strong>Table 2-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>(<a href="#openc2-slpf-v10">OpenC2-SLPF-v1.0</a>, ...)</td>
</tr>
<tr class="even">
<td style="text-align: left;">Common Content</td>
<td style="text-align: left;">Language Specification</td>
</tr>
<tr class="odd">
<td style="text-align: left;">Message</td>
<td style="text-align: left;">Transfer Specifications<br>(<a href="#openc2-https-v10">OpenC2-HTTPS-v1.0</a>, <a href="#openc2-mqtt-v10">OpenC2-MQTT-v1.0</a>, ...)</td>
</tr>
<tr class="even">
<td style="text-align: left;">Secure Transport</td>
<td style="text-align: left;">HTTPS, CoAP, MQTT, OpenDXL, ...</td>
</tr>
</tbody>
</table>
<ul>
<li>The <strong>Secure Transport</strong> layer provides a communication path between the Producer and the Consumer. OpenC2 can be layered over any standard transport protocol.</li>
<li>The <strong>Message</strong> layer provides a transfer- and content-independent mechanism for conveying Messages. 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 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. Producers and Consumers will support one or more profiles.</li>
</ul>
<p>OpenC2 is intended to be integrated into different systems which will provide a variety of security services. <a href="#appendix-b-safety-security-and-privacy-considerations">Appendix B</a> describes the possible threats that could affect OpenC2 operations and the security services needed to protect those operations against such threats. Because the implementation of these services are beyond the scope of this specification, the review in Appendix B is for reference purposes and to emphasize the importance of considering security services in the creation of OpenC2 implementations.</p>
<hr />
<h1 id="3-conformance">3 Conformance</h1>
<p>This section defines the conformance requirements for OpenC2 implementations.</p>
<h2 id="31-conformance-related-definitions">3.1 Conformance-Related Definitions</h2>
<p>An OpenC2 <em>Producer</em> is defined per Section 2 of this document.</p>
<p>An OpenC2 <em>Consumer</em> is defined per Section 2 of this document.</p>
<p>The OpenC2 <em>Transfer Specification List</em> is defined as:</p>
<ul>
<li>oc2-https</li>
<li>oc2-mqtt</li>
</ul>
<p>The OpenC2 <em>Actuator Profile Specification List</em> is defined as:</p>
<ul>
<li>slpf</li>
</ul>
<p>The <em>Actuator Profile List</em> is defined as the list of Actuator Profiles supported by the Consumer as supplied in the response to the command:</p>
<pre><code>{action:query, target:features, target-specifier:[profiles]}
</code></pre>
<p>as per Section 4.1 of the Language Specification.</p>
<p>A Consumer's <em>Actuator Profile List</em> is composed of two types of profiles:</p>
<ul>
<li>Standard Actuator Profiles (SAP), i.e., those on the OpenC2 Actuator Profile Specification List; and</li>
<li>Custom Actuator Profiles (CAP), i.e., those not on the OpenC2 Actuator Profile Specification List.</li>
</ul>
<h2 id="32-openc2-producer-conformance-clauses">3.2 OpenC2 Producer Conformance Clauses</h2>
<p>CC 3.2.1 In order to conform to this specification, an OpenC2 Producer MUST only issue OpenC2 commands conforming to OpenC2 Language Specification Section 5.1 Conformance Clause 1.</p>
<p>CC 3.2.2 In order to conform to this specification, an OpenC2 Producer MUST only accept responses conforming to OpenC2 Language Specification Section 5.2 Conformance Clause 2.</p>
<p>CC 3.2.3 In order to conform to this specification, an OpenC2 Producer MUST be conformant to OpenC2 Language Specification Section 5.3 Conformance Clause 3.</p>
<p>CC 3.2.4 In order to conform to this specification, an OpenC2 Producer MUST be conformant with at least one transfer specification in the OpenC2 Transfer Specification List.</p>
<h2 id="33-openc2-consumer-conformance-clauses">3.3 OpenC2 Consumer Conformance Clauses</h2>
<p>CC 3.3.1 In order to conform to this specification, an OpenC2 Consumer MUST only accept OpenC2 commands conforming to OpenC2 Language Specification Section 5.1 Conformance Clause 1.</p>
<p>CC 3.3.2 In order to conform to this specification, an OpenC2 Consumer MUST only return responses conforming to OpenC2 Language Specification Section 5.2 Conformance Clause 2.</p>
<p>CC 3.3.3 In order to conform to this specification, an OpenC2 Consumer MUST be conformant to OpenC2 Language Specification Section 5.4 Conformance Clause 4.</p>
<p>CC 3.3.4 In order to conform to this specification, an OpenC2 Consumer MUST be conformant with at least one transfer specification in the OpenC2 Transfer Specification List.</p>
<p>CC 3.3.5 In order to conform to this specification, an OpenC2 Consumer MUST have an OpenC2 Consumer Actuator Profile List with at least one entry.</p>
<p>CC 3.3.6 In order to conform to this specification, all SAP entries on a Consumer's OpenC2 Consumer Actuator Profile List MUST conform to the corresponding OASIS OpenC2 Actuator Profiles.</p>
<h2 id="34-openc2-cap-conformance-clauses">3.4 OpenC2 CAP Conformance Clauses</h2>
<p>CC 3.4.1 In order to conform to this specification, a CAP MUST extend the functionality covered by a profile on the OpenC2 Actuator Profile Specification List, and MUST conform with the OpenC2 Actuator Profile Specification being extended.</p>
<p>For example, if a CAP extends the slpf functionality, the Consumer must conform to the OASIS OpenC2 SLPF Actuator Profile Specification. Note if the actuator function is not an extension to an existing function specified in a published AP, the Consumer implementation fails this conformance clause. For example, a CAP fails this clause if it is for malware detection, and there is not a malware detection SAP.</p>
<p>CC 3.4.2 In order to conform to this specification, all CAP entries MUST extend the functionality of a SAP in a manner consistent with the OpenC2 Language Specification section 3.1.4 requirements for extensions.</p>
<hr />
<h1 id="appendix-a-references">Appendix A. References</h1>
<p>This appendix contains the normative and informative references that are used in this document.</p>
<p>While any hyperlinks included in this appendix were valid at the time of publication, OASIS cannot guarantee their long-term validity.</p>
<h2 id="a1-normative-references">A.1 Normative References</h2>
<p>The following documents are referenced in such a way that some or all of their content constitutes requirements of this document.</p>
<h6 id="openc2-lang-v10">[OpenC2-Lang-v1.0]</h6>
<p><em>Open Command and Control (OpenC2) Language Specification Version 1.0</em>. Edited by Jason Romano and Duncan Sparrell. Latest stage: <a href="https://docs.oasis-open.org/openc2/oc2ls/v1.0/oc2ls-v1.0.html">https://docs.oasis-open.org/openc2/oc2ls/v1.0/oc2ls-v1.0.html</a></p>
<h6 id="openc2-https-v11">[OpenC2-HTTPS-v1.1]</h6>
<p><em>Specification for Transfer of OpenC2 Messages via HTTPS Version 1.1</em>. Edited by David Lemire. Latest stage: <a href="https://docs.oasis-open.org/openc2/open-impl-https/v1.1/open-impl-https-v1.1.html">https://docs.oasis-open.org/openc2/open-impl-https/v1.1/open-impl-https-v1.1.html</a></p>
<h6 id="openc2-mqtt-v10">[OpenC2-MQTT-v1.0]</h6>
<p><em>Specification for Transfer of OpenC2 Messages via MQTT Version 1.0</em>. Edited by David Lemire. Latest stage: <a href="https://docs.oasis-open.org/openc2/transf-mqtt/v1.0/transf-mqtt-v1.0.html">https://docs.oasis-open.org/openc2/transf-mqtt/v1.0/transf-mqtt-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 stage: <a href="https://docs.oasis-open.org/openc2/oc2slpf/v1.0/oc2slpf-v1.0.html">https://docs.oasis-open.org/openc2/oc2slpf/v1.0/oc2slpf-v1.0.html</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">http://www.rfc-editor.org/info/rfc2119</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">http://www.rfc-editor.org/info/rfc8174</a>.</p>
<h2 id="a2-informative-references">A.2 Informative 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.<a href="https://www.semanticscholar.org/paper/Active-Cyber-Defense-%3A-A-Vision-for-Real-Time-Cyber-Herring-Willett/7c128468ae42584f282578b86439dbe9e8c904a8">https://www.semanticscholar.org/paper/Active-Cyber-Defense-%3A-A-Vision-for-Real-Time-Cyber-Herring-Willett/7c128468ae42584f282578b86439dbe9e8c904a8</a>.<br><br>Willett, Keith D., "Integrated Adaptive Cyberspace Defense: Secure Orchestration", International Command and Control Research and Technology Symposium, June 2015 <a href="https://www.semanticscholar.org/paper/Integrated-Adaptive-Cyberspace-Defense-%3A-Secure-by-Willett/a22881b8a046e7eab11acf647d530c2a3b03b762">https://www.semanticscholar.org/paper/Integrated-Adaptive-Cyberspace-Defense-%3A-Secure-by-Willett/a22881b8a046e7eab11acf647d530c2a3b03b762</a>.</p>
<h6 id="rfc3552">[RFC3552]</h6>
<p>Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, <a href="https://www.rfc-editor.org/info/rfc3552">https://www.rfc-editor.org/info/rfc3552</a>.</p>
<h6 id="rfc7515">[RFC7515]</h6>
<p>Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <a href="https://www.rfc-editor.org/info/rfc7515">https://www.rfc-editor.org/info/rfc7515</a>.</p>
<h6 id="rfc7516">[RFC7516]</h6>
<p>Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, May 2015, <a href="https://www.rfc-editor.org/info/rfc7516">https://www.rfc-editor.org/info/rfc7516</a>.</p>
<h6 id="rfc8152">[RFC8152]</h6>
<p>Schaad, J., "CBOR Object Signing and Encryption (COSE)", RFC 8152, DOI 10.17487/RFC8152, July 2017, <a href="https://www.rfc-editor.org/info/rfc8152">https://www.rfc-editor.org/info/rfc8152</a>.</p>
<hr />
<h1 id="appendix-b-safety-security-and-privacy-considerations">Appendix B. Safety, Security and Privacy Considerations</h1>
<p>This appendix discusses security concerns related to OpenC2.</p>
<h2 id="b1-overview">B.1 Overview</h2>
<p>Cyber defense systems are high-value targets for an attacker since disabling detection and response capabilities opens the door to allow further attacks. There would be great value to an attacker to turn off the sensors, breach the defenses, disable responsive actions, and potentially use the cyber defense tools to attack the network.</p>
<h2 id="b2-threats">B.2 Threats</h2>
<p>There are two threat target areas to address when considering the security of OpenC2:</p>
<ol>
<li>Threats to and attacks on the user networks/systems being defended, and</li>
<li>Attacks directed at OpenC2 itself.</li>
</ol>
<h3 id="b21-threats-to-the-networks-and-systems-being-defended">B.2.1 Threats to the Networks and Systems Being Defended</h3>
<p>By providing the C2 for time-critical response actions OpenC2 is an enabler of improved cyber defense capabilities for user networks and systems. However, to the extent that OpenC2 traffic and processing share resources with those user networks and systems, those same threats (and mitigations) will also be applicable to OpenC2. Even if the OpenC2 traffic is segregated using logical or cryptographic separation, the underlying physical resources may still be subject to common attacks (and other threats) that will affect OpenC2 operations.</p>
<h3 id="b22-threats-to-openc2-traffic-and-processing">B.2.2 Threats to OpenC2 Traffic and Processing</h3>
<p>The threats, attacks, vulnerabilities, and impacts to a given OpenC2 implementation should be analyzed with a focus on the goals of the attacker and the resulting impacts since these will be different from a standard user analysis. Four categories of threat sources should be addressed:</p>
<ul>
<li><p><em>Malicious Adversaries</em> (external or insider) – the primary source of concern for the security of OpenC2 operations</p></li>
<li><p><em>Non-malicious Users</em> – mistakes by users, especially privileged users, can cause major lapses in cyber defense</p></li>
<li><p><em>Structural Threats</em> – failures of hardware and/or software can affect network and system integrity or availability, and impede the ability of OpenC2 mechanisms to operate</p></li>
<li><p><em>Environmental Threats</em> – disasters and infrastructure failures may need to addressed and accommodated depending on the mission needs of the defended networks</p></li>
</ul>
<h3 id="b23-potential-attack-types">B.2.3 Potential Attack Types</h3>
<p>Malicious adversaries may use any form of attack, these are some primary examples.</p>
<ul>
<li><p><em>Passive Attacks</em> – An attacker may monitor traffic at levels of sophistication and access ranging from simple traffic analysis (is there a change in the volume of OpenC2 traffic?) to eavesdropping on the contents of the messages (if unencrypted) to see what was detected, what actions are being taken, and the specific targets of OpenC2 commands. This information will let the attacker know if their active attacks have been detected and how the system responds. Their active attacks can then be revised to avoid detection or to trigger a known response. In the latter case, the attacker could use knowledge of the response strategy to cause the system to unnecessarily deny services to users.</p></li>
<li><p><em>Active Attacks, Externally Initiated</em> – An attacker may try to manipulate OpenC2 traffic by deleting, delaying, or replaying legitimate messages. They may also attempt to modify the contents of a message or masquerade as an OpenC2 Producer and issue bogus messages. Finally, an external attacker might be able to compromise a legitimate OpenC2 Producer within an environment; protection of an OpenC2 Producer should be a priority in any implementation of OpenC2. If any of these attacks succeed, the attacker can disrupt or disable responses to other attacks and can cause the defensive capabilities to impede legitimate operations. Successfully subverting defenses can allow more intrusive attacks.</p></li>
<li><p><em>Insider Attacks</em> (Malicious users) – An insider, especially a privileged user, may be able to more effectively perform any of the passive and active attacks already mentioned plus can act as a legitimate user to perform other actions. These actions could include misconfiguring devices, changing policy rules, issuing malicious commands from authorized sources, and even turning systems off.</p></li>
<li><p><em>Supply Chain or Distribution Attacks</em> - A vendor, transporter, developer, or installer may modify the software or hardware used for OpenC2-based functions. The modification may introduce an exploitable vulnerability, disable a critical function, or cause failure under specific conditions. Even if the attack is just substitution of a counterfeit component, the behavior may be different and cause problems.</p></li>
</ul>
<h2 id="b3-security-services">B.3 Security Services</h2>
<p>This section reviews the applicability of traditional security services to OpenC2 operations. As OpenC2 specifies a <em>language</em> (as opposed to a protocol or a system) that is subject to a range of implementations, in a variety of environments, using a variety of transfer protocols, data encodings, etc., this discussion does not specify any particular mechanisms to implement these security services.</p>
<p>Implementations of OpenC2 should apply well-vetted and widely-used industry standard mechanisms (e.g., as specified by Internet Engineering Task Force [IETF] Requests for Comment [RFCs]) compatible with other implementation choices to provide security services. For example:</p>
<ul>
<li><p>JSON-encoded messages could be protected using the techniques described in the JSON Object Signing and Encryption (JOSE) family of RFCs, specifically [<a href="#rfc7515">RFC7515</a>], [<a href="#rfc7516">RFC7516</a>], and associated documents.</p></li>
<li><p>CBOR-encoded messages could be protected using the techniques described in the CBOR Object Signing and Encryption (COSE) family of RFCs, specifically [<a href="#rfc8152">RFC8152</a>] and associated documents.</p></li>
</ul>
<h3 id="b31-confidentiality">B.3.1 Confidentiality</h3>
<p>Confidentiality of OpenC2 message content prevents attackers from seeing the response actions that result from attacker activities. This knowledge could aid an attacker in manipulating or circumventing cyber defenses.</p>
<h3 id="b32-integrity">B.3.2 Integrity</h3>
<p>Both data and system integrity need to be addressed in OpenC2 implementations. Data integrity is extremely important - the contents of a C2 message should not be modifiable without detection. Replay and re-sequencing attacks also need to be addressed. Message integrity must always be paired with source authentication. System integrity including software/application integrity is also critical to OpenC2 security. If a system, including system and application software, is not in a compliant, stable configuration then its actions cannot be trusted.</p>
<h3 id="b33-availability">B.3.3 Availability</h3>
<p>Availability in the context of OpenC2 is focused on the ability of Producers to send commands to Consumers, and the corresponding ability of Consumers to receive, execute, and send Responses to those commands. Assuring availability can be very difficult if the OpenC2 message traffic is carried in-band with the user traffic. Out-of-band management networks should be used where possible as they provide isolation of OpenC2 activities from attacks against operational user networks and can be engineered to provide better support for high availability. Also, approaches to addressing intermittent connectivity and actions upon reconnection should be addressed.</p>
<h3 id="b34-authentication">B.3.4 Authentication</h3>
<p>OpenC2 is envisioned for application in environments where C2 will be automated as much as possible. In the consequent machine-to-machine exchanges, the systems involved need to securely authenticate that authorized systems are involved and not rogue entities. In particular, actuators receiving and executing OpenC2 commands must be able to confirm those commands came from a source that can confidently be authenticated. With the increasing number of Internet-enabled devices, reliable machine authentication is crucial to allow secure communication in automated network environments. In any architecture deployment, consider the appropriate levels and types of authentication for managers and actuators.</p>
<p>There are also aspects of identity and credential management that need to be addressed: uniqueness of name space, identification of device type and instance, provisioning of credentials (typically digital certificates), means to verify trust chain and current status of credentials, means to revoke credentials, and session management. There are many challenges to find the right authentication model that can support a machine-to-machine communication method depending on the range of device and network capabilities in the operating environment.</p>
<h3 id="b35-authorization-and-access-control">B.3.5 Authorization And Access Control</h3>
<p>Coupled with user or device authentication, a requesting entity must have authorization before tasks are executed on its direction. Authorization is the process of enforcing policies: determining what types of actions on a resource or service are permitted for this Producer. Once a Producer has been authenticated, they may be authorized for different types of actions depending on the policy assigned. The authorization should be role- or attribute-based to avoid the problems of maintaining an identity-based access control list.</p>
<p>The policy rules may include conditional aspects such as time of day or operational status of network to prevent actions from adversely affecting missions. In these cases, it is important to determine if the Producer has knowledge of the conditions and can self-impose the policy rules or whether the policy needs to be enforced at (or near) the resource.</p>
<h3 id="b36-accountability">B.3.6 Accountability</h3>
<p>Authentication is also the basis for associating the Producer with the commands sent, the authorization decision (allow or deny), and the actions taken. The authenticated identity of the actor along with the action is captured in the audit logs and provides traceability to the responsible party.</p>
<h3 id="b37-non-repudiation">B.3.7 Non-Repudiation</h3>
<p>Non-repudiation may be required if there is a requirement to formally prove the issuance or receipt of a C2 message, however any non-repudiation requirement should be evaluated critically due to impacts on the processing, availability and delays of automated cyber defense actions. This level of security may not be required in a closed system where source authentication and logged receipt events are sufficient evidence of who sent and who received messages. Non-repudiation implementations may require a third party acting as a notary or signature-based message authentication resulting in additional costs in terms of processing, communications, and invoking third-party services for the commands and responses. A time stamping service will typically also be required. The third party would timestamp OpenC2 messages and certify proof of issuance and delivery. This will add dependencies and overhead to the system.</p>
<h3 id="b38-auditing">B.3.8 Auditing</h3>
<p>Audit trails are necessary in any secure system but have specific considerations in machine-to-machine communications. In conjunction with appropriate tools and procedures, audit trails can provide a means to help accomplish several security-related objectives, including individual accountability, reconstruction of events, intrusion detection, and problem identification. Typical events include:</p>
<ul>
<li>Authentication exchange between components (manager, actuator, and end points)</li>
<li>Message generated, message sent, message received</li>
<li>Action taken/allowed or request denied</li>
<li>Success or failure of any OpenC2 exchange</li>
<li>Configuration changes</li>
</ul>
<p>Actions and the results that are invoked using OpenC2 should be recorded and analyzed for security areas such as forensics, secure implementation, security architecture of impact changes within the environment, and completion of such tasks. This type of auditing provides the essential ingredients for early detection of actions that violate security policy.</p>
<h3 id="b39-metrics-collection-and-analysis">B.3.9 Metrics Collection And Analysis</h3>
<p>Collecting metrics will be necessary for a multitude of activities to assess performance and improve effectiveness of actions within an OpenC2 environment. Implementations should provide the ability to measure resources a user or system component (e.g., sensors and actuators) consumes. This could include the amount of system time or quantity of messages it has sent or received during a session. This can be accomplished by logging of session statistics and usage information and is used for trend analysis, resource utilization, performance assessment, and capacity planning. Overall all of these are important data captures to improve the configuration and deployment of OpenC2 components and a verification that operations are working as intended.</p>
<h2 id="b4-network-topologies">B.4 Network Topologies</h2>
<p>The available networking architecture, topology, and technology all have implications for, and may also be constrained by, OpenC2 use and security. The topology and communications modes supporting OpenC2 traffic will affect the ability and approaches to achieving robustness, providing redundancy, and meeting responsiveness goals. Ideally, OpenC2 traffic should be quickly and reliably delivered to all intended recipients with some guarantee or confirmation of both delivery and action taken. It will not always be possible to achieve these goals due to constraints of available or legacy networking and systems, mobility/connectedness of devices, effects of attacks or outages in the network, and management/cost factors.</p>
<h3 id="b41-in-band-cyber-defense-c2">B.4.1 In-Band Cyber Defense C2</h3>
<p>If OpenC2 traffic is carried in-band with user and other traffic, then it is subject to the same threats (plus the threats against cyber defense C2) and will leverage the same defenses as the other traffic. Besides being subject to the same external threats as the other traffic, the implementer also needs to consider:</p>
<ul>
<li><p><em>Resource contention issues</em>: C2 traffic may be delayed or blocked by high volumes of user traffic or reductions in network capacity or connectivity</p></li>
<li><p><em>Intended cyber defense actions</em>: The same blocking or filtering of traffic meant to stop an external attacker may affect C2 traffic flow as well (e.g., external monitoring feeds could be cut off)</p></li>
<li><p><em>Targeted attacks against cyber defense C2</em>: The attacker may specifically attempt to single out C2 traffic for intercept, modification, denial of service, or other attack</p></li>
</ul>
<h3 id="b42-out-of-band-cyber-defense-c2">B.4.2 Out-Of-Band Cyber Defense C2</h3>
<p>Out-of-Band management (OOBM) involves the use of a dedicated channel for managing network devices. OOBM allows the network operator to establish trust boundaries around accessing the management function to apply it to network resources. Depending on the specific implementation, OOBM also can be used to ensure management connectivity (including the ability to determine the status of any network component) independent of the status of in-band network components. OOBM is a common best practice with renewed focus based on the evolving threat landscape. There are a range of potential implementations of OOBM, from an entirely physically-separated network to approaches that apply logical separation (e.g., virtual LANs [VLAN]) on the network backbone to separate management traffic from ordinary user traffic.</p>
<p>C2 systems are prime objectives of adversaries and OOBM can provide another layer in the defense-in-depth model. The effectiveness of this layering or separation depends on how OOBM is implemented and secured. There should be a much lower attack surface since general users would not have access to this channel. Also security policies, generally, will restrict or prohibit connection to the OOBM through access control lists or other access methods. In practice though, implementations may have prioritized administrator access (including remote access) and chosen weaker security. For example, implementers may have left back-door access in place so that disastrous failures can rapidly be fixed. To address these types of issues, a security plan should be implemented and enforced, focusing in these areas, which will enhance the entire security architecture of the enterprise:</p>
<ul>
<li>Definitions of vulnerabilities and risks of out-of-band access for OpenC2</li>
<li>Review security architecture for mitigating those risks</li>
<li>Proper balance between security and the need for timely out-of-band access during critical events</li>
<li>Systems of processes, equipment and technologies that provide, wherever required for OpenC2 integrity, confidentiality, and/or non-repudiation for out-of-band access.</li>
</ul>
<hr />
<h1 id="appendix-c-acknowledgments">Appendix C. Acknowledgments</h1>
<h2 id="c1-special-thanks">C.1 Special Thanks</h2>
<p>Assistance with this document from the following individuals are gratefully acknowledged:</p>
<ul>
<li>Larry Feldman, HII</li>
<li>Jerome Czachor, HII</li>
<li>Kevin Cressman, Praxis Engineering</li>
</ul>
<h2 id="c2-participants">C.2 Participants</h2>
<p>The following individuals have participated in the creation of this specification and are gratefully acknowledged:</p>
<p><strong>OpenC2 TC Members:</strong></p>
<table>
<thead>
<tr class="header">
<th style="text-align: left;">First Name</th>
<th style="text-align: left;">Last Name</th>
<th style="text-align: left;">Company</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td style="text-align: left;">David</td>
<td style="text-align: left;">Bizeul</td>
<td style="text-align: left;">SEKOIA</td>
</tr>
<tr class="even">
<td style="text-align: left;">Marco</td>
<td style="text-align: left;">Caselli</td>
<td style="text-align: left;">Siemens AG</td>
</tr>
<tr class="odd">
<td style="text-align: left;">Toby</td>
<td style="text-align: left;">Considine</td>
<td style="text-align: left;">University of North Carolina at Chapel Hill</td>
</tr>
<tr class="even">
<td style="text-align: left;">Martin</td>
<td style="text-align: left;">Evandt</td>
<td style="text-align: left;">University of Oslo</td>
</tr>
<tr class="odd">
<td style="text-align: left;">Alex</td>
<td style="text-align: left;">Everett</td>
<td style="text-align: left;">University of North Carolina at Chapel Hill</td>
</tr>
<tr class="even">
<td style="text-align: left;">Jane</td>
<td style="text-align: left;">Ginn</td>
<td style="text-align: left;">Cyber Threat Intelligence Network, Inc.</td>
</tr>
<tr class="odd">
<td style="text-align: left;">John-Mark</td>
<td style="text-align: left;">Gurney</td>
<td style="text-align: left;">Copado</td>
</tr>
<tr class="even">
<td style="text-align: left;">Christian</td>
<td style="text-align: left;">Hunt</td>
<td style="text-align: left;">Copado</td>
</tr>
<tr class="odd">
<td style="text-align: left;"><em>Dan</em></td>
<td style="text-align: left;"><em>Johnson</em></td>
<td style="text-align: left;"><em>sFractal</em></td>
</tr>
<tr class="even">
<td style="text-align: left;">David</td>
<td style="text-align: left;">Kemp</td>
<td style="text-align: left;">National Security Agency</td>
</tr>
<tr class="odd">
<td style="text-align: left;">David</td>
<td style="text-align: left;">Lemire</td>
<td style="text-align: left;">National Security Agency</td>
</tr>
<tr class="even">
<td style="text-align: left;">Patrick</td>
<td style="text-align: left;">Maroney</td>
<td style="text-align: left;">AT&T</td>
</tr>
<tr class="odd">
<td style="text-align: left;">Vasileios</td>
<td style="text-align: left;">Mavroeidis</td>
<td style="text-align: left;">University of Oslo</td>
</tr>
<tr class="even">
<td style="text-align: left;">Dmitri</td>
<td style="text-align: left;">Raidman</td>
<td style="text-align: left;">Cybeats</td>
</tr>
<tr class="odd">
<td style="text-align: left;">Christopher</td>
<td style="text-align: left;">Robinson</td>
<td style="text-align: left;">Cyber Threat Intelligence Network, Inc.</td>
</tr>
<tr class="even">
<td style="text-align: left;">Michael</td>
<td style="text-align: left;">Rosa</td>
<td style="text-align: left;">National Security Agency</td>
</tr>
<tr class="odd">
<td style="text-align: left;">Duane</td>
<td style="text-align: left;">Skeen</td>
<td style="text-align: left;">Northrup Grumman</td>
</tr>
<tr class="even">
<td style="text-align: left;">Duncan</td>
<td style="text-align: left;">Sparrell</td>
<td style="text-align: left;">sFractal</td>
</tr>
<tr class="odd">
<td style="text-align: left;">Gerald</td>
<td style="text-align: left;">Stueve</td>
<td style="text-align: left;">Fornetix</td>
</tr>
<tr class="even">
<td style="text-align: left;">Drew</td>
<td style="text-align: left;">Varner</td>
<td style="text-align: left;">NineFX, Inc.</td>
</tr>
<tr class="odd">
<td style="text-align: left;">Russ</td>
<td style="text-align: left;">Warren</td>
<td style="text-align: left;">IBM</td>
</tr>
</tbody>
</table>
<p><em>Italics</em> indicates former TC members.</p>
<hr />
<h1 id="appendix-d-revision-history">Appendix D. Revision History</h1>
<table>
<thead>
<tr class="header">
<th style="text-align: left;">Revision</th>
<th style="text-align: left;">Date</th>
<th style="text-align: left;">Editor</th>
<th style="text-align: left;">Changes Made</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td style="text-align: left;">oc2arch-v1.0-csprd01.md</td>
<td style="text-align: left;">2021-12-21</td>
<td style="text-align: left;">Duncan Sparrell</td>
<td style="text-align: left;">WD01: Capture initial content prior to reorganization</td>
</tr>
<tr class="even">
<td style="text-align: left;">oc2arch-v1.0-wd01.md</td>
<td style="text-align: left;">2021-12-21</td>
<td style="text-align: left;">Duncan Sparrell</td>
<td style="text-align: left;">WD02: Capture new starter document prior to adding reorganized content</td>
</tr>
<tr class="odd">
<td style="text-align: left;">oc2arch-v1.0.md</td>
<td style="text-align: left;">2022-01-19</td>
<td style="text-align: left;">Duncan Sparrell</td>
<td style="text-align: left;">WD03: Capture reorganized content</td>
</tr>
<tr class="even">
<td style="text-align: left;">oc2arch-v1.0-wd04.md</td>
<td style="text-align: left;">2022-05-04</td>
<td style="text-align: left;">Duncan Sparrell</td>
<td style="text-align: left;">WD04: Nearly complete draft</td>
</tr>
<tr class="odd">
<td style="text-align: left;">oc2arch-v1.0-wd05.md</td>
<td style="text-align: left;">2022-05-12</td>
<td style="text-align: left;">Duncan Sparrell</td>
<td style="text-align: left;">WD05: Minor updates for clarity & readability, presented for CSD approval</td>
</tr>
<tr class="even">
<td style="text-align: left;">oc2arch-v1.0-wd06.md</td>
<td style="text-align: left;">2022-07-13</td>
<td style="text-align: left;">Duncan Sparrell</td>
<td style="text-align: left;">WD06: Updated conformance section, added example message exchange, editorial fixes</td>
</tr>
<tr class="odd">
<td style="text-align: left;">oc2arch-v1.0-wd07.md</td>
<td style="text-align: left;">2022-09-14</td>
<td style="text-align: left;">Duncan Sparrell</td>
<td style="text-align: left;">ARCH-101: editorial fixes</td>
</tr>
<tr class="even">
<td style="text-align: left;">oc2arch-v1.0-wd07.md</td>
<td style="text-align: left;">2022-09-14</td>
<td style="text-align: left;">Duncan Sparrell</td>
<td style="text-align: left;">ARCH-102: clarify LS authority on Actions in 2.3.2</td>
</tr>
<tr class="odd">
<td style="text-align: left;">oc2arch-v1.0-wd07.md</td>
<td style="text-align: left;">2022-09-14</td>
<td style="text-align: left;">Duncan Sparrell</td>
<td style="text-align: left;">Arch-103: recommend standards-based approach to security services</td>
</tr>
<tr class="even">
<td style="text-align: left;">oc2arch-v1.0-wd07.md</td>
<td style="text-align: left;">2022-09-14</td>
<td style="text-align: left;">Duncan Sparrell</td>
<td style="text-align: left;">Arch-104: add Producer takeover to B.2.3</td>
</tr>
<tr class="odd">
<td style="text-align: left;">oc2arch-v1.0-wd07.md</td>
<td style="text-align: left;">2022-09-14</td>
<td style="text-align: left;">Duncan Sparrell</td>
<td style="text-align: left;">ARCH-105: improve OOBM discussion in B.4.2</td>
</tr>
<tr class="even">
<td style="text-align: left;">oc2arch-v1.0-wd07.md</td>
<td style="text-align: left;">2022-09-14</td>
<td style="text-align: left;">Duncan Sparrell</td>
<td style="text-align: left;">WD06: Updates to align with "actuator" to "profile" change in Language Specification (forthcoming v2.0)</td>
</tr>
</tbody>
</table>
<hr />
<h1 id="appendix-e-examples">Appendix E. Examples</h1>
<h2 id="e1-application-of-actuator-profiles-and-transfer-specifications">E.1 Application of Actuator Profiles and Transfer Specifications</h2>
<p>This example illustrates the application of the various types of OpenC2 specifications. Figure E-1 shows a simple operating environment with five components:</p>
<ul>
<li><p>A Security Orchestration, Automation, and Response (SOAR) system that is the OpenC2 Producer in the environment, directing the operation of OpenC2-enabled cyber defense functions.</p></li>
<li><p>A Publish / Subscribe message broker to support communications among the other components.</p></li>
<li><p>Three OpenC2 Consumers:</p>
<ul>
<li>An IP-Connected camera, illustrative of an Internet of Things (IoT) Consumer;</li>
<li>A Laptop, illustrative of a general purpose endpoint consumer;</li>
<li>A Firewall, illustrative of a network infrastructure consumer.</li>
</ul></li>
</ul>
<h5 id="figure-e-1-application-of-actuator-profiles-and-transfer-specifications">Figure E-1: Application of Actuator Profiles and Transfer Specifications</h5>
<p><img src="images/Arch-Example-1.drawio.png" alt="Figure E-1" /></p>
<p>The diagram also shows a collection of OpenC2 specifications, and tags the components with the specifications relevant to their participation in OpenC2 exchanges:</p>
<ul>
<li>The OpenC2 Language Specification</li>
<li>A Publish / Subscribe Transfer Specification</li>
<li>Three Actuator Profiles:
<ul>
<li>Endpoint Response (tagged "E")</li>
<li>Packet Filtering ("P")</li>
<li>Software Bill of Material (SBOM) Retrieval ("S")</li>
</ul></li>
</ul>
<p>Colored circles on each of the components identify which specifications are relevant to that component:</p>
<ul>
<li><p>The message broker needs to conform to the publish / subscribe protocol called out in the Transfer Specification, but does not have any OpenC2-specific requirements.</p></li>
<li><p>Messaging is defined by a combination of information from the Language Specification and the Transfer Specification, indicated by a bi-colored (red/blue) bubble. This function is relevant to all of the OpenC2 components.</p></li>
<li><p>All IP-connected camera must support the SBOM Retrieval AP.</p></li>
<li><p>The laptop (Endpoint Consumer) must support the SBOM Retrieval AP and the Endpoint Respose AP.</p></li>
<li><p>The firewall (Infrastructure Consumer) must support the SBOM Retrieval AP and the Packet Filtering AP.</p></li>
</ul>
<h2 id="e2-actuator-profile-typical-content">E.2 Actuator Profile Typical Content</h2>
<p>This example provides an overview of the typical structure and content of an OpenC2 Acuator Profile.</p>
<h3 id="10-introduction">1.0 Introduction</h3>
<p>This section provides a brief overview of the cyber defense function addressed in this AP.</p>
<h3 id="20-openc2-language-binding">2.0 OpenC2 Language Binding</h3>
<p>This section defines the set of Actions, Targets, Arguments, and Actuator Specifiers that are meaningful in the context of PF and the appropriate status codes, status texts, and other properties of a Response message. This section is also where any AP-specific extentions to the language are defined.</p>
<h4 id="21-openc2-command-components">2.1 OpenC2 Command Components</h4>
<p>This section identifies the OpenC2 Actions, Targets, Arguments, and Target and Actuator Specifiers needed for this AP. Depending on the needs of the AP, extended targets, arguments, and specifiers can be defined in this section.</p>
<h4 id="22-openc2-response-components">2.2 OpenC2 Response Components</h4>
<p>This section defines common and unique responses neede for this AP, and the response status codes that are applicable.</p>
<h4 id="23-openc2-commands">2.3 OpenC2 Commands</h4>
<p>This section defines the commands (i.e., Action / Target pairs) used for the control of the cyber defense function. A matrix is used to identify the valid pairs:</p>
<table>
<thead>
<tr class="header">
<th style="text-align: center;"></th>
<th style="text-align: center;">action 1</th>
<th style="text-align: center;">action 2</th>
<th style="text-align: center;">action 3</th>
<th style="text-align: center;">action 4</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td style="text-align: center;">target A</td>
<td style="text-align: center;"></td>
<td style="text-align: center;">valid</td>
<td style="text-align: center;"></td>
<td style="text-align: center;"></td>
</tr>
<tr class="even">
<td style="text-align: center;">target B</td>
<td style="text-align: center;">valid</td>
<td style="text-align: center;">valid</td>
<td style="text-align: center;"></td>
<td style="text-align: center;"></td>
</tr>
<tr class="odd">
<td style="text-align: center;">target C</td>
<td style="text-align: center;"></td>
<td style="text-align: center;"></td>
<td style="text-align: center;">valid</td>
<td style="text-align: center;">valid</td>
</tr>
</tbody>
</table>
<p>A second table links the valid commands to the available arguments, and links to the subsequent section where this command is discussed in detail.</p>
<table>
<thead>
<tr class="header">
<th style="text-align: center;"></th>
<th style="text-align: center;">command 1</th>
<th style="text-align: center;">command 2</th>
<th style="text-align: center;">command 3</th>
<th style="text-align: center;">command 4</th>
<th>command 5</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td style="text-align: center;">argument 1</td>
<td style="text-align: center;">section a.b.c</td>
<td style="text-align: center;"></td>
<td style="text-align: center;">section a.b.e</td>
<td style="text-align: center;"></td>
<td></td>
</tr>
<tr class="even">
<td style="text-align: center;">argument 2</td>
<td style="text-align: center;">section a.b.c</td>
<td style="text-align: center;">section a.b.d</td>
<td style="text-align: center;"></td>
<td style="text-align: center;"></td>
<td></td>
</tr>
<tr class="odd">
<td style="text-align: center;">argument 3</td>
<td style="text-align: center;">section a.b.c</td>
<td style="text-align: center;"></td>
<td style="text-align: center;"></td>
<td style="text-align: center;">section a.b.f</td>
<td>section a.b.g</td>
</tr>
</tbody>
</table>
<p>Subsequent subsections provide needed details about each command and its relevant arguments.</p>
<h3 id="30-conformance">3.0 Conformance</h3>
<p>This section provides the conformance clauses required in an OASIS specification. Clauses are grouped into those applicable to Producers using this AP to generate commands and those applicable to Consumers receiving and executing those commands.</p>
<h4 id="31-clauses-pertaining-to-the-openc2-producer-conformance-target">3.1 Clauses Pertaining to the OpenC2 Producer Conformance Target</h4>
<ul>
<li>Baseline Producer Clauses</li>
<li>Specific Producer Clause 1</li>
<li>Specific Producer Clause 2</li>
<li>...</li>
<li>Specific Producer Clause <em>n</em></li>
</ul>
<h4 id="32-clauses-pertaining-to-the-openc2-consumer-conformance-target">3.2 Clauses Pertaining to the OpenC2 Consumer Conformance Target</h4>
<ul>
<li>Baseline Consumer Clauses</li>
<li>Specific Consumer Clause 1</li>
<li>Specific Consumer Clause 2</li>
<li>...</li>
<li>Specific Consumer Clause <em>m</em></li>
</ul>
<h3 id="appendix-e-examples-1">Appendix E. Examples</h3>
<p>Examples of commands and responses that illustrate the use of this AP will be found in Appendix E.</p>
<h2 id="e3-transfer-specification-typical-content">E.3 Transfer Specification Typical Content</h2>
<p>This example provides an overview of the typical structure and content of an OpenC2 Transfer Specification.</p>
<h3 id="10-introduction-1">1.0 Introduction</h3>
<p>This section provides a brief introduction to the transfer protocol that is the focus of this transfer specification.</p>
<h3 id="20-operating-model">2.0 Operating Model</h3>
<p>This section provides an overview of the approach employed to use the transfer protocols in support of OpenC2 messaging. A description of how OpenC2 messages are packaged for transfer in the protocol is needed. Other content of the section is flexible based on the characteristics of the protocol in use. For example, a subsection of 2.0 would describe the topic structure used in a publish / subscribe environment, or which protocol features are used in a specific way for OpenC2 messaging.</p>
<h3 id="30-protocol-mapping">3.0 Protocol Mapping</h3>
<p>This section defines specific requirements to use the transfer protocol to implement the operating model, and provides details as needed to apply the standard that describe the protocol. Similar to section 2, the structure of this ection if flexible based on the characteristics of the protocol in use.</p>