SeSaR: Security for Safety
Ermete Meda1, Francesco Picasso2, Andrea De Domenico1, Paolo Mazzaron1,
Nadia Mazzino1, Lorenzo Motta1, and Aldo Tamponi1
1
Ansaldo STS, Via P. Mantovani 3-5, 16151 Genoa, Italy
{Meda.Ermete,DeDomenico.Andrea,Mazzaron.Paolo,Mazzino.Nadia,
Motta.Lorenzo,Tamponi.Aldo}@asf.ansaldo.it
2
University of Genoa, DIBE, Via Opera Pia 11-A, 16145 Genoa, Italy
[email protected]
Abstract. The SeSaR (Security for Safety in Railways) project is a HW/SW system conceived
to protect critical infrastructures against cyber threats - both deliberate and accidental – arising
from misuse actions operated by personnel from outside or inside the organization, or from
automated malware programs (viruses, worms and spyware). SeSaR’s main objective is to
strengthen the security aspects of a complex system exposed to possible attacks or to malicious
intents. The innovative aspects of SeSaR are manifold: it is a non-invasive and multi-layer
defense system, which subjects different levels and areas of computer security to its checks and
it is a reliable and trusted defense system, implementing the functionality of Trusted Computing. SeSaR is an important step since it applies to different sectors and appropriately responds
to the more and more predominant presence of interconnected networks, of commercial systems with heterogeneous software components and of the potential threats and vulnerabilities
that they introduce.
1 Introduction
The development and the organization of industrialized countries are based on an
increasingly complex and computerized infrastructure system. The Critical National
Infrastructures, such as Healthcare, Banking & Finance, Energy, Transportation and
others, are vital to citizen security, national economic security, national public health
and safety.
Since the Critical National Infrastructures may be subject to critical events, such as
failures, natural disasters and intentional attacks, capable to affect human life and
national efficiency both directly and indirectly, these infrastructures need a an aboveaverage level of protection.
In the transportation sector of many countries the introduction into their national
railway signaling systems of the new railway interoperability system, called
ERTMS/ETCS (European Rail Traffic Management System/European Train Control
System) is very important: in fact the goal of ERTMS/ETCS is the transformation of a
considerable part of the European - and not just European - railway system into an
interoperable High Speed/High Capacity system. In particular, thanks to said innovative signaling system the Italian railways intend to meet the new European requirements and the widespread demand for higher speed and efficiency in transportation.
E. Corchado et al. (Eds.): CISIS 2008, ASC 53, pp. 116–122, 2009.
springerlink.com
© Springer-Verlag Berlin Heidelberg 2009
SeSaR: Security for Safety
117
The development of ERTMS/ETCS has set the Italian railways and the Italian
railway signaling industry among the world leaders, but it has introduced new risks
associated with the use of information infrastructures, such as failures due to natural
events and human-induced problems. The latter ones may be due to negligence and/or
to malice and can directly and heavily affect ICT security.
ICT security management is therefore becoming complex. Even for railway applications, where the safety of transport systems is still maintained, information threats
and vulnerabilities can contribute to affect the continuity of operation, not only causing inconvenience to train traffic, but also financial losses and damage to the corporate image of the railway authorities and to the one of their suppliers.
2 Implementation of ICT Security
To illustrate the main idea behind the SeSaR (Security of Safety in Railways) project,
the concept of ICT security should be defined first: implementing security means
developing the activities of prevention, detection and reaction to an accident.
In particular the following definitions hold:
•
•
•
Prevention: All the technical defence and countermeasures enabling a system to
avoid attacks and damages. Unfortunately, the drawback of this activity is that, in
order to be effective, prevention must be prolonged indefinitely in time, thus requiring a constant organisational commitment, continuous training of personnel
and adjustment/updating of the countermeasures.
Detection: When prevention fails, detection should intervene, but the new malicious codes are capable of self-mutations and the "zero-day" attacks render the
countermeasures adopted ineffective: so adequate defence architecture cannot be
separated from the use of instruments capable of analyzing, in real-time, tracks
and records that are stored in computers and in the defence network equipment.
Reaction: The last activity that can be triggered either as a consequence of prompt
detection or when the first two techniques were ineffective but some problems
start to affect the system in an apparent way. Of course in the latter case it is difficult to guarantee the absence of inefficiency, breakdowns and malfunctions.
The goal of SeSaR was to find a tool that could merge the Prevention and the Detection activities of security, in the belief that the effectiveness of the solution sought
could be based on the ability to discover and communicate what is new, unusual and
anomalous.
The idea was to design a hardware/software platform that could operate as follows:
•
•
Prevention: operate a real-time integrity control of the hardware and software
assets.
Detection: operate a real-time analysis of tracks and records stored in critical
systems and in defence systems, seeking meaningful events and asset changes.
Operator Interface: create a simple concise representation, which consists of a
console and of a mimic panel overview, to provide the operator with a clear and
comprehensive indication of anomalies identified and to enable immediate
reaction.
118
E. Meda et al.
3 Architecture
The scope of SeSaR is constituted by the ERTMS/ETCS signaling system infrastructure
used for “Alta Velocità Roma-Napoli”, i.e. the Rome-Naples high-speed railway line.
In summary, the Rome-Naples high speed system is constituted by the Central Post
(PCS, acronym for “Posto Centrale Satellite”) located at the Termini station in Rome,
and by 19 Peripheral Posts (PPF, acronym for “Posto Periferico Fisso”). The PPFs
are distributed along the line and linked together and with the PCS by a WAN.
SeSaR supplies hardware/software protection against ICT threats - deliberate and
accidental - arising from undue actions operated by individuals external or internal to
the ICT infrastructure or by automated malicious programs, such as viruses, worms,
trojans and spyware.
The distinctive and innovative features of SeSaR are:
•
•
•
•
A non-invasive defence system.
It works independently of the ICT infrastructure and Operating System (Unix,
Linux or Windows).
A multi-layer defence system, operating control over different levels and areas of
computer security, such as Asset Control, Log Correlation and an integrated and
interacting Honeynet.
A reliable defence system with the capability to implement the functionality of
Trusted Computing.
In particular, SeSaR carries out the following main functions, as shown in Fig.1:
Fig. 1. SeSaR: multi-level defence system
•
•
•
Real-time monitoring of the assets of the ICT infrastructure.
Real-time correlation of the tracks and records collected by security devices and
critical systems.
Honeynet feature, to facilitate the identification of intrusion or incorrect behaviour by creating "traps and information bait".
SeSaR: Security for Safety
•
119
Forensic feature, which allows the records accumulated during the treatment of
attacks to be accompanied by digital signature and marking time (timestamp) so
that they can have probative value. This feature also contributes to create "confidence" on the system by constant monitoring of the system integrity.
SeSaR protects both the Central Post network and the whole PPF network against
malicious attacks by internal or external illicit actions. As already mentioned, three
functional components are included: Asset Control Engine, Log Correlation Engine
and Honeynet.
3.1 Asset Control Engine
This component checks in real-time the network configuration of the system IP-based
assets, showing any relevant modification, in order to detect the unauthorized intrusion or lack (also shut-down and Ethernet card malfunctioning) of any IP node.
The principle of operation is based on:
•
•
monitoring the real-time network configuration of all IP-devices by SNMP (Simple Network Management Protocol) queries to all the switches of the system.
comparison of such information with the reference configuration known and
stored in SeSaR database.
Each variation found generates an alarm on the console and on a mimic panel.
To get updated information from the switches, the SeSaR Asset Control Engine,
(SACE, also called CAI, an acronym for Controllo Asset Impianto) uses MIB (Management Information Base) through the mentioned SNMP protocol. In a switch MIB
is a kind of database containing information about the status of the ports and the IP –
MAC addresses of the connected hosts. By interrogating the switches, CAI determines whether their ports are connected to IP nodes and the corresponding IP and
MAC addresses.
The CAI activities can be divided into the following subsequent phases:
PHASE 1) Input Data Definition and Populating the SeSaR Reference Data-Base
This phase includes the definition of a suitable database and the importation into it of
the desired values for the following data, forming the initial specification of the network configuration:
a) IP address and Netmask for each system switch and router;
b) IP address, Netmask and Hostname for each system host;
c) Each System subnet with the relevant Geographic name.
Such operations can also be performed with SeSaR disconnected from the system.
PHASE 2) Connecting SeSaR to the system and implementing the Discovery activity
This phase is constituted by a Discovery activity, which consists in getting, for each
switch of the previous phase, the Port number, MAC address and IP address of each
node connected to it. The SeSaR reference database is thus verified and completed
with MAC Address and Port number, obtaining the 4 network parameters which describe each node (IP address, Hostname, MAC address and Number of the switch port
connected to the node).
120
E. Meda et al.
Said research already lets the operator identify possible nodes which are missing or
intruding and lets him/her activate alarms: an explicit operator acknowledge is required for each node corresponding to a modification and all refused nodes will be
treated by SeSaR as alarms on the Operator Console (or GUI, Graphic User Interface) and appropriately signalled on the mimic panel.
Of course whenever modifications are accepted the reference database is updated.
PHASE 3) Asset Control fully operational activity
In such phase CAI cyclically and indefinitely verifies in real-time the network configuration of all the system assets, by interrogating the switches and by getting, for
each network node, any modification concerning not only the IP address or Port number, as in the previous phase, but also the MAC address; the alarm management is
performed as in the said phase.
3.2 Log Correlation Engine
Firewall and Antivirus devices set up the underlying first defence countermeasures
and they are usually deployed to defend the perimeter of a network. Independently of
how they are deployed, they discard or block data according to predefined rules: the
rules are defined by administrators in the firewall case, while they are signature
matching rules defined by the vendor in the antivirus case. Once set up, these devices
operate without the need of human participation: it could be said that they silently
defend the network assets. Recently new kinds of devices, such as intrusion detection/prevention systems, have become available, capable to monitor and to defend the
assets: they supply proactive defence in addition to the prevention defence of firewalls and antiviruses. Even using ID systems it is difficult for administrators to get a
global vision of the asset’s security state since all devices work separately from each
other. To achieve this comprehensive vision there is a need of a correlation process of
the information made available by security devices: moreover, given the great amount
of data, this process should be an automatic or semi-automatic one.
The SeSaR Log Correlation Engine (SLCE, also called CLI, an acronym for Correlazione Log Impianto) achieves this goal by operating correlations based on security
devices’ logs. These logs are created by security devices while monitoring the information flow and taking actions: such logs are typically used to debug rules configurations and to investigate a digital incident, but they can be used in a log correlation
process as well. It is important to note that the correlation process is located above the
assets’ defence layer, so it is transparent to the assets it monitors. This property has a
great relevance especially when dealing with critical infrastructures, where changes in
the assets require a large effort – time and resources – to be developed.
The SLCE’s objective is to implement a defensive control mechanism by executing
correlations within each single device’s log and among multiple devices’ alerts (Fig. 2).
The correlation process is set up in two phases: the Event Correlation phase (E.C.) named
Vertical Correlation and the Alert Correlation (A.C.) phase named Horizontal Correlation.
This approach rises from a normalization need: syntactic, semantic and numeric
normalization. Every sensor (security device) either creates logs expressed in its own
format or, when a common format is used, it gives particular meanings to its log
fields. Moreover the number of logs created by different sensors may differ by several
orders of magnitude: for example, the number of logs created by a firewall sensor is
usually largely greater than the number of logs created by an antivirus sensor.
SeSaR: Security for Safety
121
Fig. 2. Logs management by the SeSaR Log Correlation Engine
So the first log management step is to translate the different incoming formats into a
common one, but there is the need for a next step at the same level. In fact, by simply
translating formats, the numeric problem is not taken into account: depending on the
techniques used in the correlation processes, by mixing two entities, which greatly
differ in size, the information carried by the smallest one could be lost. In fact, at
higher level, it should be better to manage a complete new entity than working on
different entities expressed in a common format.
The Vertical Correlation takes into account these aspects by acting on every sensor
in four steps:
1.
2.
3.
4.
it extracts the logs from a device;
it translates the logs from the original format into an internal format (metadata) useful to the correlation process;
it correlates the metadata on-line and with real-time constraints by using
sketches [3];
if anomalies are detected, it creates a new message (Alert), which will carry
this information by using the IDMEF format [4].
The correlation process is called vertical since it is performed on a single sensor basis: the SensorAgent software manages a single device and implements E.C. (the Vertical Correlation) using the four steps described above. The on-line, real-time and
fixed upper-bound memory usage constraints allow for the development of lightweight software SensorAgents which can be modified to fit the context and which
could be easily embedded in special devices.
The Alerts created by Sensor Agents (one for each security device) are sent to the
Alert Correlator Engine (ACE) to be further investigated and correlated. Basically
ACE works in two steps: the aggregation step, in which the alerts are aggregated
based on content’s fields located at the same level in IDMEF, without taking into
consideration the link between different fields; the matching scenario step, in which
122
E. Meda et al.
the alerts are aggregated based on the reconstruction and match of predefined scenarios. In both cases multiple Alerts – or even a single Alert, if it represents a critical
situation – form an Alarm which will be signalled by sending it to the Operator Interface (console and mimic panel). Alarms share the IDMEF format with Alerts but the
former ones get an augmented semantic meaning given to them during the correlation
processes: Alerts represent anomalies that must be verified and used to match scenarios, while Alarms represent threats.
3.3 Honeynet
This SeSaR’s component identifies anomalous behaviours of users: not only operators, but also maintainers, inspectors, assessors, external attackers, etc... Honeynet is
composed of two or more honeypots. Any honeypot simulates the behaviour of the
real host of the critical infrastructure. The honeypot security level is lower than the
real host security level, so the honeypot creates a trap both for malicious and negligent users. Data capturing (keystroke collection and capture traffic entering the
honeypots), data controlling (monitoring and filtering permitted or unauthorised information) and data analysis (operating activities on the honeypots) the functionalities
it performs.
4 User Console and Mimic Panel
Any kind of alarms coming from Asset Control, Log Correlation and Honeynet are
displayed to the operator both in textual and graphical format: the textual format by a
web based GUI (Graphic User Interface), the graphical format by a mimic panel.
The operators can manage the incoming alarms on the GUI. There are three kinds
of alarm status: incoming (waiting to be processed by an operator), in progress and
closed. The latter ones are the responsibility of operators.
5 Conclusion
SeSaR works independently of the ICT infrastructure and Operative System. Therefore SeSaR can be applied in any other context, even if SeSaR is being designed for
railway computerized infrastructure. SeSaR and its component are useful to improve
any kind of existing security infrastructure and it can be a countermeasure for any
kind of ICT infrastructure.
References
1. Meda, E., Sabbatino, V., Doro Altan, A., Mazzino, N.: SeSaR: Security for Safety, AirPort&Rail, security, logistic and IT magazine, EDIS s.r.l., Bologna (2008)
2. Forte, D.V.: Security for safety in railways, Network Security. Elsevier Ltd., Amsterdam
(2008)
3. Muthukrishnan, S.: Data Streams: Algorithms and Applications. Foundations and Trends in
Theoretical Computer Science (2005)
4. RFC 4765, The Intrusion Detection Message Exchange Format (IDMEF)(March 2007)