OSCIDS: An Ontology based SCADA Intrusion Detection Framework

Abdullah Al Balushi, Kieran McLaughlin and Sakir Sezer

Centre for Secure Information Technologies,

Queens University Belfast, Belfast BT3 9DT, U. K.

Keywords:

Semantic Web, Intrusion Detection, Knowledge Engineering, SCADA, Modbus TCP, Security Ontology.

Abstract:

This paper presents the design, development, and validation of an ontology based SCADA intrusion detection

system. The proposed system analyses SCADA network communications and can derive additional infor-

mation based on the background knowledge and ontology models to enhance the intrusion detection data.

The developed intrusion model captures network communications, cyber attacks and the context within the

SCADA domain. Moreover, a set of semantic rules were constructed to detect various attacks and extract log-

ical relationships among these attacks. The presented framework was extensively evaluated and a comparison

to the state of the art is provided.

1 INTRODUCTION

Supervisory Control and Data Acquisition (SCADA)

systems are used to monitor and control various crit-

ical infrastructures such as electrical generation and

distribution, petroleum plants, or nuclear plants. In

the past, SCADA networks operated in closed en-

vironments using legacy communication protocols.

However, modern networks are moving towards the

use of open standards and general information and

communications technology (ICT) to enhance their

systems interoperability, reduce cost, and enhance op-

erational management. For instance, the Modbus se-

rial communication protocol developed by Modicon

in 1979 is now being encapsulated into TCP/IP frames

in the newer version of Modbus TCP/IP, also referred

as Modbus TCP (Modbus, 2012).

Nevertheless, the incorporation of such open tech-

nologies in SCADA networks exposed them to a wide

range of vulnerabilities and cyber-attacks such as re-

connaissance, command injection, denial of service,

and response and measurement injection. As a re-

sult, the number of cyber incidents is signiﬁcantly

increasing (Kang et al., 2014) which presents novel

challenges for both academic researchers and indus-

try experts.

In order to provide an adequate level of protec-

tion to SCADA networks, various types of SCADA-

speciﬁc intrusion detection systems (IDSs) have been

proposed (Zhu and Sastry, 2010). However, the cur-

rent generation of IDS systems in SCADA networks

are often faced with several challenges. First, the ma-

jority of the existing systems, especially signature-

based, are purely syntactic and lack a clear description

of intrusion behaviours and semantics of the moni-

tored systems (Barry and Chan, 2009). This issue

may result in missing the detection of sophisticated

attacks (Had

ziosmanovi

c et al., 2014) such as Stuxnet

(Langner, 2011) that may exploit legitimate looking

commands to cause damage on the system. Second,

intelligent capabilities such as reasoning over exist-

ing domain knowledge, which can assist in identify-

ing the logical relationships between various attacks

are missed by these IDS systems. This issue can result

in the need for intensive expertise and efforts to man-

ually analyse the connection between these attacks.

To address the above limitations, this paper

presents an ontology-based intrusion detection system

called OSCIDS (Ontology-based SCADA Intrusion

Detection System). OSCIDS is a knowledge-based

system that utilises ontology to extract semantic rela-

tions among attacks and detect intrusions. The devel-

oped ontology enables representing the main concepts

and semantic relations of network communications,

cyber-attacks, and inferring additional useful knowl-

edge from the existing background knowledge. The

main contributions of this paper are:

• A novel approach for intrusion detection in

SCADA networks using ontologies has been pro-

posed. In contrast to current signature-based tech-

niques, the proposed framework utilises the se-

mantic deﬁnitions of industrial network packets

Balushi, A., McLaughlin, K. and Sezer, S.

OSCIDS: An Ontology based SCADA Intrusion Detection Framework.

DOI: 10.5220/0005969803270335

In Proceedings of the 13th International Joint Conference on e-Business and Telecommunications (ICETE 2016) - Volume 4: SECRYPT, pages 327-335

ISBN: 978-989-758-196-0

327

and logical relationships between attacks to en-

hance the intrusion detection process.

• Formal semantic modelling of SCADA cyber in-

trusions and speciﬁcation of Modbus TCP/IP in-

dustrial communications is presented. The con-

structed model provides an expressive representa-

tion of possible intrusions and enables new intru-

sion analysis capabilities such as the use of rea-

soning over existing knowledge and deriving ad-

ditional information from the raw packets.

• A set of semantic rules for background knowl-

edge inferences and intrusion detection has been

developed. These rules can utilise both raw packet

features and the derived features by the reasoning

process to detect various attacks or ﬁnd their log-

ical relationship.

• The proposed framework prototype is developed

using open-source technologies. This enables sys-

tem extensibility and ﬂexibility. Moreover, an

evaluation of the proposed framework is provided

with a comparison to the state-of-the-art IDS so-

lution.

This paper is organised as follows. Section 2

presents the background and related works. Section

3 discusses the development and the architecture of

proposed OSCIDS framework. Section 4 presents the

experimental results, while Section 5 concludes the

paper.

2 BACKGROUND AND RELATED

WORK

2.1 Modbus TCP/IP Communications

Overview

Modbus is a serial communications protocol devel-

oped by Modicon (now Schneider Electric) in 1979

for use in industrial networks. Modbus TCP, on the

other hand, refers to the encapsulated Modbus com-

munications into TCP/IP frames. The Modbus TCP

has a simple request/response architecture. A Modbus

client (Master) sends a packet to the Modbus server

requesting a speciﬁc command to be executed or to re-

turn some data. Various commands can be requested

which may include reading process measurements,

writing conﬁgurations, performing diagnostics oper-

ations, or executing a process control operation. The

server processes the received command and in many

cases returns a response indicating the status of com-

mand execution or describing any errors which oc-

curred.

Modbus TCP packet contains several features at

both network and application layers. The main fea-

tures of Modbus TCP packets are illustrated in Figure

1. These features include the TCP/IP headers and the

Modbus Application Layer (known as Modbus Appli-

cation Data Unit(ADU)) features.

Transaction ID

(2 bytes)

Protocol ID

(2 bytes)

Length

(2 bytes)

Unit ID

(1 byte)

Function Code

(1 byte)

Data

(252 bytes)

Modbus ADU (Application Data Unit)TCP headerIP headerEthernet frame

MBAP header (7 bytes) PDU (253 bytes)

TCP data

| |

Figure 1: Modbus TCP packet structure.

2.2 SCADA-speciﬁc Intrusion Detection

Systems

In the literature, there exist a number of IDS proposals

that are speciﬁcally addressing the intrusion detection

problem in SCADA networks (Zhu and Sastry, 2010).

We will present some of the recent IDS proposals with

reference to Modbus communications.

Snort (Roesch et al., 1999) is an open source

signature-based intrusion detection system used in

many networks. Digital Bond Inc.(Peterson, 2009)

has developed a Modbus pre-processor and a set of

14 attack signature rules that captures various attacks.

These attacks are mainly reconnaissance, denial of

service, and unauthorised access commands. (Mor-

ris et al., 2013) presented a set of 50 Snort rules for

attack detection on Modbus communications over se-

rial lines and TCP/IP.

Other approaches that rely on anomaly detection

techniques have been proposed. (Mallouhi et al.,

2011) proposed an anomaly-based IDS for industrial

protocols including Modbus TCP/IP. Their system

consists of a Modbus and TCP analysers that use the

n-gram algorithm for intrusion detection. This system

was developed to detect several attacks such as spoof-

ing, TCP SYN ﬂood, Modbus-speciﬁc attacks, De-

nial of service, and Man in the middle attacks. Nev-

ertheless, the authors provided only preliminary re-

sults. (Carcano et al., 2011) proposed an intrusion de-

tection system for Modbus protocol in power plants.

Their approach is based on the concept of Critical

State Analysis and State Proximity. (Sayegh et al.,

2014) presented an anomaly-based intrusion detection

system developed for SCADA networks. In their ap-

proach, time correlation between different packets is

extracted to identify malicious events.

Besides the above IDS techniques, an emerging

research area for the utilisation of Artiﬁcial Intelli-

gence (AI) techniques such as ontology knowledge

SECRYPT 2016 - International Conference on Security and Cryptography

328

representation, has been approached by researchers

and industry experts to design, implement, and en-

hance intrusion detection systems.

2.3 Ontology-based Approaches for

Intrusion Detection

An ontology formally represents the knowledge

within a speciﬁc domain through a list of concepts

and their relationship in a format that is easy to under-

stand by human and machines. It provides machines

with powerful semantic-level capabilities such as log-

ical inferences and reasoning over existing knowl-

edge. However, the use of ontology approaches for

security monitoring in SCADA domain is still in its

infancy and little work is published in this regard.

(Barnett et al., 2012) developed an ontology for

the security of Smart grids. The proposed ontology

focuses on both physical and network speciﬁc risks.

The authors also developed a graphical user interface

(GUI) that displays the results of a Failures mode

effects analysis based on the prioritisation by likeli-

hood, detectability, and severity. However, the built

ontology is simple and may not be suitable for intru-

sion detection. (Sheldon et al., 2013) proposed an on-

tology to assess root causes and impacts of cyber in-

trusions on SCADA systems. Nevertheless, the evalu-

ation results are not provided in this work. (Sartakov,

2015) proposed the use of an ontological represen-

tation of networks for intrusion detection in Cyber-

Physical systems. The proposed approach combines

both logical and physical elements of the network that

are used to build a speciﬁcation model. Nevertheless,

the proposed ontology is very general and it is not

clear whether some speciﬁc industrial protocols are

considered in the modelling or not.

The use of ontology has also appeared in several

European Framework Programmes (FP7) projects and

practical implementations, but with different objec-

tives than for intrusion detection. In SERSCRIS

project (Surridge et al., 2012), an ontology was con-

structed to describe generic system assets, threats, se-

curity controls and their relationships in critical in-

frastructure networks. However, the scope of pub-

lished work is limited to the modelling of threats and

vulnerabilities rather than using it for run-time mon-

itoring. In another project named INSPIRE (Chora

et al., 2010), a decision-aid tool for diagnostic and re-

covery is proposed using ontology. The constructed

ontology describes SCADA interdependencies, vul-

nerabilities, and threats. However, the proposed on-

tology is focused on diagnostics and may not be suit-

able for our intrusion detection objective.

Despite the recent advances in security researches

for industrial control systems (ICS), it is clear that the

use of ontology approaches for intrusion detection in

SCADA domain is limited. An ontology can provide

several advantages and enables enhanced information

analysis to the intrusion detection task. This includes

representing the knowledge in a clear structure and

with powerful semantic-level capabilities such logi-

cal inferences and reasoning over existing knowledge.

Therefore, we propose an ontology-based intrusion

detection system for use in SCADA networks.

3 ONTOLOGY-BASED SCADA

IDS (OSCIDS)

The ontology-based intrusion detection framework

presented in this paper is a knowledge-based sys-

tem. It utilises the power of semantic data deﬁnitions

to capture and represent intrusion-related knowledge

within the domain in a formal language that is un-

derstood by both humans and machines. This data

representation, backed up by the semantic deﬁnitions,

enables expressing the relationships among the hier-

archically organised concepts of the data. Therefore,

new capabilities related to the classiﬁcation and rea-

soning over the existing data are made possible. The

OSCIDS framework is prototyped in Java language

on top of the open-source Apache Jena API frame-

work (Jena, 2011). Jena provides an extensive set of

features for processing ontology such as triples stor-

age, inferences and rule engines, and querying en-

gines.

3.1 Architecture

The overall architecture of OSCIDS is presented in

Figure 2. It consists of several components that are

described as follows.

• Knowledge Base (KB): This component provides

a repository storage for all the knowledge ele-

ments used by the framework. This includes

the ontological models, processed network pack-

ets, attack instances, classes relationships, se-

mantic rules, and any other related information.

This component is implemented using JENA TDB

(Triple Store Database) which provides a persis-

tent storage on hard drives with a high perfor-

mance and the datasets are protected against ac-

cidental corruption, unexpected process termina-

tions and system crashes.

• Semantic Protocol Analyser: This component

is responsible for the processing of raw network

OSCIDS: An Ontology based SCADA Intrusion Detection Framework

329

packets and the extraction of main features includ-

ing the Modbus application-layer as per the devel-

oped ontology model. Then, it creates a packet in-

stance in the knowledge base under a proper class

such as Modbus TCP instance. This component

is developed in Java language using JNETPCAP

library with integration to Jena API functions to

allow accessing and modifying the data in the KB.

• Inference and Rule Engines: This component of

the framework enables rules evaluation on the ex-

isting knowledge (such as packet instances) and

the retrieval of information stored in the KB. Us-

ing a set of ontological statements (such as restric-

tions and truth conditions), it can automatically

derive additional information to enhance the qual-

ity of existing data. For example, new semantic

features such as the packet type, the application

layer payload type, the characteristic of the used

industrial command can be generated out of the

raw packet features.

• Classiﬁcation and Detection Module: This

module facilitates the communication interface

between all the system components and controls

the overall workﬂow. It is responsible for guiding

other components to the intrusion detection task

and taking the ﬁnal decisions when required.

Figure 2: Overall OSCIDS Framework Architecture.

3.2 Workﬂow

The main activities of the framework are illustrated in

ﬁgure 3, and the step by step operating process is as

follows:

The raw network packets are captured and fed

into the system and handled by the semantic proto-

col analyser (Step 1). The semantic protocol analyser

retrieves the network communications model (ontol-

ogy) (Step 2) and uses the encoded knowledge about

Modbus TCP/IP and other deﬁned communications

characteristics to extract the main packet features.

The resultant packet with its extracted features is con-

verted to a Resource Description Framework (RDF)

format and added to the knowledge base under a

proper class as Modbus-TCP, TCP (non-Modbus), or

UDP packet instances (Step 3). Next, the process han-

dling task is forwarded to the classiﬁcation and detec-

tion module (Step 4). This module instructs the infer-

ence and rule engine to execute various semantic rules

for reasoning and attack detection (Step 5). These

rules are loaded from text ﬁles (Step 6) and their exe-

cution results are returned back (Step 7). If the system

determined that a malicious packet has been found, an

alert is created in the KB and sent to the security ana-

lyst (Step 8).

Semantic Protocol Analyzer

Classification and

Intrusion Detection

Semantic Rules

(Text files)

Inference and Rule

Engines

Retrieve Modbus TCP

communication Ontology

Create an Instance

Request to

Apply Rules

Results

Alert

Security Analyst (GUI)

Figure 3: OSCIDS Framework Work-ﬂow.

3.3 Ontology Development

The SCADA intrusion knowledge is captured and

encoded using ontology. The constructed on-

tology deﬁnes the Modbus TCP communications,

Cyber-attacks, and the logical relationships among

packet and attack instances. This model is derived

by analysing the protocol speciﬁcations (Modbus,

2012) and attack taxonomies (Drias et al., 2015;

Had

ziosmanovi

c et al., 2014). A high-level represen-

tation of the developed ontology is depicted in Figure

The main concepts (classes) contained in this

ontology are presented in Table 1. The described

classes, which include TCP packet, Modbus TCP/IP

Packet, and Attack instance, are used to describe dif-

ferent types of data and their deﬁnition. Each of these

SECRYPT 2016 - International Conference on Security and Cryptography

330

classes may have several subclasses and properties

organised in a hierarchy. For instance, the Modbus

TCP class has several subclasses such as Request-

Message, Response-Message, and Modbus-Header.

Table 1: Main classes contained in the SCADA intrusion

ontology.

Class Description

TCP

Packet

This class represents an instance of a

network packet. This includes all TCP

packets whether it has Modbus com-

munication or not.

Modbus

Packet

This class is used to represent instances

of Modbus TCP packets and their fea-

tures.

Attack This class represents the cyber-attack

instances on SCADA systems. It has

several attack information such as im-

pact, affected systems, attack descrip-

tion, and attack vector.

Moreover, in ontology, the relationship between

classes are deﬁned using object properties, while the

data properties are used to describe the data values,

as presented in Table 2. The logical relationships de-

scribe the connection between different elements of

an attack. For example, an [Attacker] performs an

[Attack] which occurred at a speciﬁc [Time] and has

an [Impact] on the [Target]. This [Attack] uses a

[Mechanism] to exploit a [Vulnerability] utilising a

[Protocol] packet message.

Table 2: Properties contained in the SCADA intrusion on-

tology.

Domain Properties

TCP

packet

hasTime, hasTCPLength, hasSrcIP,

hasSrcPort, hasSrcMAC, hasDstIP,

hasDstPort, hasDstMAC

Modbus

packet

hasModbusTransID, hasMod-

busUnitID, hasModbusProtoID,

hasModbusLen, hasModbusFC, has-

ModbusSubFC, hasMExcepCode,

hasModbusPacketType

Network

packet

hasImpact, hasCount, isMalicious,

hasCorrelationID, hasAttackVector

3.4 Semantic Rules Generation

In this paper, a set of 15 rules were developed to vali-

date the proposed system capabilities in detecting ma-

licious Modbus communications, as shown in Listing

1. These rules cover various attacks such as denial

of service, protocol speciﬁcation violation, system in-

tegrity, and reconnaissance attacks. Some rules were

also used to derive additional knowledge from the raw

packet data that can be used by other attack detection

rules.

Listing 1: Semantic detection rules using Jena format.

[Rule01: (?p ics:hasSrcPort 502) −> (?p ics:hasPacketType ”Response

”)]

[Rule02: (?p ics:hasDstPort 502) −> (?p ics:hasPacketType ”Request”)]

[Rule03: (?p ics:hasTCPlen ?TCPLen), greaterThan(?TCPLen,300) −>

(?p ics:hasImpact ”Speciﬁcation−Violation”)(?p ics:

hasAttackVector ”Oversized packet length”)(?p ics:isMalicious ”

Yes”)]

[Rule04: (?p ics:hasProtoID ?ProtocolID), notEqual(?ProtocolID,0) −>

(?p ics:hasImpact ”Speciﬁcation−Violation”)(?p ics:

hasAttackVector ”Illegal ModbusTCP Protocol ID”)(?p ics:

isMalicious ”Yes”)]

[Rule05: (?p ics:hasModbusLen ?Len), greaterThan(?Len,254) −> (?p

ics:hasImpact ”Speciﬁcation−Violation”)(?p ics:hasAttackVector

”Oversized Modbus packet length”)(?p ics:isMalicious ”Yes”)]

[Rule06: (?p ics:hasUnitID ?UnitID), greaterThan(?UnitID,247) −> (?p

ics:hasImpact ”Speciﬁcation−Violation”)(?p ics:hasAttackVector

”Illegal Modbus Unit ID”)(?p ics:isMalicious ”Yes”)]

[Rule07: (?p ics:hasPacketType ”Request”),(?p ics:hasFunctionCode ?

FC),greaterThan(?FC,127) −> (?p ics:hasImpact ”Speciﬁcation

−Violation”)(?p ics:hasAttackVector ”Out of range Modbus

Function Code”)(?p ics:isMalicious ”Yes”)]

[Rule08: (?p ics:hasFunctionCode 8)(?p ics:hasSubFunctionCode 10)

−> (?p ics:hasImpact ”System−Integrity”)(?p ics:

hasAttackVector ”CLEAR−AUDIT−COUNTERS−DIAG−

REGISTERS”)(?p ics:isMalicious ”Yes”)]

[Rule09: (?p ics:hasFunctionCode 8)(?p ics:hasSubFunctionCode 4) −>

(?p ics:hasImpact ”Denial−of−Service”)(?p ics:hasAttackVector

”FORCE−LISTEN−ONLY−MODE”)(?p ics:isMalicious ”Yes

”)]

[Rule10: (?p ics:hasFunctionCode 8)(?p ics:hasSubFunctionCode 1) −>

(?p ics:hasImpact ”Denial−of−Service”)(?p ics:hasAttackVector

”RESTART−COMMUNICATIONS−OPTION”)(?p ics:

isMalicious ”Yes”)]

[Rule11: (?p ics:hasFunctionCode 43) −> (?p ics:hasImpact ”System−

Reconnaissance”)(?p ics:hasAttackVector ”READ−DEVICE−ID

”)(?p ics:isMalicious ”Yes”)]

[Rule12: (?p ics:hasExceptionCode 6) −> (?p ics:hasImpact ”Denial−

of−Service”)(?p ics:hasAttackVector ”SLAVE−DEVICE−

BUSY”)(?p ics:isMalicious ”Yes”)]

[Rule13: (?p ics:hasFunctionCode 17) −> (?p ics:hasImpact ”System−

Reconnaissance”)(?p ics:hasAttackVector ”REPORT−SERVER−

INFORMATION”)(?p ics:isMalicious ”Yes”)]

[Rule14: (?p ics:hasExceptionCode 5) −> (?p ics:hasImpact ”Denial−

of−Service”)(?p ics:hasAttackVector ”ACKNOWLEDGE−

EXCEPTION−CODE−DELAY”)(?p ics:isMalicious ”Yes”)]

[Rule15: (?p ics:hasDstPort 502)(?p ics:hasPayloadType ”Non−Modbus

−TCP”) −> (?p ics:hasImpact ”Speciﬁcation−Violation”)(?p ics

:hasAttackVector ”Non−Modbus Communication on TCP Port

502”)(?p ics:isMalicious ”Yes”)]

OSCIDS: An Ontology based SCADA Intrusion Detection Framework

331

Figure 4: High-level view of the proposed SCADA intrusion ontology.

4 OSCIDS FRAMEWORK

EVALUATION

In order to validate the proposed OSCIDS frame-

work, we conducted several experiments using mul-

tiple datasets. The experimental results and compar-

ison to state of the art solutions are provided in this

section. Snort IDS with the QuickDraw (Peterson,

2009) Modbus preprocessor and rule-set is used for

comparison as a state-of-the-art solution.

4.1 Experiments Setup and Datasets

The architecture of research test-bed used for the ex-

periments is illustrated in Figure 5. It contains sev-

eral components including 1) A simulated Modbus

Server using ConPot industrial honey-pot. 2) A Mod-

bus Client with a Python script that is conﬁgured to

poll Modbus measurements at a deﬁned time interval

for the generation of benign trafﬁc. 3) An attacker

machine with KALI-Linux distribution for penetra-

tion testing. 4) Snort IDS with Quick-draw. 5) The

proposed OSCIDS framework prototype.

Furthermore, two datasets of network trafﬁc cap-

tures (PCAP) were used. The ﬁrst set was ob-

tained from Digital Bond (Peterson, 2009). The sec-

ond dataset is constructed using our research test-bed

components, which includes both benign and mali-

cious trafﬁc samples.

Modbus Server

Modbus Client

Ethernet Switch

ConPot simulation

with Python scripts

OSCIDS

Attacker

KALI-Linux

Proposed IDS

Figure 5: Experimental Test-bed Architecture.

4.2 Experiment 1: Ontology-based vs.

Snort Intrusion Detection

This experiment aims at evaluating the attack detec-

tion capability of our proposed system and provid-

ing a comparison to state-of-the-art Snort IDS with

QuickDraw (Peterson, 2009). The experimental pro-

cess was developed as follows. First, the two datasets

described previously are fed into running instances of

Snort IDS (with QuickDraw) and the proposed IDS

framework. The results of each system were recorded

and used for comparison.

In this experiment, a total of 468 network pack-

ets were processed by our system. Out of these

packets, 331 Modbus-TCP packets were converted to

RDF instances with the class type of Modbus Packet,

while 137 (Non-Modbus) packets were added as TCP

SECRYPT 2016 - International Conference on Security and Cryptography

332

Packet instances.

The proposed system was successfully able to de-

rive a set of additional features to the raw packet in-

formation. These features include, but not limited

to, the packet payload type (TCP or Modbus TCP),

Modbus message type (Request/Response), function

or exception codes description. Furthermore, the

evaluation of semantic detection rules on the pack-

ets resulted in identifying malicious packet instances.

The detected attack includes System-Reconnaissance

(51.14%), Denial-of-Service (12.7%), Speciﬁcation-

Violation (0.09%), System-Integrity (0.18%), and

Miscellaneous (33%). An example Modbus packet

instance with the extended features in RDF triples for-

mat is illustrated in Listing 2.

Listing 2: A malicious Modbus packet instance in RDF for-

mat.

< r d f : D e s c r i p t i o n r d f : a b o u t = ” h t t p : / /

SCADA. ICS / OIDS / n e t w o r k t r a f f i c .OWL#

MODBUSTCPpacket22”>

Yes

2015−08−22 13 : 0 1 : 4 4

. 8 3 7 1 6 1

CLEAR−AUDIT−

COUNTERS−DIAG−REGISTERS< /

i c s : h a s A t t a c k V e c t o r>

System−I n t e g r i t y< /

i c s : h a s I m p a c t>

R equ e s t< /

i c s : h a s P a c k e t T y p e>

10

6

0

502

Modbus−TCP< /

i c s : h a s P a y l o a d T y p e>

D i a g n o s t i c s

( 0 8 )

00 : 2 0 : 7 8 : 0 0 : 6 2 : 0 D< /

ics : hasS r cMAC>

0

66

00 : 0 2 : B 3 : C E : 7 0 : 5 1< /

ics :ha sDs t MAC>

1 9 2 . 1 6 8 . 0 . 3< /

i c s : h a s D s t I P>

8< /

i c s : h a s F u n c t i o n C o d e>

2578

1 9 2 . 1 6 8 . 0 . 5 7< /

i c s : h a s S r c I P>

10< /

i c s : h a s S u b F u n c t i o n C o d e>

< / r d f : D e s c r i p t i o n>

Moreover, a brief security alert is forwarded to

the security analyst or console in standard Syslog

format (RFC 3164) as following:

<0> 2015−08−22 1 3 : 0 1 : 4 4 . 8 3 7 1 6 1 OSCIDS IDS SB−011

S u s p i c i o u s Modbus D i a g n o s t i c c od e (CLEAR−

AUDIT−COUNTERS−DIAG−REGISTERS ) h a s bee n

s u c c e s s f u l l y e x e c u t e d on a Modbus d e v i c e

1 9 2 . 1 6 8 . 1 . 1 0 2578 1 9 2 . 1 6 8 . 1 . 2 2 2 502

A comparison of the attack detection rate, false

positives, and accuracy between the proposed system

and Snort IDS is presented in Table 3. The proposed

system was also assessed on its performance. It took

the system 492.77 Milliseconds (0.49277 Second) to

process and create 468 packet instances in RDF for-

mat. While applying the 15 semantic rules for in-

ference and attack detection took 21.86 Milliseconds

(0.02186 Second).

Table 3: Comparison of attack detection rates between the

proposed OSCIDS and Snort IDS.

IDS Detection

Rate (%)

False Pos-

itive (%)

Accuracy

(%)

OSCIDS 97.80 1.09 96.70

Snort IDS 96.70 1.64 94.50

4.3 Experiment 2: Complex Attack

Detection and Correlation

In this experiment, we assess the proposed system for

its ability in correlating various packet to provide se-

curity analyst with useful insights of the network se-

curity. Many attacks against SCADA systems are a

sequence of individual attack steps. The derived fea-

tures by the reasoning engine and the developed on-

tology can provide a base for correlating malicious

events and detecting more complex attack scenarios.

For instance, several packets can be correlated us-

ing their shared impact on the system, or their be-

havioural reﬂection on the system (e.g., causing same

Modbus exceptions). Searching and extracting infor-

mation from the background knowledge is performed

through SPARQL queries (Harris et al., 2013). As a

demonstration example, let us assume that a speciﬁc

Modbus server (with IP address = 192.168.0.3) is un-

der an attack originating from the Attacker (with IP

address = 192.168.0.57). A list of all malicious packet

ﬂows between the two systems can be retrieved using

the following SPARQL query:

Listing 3: SPARQL Query to retrieve all malicious packets

between two nodes.

SELECT ∗ WHERE {{? p i c s : h a s S r c I P ’ 1 9 2 . 1 6 8 . 0 . 5 7 ’ .

? p i c s : h a s D s t I P ’ 1 9 2 . 1 6 8 . 0 . 3 ’ . } UNION {? p

i c s : h a s S r c I P ’ 1 9 2 . 1 6 8 . 0 . 3 ’ . ? p i c s : h a s Ds t I P

’ 1 9 2 . 1 6 8 . 0 . 5 7 ’ . } ? p i c s : h as P ac k e t Ty p e ?

P a c k et Ty pe . ? p i c s : h as I m p a c t ? im p a c t . ? p i c s

: h a s A t t a c k V e c t o r ? A t t a c k V e c t o r . }

OSCIDS: An Ontology based SCADA Intrusion Detection Framework

333

Table 4: Final list of the correlated communication packets between the two systems.

Packet ID Source IP Server IP Payload Attack Vector Impact Status

MODBUS7 192.168.0.57 192.168.0.3 Modbus FORCE LISTEN ONLY MODE Denial of Service Failed

MODBUS9 192.168.0.57 192.168.0.3 Modbus FORCE LISTEN ONLY MODE Denial of Service Failed

MODBUS11 192.168.0.57 192.168.0.3 Modbus FORCE LISTEN ONLY MODE Denial of Service Failed

TCP13 192.168.0.57 192.168.0.3 Non Modbus Non Modbus Communication Speciﬁcation Violation

MODBUS14 192.168.0.57 192.168.0.3 Modbus RESTART COMMUNICATIONS OPTION Denial of Service Failed

MODBUS16 192.168.0.57 192.168.0.3 Modbus RESTART COMMUNICATIONS OPTION Denial of Service Successful

MODBUS19 192.168.0.57 192.168.0.3 Modbus RESTART COMMUNICATIONS OPTION Denial of Service Successful

TCP21 192.168.0.57 192.168.0.3 Non Modbus Non Modbus Communication Speciﬁcation Violation

MODBUS22 192.168.0.57 192.168.0.3 Modbus CLEAR AUDIT DIAG REGISTERS System Integrity Successful

MODBUS25 192.168.0.57 192.168.0.3 Modbus CLEAR AUDIT DIAG REGISTERS System Integrity Successful

MODBUS39 192.168.0.57 192.168.0.3 Modbus REPORT SERVER INFORMATION System Reconnaissance Successful

MODBUS42 192.168.0.57 192.168.0.3 Modbus REPORT SERVER INFORMATION System Reconnaissance Successful

The SPARQL query resulted in a total of 29 packet

instances which contain both request and response

Modbus messages. However, different from Snort

IDS, the proposed system extracts the response mes-

sage description about the command execution and

combines this information with the request pair using

a unique message correlation ID. Therefore, the ﬁnal

list of correlated packets for the selected two systems

is presented in Table 4.

5 CONCLUSION

According to the aforementioned experiments and re-

sults, it is clear that the proposed ontology-based IDS

(OSCIDS) is an effective tool for the detection of

intrusions and malicious industrial communications.

The use of ontology modelling can provide rich se-

mantic logics in the represented intrusion knowledge.

This enables advanced capabilities such as reason-

ing and deriving additional useful information from

the existing knowledge, that is beyond the traditional

IDS systems which utilise basic taxonomy represen-

tations. Furthermore, the correlation between packets

or attacks can be made using ﬂexible features that are

not limited to the raw packet information (e.g., Source

IP address) but can utilise the semantic meaning of

the data (e.g., the impact on the system, the purpose

of the command). We intend to apply the proposed

approach on other industrial protocols such as DNP3.

REFERENCES

Barnett, B., Crapo, A., and ONeil, P. (2012). Experiences in

using semantic reasoners to evaluate security of cyber

physical systems. Technical report, GridSec.

Barry, B. I. and Chan, H. A. (2009). Syntax, and semantics-

based signature database for hybrid intrusion detec-

tion systems. Security and Communication Networks,

2(6):457–475.

Carcano, A., Coletta, A., Guglielmi, M., Masera, M.,

Fovino, I. N., and Trombetta, A. (2011). A multi-

dimensional critical state analysis for detecting intru-

sions in scada systems. Industrial Informatics,IEEE

Trans. on, 7(2):179–186.

Chora

s, M., Flizikowski, A., Kozik, R., and Hołubowicz,

W. (2010). Decision aid tool and ontology-based rea-

soning for critical infrastructure vulnerabilities and

threats analysis. 4th CRITIS, pages 98–110.

Drias, Z., Serhrouchni, A., and Vogel, O. (2015). Taxonomy

of attacks on industrial control protocols. In ICPE’15,

pages 1–6. IEEE.

Had

ziosmanovi

c, D., Sommer, R., Zambon, E., and Hartel,

P. H. (2014). semantic security monitoring for indus-

trial processes. In 30th ACSAC, pages 126–135. ACM.

Harris, S., Seaborne, A., and Prudhommeaux, E. (2013).

Sparql 1.1 query language. W3C, 21.

Jena (2011). Jena–a semantic web framework for java. Talis

Systems.

Kang, D.-H., Kim, B.-K., and Na, J.-C. (2014). Cyber

threats and defence approaches in scada systems. In

16th ICACT, pages 324–327. IEEE.

Langner, R. (2011). Stuxnet: Dissecting a cyberwarfare

weapon. Security & Privacy, IEEE, 9(3):49–51.

Mallouhi, M., Al-Nashif, Y., Cox, D., Chadaga, T., and

Hariri, S. (2011). A testbed for analyzing security of

scada control systems (tasscs). In IEEE ISGT, pages

1–7. IEEE.

Modbus (2012). Modbus speciﬁcation v1. 1b3. Modbus

Organization, Inc., April, 26.

Morris, T. H., Jones, B. A., Vaughn, R. B., and Dandass,

Y. S. (2013). Deterministic intrusion detection rules

for modbus protocols. In 46th HICSS, pages 1773–

1781. IEEE.

Peterson, D. (2009). Quickdraw: Generating security log

events for legacy scada and control system devices. In

CATCH’09, pages 227–229. IEEE.

Roesch, M. et al. (1999). Snort ids. In LISA, volume 99,

pages 229–238.

Sartakov, V. A. (2015). Ontological representation of net-

works for ids in cyber-physical systems. In 4th AIST,

pages 421–430. Springer.

Sayegh, N., Elhajj, I. H., Kayssi, A., and Chehab, A. (2014).

Scada intrusion detection system based on temporal

SECRYPT 2016 - International Conference on Security and Cryptography

334

behavior of frequent patterns. In 17th MELECON,

pages 432–438. IEEE.

Sheldon, F., Fetzer, D., Manz, D., Huang, J., Goose, S.,

Morris, T., Dang, J., Kirsch, J., and Wei, D. (2013).

Intrinsically resilient energy control systems. CSI-

IRW’13, pages 63:1–63:4. ACM.

Surridge, M., Chakravarthy, A., Hall-May, M., Chen, X.,

Nasser, B., and Nossal, R. (2012). Serscis: Semantic

modelling of dynamic, multi-stakeholder systems.

Zhu, B. and Sastry, S. (2010). Scada-speciﬁc intrusion de-

tection/prevention systems: a survey and taxonomy.

In 1st SCS.

OSCIDS: An Ontology based SCADA Intrusion Detection Framework

335