The ICD Conceptual Reference Model

The ICD Conceptual Reference Model provides an introduction to the concepts, ecosystem considerations, and inter-party relationships needed to enable organizations to share and automatically respond to cyber threat information, indicators, and intelligence (CTI3). This Conceptual Reference Model also presents a shared understanding of the scope, strengths, and limitations of Security Orchestration Automation and Response (SOAR) in an integrated environment. These models are implementation independent, thereby providing system architecture flexibility by establishing the baseline for technology insertion. Also, they do not provide recommendations on prioritization of capabilities, functions, and activities.

There are three models that comprise the ICD Conceptual Reference Model, each of which incorporates the common guiding principles, technical positions, and patterns used throughout the ICD community:

  • The Orchestration Model presents functions that are used to satisfy an organization’s activities in response to CTI3.
  • The Activities Model presents the ICD capabilities with respect to the CTI3 orchestration and sharing activities within and between the Federation Manager and the Federation Members.
  • The Capabilities Model presents details on the capabilities and their relationships and shows how CTI3 flows within and between the Federation Manager and the Federation Members.

Details of the ICD Reference Models can be found in the following white paper located here: ICD Conceptual Reference Model Whitepaper.


It is important to note that a conceptual reference model is different from a reference architecture. A reference architecture focuses on enabling deployment of locally optimal solutions for specific enterprises and business models. Below is an example using a smart phone to illustrate the differences:

Smart Phone Example to Illustrate Differences Between a Conceptual Reference Model to Reference Model
Conceptual Reference Model Reference Model
Contain information such as:
  • Possible capabilities of a smart phone
  • Ways a user could interact with it
  • How phones can interact with other phones to enable human interaction
 Contain information such as:
  • Blueprints for each subcomponent
  • Explain how the various components fit together
  • Identify standards that must be followed for compliance with appropriate laws and authorities

THE ORCHESTRATION MODEL

The Orchestration Model is comprised of the following four components. Please note that the items contained within each are not all-inclusive due to the ever-changing nature of the ICD domain, and should be tailored by each organization to fit their individual needs.

  • Functions: A selection of actions that can be carried out by various cybersecurity tools and products an organization may choose to deploy in their environment.
  • Capabilities: Abilities provided by a cybersecurity tool or product, which can be orchestrated.
  • Orchestrate: Represents the Security Orchestration, Automation, and Response (SOAR) product that is responsible for executing the capabilities in a repeatable, auditable, and scalable manner that satisfies organizational policies that govern the whole process.
  • Activities: High level processes than an organization undertakes to satisfy policy and governance requirements.

An organization does not need to orchestrate all the capabilities in their environment; rather, capabilities can be connected and disconnected to the SOAR product depending on the organization’s comfort level and/or current operational situation. Understanding which activities an organization wants to complete and what functions and capabilities are available within that organization to help complete those activities allows for a better understanding of how orchestration can benefit the organization. In addition, understanding what functions and capabilities are needed to complete required activities allows for more informed purchasing of security tools and products.

THE ACTIVITIES MODEL

The Activities Model presents the capabilities and activities a Federation Member and Federation Manager can conduct to facilitate orchestration, as well as the sharing of CTI3 between parties. An organization does not need the ability to perform every capability and activity to implement some degree of security automation and orchestration.

THE CAPABILITIES MODEL

The Capabilities Model presents the flow of CTI3 across the range of potential capabilities (which are provided by the various cybersecurity tools and products that an organization can deploy to their environment) both within and between the Federation Manager and Federation Member. It also contains ideas on how each capability can be decomposed further. The capabilities conveyed are not meant to be exhaustive, and said capabilities may contain additional component capabilities not shown here.

One note to facilitate the readability of this model is that a Federation Member can receive CTI3 from one or more of the following possible sources:

  • Various internal sensors (bottom right of the Model) deployed across their enterprise.
  • A peer-to-peer relationship directly with other Federation Members to receive and/or share CTI3
  • Federation Managers who offer CTI3 subscription(s) with a common interest or potential relationship (e.g., same sector, geographic region)

An organization can use these models to identify their high-priority activities, capabilities, and functions which can facilitate identification of potential tools and products to satisfy their needs. Said organization can then validate whether the prospective product(s) can provide the desired capability in discussion with the vendors. As the tools are deployed and tested, the organization can confirm whether their target capabilities are satisfied and the CTI3 is flowing through their system as expected. Likewise, gaps may be identified that require modification to and/or additional procurement of cybersecurity tools and products.