IACD and the Quest for an Orchestrated Cyber Defense

This article is the first of a series that focuses on the latest trends in the field of cyber defenses that tackle the growing imbalance between defenders and attackers. Our journey takes us through the operationalization of the Integrated and Adaptive Cyber Defense (IACD) framework to guide security operational teams on the path towards security automation. After a short summary of the main issues encountered with traditional defense strategies, the article describes the IACD framework and details the orchestration services it models.

SEKOIA Team
May 20, 2019 · 8 min read
Image for post
Image for post
Photo by Franck V. on Unsplash

Context and issues

Gradually over the years, computerized environments have undergone many technological evolution. With the rise of virtualization, data and processes tend to migrate more and more into the cloud. These changes have led to new interactions, new architectures and therefore new attack surfaces. Mobility is everywhere and the perimeter of defense is becoming more and more uncertain. For these reasons, the complexity of protecting these computerized environments increases with these developments.

In addition, our traditional defense strategies are struggling to adapt to distributed environments. Indeed, permanent cyber defense postures that exploit separation, isolation, and concentration of effort on certain response points are inadequate for distributed, mobile, highly connected, and cloud-based environments.

Another aspect of our traditional defensive strategies is constantly weakened: the reactive strategy. The latter establishes that the defense posture must react to an attack to preserve the security objectives of its perimeter. For example, in the case of a malware such as NotPetya, the classic reactive approach is to isolate the dangerous applications identified as the main source of the epidemic. Nowadays, such isolation is being implemented through firewalls, data leak prevention solutions, and virus detection software. Unfortunately, such an approach is inappropriate when confronted with destructive attacks.

In addition to this complexity, there are the better planning of cyberattacks, their increasing sophistication and cybercriminals targeting specific organizations, regions or customer profiles. For all these reasons, traditional security strategies are less effective than before. For example, many companies say they cannot hire enough people with strong cyber security skills to deal with these new challenges. In such a context, human validation as well as the monitoring of all cyber defense operations cannot meet the operational needs of our growing infrastructures.

These findings are shared by many cyber defense actors who observe every day the growing imbalance that exists between defense teams and attackers. For all these reasons, new cyber defense strategies are being studied and proposed to be operationalized. This series of articles aims to detail one of them: the IACD framework and how it helps to accelerate cyber defense operational cycles until reaching the anticipation and thus get away from the bounded framework of the reaction.

IACD framework

Among other things, the IACD framework provides an architecture that aims to address the three following main aspects of the cyber security operations:

  • Orchestration to reduce the integration costs and timelines while enabling dynamic composability of the defense architectures. It also aims to ease the alignment of defensive actions with business and operational priorities.
  • Information Sharing to break the adversaries agility.
  • Automation to increase the speed of cyber defense and to improve the effectiveness of human defenders by placing them “on-the-loop” rather than “in-the-loop” of cyber security operations.

In this article, we focus on the solutions offered by the IACD framework to the orchestration issues. The Information Sharing and Automation aspects of the IACD framework are described in forthcoming articles.

Orchestration

The orchestration service of the IACD architecture relies on a tailored version of the Observe, Orient, Decide and Act (OODA) control loop: the IACD operational loop. As illustrated below, the IACD operational loop is made of four distincts capabilities:

  1. sensing capability to monitor and interface with the cyber environment,
  2. sense-making capability to recognize and assess the collected observations,
  3. decision-making capability to select the best response actions,
  4. the acting capability to implement the retained Course of Actions.
Image for post
Image for post
Illustration of the four main steps of the IACD Operational Loop

To reach its goal, the framework provides a conceptual model that comprises the definitions required to integrate SOAR (Security Orchestration Automation and Response solutions) into your cyber defense architecture. In this model, the SOAR product is responsible for executing the different capabilities provided by cyber security tools or products. In this schema, the orchestration service monitors and executes the response actions to reach both businesses and/or operational objectives.

Playbooks, Workflows and Local Instances

To permit the automation of a playbook execution, the orchestration conceptual model defines the notion of workflow as the machine-understandable instantiation of a playbook. A workflow defines the technical steps to be executed such that procedures are both auditable and repeatable: two fundamental characteristics.

The last abstraction level of the security automation is called local instance. A local instance denotes the tailored workflow for a specific environment, executing specific actions on specific devices and applications in response to specific conditions or events.

How to build a playbook

  1. identify the initiating conditions,
  2. list response actions,
  3. identify optional and required actions,
  4. order mandatory actions,
  5. insert optional actions in the playbook diagram.

The following details each of these stages:

Image for post
Image for post
The five stages of the playbook creation guidelines

The first stage consists in identifying the initiating condition of the playbook. The execution of a security process is activated or invoked in response to a predefined event or condition (e.g. reception of an attached filed, server not responding, increased traffic on a specific endpoint). In terms of orchestration, these events or conditions are called initiating conditions. It should be noted that in some cases, the execution of the playbook can be triggered by a clock configured to raise an event at a specific frequency (every hours, once a week, …). It is not expected to include the mechanism that triggered the playbook execution in the definition of the initiating condition. This way, we ensure the creation of generic enough playbooks that can be broadly applied to different organizations and let vendors derivate workflows from it.

The second stage defines the core content of the playbook: the process steps. Process steps represent “what should be done” with the definition of all the actions to be followed or implemented in response to the initiating condition. For example, the following process steps participate in a remediation playbook that triggers when a malicious indicator is detected on the network:

  • Collect information to Triage Scope, Criticality and Risk
  • Select Initial Response
  • Execute Initial Response Actions to address Compromise
  • Collect Information to Investigate Extend of Compromise
  • Identify Other Potentially Compromised Assets
  • Select Response Actions
  • Execute Response

Because a playbook should apply to different organizations, the process steps must not be so specific nor include aspects that could prevent its application given the context even if these process steps come from best practices.

The third stage consists in identifying the optional and required process steps among all the listed response actions. It comes from the fact that various factors are considered when establishing the best practices. For instance, one should always consider the sector, the asset type, the risk tolerance and the security maturity when designing a playbook. One way to address the context diversity while ensuring the genericity of the playbook, is to regroup process steps as required or optional.

The fourth stage focuses on the creation of the process steps diagram. This diagram denotes the order by which every required process step must be executed to reach the playbook’s objective. It is implemented as a directed graph where nodes are process steps and edges are transitions between process steps. As illustrated in the example below, such diagram accepts two types of transitions: automatic and manual transitions respectively represented by plain and dashed lines. Thus, a dashed line indicates that executing the next process step must be authorized or performed by a human. When executed manually, one should note that the operator of the playbook may choose “a none of the above” option which simply moves the current execution to the next step in the playbook.

Image for post
Image for post
Example of a process steps diagram as provided by the IACD Framework

The final stage in the recommended guideline is to reference the optional process steps in the diagram. These previously identified optional steps denotes additional actions that can improve the quality of the playbook execution but might not be applicable in all contexts.

Image for post
Image for post

Various examples of IACD playbooks are freely available on the IACDautomate website: https://www.iacdautomate.org/playbook-and-workflow-examples

Conclusion

SEKOIA.IO Blog

SEKOIA.IO — The Intelligence-Driven SaaS SIEM

SEKOIA Team

Written by

Pure player français de la cybersécurité depuis 2008 #ThreatIntelligence #CERT (réponse sur incident) #Pentest #RedTeam #Conseil #Formation #MSSP

SEKOIA.IO Blog

SEKOIA.IO — The Intelligence-Driven SaaS SIEM

SEKOIA Team

Written by

Pure player français de la cybersécurité depuis 2008 #ThreatIntelligence #CERT (réponse sur incident) #Pentest #RedTeam #Conseil #Formation #MSSP

SEKOIA.IO Blog

SEKOIA.IO — The Intelligence-Driven SaaS SIEM

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store