This work is accepted for publication in ECSA 2020, Laquila, Italy.
The published version is available at https://doi.org/10.1007/978-3-030-58923-3_11
Architecture-centric Support for Integrating Security
Tools in a Security Orchestration Platform
Chadni Islam1,2, M. Ali Babar1 and Surya Nepal2
1 CREST Centre, University of Adelaide, Adelaide, SA 5005, Australia
2 CSIRO’s Data61, NSW, Australia
Abstract. Security Operation Centers (SOC) leverage a number of tools to detect,
thwart and deal with security attacks. One of the key challenges of SOC is to
quickly integrate security tools and operational activities. To address this chal-
lenge, an increasing number of organizations are using Security Orchestration,
Automation and Response (SOAR) platforms, whose design needs suitable ar-
chitectural support. This paper presents our work on architecture-centric support
for designing a SOAR platform. Our approach consists of a conceptual map of
SOAR platform and the key dimensions of an architecture design space. We have
demonstrated the use of the approach in designing and implementing a Proof of
Concept (PoC) SOAR platform for (i) automated integration of security tools and
(ii) automated interpretation of activities to execute incident response processes.
We also report a preliminary evaluation of the proposed architectural support for
improving a SOAR’s design.
Keywords: Security orchestration, security automation, software architecture,
security tool integration, design space.
The adoption of Security Orchestration, Automation and Response (SOAR) platforms
has recently gained major popularity among security analysts, Security Operation Cen-
ters (SOC) and incident response team [1-4]. SOAR platforms enable integration, or-
chestration and automation of the activities (e.g., block IP, scan endpoint and isolate
host) performed by security tools and human experts .
Existing SOAR platforms lack proper abstractions for designing a platform at the
architectural level [1-3, 5]. Most of the existing SOAR platforms are implemented in
ad-hoc manners without much attention to the underlying infrastructure . As a result,
there can be several engineering challenges involved in embedding agility in a SOAR
platform [2, 4, 7]. These challenges result in highly complex and monolithic design that
is hard to evolve overtime. A SOAR’ design complexity may also worsened by a lack
of conceptual and practical guidelines for optimal architectural design decisions [2, 6].
An architecture-centric approach [7-9] is expected to help in reducing the design
complexity of a SOAR by modularizing the functionalities and non-functional
requirements. The architectural design decision provides a foundation for analyzing and
understanding the sub-optimal design choices , which can be improved by leverag-
ing suitable architectural styles and patterns.
A design space is required to capture and characterize design decisions for integrat-
ing techniques and tools that underpin a SOAR platform . Developing design spaces
for different domains of software systems is a growing trend . The design space of a
SOAR platform involves many architectural design decisions and trade-offs that are
impacted by security tools and applications integrated into these platforms. We propose
a concept map considering the functionalities performed by a SOAR platform. It allows
one to modularize the functions and separate the concerns of the components that pro-
vide the design space of a SOAR platform.
In this article, we present an architecture-centric approach to design and implement
a SOAR platform. The proposed approach consists of three parts:
─ Abstraction to model SOAR platform design space: We provide a concept map of a
SOAR platform that defines and relates the key concepts of SOAR to support under-
standing of security tools integration and orchestration. The design space is useful
for understanding and analyzing requirements of emerging SOAR platforms and in-
tegration technologies for faster response and efficiency.
─ Layered Architecture for SOAR platform: We provide a layered architecture that
modularizes the components into different layers based on two key functionalities –
integration and orchestration. These two key requirements are to guide architects to
design and deploy a SOAR platform to integrate security tools and orchestrate ac-
tivities based on integrated security tools. We further consider the architecture style
and pattern as a mean for delimiting the design space.
─ Proof of concept SOAR support: We have developed a Proof of Concept (PoC)
SOAR platform that has been designed to fulfill the quality requirements - integra-
bility, interpretability and interoperability following the proposed architecture. We
have used seven security tools with different capabilities. The evaluation results
show the feasibility of the proposed architecture approach for (i) automated integra-
tion of security tools and (ii) automated interpretation of incident response activities.
This paper is organized as follows. Section 2 introduces a concept map of a SOAR
platforms' design space. Section 3 presents the modularized architecture of a SOAR
platform. Section 4 details the dimension of a SOAR platform’s integration design
space. Section 5 presents a case study. Section 6 demonstrates the evaluation of the
PoC. Section 7 discusses related work and section 8 concludes the paper.
2 Security Orchestration and Automation
The SOAR platforms are integrated solutions for an organization's SOC. The underly-
ing technologies of SOAR platforms are designed to interweave people, process and
technology. In a SOAR platform, people are responsible for intelligence-based decision
making and technologies are used to streamline complex process. The key purpose of
a SOAR platform is to power automation through orchestration. The functionalities of
a SOAR are mainly categorized into integration, orchestration and automation .
The development of any SOAR platform first needs to focus on integrating the se-
curity tools in a single platform. Depending on the organizations, the security tools can
be open source, commercial, proprietary, packaged or even legacy bunch of scripts.
Security tools are generally integrated using plugins, scripts, APIs and modules. Mostly
SOAR vendors provide plugins and APIs based support for 150 – 200 security tools
[10, 11]. Security tools generate data in a variety of formats. Further, the data are uni-
fied to enable interoperability among security tools.
The second key task of a SOAR is orchestration. It allows organizations to deploy
and operationalize their security process or Incident Response Process (IRP) using a
piece of code or script, also known as a playbook. An IRP is a set of activities performed
by security experts and security tools. Playbooks contain a set of instructions that makes
security tools interoperate in a manner where the output of one tool is used as an input
to other tools. An orchestration process improves the response to a security incident by
reducing the manual and repetitive tasks done by human experts.
The third task of a SOAR is automation or response. An organization needs to iden-
tify what they need to orchestrate and what can be automated. Mostly validation, prior-
itization, reducing false alarms and checking for access control authorization are the
different types of activities that are automated through orchestration processes. The
SOAR community has not quite reached a consensus on any standard mechanism of
automation of security activities.
2.1 Functional Requirements of Security Orchestration and Automation
SOAR as a unifier or hub. We adopt the functionality of a SOAR outlined in a recent
multivocal review . We consider a SOAR platform as a hub that unifies the activities
of security tools and provides a single pane for supporting operations of a SOC. Secu-
rity tool integration is one of the most important resource intensive and time-consuming
activities in a SOC. Security tools can be integrated using several architectural integra-
tion styles . Semantic technology can be leveraged for integrating security tools. A
semantic integration mechanism ensures that a SOAR platform can interpret the data
consumed and generated by security tools for interoperability. A SOAR platform first
needs to integrate security tools and then based on integration mechanisms it interprets
the IRPs. It can enable organizations to use playbooks from different vendors to model
an orchestration process by unifying the semantics provided in playbooks. Most SOAR
platforms filter incoming alerts based on their syntactic and semantics correctness be-
fore delivering them to analytics tools. A SOAR’s architecture should support
semantics integration among the artifacts produced and consumed by security tools.
SOAR as a coordinator or orchestrator. A SOAR platform orchestrates security tools
activities and streamlines complex security processes into simplified processes. The
orchestration processes can be considered as a sequence of actions, where the output of
one tool needs to be the input of other tools. A simplified process is easy to follow and
enables a SOC to differentiate between manual and automated processes. It also helps
to keep track of the ongoing scans and activities that require immediate human
involvement. It should be noted that a lot of SOAR literatures tend to use integration
mechanisms or connecting tools as an umbrella term to cover all processes that happen
under-the-hood of security orchestration. Whilst this abstraction is helpful to gain an
initial understanding of security orchestration, we argue that architects would benefit
from a more modularized model that clearly distinguishes the activities related to inte-
gration, orchestration and automation within SOAR platforms.
2.2 Quality Attribute Requirements
A SOAR should also satisfy certain quality attribute requirements. The essential quality
attribute requirements or Non-Functional Requirements (NFRs) of a SOAR are catego-
rized into design time and runtime requirements. To design an architecture of a SOAR
platform, we focus on the following quality attributes.
• Integrability: Security tools integrated into a SOAR platform come from different
vendors. An architecture of a SOAR platform is expected to seamlessly integrate
security tools and quickly adapt modification of security tools’ functionalities.
• Interoperability: A SOAR platform should support semantic integration of differ-
ent types of artifacts generated by security tools and data sources. The integration
mechanism needs to ensure that security tools can interoperate with each other.
• Interpretability: A SOAR platform should be able to semantically interpret the data
generated and consumed by security tools.
• Flexibility: A SOAR platform’s tasks depend on IRPs and emerging threat behavior
which changes continuously. A SOAR architecture should be flexible to provide
mapping support for security tools and IRPs to adapt the changes.
• Usability: A SOAR’s architecture needs to be easily understandable so that a SOC
can easily learn and operate a SOAR platform and interpret the input, output and
activities of the components.
2.3 Abstraction for Security Orchestration and Automation
Organizations generically deploy and run a SOAR platform on top of existing security
tools, information systems and organizational infrastructures to fulfill their security re-
quirements and business needs. An architect must understand the core concepts of a
SOAR platform to design and communicate about the orchestration process and re-
quired integration and automation technologies with stakeholders and developers of a
SOAR platform. The lack of a comprehensive view might result in concept overlapping
and ambiguity. To address this issue, we propose a conceptual map to capture the com-
mon terminologies of a SOAR. Fig. 1 shows the conceptual map of a SOAR platform
that provides the key elements and relationships among these elements.
A SOAR platform connects a wide variety of security tools that have different capa-
bilities. By capability, we mean the features and characteristics of security tools, which
can support different types of activities. Security tools are generally categorized as de-
tection, analysis and response tools depending on their capabilities (Fig. 1). This cate-
gorization is made based on the activities performed by security tools while responding
to an incident. For example, monitoring tools can be considered under detection or
analysis tools depending on their contribution to an IRP. A detailed description of se-
curity tools used for this research is out of the scope of this paper.
Incident Response Plan
Composition Generalization AB
Fig. 1. Conceptual map of security orchestration and automation
A SOAR platform is designed and deployed based on an organization’s security re-
quirements and the available security tools. A SOAR developer needs to design and
develop different types of integration mechanisms (e.g., APIs, plugins or modules) to
integrate security tools (Fig. 1). A SOAR platform performs a set of tasks that can be
categorized in unification, orchestration and automation. It runs the orchestration pro-
cess that invokes security tools to perform certain activities. An orchestration process
is the composition of tasks performed by a SOAR and activities performed by security
tools. It contains the invocation actions, scripts to invoke tools and the responses of
security tools. Orchestration processes govern the integration, orchestration and auto-
mation task to respond to a security incident.
The orchestration process primarily is designed in the form of a set of playbooks,
which are generally dedicated to a particular security incident and have a dedicated set
of security tools that are deployed in an organization’s environment. Most organizations
also have dedicated Security Incident Response Team (CSIRT) who mainly design
IRPs for security incidents based on an organization’s preferred security requirements
(i.e., confidentiality, integrity and availability), policies and quality requirements.
SOAR developers or playbook designers design and develop playbooks based on the
available security tools and well-known integration mechanisms.
3 SOAR Architecture
We propose an architecture to ensure the functional and non-functional requirements
of a SOAR platform. The key research objective is “how software architecture can play
a role in improving the design practices of a SOAR platform?”. We design the archi-
tecture of SOAR platform at two levels of abstraction. The architecture is first designed
following the layered architectural style which provides the first level of abstraction.
There are six layers – (i) security tool, (ii) integration, (iii) data processing, (iv)
semantic, (v) orchestration and (vi) User Interface (UI) layer as shown in Fig. 2. Each
layer has both logical and physical aspects. The logical aspects cover the architectural
building blocks and design decisions of a SOAR platform. The physical aspects include
the realization of the logical aspects by using organizations' technologies and products.
Each layer has a separation of concerns that allows security staff to freely choose the
preferred components and deploy a SOAR based on their requirements (Fig. 2).
Security Tool Layer
Security Tool Security Tool Security Tool Security Tool
Fig. 2. High-level architecture for SOAR platform
Each layer is decomposed into components and sub-components. We consider the
components as the lower level of abstractions. Fig. 2 shows the core components and
interactions among the components that are required to achieve the desire goals of a
SOAR platform. Different functionalities of a SOAR platform require different combi-
nations of these components. We specify the components as a principle computation
element that implement different tasks of a SOAR to execute IRPs.
UI layer: Security staff initiate existing IRPs or define new plans using a SOAR’s
User Interfaces (UIs) such as interactive dashboards or Integrated Development Envi-
ronment (IDE) or Command Line Interface (CLI). The UI layer supports flexibility in
designing UIs that helps define IRPs and integrate security tools. A SOC can easily
learn and operate a SOAR platform using the UI. An abstraction layer or API layer can
be implemented as part of the UI layers to maintain and encapsulate the interaction
among a SOAR’s user and its components (Fig. 2).
Orchestration layer: The orchestrator and task manager together form the coordi-
nator of a SOAR platform (Fig. 2). The orchestrator is responsible for coordinating and
forming configuration to achieve interoperability and automating the execution of
IRPs. The planner in the orchestration layer has a set of ‘playbooks’ to automate the
execution of an IRP and keep track of the tasks being executed. Each playbook has a
set of tasks that contains the details of the process about the input required to execute a
task and also the output that is generated after task execution. The playbooks further
contain the conditions that trigger the execution of a particular task. A playbook’s tasks
vary depending on the requirements of a SOC and the types of security tools available.
The orchestrator monitors the successful or unsuccessful execution of tasks. The plan-
ner provides a set of APIs through which a user can update or modify the orchestration
process. An orchestrator may use a set of APIs to govern the execution of an IRP.
Semantic layer: The semantic layer is responsible for the semantic interpretation
of data that flows across a SOAR platform. It consists of a knowledge base, query en-
gine and interpreter. A knowledge base usually consists of an ontology of security
tools, their capabilities and activities of an IRP, which enables the interpreter to seman-
tically interpret security tools’ capability and IRPs’ activities. The details of the ontol-
ogy can be found in . The query engine is responsible for extracting data from a
knowledge base. In our proposed architecture, we consider the semantic layer separate
from other layers to give SOC the flexibility to define or modify an ontology.
Data processing layer: The information used by a SOAR ranges from business-
critical data to usage systems logs, alerts logs and malicious activities that are processed
by the data processing layer. Data curator, data extractor and data analyzer are the
three main components of data processing layer. The data curator gathers the data pro-
duced by tools for analysis. This layer contributes toward interoperability and inter-
pretability by processing the heterogeneous structured and unstructured data of differ-
ent security tools and playbooks. It is responsible for sharing semantically structured
data among different components of a SOAR throughout an IRP execution process. An
architect can incorporate any automation algorithm or data analysis techniques as part
of data analyzer without affecting other components of a SOAR.
Integration layer: The integration layer has five components: integration manager,
wrapper, tool registry, plugin repository and API gateway. This layer is designed to
integrate security tools. The integration manager works as a description module
through which security tools are integrated and information is provided to enable inter-
pretability among them. A tool registry is responsible for discovering and registering
available security tools to monitor their status and report any changes. Security tools
are registered in terms of their capabilities (i.e., input, output and functions) and types.
The wrapper, API gateway and plugins are intermediary components that provide in-
terfaces to encapsulate security tools for data translation or imposing orchestration. An
integration manager uses these components to initiate a request and become the ultimate
recipient of orchestrator’s commands. The difference between wrapper, plugins and
API gateway lies in security tools integration and communication protocols.
Security tool layer: The security tools layer consists of multivendor heterogeneous
security tools, which are typically a mix of open source, proprietary, custom and com-
mercial-of-the shelf (COT) products. These tools are mainly characterized as unmodi-
fiable components of a SOAR platform. Given most of the security tools are required
to interact with each other, an in-depth understanding of the security tools’ data struc-
tures and capabilities are necessary to integrate them into a SOAR platform.
Fig. 3 shows an example UML sequence diagram for responding to a security inci-
dent that comprises of components from each layer.
:Security Tool :APIs/plugins :Data Analyzer :Interpreter :Orchestrator
Generate Dat a Send Data Collected Dat a
Interprete d Data
Find Capabilit y
Invoke Too l
Interprete d Tool
Send Com mand
Invoke Too l
Fig. 3. An example sequence diagram showing the flow of data and interaction of components
4 Dimensions of the Design Space of SOAR
The design space of a SOAR reveals that the integrated security tools and orchestration
process mainly govern the tasks of a SOAR platform. Hence, we have considered the
architectural design decisions from the process and technology perspective for auto-
matically integrating security tools and orchestrating IRPs.
Process decision: Along with defining the orchestration process, it is important to
define the process for integrating security tools and analyzing data. A SOAR’s process
varies depending on the mode of a task – automated, semi-automated or manual. The
automation of the integration process relies on five design decisions for integration
process, interpretation process, security tools to capability mapping process, security
tool discovery process and security tool invocation process. A decomposition of the
functions based on layers helps in selecting a suitable technology depending on required
process. For example, the task to manually integrate security tools is separated from
automatically interpreting the security tools’ data. Security tools are first required to
integrate into a SOAR platform, then processes are designed to interpret the security
tools data and IRPs activities. Here, the modular architecture helps with defining dif-
ferent processes, which are mainly orchestration of security tools, SOAR’s components
and organizational information systems.
A SOAR platform can be centralized, distributed or hybrid depending on an organi-
zation’s infrastructure . For centralized or distributed applications, the communica-
tion protocols are different. In most cases, these communication protocols (i.e., REST
API, RPC and event-driven) are hidden under the internal structures of security tools,
which expose their functions through APIs. A communication process can be designed
to manage distributed communication among different security tools.
Technology decision: From a technology perspective, we mainly consider the inte-
gration technologies, interpretation mechanisms and tools discovery mechanisms that
are required for integrating security tools, designing the orchestration process and pow-
ering automation. A SOAR’s taxonomy has six automation strategies . An underly-
ing technology infrastructure consists of the assets of an organization depending on the
type of the automation strategy. Example of assets includes various hardware and soft-
ware infrastructures (i.e., computer systems, operating systems and applications) that
an organization needs to protect from security attacks. Orchestrations can take place in
different types of environments which can be open or restricted. We need to consider
different architectural integration styles to ensure that the integration constraints related
to different security tools and stakeholders (e.g., semantic, performance and compo-
nent constraints) are addressed .
Following we provide a set of design decisions that need to be made by an architect.
• Building a generic block of a SOAR platform. An architect can choose to design a
playbook and script for orchestration and automation.
• Disseminating tools that are integrated and participate in orchestration. Architects
have to decide on how to map security tools to IRP and where to deploy them in an
organization’s environment so that orchestrator can invoke the tools when required.
• Setting up a mechanism for an orchestrator to discover security tools. An architect
has to choose integration styles and define processes for discovery of security tools.
• Setting up and starting an orchestration process. An architect has to decide who has
the right to modify the process and provide an interface to modify or add new IRPs.
Table 1 shows a summary of the architectural design decisions for achieving the
desired functional and non-functional requirements of a SOAR platform. By architec-
tural design decisions we mean the design decisions that would have system wide im-
pact and/or impact on more than one non-functional requirements .
Table 1. Summary of architectural design decision
Ontology for formalizing security
tools and activities of IRPs
Make a SOAR architecture flexible to integrate differ-
ent types of security tools with varied data formats.
Use of ontology for semantic inte-
gration and information discovery
Support tools specific integration and automated exe-
cution of IRPs in dynamic environment
Layered architectural style
Easy evolution of SOAR’s components and easy mod-
ularization of functionalities and components
Abstraction of SOAR’s components
task with a set of APIs
Make a SOAR platform easy to use, manage and learn
Automated integration and interpre-
Enable reuse of existing components with changes in
IRPs and security tools
Share ontology template in a central-
ized repository pattern
Provide access of the ontology to its end users and
support flexibility in update
5 Case Study – Prototype Implementation
In this section, we present a Proof of Concept (PoC) SOAR platform that we have de-
signed and implemented based on the proposed architectural approach . The func-
tional requirements of our PoC are to automate the process of integrating security tools,
automate the selection of security tools to execute an IRP and automate the execution of
a set of IRPs. We designed the PoC in a way so that it is easily evolvable for future
changes. In this implementation, we considered two types of changes that are most com-
mon is SOARs execution environment – change in security tools and change in IRPs.
Fig. 4. presents the implementation architecture of the PoC. We analyzed the instruction
of integration and orchestration to select the technologies and identify the design deci-
sions. We designed automated integration processes and selected semantic technologies
to enable semantic integration and interpretation of security tools data.
Splunk API MISP API
Send data (alert, log, report, packet)
SPARQL query engine
Output Handler Input Constructor
Fig. 4. Implementation architecture of the PoC for security tool integration
We selected seven open-source tools
with varied capabilities. The selected tools are
Snort, Splunk, LimaCharlie, MISP, Windows defender, Wireshark and WinPCap which
are IDS (Intrusion Detection System), SIEM (Security Information and Event Manage-
ment Tool), EDR (Endpoint Detection and Response) tool, Open Source Threat Intelli-
gence and Sharing Platform (OSINT), Firewall and packet monitoring and logging tools
respectively. The security tools were selected based on the diversity in their capabilities
because execution of an IRP would require multiple security tools. We used 24 different
capabilities of the selected tools with MISP as a new tool to be integrated later. We have
curated a set of IRPs from Demisto’s (i.e., a SOAR platform provider) collaborative
playbooks . We have selected 21 IRPs and slightly modified them to fit the
capabilities of the seven security tools used for our research. We designed another 48
IRPs as a new set of IRPs that PoC would require to execute without user intervention.
The list of capabilities and IRPs are available at .
The implementation decision incorporated APIs based integration style as our
primary mechanism to integrate security tools into a SOAR. The data from the security
tools such as MISP and Splunk have been made accessible through their APIs. Besides,
we have built wrappers for security tools that do not provide specific APIs such as Snort.
Integrating a new tool required us to identify security tool’s APIs or information sharing
protocol and implement a suitable integration mechanism. The API and wrappers of Fig.
4 are part of the integration layer of the PoC.
We also designed an ontology to formalize security tools, their capabilities and IRP’s
activities to enable semantic interpretation of security tools data . Each security tool
can execute multiple activities and each activity can be executed by multiple security
tools. We used Apache Jena Fuseki server to store the ontology. Security tools are
https://www.snort.org, https://www.splunk.com/, https://www.limacharlie.io/, misp-project.org
formalized based on their capabilities and the activities of IRPs are mapped with security
tool class of an ontology. Table 2 and Table 3 illustrate how security tools and IRPs
have been mapped onto an ontology. We designed a SPARQL query engine to retrieve
the required information from the ontology. The retrieve data are interpreted through an
interpreter, which mainly deconstructs the data for further processing. The designed
ontology along with the interpreter built the semantic layer.
Table 2. Illustration of a selected set of object properties of security tool class of an ontology
Table 3. Illustration of a selected set of data properties of security tool class of an ontology
We built a collector to gather security tools’ data, which are sent to an orchestrator
via the interpreter for actions, e.g., Splunks API is configured to receive system logs of
various endpoints. This data is searched and processed to find programs, files or users
that could be malicious. Further to formulate the commands, an input constructor is built.
The automation algorithms or processes have been mainly built as integration pro-
cesses that are the parts of the orchestration layer (Fig. 4). We designed and imple-
mented scripts to define the automated integration process, which includes selecting the
security tools based on activity description, interpreting their capabilities, formulating
the input commands and finally invoking the security tool by calling appropriate APIs
. An example is shown in Fig. 5 where the output of Splunk is sent to LimaCharlie.
The orchestrator is required to collect the output of Splunk and then interpret it. All the
data generated by Splunk might not be required by LimaCharlie; so, the orchestrator
would require to construct the input of LimaCharlie from Splunk’s output to invoke
LimaCharlie. We developed and designed this process as part of the integration process
to automate the interpretation of the security tools data, which enable seamless interop-
erability among security tools. Using the integration process, data sharing among the
security tools of Fig. 5 happened seamlessly.
In this section, we report how the PoC has been evaluated to demonstrate the feasibility
of the proposed architecture approach based on two scenarios.
-log: DataElemen t
Output to directory
+deleteFile(String , String)
+killProcess(Strin g, String)
Fig. 5. Example of data transfer from Splunk to LimaCharlie
6.1 Automating the Process for Integration Security Tools
Let’s assume that a user has expressed a goal of integrating security tools. We have
decided to use the proposed architecture for automating security tools integration. In
the current implementation, an ontology is available that works as a knowledge base of
a set of existing security tools. To integrate the available security tools, the orchestrator
provides a template of an ontology to users for specifying the tools’ capabilities and
map it with the available activities or activity it can execute. This process stores the
security tools’ information in an ontology that makes the information available to the
orchestrator. If the security tools have different capabilities, the information is updated
in the ontology. Further, the process for automating the integration of security tools is
invoked which enables the collector to collect the security tools’ output and orchestrator
to formulate and send commands to the security tool for executing the desired activities.
Other integration approaches such as designing static APIs for communicating with
security tools or plugin-based integration require to develop wrapper along with con-
nection with the data curator and the orchestrator to collect the security tool data. The
collector needs to be configured to access the data generated by security tools. Thus,
integrating a single tool would require development of at least one component and con-
nection of that component with the orchestrator. For a security tool with multiple capa-
bilities, for instance, Splunk and Limacharlie have different sets of APIs to invoke dif-
ferent capabilities, a single API or wrapper would fail to invoke different capabilities.
For example, for LimaCharlie with static API based integration, we have designed two
sets of scripts to kill a process and isolate a process. For seven security tools with 24
capabilities at least 48 connections are required among the orchestrator and security
tools while considering API and wrapper-based integration for taking the output and
provide the commands to execute an activity. An increase in the connections and com-
ponents increases the design space of a SOAR. With the inclusion of new security tools,
a new connection emerges and a user would require to go through the existing APIs,
wrapper and connection to integrate a security tool in a playbook to execute an IRP. An
update in the existing security tool features, for example, addition of new capabilities
or change in the existing API parameters also requires designing the connections and
updating the playbook where the security tools have been used.
With the semantic-based integration approach, we only need to update security tools
details in an ontology. The connections between the ontology and other components
have already been designed and that do not require any changes. Thus, with the PoC,
the number of components and connections remain constant with the integration of new
security tools – that is MISP. Without considering the proposed architecture approach
the number of components increased at least by 2 upon the integration of new security
tools. We found that semantic-based integration is more suitable in this case. This
demonstrates that the proposed architecture-based implementation keeps the compo-
nents and connections lower by reusing the existing components.
Our observation from running the experiment reveals that building wrapper and APIs
require more time than updating the security tool details in an ontology. Hence, ontol-
ogy-based automated integration process free SOC’s time.
6.2 Automating the Interpretation of the Activities to Execute an IRP
We assume a user has expressed his/her goal to identify and isolate suspicious end-
points. Using the current implementation, the orchestrator can identify the capabilities
required to execute the activities and then select the security tools that can execute that
capability. As the process for automatically identifying the capabilities required to ex-
ecute an activity and selecting the security tools are already defined, a user would not
require to manually identify the security tools. He/she just needs to request the orches-
trator for security tools that can perform the required activities. The orchestrator runs
the process and returns the available security tools. Then the user can also define which
security tools would be used for each activity. Next, the orchestrator automatically gen-
erates the commands to invoke the security tools to execute a sequence of activities. In
this whole process, the current architectural based implementation has reused the exist-
ing process, components and protocols.
With the non-modular and monolithic implementation of a SOAR platform, a play-
book is required to design to fulfill a user’s goal. Developing a playbook would require
an understanding of a playbook’s structure, knowledge of the available security tools,
developing scripts to access the generated data of the security tools and their specific
APIs to execute an activity. In the monolithic approach, each playbook is designed for
a specific IRP which cannot be reused even if the new IRP is a subset of the existing
IRPs. A user requires to modify the existing playbook to execute the new IRP.
Modularizing a SOAR’s architecture provides a clear understanding of which part
would require an update and which components can be reused without modification.
Reusing the existing components provides the following benefits: a SOC spends less
time in adapting the changes and the evolution of a system does not increase the com-
plexity of architecture. Further, it has reduced the overhead for users in adopting the
changes by providing the processes that can be reused. The evaluation shows that with-
out separating the concerns, the number of changes would require more than our pro-
posed architectural based implementation.
The PoC has accurately executed 45 IRPs among the new 48 IRPs. For three of the
IRPs, the orchestrator could not find any security tools with the required capabilities to
execute some of the activities, thus those were executed partially. The successful
execution of the 45 IRPs demonstrates that the developed PoC has accurately inter-
preted the data generated by the used security tools without user intervention. The se-
curity tool MISP is also used by some of the new IRPs; thus, it has also been success-
fully integrated. From the evaluation, we also observe that that incorporating the
changes in the PoC is easier compared to other approaches.
This paper has demonstrated the feasibility of the proposed architecture for security
tool integration and IRP interpretation based on three quality attributes - integrability,
interpretability and interoperability. Other quality attributes of a SOAR can be evalu-
ated by following different architectural evaluation techniques such as Scenario based
Architecture Analysis Method (SAAM) and Architecture Tradeoff Analysis Method
(ATAM) [8, 17].
7 Related Work
The leading security service providers aim to provide SOAR platforms to deliver end
to end security services [10, 11, 18, 19]. For example, FireEye (i.e., a leading cyberse-
curity company) designs a SOAR platform to integrate its endpoint products and offer
supports to its industry partners . Whilst the start-ups mainly focus on developing
APIs to integrate different third-party solutions and provide playbooks for automated
and semi-automate IRPs . The ad-hoc implementations of a SOAR platform in-
crease the design complexity of such a platform as these platforms are built as a whole
without separating the concerns of the deployed components. Further, a SOAR is a
large-scale system that integrates an organization's information and security systems.
Organizations are facing several challenges in managing these solutions while any
changes occur in the underlying operating environment such as integrating new security
tools and defining new IRPs [2, 13]. Our work addresses these kinds of challenges.
The current state-of-the-practices and state-of-the-arts of SOARs lack a shared un-
derstanding between the vendors and stakeholders of SOAR [1, 3, 4, 21, 22]. For ex-
ample, there is no shared understanding of the key software components and technolo-
gies that are necessary to integrate and enable interoperability among various security
tools and bring automation in IRPs execution. In these studies, a SOAR platform has
mainly focused on security tools interactions, isolated processes and low-level infra-
structures, while paying less attention to the problems of how different components of
a SOAR and security tools coordinate.
A security team requires an understanding of the internal structure of a SOAR (i.e.,
libraries to integrate new security tools or requirements) to adopt the changes in a
SOAR platforms execution environment. Adopting the changes remains a tedious and
difficult undertaking for end-users. State-of-the-art approaches for security process
modeling provide limited or no decomposition mechanisms, which easily results in
monolithic processes that address multiple concerns in a single model [1, 3, 4, 22].
None of the existing works provides the architectural design space that could inform
architects of the decisions to be made where multiple components are interconnected.
Software architecture is composed of early design decisions, which can help to address
some of the existing challenges to be addressed by SOAR platform designers [6-8]. An
increased focus on architectural aspects of SOAR can also facilitate further research on
the design decisions of the exiting SOAR platforms to form guidelines, rules and design
techniques. The rise of security incidents has increased the demand for knowledge, pro-
cesses and techniques for designing and deploying highly configurable and scalable
SOAR platforms. As most organization prefer to utilize their available software and
security tools, it would be helpful to consider architectural design decisions for trade-
off analysis before deploying a SOAR platform to enhance a SOC’ efficiency.
Exploring and understanding the architectural design decision before designing and im-
plementing a SOAR platform is a valuable task. The captured design decision would
help developers as well as a SOC staff of an organization to systemize their decision
process and trade-off analysis. The architectural design decisions would serve as a
standalone lexicon to describe and evaluate the existing and new SOAR platform. In
this paper, we have designed a conceptual diagram of SOAR platform to support an
architect's understanding of the design space of SOAR. We have further identified the
requirement of a SOAR in terms of unification, orchestration and automation and pro-
posed a layered architecture to modularize the functions and separate the concerns of
the components of a SOAR platform. The architecture design decisions are chosen from
the process and technology perspectives. We have used the proposed approach to de-
sign and implement a PoC SOAR platform for an ad-hoc SOC infrastructure and ob-
serve its impact on the automated integration and interpretation process. We have lev-
eraged well-known architectural styles and patterns to implement the PoC. We have
observed that the consideration of the principal dimension of the architecture design
space has improved SOAR design practices.
The proposed approach has further laid a foundation for future research on the design
space and deployment automation of SOAR platforms. In our future work, we plan to
conduct a large-scale mapping of the existing SOAR platform and IRPs onto the archi-
tecture design decisions to generate patterns and hide interaction among the different
components across multiple technology paradigm.
This work is partially supported by CSIRO’s data61, Australia. We acknowledge the contribution
of Faheem Ullah, Aufeef Chauhan and Triet Mihn Le for their feedbacks in improving the work.
 E. Feitosa, E. Souto, and D. H. Sadok, An orchestration approach for unwanted Internet traffic
identification, Computer Networks, Article vol. 56, no. 12, pp. 2805-2831, 2012.
 C. Islam, M. A. Babar, and S. Nepal, A Multi-Vocal Review of Security Orchestration, ACM
Computing Surveys (CSUR), vol. 52, no. 2, p. 37, April 2019.
 S. Luo and M. B. Salem, "Orchestration of software -defined security services," in 2016 IEEE
International Conference on Communications Workshops, (ICC '16) , Kuala Lumpur, Malaysia, 2016.
 H. Nadkarni, Security orchestration framework, US Patent 9,807,118, 2017.
 T. H. Koyama, Kunio; Kitazume, Hideo; Nagafuchi, Mit suhiro. (2015) Security Orchestration with a
Global Threat Intelligence Platform. NTT Technical Review.
 M. A. Chauhan, M. A. Babar, and Q. Z. Sheng, A Reference Architecture for provisioning of Tools as
a Service: Meta-model, Ontologies and Design Elements, Future Generation Computer Systems, vol.
69, pp. 41-65, April 2017.
 A. Jansen and J. Bosch, "Software Architecture as a Set of Architectural Design Decisions," in
Proceedings of the 5th Working IEEE/IFIP Conference on Software Architecture, USA, 2005.
 L. Bass, P. Clements, and R. Kazman, Software architecture in practice. Addison-Wesley
 R. Haesevoets, D. Weyns, and T. Holvoet, Architecture-centric support for adaptive service
collaborations, ACM Trans. Softw. Eng. Methodol., vol. 23, no. 1, pp. 1-40, 2014.
 FireEye. (November 20, 2017). Security Orchestration In Action: Integrate – Automate –Manage
[Online]. Available: https://www2.fireeye.com/Webinar-FSO-
 IBM. (November 1, 2019). Orchestrate Incident Response [Online]. Available:
 J. Andersson and P. Johnson, "Architectural integration styles for large-scale enterprise software
systems," in Proceedings Fifth IEEE International Enterprise Distributed Object Computing
Conference, Seattle, WA, USA, 2001, pp. 224-236.
 C. Islam, M. A. Ba bar, and S. Nepal, "Automated Interpretation and Integration of Security Tools
Using Semantic Knowledge," in Advanced Information Systems Engineering (CAiSE '19), Rome, Italy,
 C. Islam. (2020). Proof of Concept SOAR [Online]. Available: https://github.com/Chadni -
 Demisto. (Ja nuary 21, 2020). Demisto Platform Content Repository [Online]. Available:
 C. Islam, M. A. Babar, and S. Nepal, "An Ontology -Driven Approach to Automate the Process of
Integration Security Software Systems," in IEEE/ACM International Conference on Software and
System Processes (ICSSP '19), Montreal, Canada, 25-26 June, 2019.
 M. A. Babar, L. Zhu, and R. Jeffery, "A framework for classifying and comparing software architecture
evaluation methods," in 2004 Australian Software Engineering Conference. Proceedings., 2004, pp.
 Siemplify. (December 5, 2019). What is security orchestration and automation [Online]. Available:
 Swimlane. (November 20, 2017). Security Automation and Orchestration [Online]. Available:
 Demisto. (December 5, 2017). Security orchestration and automation [Online]. Available:
 E. Digiambattista, Enterprise level security orchestration, US Patent 2017/0017795 A1, 2017.
 R. Poornachandran, S. Shahidzadeh, S. Das, V. J. Zimmer, S. Vashisth, and P. Sharma, Premises -
aware security and policy orchestration, US Patent 14/560,141, 2016.