An Architecture for Securing Communications in Critical Infrastructure

Christian Callegari

, Alessandro Cantelli Forti

, Giuseppe D’Amore

, Enrique de la Hoz

David Echarri

, Iv

an Garc

ıa-Ferreira

and Germ

an L

opez-Civera

RaSS National Laboratory, CNIT, Pisa, Italy

Vitrociset S.p.A., Rome, Italy

Computer Engineering Department, University of Alcala, Alcala de Henares, Spain

Oesia Network, Madrid, Spain

Keywords:

Critical Infrastructure, Intrusion Detection System, Intrusion Prevention System, Honeynet, Firewall.

Abstract:

The disruption of communications in critical infrastructures could have a serious impact on the health, safety,

security or economic well-being of citizens or even prevent the effective functioning of governments or other

agencies. For this reason, in this paper we present a distributed architecture, named CYBERSENS, aimed at

preventing, early detecting, and mitigating cyber attacks to critical infrastructure networks. CYBERSENS is

an advanced IDS/IPS system specially tailored for securing communications in critical infrastructures. It’s fed-

erated architecture, the combination of misuse detection techniques and novel anomaly detection approaches,

and the inclusion of mechanisms for self-obfuscation and self-protection, makes our proposal specially suit-

able for these scenarios.

1 INTRODUCTION

Since the mid-1990’s, dramatic experiences caused by

natural or man-made disasters made urgent to under-

stand the dependency of our society from those in-

frastructures that, if disrupted or destroyed would se-

riously compromise our quality of life and/or overall

functioning of the society. Therefore, Critical Infras-

tructure protection has become a general label for a

range of activities undertaken jointly by government

and operators of key location, facilities and system to

ensure an adequate management risk.

Critical infrastructures (EUCommission, 2004)

consist of those physical and information technology

facilities, networks, services and assets which un-

availability or malfunction could have a serious im-

pact on the health, safety, security or economic well-

being of citizens or prevent the effective functioning

of governments. Critical infrastructures extend across

many sectors of the economy, including banking and

ﬁnance, transport and distribution, energy, utilities,

health, food supply and communications, as well as

key government services.

Infrastructure systems are characterised by a high

degree of interconnection. Many physical, virtual and

logical dependencies are not apparent until a crisis oc-

curs and the connection breaks down. The high level

of interdependence can lead to cascading shut-downs.

At the same time, smaller and smaller disruptions are

enough to cause dramatic consequences in complex

systems.

In this paper we present a security system, named

CYBERSENS, for the protection of the critical in-

frastructures from cyber attacks. In a nutshell, CY-

BERSENS should be able to prevent, early detect, and

mitigate cyber attacks, while simultaneously keeping

the communications alive and preserving the privacy

of the critical infrastructure users.

In more detail, the functionalities of the CY-

BERSENS system are

• Intrusion prevention/detection: it represents the

core activity of the system. The early detection

and localisation of cyber attacks is carried out by

applying signature-based techniques, effective in

detecting well-known attacks, and anomaly based

techniques, effective in also detecting novel (e.g.,

zero-day) attacks

• Privacy preserving data aggregation and ex-

port: given its distributed architecture, the CY-

BERSENS system makes use of probabilistic data

structure and algorithms that aim to aggregate, ex-

Callegari, C., Forti, A., D’Amore, G., Hoz, E., Santamaria, D., García-Ferreira, I. and López-Civera, G.

An Architecture for Securing Communications in Critical Infrastructure.

DOI: 10.5220/0006016801110120

In Proceedings of the 13th International Joint Conference on e-Business and Telecommunications (ICETE 2016) - Volume 1: DCNET, pages 111-120

ISBN: 978-989-758-196-0

111

change, and export private data among the differ-

ent probes and between the probes and the Main

Control Unit (MCU), without disclosing any pri-

vate information to any external entity

• Trafﬁc masking by encryption and trafﬁc genera-

tion: data links between nodes are encrypted us-

ing known standard best encryption techniques

known to be effective. Trafﬁc padding is provided

as an option by producing or injecting fake trafﬁc

into data links to prevent a passive trafﬁc snifﬁng

to ﬁgure out usage statistics or behaviours

• Attack deviation and redirection – Honeynet: fake

working hosts are decoyed at the purpose of being

a natural target for incoming malicious trafﬁc be-

hind external level of defences. Analysis of trafﬁc

coming from honeynet is used to increase knowl-

edge about malicious techniques in use

• Self-protection: systems aimed at detecting cyber

attacks often become the target of attacks aimed

at stopping the correct functioning of the system

itself, e.g. by increasing consumption of computa-

tional resources. Hence, static secure techniques,

such as ﬁrewalls, are deployed for protecting the

system itself from external attacks

It is important to highlight that in our proposal,

not only does our system take into account the single

critical infrastructure, but it can also protect the inter-

connection among several infrastructures if needed.

The remainder of the paper is structured in the fol-

lowing way: in Section 2 we present the general ar-

chitecture of the proposed system, describing all the

system components and their functionalities. Then

Section 5 details the objectives and the speciﬁcation

of the system, while in Section 3 and 4 we detail the

Anomaly Detection Subsystem and the Misuse-based

Detection Subsystem, respectively. Finally Section 6

concludes the paper with some ﬁnal remarks.

2 GENERAL ARCHITECTURE

As stated in the introduction, the main goal of CY-

BERSENS module is to be able to prevent cyber-

attacks against the telecommunication networks that

enable critical infrastructure normal operation, by

performing an early detection of any sign indicator

of an attack. This early detection allows to prevent a

possible compromise of the IT assets under protection

of the system.

To accomplish this objective, an advanced Intru-

sion Prevention System (IPS) will be deployed, fol-

lowing a distributed approach that allows to meet per-

formance and privacy requirements. To this aim the

system must take into account the sensitivity of the

data that are exchanged between critical infrastruc-

tures and the impact that an attack could have on

them. Moreover the developed detection system must

not introduce data leaks or new vulnerabilities in the

system it is trying to protect. Therefore special mea-

sures related with data privacy and the protection of

the whole system have to be taken.

From the functional point of view, the different

CYBERSENS elements perform a task that is within

three main functional blocks: information gather-

ing module, analysis engine, and alert system (Bace,

2000). These three submodules create a sequential

ﬂow that allows to cover each phase during a typical

cyber incident: monitoring, detection, and mitigation.

In Figure 1 we can observe the overall architecture

of CYBERSENS. The main elements of the system

are:

• Local Central Unit: CYBERSENS central unit

is entitled with the actual IPS functionalities. The

objective is to combine misuse and anomaly de-

tection techniques to cover a wide variety of at-

tacks and be able to discover and react to non-

standard types of attacks and new vulnerabilities.

Misuse detection techniques are based on the pro-

cess of data samples looking for known mali-

cious behaviour. They usually work using some

kind of signature that describes what to look for

in the data to classify it as malicious. Despite

the fact it is a really widely used approach they

can only detect already disclosed vulnerabilities,

so novel attacks that cannot be directly detected

with these signatures or inferred from them will

not be caught by the detection system. Even so,

they perform really well at detecting known at-

tacks and are therefore needed to protect the sys-

tem from the millions of malicious samples al-

ready described by signatures. In contrast to mis-

use detection methods, anomaly detection aims

to detect deviations from the normal behaviour.

These deviations or anomalies may be produced

by intruders or may be due to hardware or soft-

ware malfunction. The idea is that this kind of

anomalies can be used as early detection indica-

tors of attacks. More details about the detection

strategies will be provided in Sections 3 and 4

Privacy issues are also a concern, since the in-

formation collected at each CYBERSENS central

unit is very sensible, as it represents the current

status of the overall architecture and its elements.

Consequently extensive use of cryptographic al-

gorithms and secure message exchange is made in

the communication between each CYBERSENS

central unit and its probes and also between each

DCCI 2016 - SPECIAL SESSION ON DATA COMMUNICATION FOR CRITICAL INFRASTRUCTURES

112

Figure 1: System Architecture.

CYBERSENS central unit if needed.

• Main Central Unit (MCU): this elements is re-

sponsible to collect and correlate the data sent by

the local central unit, so as to generate alarms and

put the proper reaction strategies in place. For

this reason, each local central unit sends to the

main central unit information about the detected

attacks(e.g., location of the attack and the cate-

gory it can be classiﬁed in). The Common Attack

Pattern Enumeration and Classiﬁcation (CAPEC)

(Enumeration, 2013) initiative is used as a com-

mon language to describe the attacks included in

the alerts. It is composed by a hierarchical struc-

ture that easily allows to correlate and cluster re-

lated alerts to make it easier to analyse the situa-

tion in real time.

• Network Probes: The purpose of these probes is

to collect all input and output trafﬁc that travels

through the critical infrastructure network. This

function is usually performed by dedicated hard-

ware systems that allow to forward all the trafﬁc

that goes through them to another node entitled

with monitoring tasks. There exists a wide variety

of hardware (mainly industry level switches and

routers) that already implements these techniques

like SPAN port or port mirroring (Woodring,

2001). Virtualised solutions also have this func-

tionality so even in the case of a virtualised en-

vironment inside a critical infrastructure, trafﬁc

monitoring can also be performed without acquir-

ing new hardware. Also open source projects like

OpenVSwitch or VyOS (virtual switch and router

solution respectively) include mirror port capabil-

ities, so they can be easily integrated into a virtu-

alised architecture if needed.

The second aspect that has to be addressed when

deploying a network probe monitoring infrastruc-

ture is the aggregation and reduction level made

over the collected trafﬁc before exporting it to

monitoring or analysis tools. Netﬂow (Claise,

2004) is a standard proposed by CISCO that in-

cludes a format that describes the ﬂows and a pro-

tocol to generate and transmit these ﬂows and the

statistics related to them to other devices.

Considering the multi-operator scenario, like the

one depicted in Figure 1, each network probe,

apart from simply collecting/aggregating the traf-

ﬁc, must also perform some additional operations

depending on the required output. In more detail,

as it will be clear in the following sections, the

probes must either perform some processing (e.g.,

misuse based intrusion detection) or send aggre-

gated information to Central Unit (one per critical

infrastructure), where the trafﬁc is analysed by the

anomaly detection algorithms.

In the latter case, considering that direct analysis

of raw network trafﬁc is not feasible due to com-

An Architecture for Securing Communications in Critical Infrastructure

113

putational cost and bandwidth limitations some

kind of “additional” aggregation and data reduc-

tion is needed prior to detection phase. Both tech-

niques aim to reduce the size and noise in col-

lected data, retrieving meaningful statistics and

summaries that allow to analyse it without los-

ing any relevant information or at least being able

to conﬁgure how much information we are able

to loose during the process. Moreover, given the

“multi-operator” scenario depicted in Figure 1,

where multiple critical infrastructures are inter-

connected, some privacy constraints can arise that

make “standard” aggregation techniques, such as

NetFlow, unusable.

For this reason the CYBERSENS network probes

have the ability of performing random aggrega-

tion (e.g., by using random data structures like

sketches (Cormode and Muthukrishnan, 2005)).

This kind of data aggregation techniques allow

to dramatically reduce the size of the data while

retaining enough information about its trend or

the number of occurrences of each data instance.

Moreover this data structures may be conﬁgured

to achieve a balance between the data stored in

memory and the amount of information they are

able to ignore.

Therefore each probe can be conﬁgured to aggre-

gate the data as needed depending on the size of

the network, the number of elements monitored

on it, and the kind of analysis to be performed.

• Host Probes: The purpose of this agents is to

collect information about the applications that are

running inside the host. This information includes

system calls, software executed, application spe-

ciﬁc or operating system logs, etc. This data is

useful to detect threats that are already inside the

host, representing a second barrier of protection

against attacks that could bypass network detec-

tion. This kind of probes may have an impact in

the performance of the monitored hosts, so reduc-

tion techniques are applied. The reduction level

applied to the data will be conﬁgurable from the

central unit assigned to it. This reduction can be

simply based on the sampling rate or the actual

format which the logs are transformed to. Appli-

cation malfunctionings can also be detected moni-

toring this kind of logs, this way end-of-life hard-

ware can also be addressed and prevent service

outage due to downtime.

The software category where these probes are in-

cluded is Host-based intrusion detection system.

An an example, in our system, we have used OS-

SEC (Bray et al., 2008), an open-source project

that represents the de facto standard in the indus-

try and have versions for both UNIX and Win-

dows operating systems.

• Virtualised Honeynet: One of the main objec-

tives of the CYBERSENS module is to build a

resilient system that allows to perform early de-

tection of new threats and attacking techniques.

This means that the system itself has to be able to

learn from novel attacks to detect 0-day type vul-

nerabilities, especially in the Anomaly Detection

phase. One of the best ways to obtain up-to-date

types of attacks is to get them directly from the

source, which means to collect information about

real attacks. To do so without damaging any real

infrastructure the usual practice is to employ hon-

eypots. Honeypots can be described as computer

system expressly conﬁgured to attract attackers

(Zhang et al., 2003). To this aim they mimic the

software, conﬁguration and behaviour of a legit-

imate system similar to a typical server exposed

to the Internet. Once an attacker tries to penetrate

this kind of system all the actions she makes are

logged and monitored for further analysis. This

process includes the collection of all trafﬁc, com-

mands executed, ﬁle changes, etc. With this in-

formation an expert can create attack signatures

to feed misuse detection tools. Anomaly detec-

tion systems can beneﬁt too from the information

gathered through honeypots as they can feed the

algorithms with anomalous trafﬁc that can be used

to train them. The combination of multiple hon-

eypots that tries to create a whole network that

resembles a typical company network, is what is

called a honeynet(Spitzner, 2003).

In the context of CYBERSENS, the honeypots

employ virtualization techniques to deploy the

vulnerable system. Virtualization allows to isolate

the honeypot and to be able to gather information

of it from the host system. They also allow to de-

ploy different kinds of systems in a single host,

making it easier to imitate a network where mul-

tiple kinds of host and services are deployed.

In general, many different types of honeypots are

available, usually classiﬁed as low or high inter-

action. Low interaction honeypots tries to mimic

a service or only a few services of a system. They

are intended to be used as bait and collect infor-

mation about the level of exposure (i.e. how many

attacks are we receiving?) and the source of the at-

tacks (i.e. IP addresses, location, attack attempts).

As they only imitate a set of services they are eas-

ier to detect by an intruder, who therefore stop at-

tacking it or even tries to attack the honeypot it-

self. On the other hand high interaction honeypots

are focused on simulating a real system including

DCCI 2016 - SPECIAL SESSION ON DATA COMMUNICATION FOR CRITICAL INFRASTRUCTURES

114

all typical services. Consequently, the informa-

tion collected from them is much more detailed

and they can also create a timeline of the attack

and the techniques employed to exploit the hon-

eypot.

CYBERSENS makes use of a hybrid approach

in which bait-like systems are deployed in each

critical infrastructure and when an attacker is at-

tracted to it and tries to connect, he is redirected

to the actual honeynet, realised by a virtualised

dedicated VPN either “internal” to a given criti-

cal infrastructure or “external” to all of them. It

is important to highlight that all the data collected

from the honeynets may also need some kind of

aggregation before exporting it to its central unit

for analysis, so similar techniques to the ones em-

ployed in the probes should be applied.

It is worth noting that the decision of redirecting a

particular ﬂow to the honeynet is made by a Main

Central Unit. CYBERSENS will only alert that

a malicious activity is undergoing in a particular

segment of the network.

• Trafﬁc Generating System: even though all sen-

sible trafﬁc between different critical infrastruc-

tures must be encrypted, a passive snifﬁng attack

could be possible if the network is compromised

at any point of the communication. Despite the

fact that an attacker would not be able to eaves-

drop the content of the communication, statisti-

cal analysis may disclose some meaningful infor-

mation. This type of analysis involves the study

of the timestamp, size, source and destination of

the messages exchanged. This type of data is not

usually encrypted and an attacker could link and

correlate the instant when a message is sent with

side-channel information. For example the mes-

sage that is sent when an alert is launched may

not vary too much from one alert to another, so it

will take up similar size during the time and will

always be sent to the same IP address. An attacker

can induce when an alert is launched if she inten-

tionally generates an alert and correlate the mes-

sage she sees on the network despite the fact that

it is encrypted.

The purpose of this submodule is to avoid this

kind of analysis by generating and injecting fake

trafﬁc into the data links that supports each crit-

ical infrastructure. This means that an attacker

could not distinguish between real and fake trafﬁc

when observing it from outside. To accomplish

this objective Trafﬁc Flow Conﬁdentiality (TFC)

techniques could be employed. These methods

increase the entropy level of the trafﬁc patterns

that can emerge from the typical behaviour of the

users and system that use it to connect to other

networks. They do so by modifying the length,

frequency or origin-destination pattern. One di-

rect consequence of this techniques is the impact

they can have on the performance of the network

as they may involve delaying or rerouting packets

(Carlen, 2013).

Therefore this module must be correctly installed

in each critical infrastructure, so that it provides

protection from eavesdropping inside the criti-

cal infrastructure and also in the communications

made through the backbone network.

• Backbone Software Deﬁned Network (SDN):

despite it is not strictly part of the CYBERSENS

system, the design of the backbone network that

supports the communication between all CY-

BERSENS central units and the MCU is a critical

issue. This network must be ﬂexible enough to be

able to meet changing requirements and different

performance demands according to the activity

performed at each critical infrastructure. The em-

ployment of Software Deﬁned Networks (SDN)

represents the main approach to build a resilient

and ﬂexible network.

Even though availability issues have been taken

into account during architecture design and the

CYBERSENS module can act autonomously at

each critical infrastructure if needed, a network

outage will impact the performance of the detec-

tion and reaction process. To address this issue, a

resilient backbone network is needed and the SDN

approach allows to deploy multiple data links be-

tween each node and make use of backup links if

needed. Moreover it provides different alternative

paths to reach each critical infrastructure even in

the case of an attack as the reaction strategies put

in place by the MCU may alter the topology of the

network to protect some assets.

Obviously, the backbone network have to meet

all the requirements imposed by the rest of the

CYBERSENS architecture elements. That means

that encryption mechanisms and secure commu-

nication tunnelling methods like IPSEC and VPN

must be provided by the network and properly

conﬁgured. SDN may help to develop robust con-

ﬁguration that can be replicated at each critical

infrastructure via a centralized management point

(SDN controller).

The result of combining all these elements is a

solid workﬂow that enables a robust intrusion de-

tection system. The development of a hybrid ap-

proach that combines misuse and anomaly detection

techniques provides a wide protection against known

An Architecture for Securing Communications in Critical Infrastructure

115

Figure 2: System Workﬂow.

and novel threats. All the processes involved in CY-

BERSENS module can be summarized in four main

categories (as sketched in Figure 2).

1. Collection Phase: this phase includes the deploy-

ment of network and host probes that collect all

the data that will be fed later to the detection en-

gine

2. Aggregation Phase: raw data collected from

probes is not feasible to process, therefore dimen-

sionality reduction and aggregation techniques are

applied to it before performing actual detection on

the data

3. Detection Phase: misuse and anomaly detection

methods will be applied to detect malicious be-

haviours in the system. This process includes

privacy preservation techniques that allow to de-

tect anomalies while protecting sensitive data col-

lected from each probe

4. Alert Phase: every time an anomaly is detected

appropriate measures have to be taken. To do so,

CYBERSENS must communicate with the MCU

sending alerts and information about the detected

incident

3 ANOMALY DETECTION

SUBSYSTEM

In distributed anomaly detection algorithms, multiple

detection probes – distributed in the backbone net-

work – monitor a given portion of the network sep-

arately and report the collected information to a sin-

gle location (namely the Local Central Unit) that an-

alyzes the data and generates the alerts. A sketch of

this architecture in provided in Figure 3.

Figure 3: Anomaly Detection system: Architecture.

As a ﬁrst step, the probes have to collect and pre-

process the network trafﬁc, so as to extract the needed

information to be sent to the central unit, which then

performs the actual anomaly detection phase. As an

example, by limiting the scope to the simplest case

of anomaly detection algorithms that analyzes traf-

ﬁc volumes only, the data collected by the probes

can be simply represented by the estimation of the

number of trafﬁc ﬂows observed in a given time win-

dow. Hence, the ﬁrst problem to be solved is to pro-

vide a reliable estimate of such quantities. Note that

this task, that is not trivial when performed over the

multi-gigabits links of a backbone network, has been

discussed in several previous works, and the use of

probabilistic data structure has emerged as a standard

approach (Flajolet and Martin, 1985)(Callegari et al.,

2010). It is worth noticing here that, when aggregat-

ing these structures at the CYBERSENS Central Unit

level, several problems (such as not counting dupli-

cated ﬂows – i.e. the ﬂows observed by more than a

single probe) must be solved.

CYBERSENS mainly makes use of reversible

sketches (Schweller et al., 2004) in this phase to

aggregate the trafﬁc and of LogLog Counter (Du-

rand and Flajolet, 2003) for estimating cardinali-

ties, combined together in the LogLog Counting Re-

versible Sketch data structure (Callegari et al., 2012).

Nonetheless, the architecture has been designed to be

general enough to allow to run multiple aggregation

and estimation techniques.

In general, the information produced by the

DCCI 2016 - SPECIAL SESSION ON DATA COMMUNICATION FOR CRITICAL INFRASTRUCTURES

116

probes represent sensitive users information and must

not be openly disclosed. From this point of view, the

use of probabilistic data structures,as the ones previ-

ously discussed, also provides an ideal container to

keep all such data in an aggregate and not directly ac-

cessible way. However, whenever trafﬁc anomalies

are detected, the use of LLCRS provides us a way of

identifying the ﬂows (in particular, IP addresses) re-

sponsible for that supposed misbehavior.

From the anomaly detection perspective, the CY-

BERSENS system can run several anomaly detection

algorithms, based on different statistical approaches.

In more detail, we have studied two distinct ap-

proaches:

• Distributed CUSUM: in such an approach the

probes mainly export simple ﬂow counters to-

wards the CYBERSENS central unit, which de-

tect anomalous behaviors by means of a change-

point detection algorithm

• Distributed PCA: in this case, the probes

perform some preliminary processing over the

data (distributed PC computation) and the CY-

BERSENS aggregates the pre-processed data to

perform the actual anomaly detection phase (Cal-

legari et al., 2015)

As a ﬁnal step, if an anomaly is detected the cen-

tral unit sends an alert to the MCU, containing:

• timestamp: date and time of acquisition

• spatial ID: ID conveying spatial information asso-

ciated to the source that has provided the consid-

ered data

• cyber threat classiﬁcation (class): the type of cy-

ber threat revealed, if available

• attacker(s) and victim(s) IP addresses

4 ISUSE-BASED DETECTION

SUBSYSTEM

As depicted in Figure 4, where the general archi-

tecture of the Misuse-based detection subsystem is

shown, such a subsystem is composed of several com-

ponents, namely a set of distributed sensors and a cen-

tralized server.

The sensor represents the software that is installed

in the network and is composed of several open-

source tools. They provide three main capabilities:

IDS, misuse detection and real time monitoring.

CYBERSENS can include different IDS to de-

tect threats in the network and in the system, being

Figure 4: Misuse-based Detection system: Architecture.

three top possibilities Snort (www.snort.org), Suri-

cata (suricata-ids.org), and Bro (www.bro.org), be-

cause of their wide adoption among security indus-

try and being considered best-of-breed in security.

Moreover, apart from these “basic” conﬁguration, a

sensor can include other tools to detect speciﬁc at-

tacks or gain additional information: e.g., OSSEC

(Bray et al., 2008), Ntop (www.ntop.org), Nagios

(www.nagios.org).

All these tools are linked together so as to provide

a user with a single integrated environment. More-

over, to combine and process the logs produced by

the different tools, as well as the system logs (syslog

in Linux) that are continually monitored so as to get

all the thread in the system, CYBERSENS makes use

of a set of regular expressions, which ﬁlter the system

logs to a new CYBERSENS log, which is stored in

database.

The described processes are achieved by a Cy-

bersens central agent that is located in the sensor sys-

tem. This agent mainly controls each tool to assure

that everything is working ﬁne in the sensor. If some

vital process to the system fails the agent sends an

alarm to the server.

On the other hand, the server’s main responsibili-

ties are: to receive event information from sensors, to

correlate events into alerts, and to perform online in-

ventory and sensors conﬁguration. It is worth noting

that the communication between the server and the

different sensors through the network is performed

through a VPN tunnel, which assures a secure com-

munication.

Apart from these “speciﬁc” misuse-based detec-

tion subsystem elements, also the Local Central Unit

is involved, mainly working as a a correlation en-

gine. In more detail, its main goal is to analyze the

received events, and determine which ones are valu-

An Architecture for Securing Communications in Critical Infrastructure

117

able enough to be reported to the MCU as an alert. To

do so, its logic uses several heuristics, for example:

• Events are of the same type, and are directed to

the same target

• An event can be associated to known information

of the target. For example, if we know the at-

tack affect an SSH server on Linux, and target is

a Linux, an alert can be raised. Otherwise, if it

is a Windows machine, it won’t. In another case,

we could raise an alert if the target is known to

be vulnerable to the vulnerability actually being

exploited by the attack

Moreover, the subsystem is also equipped with

an active and passive scanner that continuously looks

for any change in the network (e.g., new applica-

tion, topological changes). The active scanners are

performed by tool which scan the network periodi-

cally, like nmap (nmap.org), while the passive scan-

ners “listens” the network looking for changes, like

p0f (lcamtuf.coredump.cx/p0f.shtml).

Finally, the subsystem also makes use of

several vulnerability analysis tools like Openvas

(www.openvas.org), to detect any problem in the net-

work, and of monitoring tool that allow to proﬁle the

several “entities” in the network.

As in the anomaly detection case, also this subsys-

tem, in case an attack is detected, sends an alert to the

MCU.

5 CYBERSENS SYSTEM

EVALUATION BENCHMARKS

To measure the level of accomplishment of CY-

BERSENS module, ﬁrst we have to identify and enu-

merate its goals and then ﬁnd performance indicators

that allow us to get metrics about the behaviour of the

module. Following the functionalities outlined in Sec-

tion 1, the CYBERSENS goals can be summarised in

ﬁve main categories:

• Detection and prevention of malicious events: it

represents the main objective of the module and

its performance must be carefully measured. The

detection phase can be seen as a classiﬁcation

problem in which the events generated by the cap-

tured network trafﬁc and logs captured must be

divided into normal and malicious categories. To

measure the quality of the decisions these algo-

rithms take, two of the main performance indica-

tors are the false positive rate and the detection

rate. False positive rate indicates how much the

algorithm classiﬁes a benign sample as malicious,

while the detection rate tells how many malicious

samples are properly detected as bad ones. The

combination of different samples of these met-

rics using different conﬁgurations allows to draw

a Receiver Operating Characteristic (ROC) curve.

This kind of graphical plot shows the behaviour

of classiﬁcation algorithms when their discrimi-

nation parameters are modiﬁed. It will provide

a good indicator of how well and how ﬂexible

are the detection algorithms developed in the CY-

BERSENS module. Additional tests can also be

performed to analyse how the algorithms behave

at guessing the speciﬁc category of attack seen in

the malicious events

• Privacy preservation and data aggregation: the

second goal of the CYBERSENS module is to be

able to manage the complexity and size of the data

collected from the network and hosts. The com-

bination of aggregation and reduction techniques

has been studied. Privacy is a complex parameter

to measure as there are not direct tests that allows

to see how much private data is leaked during the

normal work process of the system. Since encryp-

tion mechanisms are going to be enforced during

the transport of the data between each element of

the architecture, a coverage test is performed. In

this type of tests we can evaluate how many nodes

are conﬁgured to use encryption mechanisms and

if they are properly conﬁgured (e.g., encryption

algorithms, key size, key storage method)

• Trafﬁc generation: as previously mentioned,

the platform communications and network trafﬁc

must be robust against passive snifﬁng attacks. To

address this issue the platform fake ﬂows are in-

jected at each network so as to make it harder for

an attacker to deduce any meaningful information

doing statistical analysis of the trafﬁc. The level

of protection that introduces this feature is mea-

sured doing actual statistical analysis of the trafﬁc

and running pattern searching algorithms against

captured traces with and without injections inside.

Another key issue is how these injections may

inﬂuence the detection performance as they may

introduce non-standard behaviour inside the net-

work that could be detected as anomalous and in-

crease the false positive rate. To evaluate such an

impact samples of trafﬁc data with and without

injections inside are collected and the same mea-

sures are made to judge the detection performance

• Attack redirection to honeynets: when an attack

is detected by CYBERSENS module it should be

redirected to a honeynet. This objective is focused

on the collection of attacker data while interacting

inside the honeynet, producing precious informa-

tion that can feed the detection algorithms with

DCCI 2016 - SPECIAL SESSION ON DATA COMMUNICATION FOR CRITICAL INFRASTRUCTURES

118

new malicious behaviour. It is also expected that

very few of the normal trafﬁc is redirected to the

honeynet as it will produce service outage for le-

gitimate users of the network. This requirement

is directly linked with the detection performance

indicators. A high false positive rate would proba-

bly produce more redirections of benign trafﬁc to

a honeynet. With this in mind the type of attacks

or the speciﬁc threshold that is used to choose a

ﬂow as malicious (and therefore a candidate for

redirection) is conﬁgurable, making it easy to ad-

just the rate in case of detecting legitimate trafﬁc

ending at the honeynet

• Self-protection: as the system itself is expected

to be the target of attacks it has been built to re-

sist them and react in the case of a platform com-

promise. To this aim, CYBERSENS system de-

ploys probes at the actual elements of the plat-

form. Therefore proper responses are intended

to protect the platform itself (e.g.,isolating par-

tial segments that may be under attack, contain-

ing the spread of the intrusion). On the other side

resource overconsumption may also be the source

of targeted attacks aimed to disable security mea-

sures to bypass monitoring services. Moreover it

can lead to a DoS attack if the resource consump-

tion lead to a service outage in the actual services

of the critical infrastructure. To measure how this

requirement is met, simulated alerts are sent to the

MCU to evaluate how the system react to attacks

inside the platform and if they are properly iso-

lated

Given these functionalities, the main requirements

that the CYBERSENS system should fulﬁl, to prop-

erly protect a critical infrastructure, are:

• Detection rate in the range 70% to 90%, with a

false alarm rate lower than 20%

• Ability of processing, almost in real-time, net-

work trafﬁc with a granularity either at the ﬂow

level, if direct access to the network devices is

guaranteed, or at the aggregate level, if data are

exported from the network devices to the moni-

toring probe

• Ability of redirecting the 70% of anomalous traf-

ﬁc to the honeynet, with only a maximum of 1%

of normal trafﬁc also redirected to the honeynet

• Ability of processing more than 1000 events in the

case of usage of log records for forensic activi-

ties, corresponding to maximum time to perform

searches in data recently archived of 15’ and of

30’ in data archived in 6 months

• Ability of disclosing not more than 1% of private

data during aggregation and export

6 CONCLUSIONS

One of the main concerns for today’s critical in-

frastructures is protection against cyber attacks.

For effective protection, advanced Intrusion Pre-

vention/Detection Systems (IDS/IPS) are paramount.

This paper presents CYBERSENS, a novel advanced

IDS/IPS system intended for critical infrastructures.

Particularly, the general architecture and the main

functionalities of the CYBERSENS system, as well

as the interactions with other subsystems within the

critical infrastructure network are described. Finally,

an outline of the evaluation metrics we will use to as-

sess CYBERSENS performance is presented.

ACKNOWLEDGEMENTS

This work was partially supported by SCOUT, a re-

search project supported by the European Commis-

sion under its 7th Framework Program (contract-no.

607019). The views and conclusions contained herein

are those of the authors and should not be inter-

preted as necessarily representing the ofﬁcial policies

or endorsements, either expressed or implied, of the

SCOUT project or the European Commission.

REFERENCES

Bace, R. G. (2000). Intrusion detection. Sams Publishing.

Bray, R., Cid, D., and Hay, A. (2008). OSSEC host-based

intrusion detection guide. Syngress.

Callegari, C., Di Pietro, A., Giordano, S., Pepe, T.,

and Procissi, G. (2012). The loglog counting re-

versible sketch: A distributed architecture for detect-

ing anomalies in backbone networks. In Communica-

tions (ICC), 2012 IEEE International Conference on,

pages 1287–1291.

Callegari, C., Gazzarrini, L., Giordano, S., Pagano, M.,

and Pepe, T. (2010). When randomness improves

the anomaly detection performance. In Proceedings

of the International Symposium on Applied Sciences

in Biomedical and Communication Technologies (IS-

ABEL).

Callegari, C., Giordano, S., and Pagano, M. (2015). Net-

work and System Security: 9th International Confer-

ence, NSS 2015, New York, NY, USA, November 3-

5, 2015, Proceedings, chapter Enforcing Privacy in

Distributed Multi-Domain Network Anomaly Detec-

tion, pages 439–446. Springer International Publish-

ing, Cham.

Carlen, P. L. (2013). Trafﬁc ﬂow conﬁdentiality mech-

anisms and their impact on trafﬁc. In Military

Communications and Information Systems Confer-

ence (MCC), 2013, pages 1–6. IEEE.

An Architecture for Securing Communications in Critical Infrastructure

119

Claise, B. (2004). Cisco systems netﬂow services export

version 9.

Cormode, G. and Muthukrishnan, S. (2005). An improved

data stream summary: the count-min sketch and its

applications. Journal of Algorithms, 55(1):58 – 75.

Durand, M. and Flajolet, P. (2003). Loglog counting of

large cardinalities. In In ESA, pages 605–617.

Enumeration, C. A. P. (2013). Classiﬁcation (capec). URL

https://capec. mitre. org.

EUCommission (2004). Critical Infrastructure Protection in

the Fight against Terrorism.

Flajolet, P. and Martin, G. N. (1985). Probabilistic counting

algorithms for data base applications. J. Comput. Syst.

Sci., 31(2):182–209.

Schweller, R., Gupta, A., Parsons, E., and Chen, Y. (2004).

Reversible sketches for efﬁcient and accurate change

detection over network data streams. In Proceedings

of the 4th ACM SIGCOMM conference on Internet

measurement, IMC ’04, pages 207–212, New York,

NY, USA. ACM.

Spitzner, L. (2003). The honeynet project: Trapping the

hackers. IEEE Security & Privacy, (2):15–23.

Woodring, S. (2001). Port mirroring in channel directors

and switches. US Patent App. 10/026,706.

Zhang, F., Zhou, S., Qin, Z., and Liu, J. (2003). Honeypot:

a supplemented active defense system for network se-

curity. In Parallel and Distributed Computing, Appli-

cations and Technologies, 2003. PDCAT’2003. Pro-

ceedings of the Fourth International Conference on,

pages 231–235. IEEE.

DCCI 2016 - SPECIAL SESSION ON DATA COMMUNICATION FOR CRITICAL INFRASTRUCTURES

120