The document discusses incident response in cyber-relevant time and the need for automation and standardization to enable faster response times. It introduces OpenC2 as an emerging open standard for command and control that aims to provide unambiguous machine-to-machine communication through a common language and protocols. OpenC2 focuses on the "acting" portion of cyber defense by coordinating defensive actions across different security systems through open specifications.

1. Incident Response in Cyber-Relevant Time
Lillehammer, August 27, 2019
Vasileios Mavroeidis, Security Researcher
Information and Cyber Security Research Group
University of Oslo
Email: vasileim@ifi.uio.no
Kamer Vishi, Security Researcher
Information and Cyber Security Research Group
University of Oslo
Email: kamerv@ifi.uio.no

2. • Statically Configured
• Operate in Isolation
• Incident Response and Recovery at «manual» pace
• Detection times without automated systems are slow. Inputs and
Outputs are manually pushed in different technologies.
• No standardized interfaces for communication between different
functional blocks
Cyber Defenses of Today

3. 3
Integration in the Absence of Standards

4. Cyber Defenses of Tomorrow
Coordinated Defense (multi-part response actions) in Cyber Relevant Time
Defenses are DYNAMICALLY configured and are part of an ORCHESTRATION process
“IOC might take 60 minutes to investigate manually can be researched in 30 seconds with Orchestration” [FireEye]
S T A N D A R D I Z A T I O N I S A K E Y E N A B L E R F O R A U T O M A T I O N
Need to speak the same language and protocols
Need to share what we know about attacks in cyber-relevant time (CTI)
How?

5. Open Command and Control

6. Active Cyber Defense
is a synchronized, real-time capability to discover, detect, analyze, and mitigate
threats and vulnerabilities to defend information networks (DoD 2011)
Comprises of 6 functional areas:
• sensing
• sense-making
• decision-making
• acting – OpenC2
• messaging/control (coordination)
• mission management (establish, operate and maintain ACD)

7. Open Command and Control (OpenC2)
Currently Three Official Specifications (approved on August 5th, 2019)
• Open Command and Control (OpenC2) Language Specification Version 1.0
• Open Command and Control (OpenC2) Profile for Stateless Packet Filtering Version
1.0
• Specification for Transfer of OpenC2 Messages via HTTPS Version 1.0
v1.0

8. • Unambiguous Machine-to-Machine Communication
• Simplicity
§ Low overhead on sensor and actuator
• Focuses on the ‘Acting’ portion of cyber defense
• OpenC2 assumes the following has been done:
§ Sensing: What triggers the action
§ Analytics: Why
§ Decision: Which action
OpenC2 at a Glance

9. • Actuator: The device or sensor that executes a native OpenC2 command
• Orchestrator: Is a mission manager that will issue the OpenC2 commands to
the appropriate actuators, and in the synchronous case, ensure the commands
are executed in the correct order
• Profile: A minimum to implement set of OpenC2 commands that a class of
actuators support
• OpenC2 Proxy: Provides a mapping of OpenC2 commands to and from devices
that do not natively support OpenC2.
OpenC2 Terminology

10. “Future” Cyber Defenses

11. Edge router
Firewall
Sandbox
End-point
.
.
.
SUBSCRIBERS
ORCHESTRATOR
Subscribe to a specific topic
Issue
OpenC2
command
Send the translated
command to a specific
subscriber
Pub/Sub Environment with OpenC2 Proxy
(Note: native interfaces are not supported)
OPENC2 PROXY
Translate/Map
Forward the OpenC2 command
OIF
(OpenC2 Integration Framework)
Classes/Topics
1. Edge router
2. Network Firewall
3. Sandbox
… …
n. End-point
Broker
(Store and Forward)

12. Edge router
Firewall
Sandbox
End-point
.
.
.
SUBSCRIBERS
ORCHESTRATOR
Subscribe to a specific topic
Issue
OpenC2
command
Send to a specific subscriber
Pub/Sub Environment with Security Appliances Supporting
NATIVE OpenC2 Interface
OIF
(OpenC2 Integration Framework)
Classes/Topics
1. Edge router
2. Network Firewall
3. Sandbox
… …
n. End-point
Broker
(Store and Forward)
OPENC2 PROXY
Translate/Map
Proxy is eliminated!

13. OpenC2 - Stateless Packet Filtering (SLPF)
● Example: Deny a particular connection
○ Block a particular connection within the domain and do not send a host unreachable
{
"action": "deny",
"target": {
"ipv4_connection": {
"protocol": "tcp",
"src_addr": "192.168.1.1",
"src_port": 10996,
"dst_addr": "81.167.155.132",
"dst_port": 80
}
},
"args": {
"start_time": 1534775460000,
"duration": 500,
"response_requested": "ack",
"slpf": {
"drop_process": "none"
}
},
"actuator": {
"slpf": {
"asset_id": "30"
}
}
}
OpenC2 Command
{
"status": 200
}
OpenC2 Response

14. Example: OpenC2
DENY
{
"action":"deny",
"target":{
"ipv4-connection":{
"protocol":"tcp",
"dst_port":"22",
"dst_addr":"172.20.52.0/24",
"src_addr":"171.69.198.0/24"
}
},
"actuator":{
"slpf":{
"asset_id":"uio_router1"
}
},
"args":{
"command_id": "sikkerhetsfestivalen27082019",
"response_requested":"ack"
}
}
ALLOW
{
"action":"allow",
"target":{
"ipv4-connection":{
"protocol":"tcp",
"dst_addr":"0.0.0.0/0",
"src_addr":"0.0.0.0/0"
}
},
"actuator":{
"slpf":{
"asset_id":"uio_router2"
}
},
"args":{
"command_id":" sikkerhetsfestivalen28082019",
"response_requested":"ack"
}
}

15. Example: Cisco
.
.
.
access-list 102 deny tcp 171.69.198.0 0.0.0.255 172.20.52.0 0.0.0.255 eq ssh
access-list 102 permit tcp any any
.
.
.

17. Security Playbooks and Orchestration
This playbook maintains the effectiveness of a subset of controls associated with:
NIST Cybersecurity Framework: ID.RA-2, ID.RA-5, DE.AE-3, RS.AN-1
Source: IACD
• Potential Malicious Indicator Identified
§ Process for investigating and responding to a potential malicious indicator identified on the network.

18. OpenC2 in the wild: Symantec’s ICDx supports OpenC2
Source: Symantec
Actions supported by Symantec ICDx are allow, deny, contain, query, and remediate.

19. OpenC2 SLPF Crash Course

20. Subset

25. Source: Allan Thomson – LookingGlass CyberSolutions
Coordinated response actions
We created a new working group within
Oasis Open that goes by the name CACAO
Focus on Course of Action Playbooks
Automation
Transitioning from atomic
actions/commands to coordinated
response actions

26. Who is OpenC2?

27. Incident Response in Cyber-Relevant Time
Lillehammer, August 27, 2019
Vasileios Mavroeidis, Security Researcher
Information and Cyber Security Research Group
University of Oslo
Email: vasileim@ifi.uio.no
Kamer Vishi, Security Researcher
Information and Cyber Security Research Group
University of Oslo
Email: kamerv@ifi.uio.no
Thank you!

28. Bonus slides

29. ¨ OpenC2
¤ Standard Command Language
¤ Supports Acting
¨ Language Specification
¤ Actions
¤ Default Target namespace
¤ Semantics, syntax
¤ Minimum to implement
¨ Actuator Profiles
¤ Puts the language in context
¤ Current: SLPF
¤ Future Efforts
n Routing, State-full Filtering, COMSEC,
¨ Implementation Specifications
¤ All other integration aspects
¤ Use of other standards to
address ‘External Dependencies’

30. Security playbook explanation example shown previously

31. OpenC2 Command
Producer
Extract UID
“asset_id” from
actuator specifier
Extract
action and target
Extract arguments
OpenC2 translation functions
to vendor specific technologies
Transmission functions
e.g. “ssh” - “http”
Take/Extract relevant information based on UID from
DB/SJON of the actuator. Specificity and vendor_specific
information (It can also be Pub/Sub environment but then we
would need to access a vendor_specific configuration file for
additional information relevant to the technology)
DB/JSON/PUB/SUB
Consumer
ProxyblockforCiscoIOSSLPF
Mapping
Response to the Proxy