Conference PaperPDF Available

Architecture-centric Support for Integrating Security Tools in a Security Orchestration Platform

Authors:

Abstract and Figures

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.
Content may be subject to copyright.
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
{chadni.islam, ali.babar}@adelaide.edu.au
2 CSIRO’s Data61, NSW, Australia
{chadni.islam, surya.nepal}@data61.csiro.au
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.
1 Introduction
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 [2].
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 [2]. 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
2
requirements. The architectural design decision provides a foundation for analyzing and
understanding the sub-optimal design choices [7], 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 [2]. Developing design spaces
for different domains of software systems is a growing trend [7]. 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 [2].
3
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 [2]. 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 [12]. 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
4
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.
5
Incident Response Plan
Playbook
Designer
SOAR
Developer
Detection
Analysis
Response
implements
requires
provides
integrates Activity
Security Tool
Task
executes
executes
Unification
Orchestration
Automation
Playbook
Orchestration Process
runs and
manages
supports
Organization
SOAR Platform
Capability
Legend ABAB
Composition Generalization AB
relation
uses
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)
6
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).
Semantic Layer
Integration
Layer
Orchestration
Layer
Data Processing
Layer
Tool Registry
Interpreter
Data Extractor
PlannerOrchestratorTask Manager
Query Engine
Plugin Repositories
UI Layer
Abstraction Layer
API Gateway
Wrapper
Security Tool Layer
Knowledge Base
Data Analyzer
Security Tool Security Tool Security Tool Security Tool
Users
Integration Manager
Data Curator
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
7
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 [13]. 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.
8
:Security Tool :APIs/plugins :Data Analyzer :Interpreter :Orchestrator
Generate Dat a Send Data Collected Dat a
Interprete d Data
Find Capabilit y
Capability
Invoke Too l
Interprete d Tool
Generate Command
Send Com mand
Invoke Too l
Find Tool
Tool
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 [2]. 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
9
are required for integrating security tools, designing the orchestration process and pow-
ering automation. A SOAR’s taxonomy has six automation strategies [2]. 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 [12].
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 [8].
Table 1. Summary of architectural design decision
Design Decisions
Ontology for formalizing security
tools and activities of IRPs
Use of ontology for semantic inte-
gration and information discovery
Layered architectural style
Abstraction of SOAR’s components
task with a set of APIs
Automated integration and interpre-
tation process
Share ontology template in a central-
ized repository pattern
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 [14]. 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
10
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.
MISP API
LimaCharlie API
Splunk API MISP API
LimaCharlie API
Splunk API
Input
Output
Wrapper
Wrapper
Wrapper
Wrapper
Ontology
Collector
Process Orchestration
Collected data
Integration
Security Tools
Send data (alert, log, report, packet)
Interpreted
data
invoke process
Invoke tools
MISP Splunk
LimaCharlie
Snort
Wireshark
WinPcap
WinDefender
command
Data Analyzer
SPARQL query engine
IRP Orchestrator
Interpreter
Output Handler Input Constructor
Fig. 4. Implementation architecture of the PoC for security tool integration
We selected seven open-source tools
1
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 [15]. 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 [14].
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 tools 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 [13]. 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
1
https://www.snort.org, https://www.splunk.com/, https://www.limacharlie.io/, misp-project.org
11
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
security tool
Security
Tool class
has Capability
Capability class
executeActivity
snort_s
IDS
intrusion_detection_s
IntrusionDetection
detectIncident
limaCharlie_l
EDR
intrusion_detection_l
process_killing_l
IntrusionDetection
ProcessKilling
detectIncident
killProcess
splunk_s
SIEM
log_collection_s
alert_analysis_a
LogCollection
AlertAnalysis
collectAlertLog
investigateAlert
Table 3. Illustration of a selected set of data properties of security tool class of an ontology
security tool
Security
Tool class
isIntegrated
hasInputType
hasRule
hasConfigFile
snort_s
IDS
True
network traffic
False
snorts.config
limaCharlie_l
EDR
True
payloads
True
inputs.conf
splunk_s
SIEM
True
logs
True
LCConf
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
[16]. 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.
6 Evaluation
In this section, we report how the PoC has been evaluated to demonstrate the feasibility
of the proposed architecture approach based on two scenarios.
12
Interpreter
SplunkCollector
-String: dir
+run()
....
OutputHandler
-log: DataElemen t
+run()
...
Directory
Splunk
<<Interface>>
InputConstructor
+formulateCommand(S tring)
Output to directory
LimacharlieInpu tConstructor
+deleteFile(String , String)
+killProcess(Strin g, String)
.....
+interpret(DataElem ent)
ArrayList<HasMap>
Querier
+getToolCaps(S tring)
+getReqCaps(String)
Ontology
<<Interface>>
Collector
+getData(DataEl ement)
.....
LimaCharlie
Orchestrator
+execute()
+getProcess(String)
IRP
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.
13
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
14
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 [10]. Whilst the start-ups mainly focus on developing
APIs to integrate different third-party solutions and provide playbooks for automated
and semi-automate IRPs [20]. 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
15
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.
8 Conclusion
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.
Acknowledgement
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.
References
[1] 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.
[2] 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.
16
[3] 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.
[4] H. Nadkarni, Security orchestration framework, US Patent 9,807,118, 2017.
[5] T. H. Koyama, Kunio; Kitazume, Hideo; Nagafuchi, Mit suhiro. (2015) Security Orchestration with a
Global Threat Intelligence Platform. NTT Technical Review.
[6] 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.
[7] 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.
[8] L. Bass, P. Clements, and R. Kazman, Software architecture in practice. Addison-Wesley
Professional, 2003.
[9] 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.
[10] FireEye. (November 20, 2017). Security Orchestration In Action: Integrate Automate Manage
[Online]. Available: https://www2.fireeye.com/Webinar-FSO-
EMEA.html?utm_source=fireeye&utm_medium=webinar -page.
[11] IBM. (November 1, 2019). Orchestrate Incident Response [Online]. Available:
https://www.ibm.com/security/solutions/orchestrate-incident-response.
[12] 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.
[13] 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,
2019.
[14] C. Islam. (2020). Proof of Concept SOAR [Online]. Available: https://github.com/Chadni -
Islam/Security-Orchestration-PoC.
[15] Demisto. (Ja nuary 21, 2020). Demisto Platform Content Repository [Online]. Available:
https://github.com/demisto/content.
[16] 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.
[17] 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.
309-318.
[18] Siemplify. (December 5, 2019). What is security orchestration and automation [Online]. Available:
https://www.siemplify.co/resources/what-is-security-orchestration-automation/.
[19] Swimlane. (November 20, 2017). Security Automation and Orchestration [Online]. Available:
https://swimlane.com/use-cases/security-orchestration-for-automated-defense/.
[20] Demisto. (December 5, 2017). Security orchestration and automation [Online]. Available:
https://www.demisto.com/wp-content/uploads/2017/04/MH-Demisto-Security-Automation-WP.pdf
[21] E. Digiambattista, Enterprise level security orchestration, US Patent 2017/0017795 A1, 2017.
[22] 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.
... For instance, AI/ML approaches are not only used for detecting software vulnerabilities [103] and cyber-attacks [184], but also employed in developing sophisticated cyber-attack mechanisms [123]. Similarly, AI/ML algorithms are used for detecting data exiltration and automating response process to cyber incidents [82,148,168]. However, we ind little evidence (only 3 papers) in support of using AI/ML for enhancing the cybersecurity of C3I systems. ...
Full-text available
Article
Command, Control, Communication, and Intelligence (C3I) systems are increasingly used in critical civil and military domains for achieving information superiority, operational efficacy, and greater situational awareness. The critical civil and military domains include, but are not limited to battlefield, healthcare, transportation, and rescue missions. Given the sensitive nature and modernization of tactical domains, the security of C3I systems has recently become a critical concern. This is because cyber-attacks on C3I systems have catastrophic consequences including loss of human lives. Despite the increasing number of cyber-attacks on C3I systems and growing concerns about C3I systems’ security, there is a paucity of a comprehensive review to systematize the body of knowledge on the security of C3I systems. Therefore, in this paper, we have gathered, analyzed, and synthesized the body of knowledge on the security of C3I systems. We have identified and reported security vulnerabilities, attack vectors, and countermeasures/defenses for C3I systems. In particular, this paper has enabled us to (i) propose a taxonomy for security vulnerabilities, attack vectors, and countermeasures; (ii) interrelate attack vectors with security vulnerabilities and countermeasures; and (iii) propose future research directions for advancing the state-of-the-art on the security of C3I systems. We believe that our findings will serve as a guideline for practitioners and researchers to advance the state-of-the-practice and state-of-the-art on the security of C3I systems.
... Finally, the paper is concluded in Section 8. [75] and ThreatConnect [17] provide SOAR platforms, which leverage APIs for easy integration of tools but they do not provide any support to security teams for finding relevant APIs from diverse security tools. Islam et al. [29] propose architectural support for integrating security tools, requiring manual API learning from documentation. Though the existing works have focused on automation and orchestration of security tool integration and their activities, these studies lack providing suitable support for automatically extracting APIs of security tools. ...
Full-text available
Preprint
Security Orchestration, Automation, and Response (SOAR) platforms integrate and orchestrate a wide variety of security tools to accelerate the operational activities of Security Operation Center (SOC). Integration of security tools in a SOAR platform is mostly done manually using APIs, plugins, and scripts. SOC teams need to navigate through API calls of different security tools to find a suitable API to define or update an incident response action. Analyzing various types of API documentation with diverse API format and presentation structure involves significant challenges such as data availability, data heterogeneity, and semantic variation for automatic identification of security tool APIs specific to a particular task. Given these challenges can have negative impact on SOC team's ability to handle security incident effectively and efficiently, we consider it important to devise suitable automated support solutions to address these challenges. We propose a novel learning-based framework for automated security tool API Recommendation for security Orchestration, automation, and response, APIRO. To mitigate data availability constraint, APIRO enriches security tool API description by applying a wide variety of data augmentation techniques. To learn data heterogeneity of the security tools and semantic variation in API descriptions, APIRO consists of an API-specific word embedding model and a Convolutional Neural Network (CNN) model that are used for prediction of top 3 relevant APIs for a task. We experimentally demonstrate the effectiveness of APIRO in recommending APIs for different tasks using 3 security tools and 36 augmentation techniques. Our experimental results demonstrate the feasibility of APIRO for achieving 91.9% Top-1 Accuracy.
... We have taken in consideration the cloud security challenges as a well-researched topic to learn a knowledge integration problem in the security field [40,41] using the best findings of the semantic approach [42]. ...
Full-text available
Article
This work considers challenges, related to the lack of methods of automatic threat modeling and well-formed data sources of threats and countermeasures as well as techniques to collect such security knowledge. Cloud computing domain has been in a focus of security scientists and experts for decade, however it is still a problem to make secure the use of cloud systems and their applications, because of distributed nature, variety of deployment models, and different stakeholders. Towards automation of the threat modeling process we have proposed an ontological approach both to analysis of a system design (by an ontology-driven threat modeling framework) and creation of security patterns (by an ontological schema of security pattern). This work briefly describes those efforts and concentrated on an ontological catalog of cloud system threats. The work offers an Academic Cloud Computing Threat Patters (ACCTP) catalog as a way of the threat modeling of cloud systems and a set of design primitives as means of learning cloud security challenges.
Article
Standardization of the security operations dashboard is essential for efficient operation of security operations center. It must be able to comprehensively express the business activities of the security operations center. It should be possible to easily explain all business activities of the security operations center. In this paper, a security operations dashboard design based on Blockade-Detection-Response (BDR) is proposed. The BDR based security operations dashboard design is intended to reduce the effort and time required for configuring a dashboard for VIPs, and contribute to the systematic security operations from the perspective of blockade, detection and response for everlasting cyber threats.
Full-text available
Conference Paper
A wide variety of security software systems need to be integrated into a Security Orchestration Platform (SecOrP) to streamline the processes of defending against and responding to cybersecurity attacks. Lack of interpretability and interoperability among security systems are considered the key challenges to fully leverage the potential of the collective capabilities of different security systems. The processes of integrating security systems are repetitive, time-consuming and error-prone; these processes are carried out manually by human experts or using ad-hoc methods. To help automate security systems integration processes, we propose an On tology-driven approach for S ecurity OrchestrAtion Platform (OnSOAP). The developed solution enables interpretability, and interoperability among security systems, which may exist in operational silos. We demonstrate OnSOAP's support for automated integration of security systems to execute the incident response process with three security systems (Splunk, Limacharlie, and Snort) for a Distributed Denial of Service (DDoS) attack. The evaluation results show that OnSOAP enables SecOrP to interpret the input and output of different security systems, produce error-free integration details, and make security systems interoperable with each other to automate and accelerate an incident response process.
Full-text available
Chapter
A security orchestration platform aims at integrating the activities performed by multi-vendor security tools to streamline the required incident response process. To make such a platform useful in practice in a Security Operation Center (SOC), we need to address three key challenges: interpretability, interoperability, and automation. In this paper, we proposed a novel semantic integration approach to automatically select and integrate security tools with essential capability for auto-execution of an incident response process in a security orchestration platform. The capability of security tools and the activities of the incident response process are formalized using ontologies, which have been used for NLP based approach to classify the activities for the emerging incident response processes. The developed ontologies and NLP approaches have been used for an interoperability model for selection and integration of security tools at runtime for the successful execution of an incident response process. Experimental results demonstrate the feasibility of the classifier and interoperability model for achieving interpretability, interoperability, and automation of security tools integrated into a security orchestration platform.
Full-text available
Article
Organizations use diverse types of security solutions to prevent cyber-attacks. Multiple vendors provide security solutions developed using heterogeneous technologies and paradigms. Hence, it is a challenging rather impossible to easily make security solutions to work an integrated fashion. Security orchestration aims at smoothly integrating multivendor security tools that can effectively and efficiently interoperate to support security staff of a Security Operation Centre (SOC). Given the increasing role and importance of security orchestration, there has been an increasing amount of literature on different aspects of security orchestration solutions. However, there has been no effort to systematically review and analyze the reported solutions. We report a Multivocal Literature Review that has systematically selected and reviewed both academic and grey (blogs, web pages, white papers) literature on different aspects of security orchestration published from January 2007 until July 2017. The review has enabled us to provide a working definition of security orchestration and classify the main functionalities of security orchestration into three main areas—unification, orchestration, and automation. We have also identified the core components of a security orchestration platform and categorized the drivers of security orchestration based on technical and socio-technical aspects. We also provide a taxonomy of security orchestration based on the execution environment, automation strategy, deployment type, mode of task and resource type. This review has helped us to reveal several areas of further research and development in security orchestration.
Full-text available
Article
Software Architecture (SA) plays a critical role in designing, developing and evolving cloud-based platforms that can be used to provision different types of services to consumers on demand. In this paper, we present a Reference Architecture (RA) for designing cloud-based Tools as a service SPACE (TSPACE) for provisioning a bundled suite of tools by following the Software as a Service (SaaS) model. The reference architecture has been designed by leveraging information structuring approaches and by using well-known architecture design principles and patterns. The RA has been documented using view-based approach and has been presented in terms of its context, goals, the RA meta-model, information structuring and relationship models using ontologies and components of the RA. We have demonstrated the feasibility and applicability of the RA with the help of a prototype and have used the prototype to provision tools for software architecting. We have also evaluated the RA in terms of effectiveness of the design decisions and the RA’s completeness and feasibility using scenario-based architecture evaluation method. The proposed TSPACE RA can provide valuable insights to information structure approaches and guidelines for designing and implementing TSPACE for various domains.
Full-text available
Article
In today's volatile business environments, collaboration between information systems, both within and across company borders, has become essential to success. An efficient supply chain, for example, requires the collaboration of distributed and heterogeneous systems of multiple companies. Developing such collaborative applications and building the supporting information systems poses several engineering challenges. A key challenge is to manage the ever-growing design complexity. In this article, we argue that software architecture should play a more prominent role in the development of collaborative applications. This can help to better manage design complexity by modularizing collaborations and separating concerns. State-of-the-art solutions, however, often lack proper abstractions for modeling collaborations at architectural level or do not reify these abstractions at detailed design and implementation level. Developers, on the other hand, rely on middleware, business process management, and Web services, techniques that mainly focus on low-level infrastructure. To address the problem of managing the design complexity of collaborative applications, we present Macodo. Macodo consists of three complementary parts: (1) a set of abstractions for modeling adaptive collaborations, (2) a set of architectural views, the main contribution of this article, that reify these abstractions at architectural level, and (3) a proof-of-concept middleware infrastructure that supports the architectural abstractions at design and implementation level. We evaluate the architectural views in a controlled experiment. Results show that the use of Macodo can reduce fault density and design complexity, and improve reuse and productivity. The main contributions of this article are illustrated in a supply chain management case.
Full-text available
Conference Paper
Software architectures have high costs for change, are complex, and erode during evolution. We believe these problems are partially due to knowledge vaporization. Currently, almost all the knowledge and information about the design decisions the architecture is based on are implicitly embedded in the architecture, but lack a first-class representation. Consequently, knowledge about these design decisions disappears into the architecture, which leads to the aforementioned problems. In this paper, a new perspective on software architecture is presented, which views software architecture as a composition of a set of explicit design decisions. This perspective makes architectural design decisions an explicit part of a software architecture. Consequently, knowledge vaporization is reduced, thereby alleviating some of the fundamental problems of software architecture.
Full-text available
Conference Paper
A predominant problem in the management of large-scale enterprise software systems is application integration. Despite the considerable efforts spent on the development of new standards and technologies for software interoperation, the integration of systems that originally were not designed to interact with each other is a major undertaking, requiring in-depth knowledge of existing systems, incorporation of integration products, and development and/or parameterization of various kinds of adapters and gateways. The article presents the concept of architectural integration styles, i.e. architectural styles describing software structures of integration solutions for enterprise software systems. The article further proposes an approach for selection of styles based on the characteristics of the existing software applications and the desired quality attributes of the integrated system. A number of architectural integration styles for enterprise systems are presented, and a case study of the style selection process applied to a mid-sized Swedish electricity retailer is described
Article
a b s t r a c t A simple examination of Internet traffic shows a wide mix of relevant and unwanted traffic. The latter is becoming increasingly harmful to network performance and service availabil-ity, while often consuming precious network and processing resources. Coordinated attacks, such as distributed denial-of-services (DDoS), large-scale scans, and worm out-breaks, occur in multiple networks simultaneously and become extremely difficult to detect using an individual detection engine. This paper presents the specification of a new orchestration-based approach to detect, and, as far as possible, to limit the actions of these coordinated attacks. Core to the proposal is a framework that coordinates the receiving of a multitude of alerts and events from detectors, evaluates this input to detect or prove the existence of anomalies, and consequently chooses the best action course. This framework is named Orchestration-oriented Anomaly Detection System (OADS). We also describe an OADS prototype implementation of the proposed infrastructure and analyze initial results obtained through experimentation with this prototype.