1 of 15

Open Repositories Status�Information Briefing��David Lemire�IC-SC Co-Chair

4 April 2018

2 of 15

Agenda

  • Background & List of Open Repos
  • What’s Special About Each

2

3 of 15

Background

  • Implementation Considerations SC is responsible for open repos:
    • “shall also maintain a repository of prototype and reference implementations contributed to the OpenC2 Technical Committee.”
  • Currently have 11 open repos on GitHub
    • 7 brought forward from OpenC2 Forum
    • 4 new under OASIS
  • Repos exist to share implementation experience & encourage re-use

3

4 of 15

Repo List (shortened names)

  • ocas
  • jadn
  • yuuki
  • OrchID
  • Reactor-Master
  • Reactor-Relay
  • pub-sub-on-bsd
  • Lycan-java
  • Lycan-python
  • compatibility
  • Lycan-beam

Brought Forward

New under OASIS

4

5 of 15

Repo Status Worksheet

​

  • Identifies
    • Repo name
    • Summary description
    • Maintainer
    • Last Update (manual entry)

5

6 of 15

So, what have we got?

A review ��(in no particular order)

6

7 of 15

lycan-java / lycan-python

  • AT&T interpretation of LDD v1.0 RC4
  • Software libraries to translate
    • OpenC2 JSON strings to objects, and
    • Objects to OpenC2 JSON strings
  • Minimal implementation, just what AT&T needed OpenC2 messaging
  • Java code base is built on top of Jackson JSON library
  • Translation only, does not address transport

7

8 of 15

pub-sub-on-bsd

  • Written in C / developed on HardenedBSD
  • Use sub//pub (zeroMQ) model for comms
  • Three subparts:
    • Broadcast: creates OpenC2 messages
    • Orchestrator: sends messages to the appropriate places
    • Edge:
      • receives & acts upon OpenC2 messages
      • Plugins-based functionality, currently allow & deny
      • Intent is to create edge plugins for any functionality required by the actuator

8

9 of 15

openc2-yuuki

  • Python 2.7
  • Lightweight HTTP/JSON endpoint
  • Dispatch on the type of the target and actuator

9

10 of 15

ocas

  • OpenC2 API Simulator
  • Erlang application for simulating OpenC2
    • Purpose: validating and verifying an OpenC2 interface
    • Only consumer view is implemented to date
    • Intended to scale so that entire networks can be simulated
  • Built to forum RC4; minor updates but is currently out-of-date
  • Intend to update to CSD03�

(Ocas is also a South American tuber)

10

11 of 15

jadn

  • JSON Abstract Data Notation
  • Purposes:
    • Provides an abstract schema that is independent of serialization
    • Provision a codebase for unit testing, command validation, and conversion of the abstract notation to various serializations.
  • JADN defines the structure of datatypes independently of the serialization used to communicate and store data objects

11

12 of 15

OrchID

  • Orchestrator for Intelligent Defense
  • OpenC2 proxy built in Django 1.10.2.
  • Simple, modular API to
    • Accept OpenC2 commands, and
    • Convert them into Python actions.
  • Codebase to enable other prototype efforts

12

13 of 15

reactor-master / reactor-relay

  • Demonstrate OpenC2 managing geographically disparate network
  • Master:
    • API to command downstream relays
    • Means to manually send commands to capable actuators deployed on client's sites that wouldn't be accessible directly from the internet
  • Relay:
    • Accepts OpenC2 commands, converts to Python actions
    • Relays commands from central server to local actuators

13

14 of 15

lycan-beam

  • Collection of applications and libraries that run on the BEAM virtual machine
    • BEAM = Bogdan/Björn's Erlang Abstract Machine
  • Example languages: Erlang, Elixir

14

15 of 15

compatibility

  • Help with “chicken and egg” problem
  • Capture OpenC2 core design principles
  • Develop implementation guidelines for interoperable systems
  • Act as an evolving reference guide to OpenC2 prototype implementers
  • Provide a feedback mechanism to TC / SCs

15