2018 57th Annual Conference of the

Society of Instrument and Control Engineers of Japan (SICE).

September 11-14, 2018, Nara, Japan

Cyber Threat Information Sharing System for Industrial Control System (ICS)
Shingo Abe1, 2†, Yukako Uchida1, Mitsutaka Hori1, Yuichiro Hiraoka1 and Shinichi Horata1
1
ICS security Response Group, JPCERT/CC, Tokyo, Japan
(Tel: +81-3-3518-4600; E-mail: icsr@jpcert.or.jp)
2
Nagoya Institute of Technology, Nagoya, Japan
(Tel: +81-52-735-7177; E-mail: s.abe.562@stn.nitech.ac.jp)

Abstract: In pursuit of enhanced cyber security capability in the whole industry, an information sharing scheme for
ICS-related security information is sought after. It is suggested that exchanging cyber threat information described in a
specific machine-readable format can partly automate the security measure processes and eventually lighten the
workload of technical personnel. This will also enable information sharing across the sector and accordingly the
effective implementation of security measures (detect infection, block suspicious communication etc.) in an early stage.
This paper proposes a system to share cyber threat information with a wide range of organisations and format of the data
to be exchanged through the system.

Keywords: ICS Security, Information Sharing, STIX Format

1. INTRODUCTION developed Traceback Honeypot System (THS) [6] with

As cyber security draws public attention, many
companies and industries are urged to establish structure
for defending itself from cyber attacks. For instance,
launching Computer Security Incident Response Team
(CSIRT) and hiring cyber security experts has become a
common approach. Developing and maintaining cyber
security human resource is one of the challenges
whether it be IT (Information Technology) or OT
(Operational Technology). In particular, it is often
difficult to secure adequate personnel who is capable of
analysing cyber threats and security information and
implement appropriate security measures. Similarly, in
ICS (Industrial Control System) security, while
interconnectivity of ICS devices has been largely
increasing, the challenge in vulnerability handling and
secure implementation is being concerned. Human
resource to confront such issues is highly in demand for
ICS as well [1].
In preventing cyber attacks against information
systems, cyber threat intelligence has often been utilised.
This is based on attack indicator information shared
from other organisations and used for detecting
infection and blocking communication to/from
malicious hosts. Especially, US-CERT (United States
Computer Emergency Readiness Team) has initiated
“Automated Indicator Sharing (AIS)” project [2], where
indicators are distributed to participants in a
machine-readable format so that security measures can
be taken smoothly. On the other hand, in ICS area, there
are some guidelines provided by ICS-CERT (The
Industrial Control Systems Cyber Emergency Response
Team) [3] and NIST (National Institute of Standards and
Technology) [4], but no such a systemised and common
framework for indicator sharing.
As ICS-CERT points out, log analysis is not widely
practiced in the context of ICS security [5]. JPCERT/CC
an aim to detect cyber attacks mechanically and
determine the cause of incident in a smooth manner
without having to conduct deep log analysis.
In the previous research, we suggested that placing
THS in ICS network to detect incidents at an early stage
is one of the effective security measures without
affecting other system structure or operations. However,
given that an attack is recognised mechanically, it is also
necessary to formulate what action needs to be taken in
what circumstances, and what kind of notification
should be sent for the use of technical personnel. In
information systems, cyber threat observation using
honeypots have been conducted [7]. For example,
honeypots are placed in several different networks in an
organisation and observe scan packets at certain
domains to analyse trends of scanning activities. This
observation allows identifying vulnerabilities leveraged
for attacks or IP address of the attack origin, which will
be a basis for security measures. In contrast, THS is not
exposed onto the Internet but rather connected to closed
networks for ICS and related devices. While Honeypot
is designed to observe scans and suspicious activities on
the Internet, THS has focus on capturing traces of
attackers who have already intruded into a network.
Unless there is an attack against the THS itself, it
remains inactive. Besides cyber attacks, if there is
misconfiguration on a device in the same network,
unwanted packets may be sent to THS. When THS
reacts, it suggests that there is an ongoing device issue
or intrusion, and some measures to address the issue
(review configuration or implement security measures)
needs to be in place. Therefore, compared to honeypot
as a means to observe indications of a potential cyber
attack, THS can serve for detecting ongoing attacks
against ICS.

978-4-907764-60-9 PR0001/18 ¥400 © 2018 SICE 374

 In detecting incidents using THS, it is important for
technical personnel to immediately recognise the
anomaly that THS has observed. However, since logs
retained at THS contain technical information such as IP
addresses, ports and packet details, it requires
interpretation by analysts who have expertise in network
structure and regular communication in order to
determine the threat. In this research, we will discuss a
system which enables automatic processing of
information obtained from THS and sends notifications
to factory personnel so that the anomaly can be
recognised. If THS is operated in several organisations,
attack information observed by a THS can also be
valuable in preventing similar incidents in other
organisations. We will also explain about an early
warning network model based on indicator information
obtained through THS.
Section 2 will discuss the details of the proposed early
warning network model using THS. Section 3 will
present the framework for sharing information in a
secure manner and automated control of THS and the
early warning network.
2. MECHANISM FOR INFORMATION
SHARING FOR ICS
2.1. Use of THS in Early Warning System
THS serves both as a honeypot that imitates
responses from other network-connected devices and as
a scanner to collect information about the source and
cause of the attack packet. THS has the following two
major functions:
1) Honeypot function group
Imitates responses of a device existing in the same
network. Capable of responding to specific commands
and observing attack packets without being noticed by
an attacker.
2) Scanner function group
Conduct counter-scan upon receiving access from a host.
Collects detailed information of the host by
communicating via specific protocols (e.g. SNMP),
logging on to the source device and syncing with asset
management software.
Observations of attack traces by placing honeypot on
the Internet has been practised so far. The scanner
function is also used for managing and monitoring
devices connected to the network, which is applied in
Network Management Systems as an instance.
Combining these two techniques, THS can be suggested
as a means for network monitoring. Once an attacker
has intruded into a network and as they compromise
across the network, they may also access THS without
knowing. This triggers THS reaction to conduct
counter-scan and collect information of the source
device. The fact that THS has detected an anomaly
suggests that unwanted communication may be taking
place, which could be caused by improperly-configured
375
devices or attackers making lateral movement. There is
a preceding research on anomaly detection method
where a honeypot is combined with machine learning so
that it learns patterns of malicious communication [8].
In this way, recognising such anomaly communication
at an initial stage is a crucial step in dealing with cyber
attacks. Even if the suspicious communication is caused
by misconfiguration, it should be rectified soon as this
may result in system failure or unwanted behaviour.
2.2. Sharing Indicator of Compromise (IoC) Using
THS
In case where the malicious communication detected
by the THS is originated in cyber attacks, this means
that the attackers have already reached the network
where the THS is implemented. If any computers or
devices used as a stepping stone are identified through
the THS’s scanning function, immediate measures can
be taken to stop the malicious activity. Furthermore,
through the analysis of the communication of the
stepping stone devices and malicious files, it may be
possible to reveal a whole picture of the attack activity.
In sophisticated cyber attacks, attackers often spread
infection of remote-control malware and take control
over multiple devices via Command and Control (C&C)
servers. If there is any information from other
organisations on the malware or details of
communication to C&C servers, these can be compared
against the access logs from the network in order to
investigate how far in the network the attackers have
compromised. In minimising the damage by
sophisticated cyber attacks, it is necessary to estimate
the affected areas at the earliest and contain it at once. If
the issue is not addressed thoroughly, attackers may
figure out levels of the security measures, which may
result in additional backdoors being set up by leveraging
remaining loophole. In another case, attackers may
pretend to stop the attack temporarily and revisit later to
compromise the network.
Even in the case of information stealing malware,
C&C server addresses and domains are also considered
useful in determining infected devices effectively. Some
types of malware are customised to better suit each
attack target or avoid being detected by anti-virus
software, which makes it difficult to detect solely by the
signature pattern matching. As a protection measure for
cyber attacks against information systems, it is
becoming common to detect infected devices by
searching for communication with C&C servers that are
already identified. These kinds of information which
can be a clue in detecting cyber attacks is called
“Indicators of Compromise (IoC)”. IoC is often shared
through information sharing platforms in different
channels. It may help grasping the whole picture of the
entire attack activity by analysing together with other
IoC from various sources. In the United States,
US-CERT promotes a framework to distribute IoC to
critical infrastructure in a machine-readable format for
early warning and detection (AIS). Structured Threat
Information eXpression (STIX) [9] is the description
format of IoC which is applied in AIS, and this contains
a column for Tactics, Techniques and Procedures (TTPs)
of the attack. THS receives attack packets attempting to
conduct scan or lateral movement, which contains traces
of attack method. After sanitising, such payload
obtained by THS can be utilised as IoC. By referring to
the observations, other organisations can detect similar
attack activities on their THS by searching for
suspicious communications in the log or reconfiguring
rules for the THS.
2.3. Integration and Analysis of Information
Collected by THS
Generally, ICS devices are often implemented on a
control system network apart from information network.
In some cases, Ethernet is used for control network for
ICS devices. In large-scale networks, each branch,
factory or even system may be divided into different
network segments, each of which may also be protected
by firewall. If a THS is implemented in each network
segment or layer, it would be possible to detect how far
the network has been compromised. For this reason, it is
recommended that multiple THS should be installed in a
single organisation for effective detection of threats and
form Integrated Management System (IMS), which
integrates and analyses information gathered from each
THS.
If THS is distributed widely in a single organisation,
it is unrealistic to collect and examine information from
all of them. Instead, it is rather practical that IMS
gathers the information centrally from all THS and
notifies the administrator as necessary. If the
notification can be sent to a wider range of partners,
other administrators can also prepare to detect similar
cyber threats. For this purpose, administrators need to
change the configuration of THS to detect specific
threats. More precisely, THS configuration needs to be
dynamically changed according to IMS’s notification.
In this regard, IMS should be able to collect information
from THS, control THS’s operation and its
configuration.
Threat details from IMS have potential for more
detailed analysis if combined with other information
collected by Firewall and Network Switch. Logs
obtained in these devices are often managed and
analysed by log management system which has a
Security Information and Event Management (SIEM)
function. If IMS has a SIEM function or syncs with the
existing SIEM for log analysis, events on a network can
be investigated effectively.
2.4. Threat Information Sharing among
Organisations
As discussed earlier, IMS gathers information from
THS in each network segment. This includes not only
malicious payload from attackers but also configuration
errors, which is not always necessary to share. Sharing
376
information from IMS without processing may expose
non-related information or organisation-specific
information (ID, password, device parameter etc.). For
the scheme of information sharing, we propose “ICS
Early Warning Management System (ICSEWM)”,
which is a system to 1) integrate information stored in
multiple IMS, 2) analysing the threat details and 3)
feedback the processed IoC to each IMS. In this system,
only cyber threats need to be extracted out of collected
data, and ideally this process is expected to be
conducted by analysts who has considerable knowledge
in cyber attacks. However, it is challenging to assign
highly-skilled cyber security analysts in every branch or
factory. Therefore, it is practical to open ICSEWM to
the company headquarters or mutual organisations (e.g.
industry group, Information Sharing and Analysis
Centre – ISAC, National CSIRT) for initial processing,
and then distribute the information to each organisation.
With this approach, ICSEWM is expected to integrate a
wide range of information which can be actionable for
cyber threat mitigation. In sophisticated cyber attacks,
some specific sectors are often targeted. For example,
according to the alert issued by US-CERT, some critical
infrastructure sectors had been affected in a campaign
“dragonfly 2.0” [10] [11]. If the threat information can
be shared from the first affected organisation, other
partners can also implement preventive measures, and
the potential damage in the whole industry could be
minimised.
2.5. Format for Shared Information
In order to mutually exchange information among
ICSEWM, IMS and THS, there is a need to define a
common format and protocol for communication. While
THS is a light application which can be built up with
generic Linux box such as Raspberry Pi, IMS and
ICSEWM run on a server. Thus, client-server model as
applied in information system would be suitable. As
discussed in Section 2.1, STIX has been widely used as
a format for describing different aspect of cyber threats.
For information exchange in STIX format, Trusted
Automated eXchange of Indicator Information (TAXII)
protocol has been used. Given that IMS and ICSEWM
also serve as a TAXII server, they can also exchange
STIX-based information. Most SIEM products are now
compatible with STIX format. By enabling STIX-based
information exchange between IMS and SIEM, it would
be possible to effectively analyse IoC for information
system such as identify packets from malware-infected
devices and C&C servers. Likewise, by enabling
STIX-based information sharing between IMS and THS,
the whole ICSEWM would communicate in a single
description format. The overview of this proposed
system will be explained further in Section 3.2.
 Figure 1 Overview of the system architecture
3. IMPLEMENTATION OF EARLY
WARING NETWORK
3.1. Components of Each System
This section will describe functions that are necessary
for THS, ISM and ICSEWM. The overview of the
system architecture is described in Figure 1.
THS
In addition to honeypot and scanner function, THS
needs to have a function to send information to IMS and
change its configuration based on the information from
IMS. Here below is the THS function details:
1) Honeypot function
Imitates response of a device existing in the same
network. Capable of responding to specific commands
and observing attacks without being noticed by an
attacker.
2) Scanner function
Conduct counter-scan when receiving access from a
host and identify the source.
3) IMS reporting function
Send information gathered by the above function to IMS
in STIX format.
4) Remote reconfiguration
Receive STIX-format threat information from IMS and
reconstruct honeypot configuration
The difference from the preceding research is that
THS’s function is extended with 3) and 4) features. We
used an open source STIX library for programming and
377
implementation.
IMS
IMS serves as a TAXII server and controls THS. Here
below is the IMS function details:
1) TAXII server function
Receive and store STIX-formatted information sent
from THS and ICSEWM.
2) Control THS operation
Control THS and receive reports from THS in their
network.
3) Convert into STIX format
Remove organisation-specific information (e.g. ID,
password, set value) from the report from THS, and
convert to STIX format.
4) Notification to administrators
Determine threat level based on the reports from THS
and notify the administrators. We used ElasticSearch as
a database server and implemented using STIX library.
ICSEWM
ICSEWM serves as a TAXII server and to exchange
messages with IMS for analysis. Here below is the
ICSEWM functions in detail.
1) TAXII server function
Receive and store STIX-formatted information from
IMS.
2) SIEM function
Analyse information sent from IMS.
3) IoC distribution
Distribute the processed information (IoC) to each IMS.
4) IoC management
Create and manage IoC for distribution.
We used ElasticSearch as a database server and
implemented using STIX library.
3.2. Example of Data for Sharing
As one of the examples of the data to be shared using
the ICSEWM, we explain an example of report message
which will be sent to IMS about malicious activities
caused by “HavexRAT” [12], which was also introduced
in our preceding study. We assume that a device on ICS
network is infected with HavexRAT and sends scan
packets to the network which also reaches THS, which
triggers a report to IMS.
In this system, the message is communicated in STIX
format (v.1). This structure consists of the following 8
elements: Campaigns, Threat Actors, TTPs, Indicators,
Observables, Incidents, Courses Of Action and Exploit
Targets. Information collected from THS can be
described in Observables, Incidents or Indicators section.
Furthermore, THS configurations required for detecting
a specific threat (types of machine that THS needs to
imitate, port number for communication) provided from
IMS can be specified in “Targeted Systems” defined in
TTP. However, some of the information required for
THS configuration does not fit in the existing STIX
format. These can be inserted in description element for
each column, or there may be a need to redefine a new
STIX format especially for ICS. In the conference
presentation, we would like to discuss the potential and
extended STIX format in detail.
An example of the information is described in Figure
2. In the below message, organisation-specific
information has been already removed and converted
into a specific format. Referring to STIX, we have
developed a light and simple format for describing
cyber threats.
<campaigns>
<campaigns:name>Havex Scans</campaigns:name>
<incidents>
<category>Scans</category>
<effect>Theft of Proprietary Information</effect>
</incidents>
<ttps>
<targetSystem>OPC Server</targetSystem>
</ttps>
<descriptions>
<sourceIp>192.168.XXX.XXX</sourceIp>
<targetPort>102,502,11234,12401,44818</targetPort>
</descriptions>
</campaigns>
Figure 2 Simple format for describing cyber threats
Based on the information, IMS sends a threat report to
ICSEWM. ICSEWM creates IoC and sends it to other
IMS. The IMS which received this information analyses
378
logs in comparison to the IoC and notifies the
administrators if there is any match. If any change is
required to THS configuration to detect a specific threat,
IMS reconstructs it. In this system, organisation-specific
information will not be shared with other partners and
only threat information is shared.
4. FUTURE CHALLENGES AND
CONSIDERATIONS
In actually implementing the proposed information
sharing scheme, the following challenges need to be
considered.
z THS’s emulation function
In order for THS to deceive attackers and observe
attack activities in a prolonged period, it needs to be
capable of sending precise response to various
commands and via different protocols. The preceding
research only focuses on a particular protocol and
commands. There is a need to increase the compatibility
with other protocols and commands used in ICS
devices.
z Anomaly detection
There is a preceding study which applies machine
learning for detecting anomaly. However, it does not
cover the all the types of anomalies originated in cyber
attacks and false detection is still possible. Efforts need
to be made to develop detection method for different
kinds of cyber attacks and reducing false detection rate.
z Anomaly notification
It is difficult for factory personnel to analyse and
address all the cyber security related issues. In addition
to turning on warning lights upon anomaly detection,
we need to discuss what kind of information needs to be
provided to encourage smooth actions.
z STIX format for ICS
Use of STIX format for threat information exchange
will expand, however, its increasing data size is one of
the common challenges. There is a room for discussion
on a new STIX format which is lighter and has higher
compatibility with different systems.
z Framework for information sharing
The ICS community in Japan is a generally closed
community and there is not much information exchange
opportunity within the sector. Awareness raising
activities should be provided to enhance information
sharing in the sector.
5. CONCLUSION
We have explained an example of ICS-related
information exchange among multiple organisations
using STIX format. Linking THS, IMS and ICSEWM
using STIX format data leads to minimise the demand
for skilled technicians for threat analysis and realise
smooth threat information sharing among organisations
and factories. Shared threat information can be https://www.fsecure.com/weblog/archives/00002718.ht
processed automatically, and notifications will be sent to ml, F-Secure, 2014.
administrators. From the notification, it is expected that
security measures are taken accordingly in each
recipient organisation. This automated process is
expected to reduce the workload of technical personnel.
With an aim to improve ICS security, we will keep its
effort to address the issues.

REFERENCES
[1] S. Abe, M. Fujimoto, S. Horata, Y. Uchida and T.
Mitsunaga, “Security Threats of Internet-reachable ICS”,
Conference Proceedings of 2016 55th Annual
Conference, Society of Instrument and Control
Engineers of Japan, 2016.
[2] US-CERT, “Automated Indicator Sharing (AIS)”,
https://www.us-cert.gov/ais, US-CERT.
[3] ICS-CERT, “Training Available Through
ICS-CERT”,
https://ics-cert.us-cert.gov/Training-Available-Through-
ICS-CERT.
[4] K. Stouffer, V. Pillitteri, S. Lightman, Mabrams and
A. Hahn, “Guide to Industrial Control Systems (ICS)
Security”, NIST Special Publication 800-82r2,
https://nvlpubs.nist.gov/nistpubs/specialpublications/nist
.sp.800-82r2.pdf, NIST, 2015.
[5] ICS-CERT, 䯔 ICS-CERT Monitor March 2012 䯕 ,
https://ics-cert.us-cert.gov/sites/default/files/Monitors/I
CS-CERT_Monitor_Mar2012.pdf, ICS-CERT, 2012.
[6] S. Abe, Y. Tanaka, Y. Uchida and S. Horata, “Track
Attack Sources based on Traceback Honeypot for ICS
Network”, Conference Proceedings of 2017 56th
Annual Conference, Society of Instrument and Control
Engineers of Japan, 2017.
[7] K. Wilhoit and S. Hilt, “The GasPot Experiment:
Unexamined Perils in Using Gas-Tank-Monitoring
Systems”,
https://www.trendmicro.de/cloud-content/us/pdfs/securit
yintelligence/white-papers/wp_the_gaspot_experiment.
pdf, Trend Micro, 2015.
[8] A. Terai, S. Abe, S. Kojima, Y. Takano and I.
Koshijima, “Cyber-Attack Detection for Industrial
Control System Monitoring with Support Vector
Machine based on Communication Profile”, S4CIP'17,
2017.
[9] MITRE Corporation, “Structured Threat Information
eXpression (STIX^TM) 1.x Archive Website”,
https://stixproject.github.io/, 2017.
[10] US-CERT, “Alert (TA17-293A) Advanced
Persistent Threat Activity Targeting Energy and Other
Critical Infrastructure Sectors”,
https://www.us-cert.gov/ncas/alerts/TA17-293A,
US-CERT.
[11] US-CERT, “Alert (TA18-074A) Russian
Government Cyber Activity Targeting Energy and Other
Critical Infrastructure Sectors”,
https://www.us-cert.gov/ncas/alerts/TA18-074A,
US-CERT.
[12] D. Hentunen and A. Tikkanen, “Havex Hunts For
ICS/SCADA Systems”,

379