0% found this document useful (0 votes)
115 views12 pages

Security Validation For Data Diode With PDF

1) The document proposes security criteria and validation methods for a data diode with a restricted reverse channel to enable data reliability checks while maintaining unidirectional security. 2) It describes the implementation of a Traffic One-way System (TOS) prototype that uses disconnected cables and disabled Auto MDI-X features to ensure physical unidirectionality while integrating a reverse channel for acknowledgments. 3) The paper outlines testing conducted on the TOS prototype to validate its security according to the proposed criteria from the unit to system levels based on a V-model approach.

Uploaded by

Stephanie DM
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
115 views12 pages

Security Validation For Data Diode With PDF

1) The document proposes security criteria and validation methods for a data diode with a restricted reverse channel to enable data reliability checks while maintaining unidirectional security. 2) It describes the implementation of a Traffic One-way System (TOS) prototype that uses disconnected cables and disabled Auto MDI-X features to ensure physical unidirectionality while integrating a reverse channel for acknowledgments. 3) The paper outlines testing conducted on the TOS prototype to validate its security according to the proposed criteria from the unit to system levels based on a V-model approach.

Uploaded by

Stephanie DM
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 12

Security validation for data diode with reverse

channel

Jeong-Han Yun, Yeop Chang, Kyoung-Ho Kim, and Woonyon Kim

National Security Research Institute, Jeonmin-dong, Yuseong-gu, Daejeon, Korea


{dolgam, ranivris, lovekgh, wnkim}@nsr.re.kr

Abstract. Hardware-based data diode is a powerful security method


that removes the reverse channel for network intrusion. However, simple
removal leads to data unreliability and user inconvenience. A reverse
channel is forbidden if it affects physical unidirectionality without an
exact security analysis. If a reverse channel is used restrictively and its
security is validated, the data diode can be a secure solution. Thus, we
propose security criteria based on an application environment for a data
diode that was implemented with a reverse channel and validate the data
diode’s security by unit/integration/system testing based on our security
criteria.

Keywords: unidirectional network, data diode, security, control system,


unidirectional gateway, one-way data transfer

1 Introduction
Traditionally, SCADA systems are physically disconnected from outside net-
works to block external threat. However, the recent trend is integrating SCADA
systems into IT networks. The operation data of SCADA systems can be used
for financial purposes such as production optimization; thus securit solutions are
needed for data transmission from SCADA systems to IT networks. These solu-
tions can have different security levels depending on application characteristics
and its environment.
A unidirectional data transfer system is a network device that enables out-
going data flow, but it restricts incoming data flow for removing incoming data
lines. Its function seems similar to that of a firewall; however, a significant dif-
ference exists between two devices. Specifically, the firewall enables bidirectional
communication if it satisfies the access control list (ACL), whereas a unidirec-
tional data transfer system enables only a unidirectional data transfer although
it satisfies ACL. The unidirectional data transfer system is thus referred to as
a data diode or unidirectional security gateway owing to this characteristic. We
use the term ‘data diode’ to refer to any type of physical unidirectional network
devices in this paper.
When a firewall has a security vulnerability – such as an ACL misconfig-
uration, vulnerabilities of permitted services, or authentication bypassing – an
adversary can penetrate the network through the firewall. However, in the case
2

Fig. 1. Field-test of our data diode in a power grid system

of a data diode, the attacker cannot enter the protected area through the net-
work line because it has no route of entrance. Therefore, many SCADA security
guidelines (NIST special publication 800-82, NRC regulatory guide 5-71, IEEE
standard criteria for digital computers in safety systems of nuclear power gener-
ating stations (7-4.3.2), NEI 08-09 cyber security plan for nuclear power reactors,
and ANSSI cybersecurity for industrial control systems1 ) recommend utilities to
use data diodes for protection of SCADA systems.
In a SCADA system having critical infrastructures, some utilities use their
unique or customized protocol for data transmission. To support such protocols,
we developed data diode hardware and proxy applications to send information
from a SCADA network to a corporate network in a power grid system.
When we installed and tested our data diode in real power grid systems, as
shown in Figure 1, operators wanted to manage proxy applications and confirm
data transmission to a destination server in the corporate network. However,
because our data diode removed the physical path, operators could not check
the current status of the proxy application and the destination server. Thus data
reliability cannot be logically achieved despite our data diode experimentally
supporting a 100% success rate of data transmission between unidirectional data
paths.
The hardware-based data diode is a powerful security method that removes
the reverse physical path. In case of Figure 1, the data diode protects the control
network against all attacks from the corporate network. However, simple removal
cannot ensure data reliability and the removal forbids checking the status of data
receivers. However, if a reverse channel can be securely used, the data diode
with a reverse channel can solve these issues. To the best of our knowledge, no
systematic approach exists for security validation and verification of data diode,
which has a restricted reverse channel. We thus implemented a data diode with a
reverse channel, and we validated its security by unit/integration/system testing
based on our security criteria shown in Figure 2. The main contribution of our
1
http://www.ssi.gouv.fr/uploads/2014/01/industrial_security_WG_detailed_
measures.pdf
3

Fig. 2. TOS Implementation and validation following V-model [1]

paper is the proposal of security criteria based on an application environment


for a data diode with a reverse channel.
The remainder of this paper is organized as follows. Section 2 describes gen-
eral data diode implementations and techniques for reliable unidirectional data
transfers. Section 3 describes the design and implementation results of our traffic
one-way system (TOS) prototype product. Systematic TOS security test results
are presented in Section 4. Next, we describe a TOS field experiment conducted
for a water treatment control system and suggest suitable applications of TOS
in Section 5. Finally, Section 6 presents our conclusions.

2 Background: Data Transfer Reliability of Data Diodes

Automatic repeat request (ARQ) is a renowned strategy for guaranteeing the


reliability of communication. However, ARQ cannot be selected for data diode
because senders never know whether receivers successfully obtain the data. It is
difficult for data diode to confirm whether receive (RX) nodes soundly receive
every network packet.
Under normal conditions, the bit error rate (BER) is under 10−12 . Although
this value represents a low probability, it is nonetheless difficult to ignore during
long time. Furthermore, the possibility of packet loss caused by system perfor-
mance cannot be eliminated. In the remainder of this section, we examine the
two main techniques that are used to increase data transfer reliability and that
can be used as products.

Forward Error Correction (FEC). FEC is considered an alternative to ARQ.


Additional duplication codes are added to the original data for error recovery.
This is useful when the retransmission cost is high or inadequate. In our study,
we determined that packet loss frequently occurs in a unidirectional data path,
whereas bit errors do not. Packet loss can be considered a burst error. Inter-
leaving [2] is a good solution for packet loss recovery. However, FEC decoding
for error recovery requires considerable computing power. To develop data diode
with FEC over 1 Gbps, dedicated encoding/decoding chips are required.
4

Fig. 3. TOS architecture

Restricted reverse signals. Some vendors developed restricted reverse signal-


ing to check whether the RX node successfully received data. To avoid breaching
the unidirectionality of data diodes, these vendors devised restricted reverse sig-
naling. Hitachi and some other companies suggested a structure that has a special
electrical signal line in addition to a unidirectional data path [3]. NNSP, one of
the data diode vendors, produced an altered data diode with a special structure
to check the receiver status without an explicit physical reverse channel using an
electrical switch between transmit+ (TX+) and transmit- (TX-) lines [4] in the
RX node opens when a predefined error occurs. Then, the transmit (TX) node
detects disconnection of network line and waits until the connection returns to
normal. After the connection is restored, the TX node again transmits from the
moment of the disconnection.

3 Traffic One-way System: Physical Unidirectional Data


Transfer System with Reverse Channel

To execute real testing for security validation of reverse channels in data diodes,
we implemented a TOS(Traffic One-way System). TOS is a physical unidirec-
tional data transfer system with reverse channels for an acknowledgement mech-
anism. In this section, we introduce the internal structure of TOS and outline
the experiment conducted to assess its performance.

3.1 System Overview

TOS consists of two separate embedded systems for applying the physical uni-
directional data transfer technology. Its structure is shown in Figure 3. TOS
basically has the same architecture as a typical data diode using RJ45 Ethernet
5

(a) Appearance (b) State diagram of the TOS sender

Fig. 4. TOS

interface. We disconnected the sender’s RX cables and receiver’s transmit (TX)


cables for physical unidirectional data transfer.
However, the disconnection was not sufficient for achieving real physical uni-
directional flow on account of the Auto MDI-X2 feature of the Ethernet chip.
Auto MDI-X automatically detects the required cable connection type and elim-
inates the requirement for crossover cables to interconnect switches or for con-
necting PCs peer-to-peer; however, an attacker may change the direction of the
data channel by exchanging the TX cable for the RX cable using this feature.
Thus, we disabled the Auto MDI-X feature on each physical circuit to funda-
mentally remove the threat.
For the reverse channel, we connected digital signal generators between the
sender and receiver. To protect bidirectional communication through a reverse
channel, we installed ’real’ diodes on each digital signal line. It is impossible to
change the direction of communication through the reverse channel because of
the diodes.

3.2 Prototype Implementation


We developed a TOS prototype targeting a 100 Mbps communication environ-
ment. Figure 4a shows the appearance of the system.

Implementation. The sender and receiver were developed as an embedded


board with the same specifications. The board provides 256 MB of flash memory
and a MicroSD card slot for storage expansion based on the ARM Coretex-A8
720 MHz and RAM 256 MB. In addition, the board provides two RJ45 100
Mbps Ethernet interfaces and an RS232 interface. On each board one RJ45 100
Mbps Ethernet interface is used for the unidirectional data channel between the
sender and receiver; the other interface is used for the communication channel
for an external communication partner. The RS232 interface is used for the
management interface of each board.
The operating system is embedded Linux 3.2.0. TOS provides TCP/UDP
traffic forwarding service [5] and file transfer service. The total LOC of the
2
https://en.wikipedia.org/wiki/Medium-dependent_interface
6

Pin No. Description (System code) Pin No. Description (Error code)
1 Rx Node power-on/off 5 Storage is available
2 Rx Node network status 6 Storage is almost full
3 Feedback 7 Same file exists already
4 N packet acknowledgment 8 Reserved

Table 1. Functions of digital signal lines for a reverse channel of TOS

Fig. 5. Performance test results of TOS

application is approximately 8,500 lines in C++. Figure 4b shows the execution


states of the code following the specification and code review.

Acknowledgement mechanism using digital signal lines. One digital sig-


nal line was sufficient for only an simple acknowledgement mechanism. First,
the TOS user sets N. The receiver sends acknowledgement signal to the sender
when every N packets are normally received. If the sender does not receive the
acknowledgement signal, the sender retransmits the N packets. However, we con-
nected eight digital signal lines between the sender and receiver for convenient
management of TOS, as shown in Table 1.

Performance. We performed experiments to measure the data transfer perfor-


mance of TOS in which the acknowledgement was applied. The experiments were
repeated three times for each of the transmissions 10 MB and 100 MB under the
same conditions and the values were set to N. Figure 5 shows the experimental
results.
According to the results, the transmission rate is approximately 40∼50 Mbps
when N is 10∼50. Data reliability is always achieved when the acknowledge-
ment mechanism is applied. When the acknowledgement mechanism is not ap-
plied (No-Ack at Figure 5), transmission performance slightly increases(up to
60 Mbps) but data loss occurs inevitably. The data loss may be overcome by
7

system tuning, such as in the receiving buffer performance; nevertheless, it can


not be a fundamental solution to the data loss.

4 Security Testing of TOS

We then confirmed that TOS does not allow reverse data transmission, although
TOS was attacked at the external network connected to the TOS receiver. Our
validation process followed the V-model, as shown in Figure 2, with a unit test,
integration test, and system test. To ensure due diligence in the objectivity of
the verification tests, all processes were carried out by external specialists3 to
test the equipment of the control system and infrastructure.

4.1 Attack Assumption

Our assumptions about attackers are outlined below.

– Assumption 1: The attacker cannot physically access TOS.


– Assumption 2: The attacker can access to the TOS receiver over the network.
– Assumption 3: The attacker can take control of the TOS receiver.

TOS was installed in the internal network of the control system and in-
frastructures to block intrusion form the external network. If the attacker can
physically access TOS, the attacker can alter all aspects of TOS. Thus, we as-
sumed that the attacker cannot have direct physical access, and we only focused
on attacks against TOS from an external network. Aside from the physical ac-
cess, we considered all of possibilities of attacks against TOS as Assumptions 2
and 3.

4.2 Validation Requirements

TOS is a physical one-way system for applying the acknowledgement mechanism


using a reverse channel. Each channel ensures uni-directionality. Specifically, a
disabled Auto MDI-X forbids reverse data transmission through the data chan-
nel, and diodes-installed on the reverse channel cannot send forward signals from
the sender to the receiver. The attacker cannot send data from the receiver to
the sender through the TOS data channel.
To validate the safety of TOS, we have to check the possibility of attack
through the reverse channel, which is the only path that could enable an at-
tacker to send data or command in the reverse direction. Thus, requirements for
validating the security statement in this paper are organized as follows.

– Requirement 1 (data): When the sender receives information from the TOS
reverse channel, the sender does not store the information in the files.
3
TestMidas co., Ltd. (http://www.testmidas.com)
8

– Requirement 2 (command): Although any information is sent through the


TOS reverse channel, the sender performs only the functions defined in Sec-
tion 3.2.

Because we assume that the attacker can assume control of the receiver as
Assumption 3, it is necessary to ensure the security of TOS in a situation in
which an attacker can arbitrarily modify the receiver. Thus, all verifications
performed for TOS consisted of an original sender and an arbitrary receiver that
is transformed by the attack.

4.3 Unit Testing


Unit testing is a software testing method by which various parts–individual units
(or functions) of source code, sets of one or more computer program modules to-
gether with associated control data, usage procedures, and operating procedures–
are tested to determine whether they are fit for use4 . For unit testing, we per-
formed dynamic tests for all functions in the source code of the sender to validate
that each function of the sender satisfies Requirements 1 and 2.
We used a unit testing tool, CodeScrollT M Controller T ester5 . Based on
statements and branch coverage, we generated 1,060 test cases for 141 sender
functions. No test results violated Requirement 1 or 2. The generated test cases
covered 98.90% of statements and 97.19% of branches. The test cases did not
cover all statements and branches because dead codes remained to be generated
during development.

4.4 Integration Testing


Integration testing (also called integration and testing) is the phase in software
testing in which individual software modules are combined and tested as a group.
It employs for input the modules that were unit-tested, groups them in larger ag-
gregates, applies tests defined in an integration testing plan to those aggregates,
and delivers as its output the integrated system that is prepared for system test-
ing6 . To proceed with integration testing based on Requirements 1 and 2, we
generated and executed 314 test cases using CodeScrollT M Controller T ester.
No test results violated Requirements 1 and 2. The generated test cases covered
96.70% of all function calls. The test cases did not cover all function calls because
some unnecessary functions comprise impossible exception cases.

4.5 System Test


System testing of software or hardware is conducted on a complete, integrated
system to evaluate the system’s compliance with specified requirements7 . To
4
https://en.wikipedia.org/wiki/Unit_testing
5
http://www.suresofttech.com/products/controller-tester/
6
https://en.wikipedia.org/wiki/Integration_testing
7
https://en.wikipedia.org/wiki/System_testing
9

Fig. 6. System testing environment

perform system testing using TOS, we built a test environment, as shown in


Figure 6.
Following Assumption 3, the receiver can be attacked. For the system testing,
the test case executor simulated all actions of an attacked receiver. A system
status snapshot tool recorded the states of the processes and the file system of
the TOS sender. Using the records, we checked the difference between states
before and after testing on the sender. To track the flow of information carried
in the digital signal of the sender, we checked the source code processing in
the line when a signal occurred at all locations (14 locations). To this end, we
modified source code to record the flow. The current I-node tree, transformed
I-note list, and the current disk capacity involved to record the snapshot to check
for changes in the physical disk information. We recreated the situation in which
the sender traffic continues to flow in order to proceed with the test.

Test case generation. Based on our assumptions about attacks, the reverse
channel comprised of eight digital signal lines is the only way for an attack.
In the source code, the receiver sends only 0 or 1 through each digital signal
line. However, if the receiver is attacked as in Assumption 3, the receiver sends
any value; i.e., infinite cases. For efficient tests, we used eight inputs for each
input case: 0, 1, negative number, negative large number (for checking overflow),
positive number, positive large number (for checking overflow), Unicode, and
ASCII code. To cover all possible combination cases of eight digital signal lines,
we required 88 (16,777,216) test cases. It is practically impossible to test the
all test cases. Thus, we selected 95 test cases to use the pairwise technique [6].
Pairwise (a.k.a. all-pairs) testing is an effective test case generation technique
that is based on the observation that most faults are caused by interactions of at
most two factors. Pairwise-generated test suites cover all combinations of two;
therefore, they are much smaller than exhaustive ones while being very effective
in finding defects.
We reviewed the source code of the sender. The test case execution order of
the sender did not affect the current results of the test. Figure 4b represents the
state transition of the sender during execution. If we performed all test cases
10

for the six states in Figure 4b, we could have covered all possible cases of the
sender. The total number of test cases was 570 (= 95 (number of possible digital
signal line inputs) × 6 (state number)).

Testing result. The testing procedure is outlined below:

– 1. Setting the status of the sender


– 2. Saving the snapshot the initial status of the sender
– 3. Executing a test case
– 4. Saving a snapshot the final status of the sender
– 5. Comparing the initial and final snapshots

We performed a total of 570 tests. No result violated Requirement 1 or 2.


During the tests, we identified a software bug of the sender; i.e., the four test cases
killed the sender processes. However, this bug cannot cause security problem
related to Requirement 1 or 2. For stress testing, we performed random testing
of TOS in the test environment over three days. Once again, no result violated
Requirement 1 or 2. Thus, we conclude that the reverse channel does not cause
security problems related to Requirement 1 or 2.

5 Applications

If a reverse channel can be securely used, the data diode with a reverse channel
can provide a more secure method for data flow control than software-based
security solutions as shown in Figure 7.

5.1 Field Experiment: Safe Usages of USB Memory Stick

The control system operator should occasionally move monitoring information


files of a control system to business network for several reasons. Portable storage
(e.g. an USB memory stick) is a convenient utility to move the files. To safely
use portable storage, we usually install media control solutions. However, these
solutions cannot be installed on some specific devices and servers in the control
systems.
We thus built a system that safely downloads internal files on portable storage
using TOS. The entire structure is shown in Figure 7a. Files are sent to the
download PC through TOS. At the PC users can download the files into portable
storage. Although the download PC may be compromised, the negative effect
cannot be propagated in the control network on account of TOS. We installed
this system on two sites in October 2015 and ran it for more than eight months.
Field operators gave the system a good rate because it conveniently enhances
security.
11

5.2 Suggestion
The application shown in Figure 7b is similar to those in Figure 7a. A traffic
message control server can safely send data to end systems through TOS. TOS
directs data flow and blocks all reverse data transmission. If necessary, TOS
can allow limited requests and status checking of end systems using the reverse
channel. Although one of end system is compromised, it cannot attack the central
server and compromise other end systems. In a similar manner TOS can be
applied to a patch management system.
TOS can be applied for security enhancement of data receivers, as shown in
Figure 7c and Figure 7d. TOS blocks data leak from log server in Figure 7c.
Using the reverse channel, a system manager can remotely check the status of a
log server. In case of Figure 7d, CCTV control server can safely gather security
information and send limited orders to CCTV devices using the reverse channel.
Although an attacker can control one unprotected CCTV device, the attacker
cannot connect and steal information from other systems.

6 Conclusion
In this paper, we proposed security criteria based on an application environment
for a data diode with a reverse channel. We implemented a data diode with
a reverse channel using digital signal lines, and we validated its security by
unit/integration/system testing based on our security criteria. Our research can
be a starting point for expanding application areas of the data diode for security
enhancement.

References
1. K. Forsberg and H. Mooz, “The Relationship of System Engineering to the Project
Cycle”, Proceedings of the First Annual Symposium of National Council on System
Engineering, 57-65, October (1991)
2. J. Cai, C. Chen. “FEC-based video streaming over packet loss networks with pre-
interleaving,” Proceeding of International Conference on Information Technology:
Coding and Computing, 10–14 (2001)
3. Y. Namioka and T. Miyao. “Data communication method and information pro-
cessing apparatus for acknowledging signal reception by using low-layer protocol,”
Hitachi, Ltd., U.S. Patent 20060026292 A1, Feb 2 (2006)
4. K. Kim, E. Na, and I. Kim. “Gateway device of physically unidirectional communi-
cation capable of re-transmitting data, as single device, and method of transferring
data using the same,” NNSP, Korea Patent 1015623120000, October 15 (2015)
5. K. Kim, Y. Chang, H. Kim, J. Yun, and W. Kim. “Reply-Type based Agent Gen-
eration of Legacy Service on One-way data transfer system”, KIISC, vol. 23, no. 2,
299–305 (2013)
6. D. R. Wallace and D. R. Kuhn. “Failure Modes in Medical Device Software: an
Analysis of 15 Years of Recall Data”, International Journal of Reliability, Quality
and Safety Engineering, vol. 8, no. 4 (2001)
12

(a) File download into a portable storage through TOS

(b) Variable message sign (VMS) System

(c) Logging system

(d) CCTV monitoring system

Fig. 7. Applications of TOS

You might also like