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.

‍

‍

Context and issues

Computerized environments have evolved a lot since the 80s-90s. At the time, systems evolved in homogeneous, static and time-stable environments where the systematic use of enclaves ensured the separation of critical networks. These systems were managed by dedicated staff and rarely used mobility features such as VPNs.

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

As stated by its authors, the “Integrated Adaptive Cyber Defense is a strategy and a framework for adopting a standardized, scalable, adaptive and commercial (COTS) approach to cybersecurity operations”. This effort is sponsored by the US Department of Homeland Security (DHS) and the National Security Agency (NSA) in collaboration with the Applied Physics Laboratory of Johns Hopkins University (JHU / APL).

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

Security orchestration is a way to improve security operations by consolidating the use of technologies and processes in playbooks. Security teams often have many tools and approaches for detecting and investigating threats. The orchestration intertwines all these tools, processes, and people to speed up the execution of cyber security responses and ensure their repeatability and auditability. Orchestration is therefore a prior step towards cyber security automation.

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.

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

As a matter of fact, the key element of the orchestration is the playbook. A playbook documents a functional process by means of a set of human readable steps. A playbook is expected to cover the organization’s procedures with a high-level definition broad and generic enough to be applicable by different organizations. Playbooks can be executed manually and progressively automated over time.

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

The IACD framework provides some insights on the playbook creation process. As illustrated in the figure below, the creation of a playbook can be achieved by following five stages:

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:

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.

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.

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

Conclusion

In this article we provided insights on the key elements covered by the IACD framework to build an orchestration playbook. We described the three abstraction layers that can be used to share and implement a repeatable and auditable security process along different organizations. Finally, we described the recommended guidelines provided by the IACD framework to build your own playbooks. In our next article, we will describe how this orchestration can be coupled with an Automated Indicator Sharing (AIS) system to exchange and exploit cyber threat indicators at a machine speed.

‍