Technology explained

The DataDiode explained

in 5 simple steps
E-book by
dr. Wouter Teepe, for Fox-IT
and Colin Robbins, for Nexor

fox-it.com/datadiode
 Introduction
When protecting an isolated network against outsider attacks, there are a number of
objectives and technologies that are commonly used. Objectives typically boil down
to C.I.A.: confidentiality, integrity and availability. The best possible technology for
confidentiality is the unidirectional network connection by means of a DataDiode.
However, there is a lot of technology relating to DataDiodes that impacts integrity and
availability. In particular, protocol breaks and content checking have a subtle relation to
these objectives. This briefing paper will explain how these technologies relate to one
another and to the principal C.I.A. security objectives.

This paper focuses on situations where confidentiality

has priority over integrity, where ‘protecting secrets’
(Figure 1) is essential. DataDiodes can also be deployed for
‘protecting assets’ (Figure 2), where integrity is essential
and confidentiality is of secondary priority, typically when
protecting industrial installations. For the sake of clarity, we
will focus on the ‘protecting secrets’ scenarios in this paper.

Protecting secrets Secure environment

information classified information
internet may get in

Upstream Downstream

secrets may disclosure

Figure 1: the protecting secrets scenario not leak can lead to disaster

Protecting assets Secure environment

no external critical processes
internet interference

Downstream Upstream

status information manipulation

may get out can lead to disaster

Figure 2: the protecting assets scenario

2 | Fox-IT | Protecting confidential information using DataDiodes

1. Unidirectional network
connections
A unidirectional network connection is a link between Creating a unidirectional network connection does not
two networks for which it can be guaranteed that the prevent all methods of data leakage.
information only flows from the one network to the 1. If there is another network connection between
other, and not in the other direction. The source network the upstream and downstream network next to the
is typically referred to as ‘upstream’ and the destination DataDiode, data can be exfiltrated by means of the
network as ‘downstream’. A typical scenario is where the other network connection.
downstream network contains highly classified information 2. If it is possible on the downstream network to store
which should not be leaked to the outside world, while the information on portable storage media such as USB
upstream network is directly or indirectly linked to that sticks, this media can be physically exfiltrated and as
outside world. In this scenario, the unidirectional network such provide a means for data leakage. Controls are
connection is ‘protecting secrets’. The unidirectional needed to prevent people from using such media.
network connection prevents ‘data leakage’ or ‘data Controls may vary from technical controls such as
exfiltration’ from the downstream network. disabling USB ports to procedural controls such as
complete prohibition of portable media. When a
However, confidentiality may not be the only protection DataDiode is deployed, the operational benefit of
objective of the downstream network. Due to the uni- using such media decreases so much that it is possible
directional network connection, data cannot come out of to impose strict business policies on portable media
the downstream network, but the data flowing into the use without a major business impact. Without a
downstream network may still cause harm. The data could DataDiode, a strict portable media policy would lead
‘attack’ the downstream network. to highly impractical situations.
3. A DataDiode does not prevent people from printing
A unidirectional network connection is often implemented documents and carrying them to places where they
and enforced using a network device called a DataDiode, should not end up, or from reading documents and
as described in this paper, supported by specialist security telling the contents to people who are not allowed to
software. know it.

Fox-IT | Protecting confidential information using DataDiodes | 3

 2. Attacking the downstream
network
Computer security attacks come in many forms; a common This is almost where the protocol break enters the arena.
method of attack is to get a computer to behave in a However, let us first look closely at the information flowing
way not considered by the designers and seek to take into the downstream network.
advantage of that. Modifying protocols, for example, to
send information that is non-compliant to the protocol is In general, this data can be divided into payload data and
one way of inducing errors in a poorly designed system. traffic control data. The payload data contains the data
that the sender wants to send to the downstream network.
A common example of this kind of attack is the buffer For example, this may be a file, an email or a print job. This
overflow1. Buffer overflows can occur at any layer in payload data is essentially static: the message that is sent
the protocol stack – from the network interface to the should be the same as the message that is delivered (later
application. Buffer overflow vulnerabilities have been seen in the paper we discuss some security reasons why the
in all kinds of places, ranging from PDF files2 to network message may be deliberately transformed into something
cards3. else). The payload may also contain complex types with
multiple files embedded such as ZIP and MIME formats.
So, when letting data onto a downstream network, the
network may be exposed to attacks which are embedded
into the information flowing onto that network, even if
Traffic
the information flow is one way. A DataDiode makes Control
sure that such an attack cannot lead to data leakage – Data
Payload
even if the attackers manage to establish a command-and-
control server, the server will not be able to communicate
back via the DataDiode. However, availability and Figure 3: data send using a protocol

integrity of the downstream network are potentially still

at risk.

1 https://en.wikipedia.org/wiki/Buffer_overflow
2 http://resources.infosecinstitute.com/hacking-pdf-part-2/
3 http://theinvisiblethings.blogspot.co.uk/2010/04/remotely-attacking network-cards-or-why.html
4 | Fox-IT | Protecting confidential information using DataDiodes
3. Protocol
To deliver the payload, a protocol is used. A protocol is a In the ‘protecting secrets’ scenario it can generally be
set of communication agreements, which ensure that if assumed that the attacker has access to the upstream
both sides of a communication channel adhere to it, the network. From the upstream network, the attacker could
payload gets delivered correctly. To achieve its design attack the downstream network by abusing a design flaw
objectives, a protocol introduces extra data into the data in one of the systems on the downstream network.
flow to coordinate these protocol specific goals: traffic
control data. A protocol takes care of many things that a A unidirectional network connection prevents such an
normal computer user is never aware of: that the payload attack from leading to data leakage. The attack may still
gets routed in the right direction; that it is chopped into cause harm in terms of integrity and availability on the
parts where needed and reassembled again where possible. downstream network. A protocol break effectively cuts out
Protocols may do very complicated things like compression, attack vectors which live in the traffic control data, as will be
tunneling, load balancing, authentication, caching, spooling, discussed next.
all kinds of things to make the communication go smoothly.
Examples include FTP, SMTP and HTTP.

All this complexity which goes into these protocols makes

the system work, but only under the condition that both
sides are cooperative. An attacker may take the liberty
not to be cooperative and send malformed traffic control
data. This can cause a buffer overflow or other fault in the
receiving system, and with it launch a successful attack.
Heartbleed4 was an example of this where the attacker
chose not to be cooperative by misinforming the protocol
about the size of the payload.

4 http://heartbleed.com

Fox-IT | Protecting confidential information using DataDiodes | 5

 3.1 Protocol Break
The attacks that can be caused by one of the parties Protocol Break in action
not adhering to a protocol can only be prevented by
making sure that in the environment where attacks are What does the complete chain look like?
not acceptable, both parties in the protocol are trusted. 1. System A wants to send a message to system B.
For unidirectional communication scenarios, that means 2. The traffic from A towards B is routed to C, the
that the side sending the payload (upstream) should be catcher. System A may believe it is talking to
trustworthy, at least from the perspective of the receiver system B, but in fact it is talking to a catcher,
(downstream). The only way to ensure this is by the which acts as a proxy for system B. Systems A
application of a protocol break. and C exchange data via means of a protocol.
They exchange both traffic control data and
A protocol break consists of two components that sit payload data.
between the sender and the receiver of a message. The first 3. System C distils a payload and provides this
one is a ‘catcher’, which, while adhering to the protocol, payload to system T, the thrower.
strips all traffic control data from the data it receives, and 4. The thrower collects the payload data and sends
keeps only the payload data. The second component is a it to system B via means of a protocol. System B
‘thrower’. The thrower does the opposite: it takes bare may believe it is talking to system A, but in fact it
payload data, and sends the payload to another system is talking to a thrower, which acts as a proxy for
by means of some chosen protocol. In order to do this system A. Systems T and B exchange both traffic
successfully, the thrower does all the complicated things control data and payload data.
that are necessary to adhere to the protocol specifications,
including the creation of traffic control data.

The diagram shows that system B (downstream) will never

directly speak to system A (upstream) – communications
go via the catcher and thrower. This means that an attacker
must undergo a long chain of attacks to reach system B.
At first glance, you might conclude that the catcher and the
thrower only make the attack on system B somewhat more
cumbersome but not impossible. There is an ingenious way
of preventing this.

A C T B
Thrower
Catcher

Upstream Downstream

Figure 4: a protocol break

6 | Fox-IT | Protecting confidential information using DataDiodes

3.2 DataDiode Protocol
As we have already discussed, protocols may be very Vulnerability assessment
complex. They may be implemented in hardware or
software; these implementations may have slight design Which components of the system are vulnerable for
flaws which permit an attack on the system by exploiting attacks by means of deliberate protocol deviations?
these flaws. Basically, this is the case because these • First: System B. However, B only talks to system
protocols are often designed and implemented for a specific T. System T is not under control of an attacker
function, where security was not considered essential, or of and as such it cannot be attacked from system T.
secondary interest in best case. • Second: System T. System T talks to system B
which is supposed to be clean and to system C.
In the system described in Figure 4, the catcher and thrower System C is not initially under control of the
need some means of communication as well – they need attacker but might be exploited.
a protocol between them. This protocol is under the full • Third: System C. System C is initially trusted,
control of the security system designers. Security of the but talks to system A, which may be under the
protocol can be made a top design priority. The protocol control of an attacker. This may seem to be a
can be designed in such a way that the complete state space problem, but it is not.
of both catcher and thrower can be analyzed. The protocol
can be designed in such a way that it is very trivial to detect
any protocol deviations that may be malicious. This special
protocol between the catcher and the thrower is called the
DataDiode protocol.

How does the DataDiode protocol guarantee that when

the catcher system C is corrupted, the thrower system T
remains unaffected? Assume the protocol between the
attacker system A and the catcher system C is very
complicated.
The attacker might be able to find an exploit in the catcher,
attack it and corrupt it. However, the catcher cannot be used
as a steppingstone to attack the thrower. The DataDiode
protocol spoken between the catcher and the thrower leaves
no room for attacking the thrower because of its design.
Were the catcher to try this, the thrower would detect
malformed protocol data and simply ignore it. The important
observation here is that because the thrower cannot be
corrupted, the thrower will remain secure and cannot act as
a steppingstone to attack system B.

How does a protocol break work together with a DataDiode?

The DataDiode is put exactly between the catcher and the
thrower. The catcher and the thrower are often referred to as
‘proxy servers’. The catcher resides in the upstream network
and is often referred to as the upstream proxy server. The
thrower resides in the downstream network and is often
referred to as the downstream proxy server.

Fox-IT | Protecting confidential information using DataDiodes | 7

 4. Payload and content checking
We have not looked at the payload data yet. Using a How to prevent exploitation by the payload
DataDiode and a catcher and a thrower, we have assured
that the delivery process of the payload cannot inflict 1. Accept the risk. After all, the downstream
harm, and that the payload, if malicious, cannot exfiltrate network is completely isolated.
data. However, the legitimacy or non-maliciousness of the 2. Do a very strict pattern matching on the payload,
payload itself has not been verified. This is a fundamentally only accepting payloads recognized to be
complicated issue. The payload, for example a PDF file, conformant (i.e. whitelisting). For example, only
may be constructed in such a way that the software which accept ‘text’ files with 7 bit ASCII characters in it.
presumably will be used for viewing the PDF file, may be 3. Do some pattern matching on the payload,
exploited. To address this, there are fundamentally five removing payloads recognized to be wrong (i.e.,
approaches which are shown alongside. blacklisting). This is essentially what an anti-virus
solution does. It keeps a lot of bad things out, but
Naturally, which approach is acceptable from a function, it gives no guarantee whatsoever. An advanced
cost and risk perspective will differ from case to case. There persistent threat will be capable of ensuring its
is no magic bullet here, and depending on your adversary, malicious payload will not be recognized by using
risk appetite, functional requirements and budget you may a zero-day exploit.
choose your own balance between these approaches. 4. Convert the payload itself. Essentially, take all
information out of the source file, and create a
new one with the same contents. Conceptually
this is the same as what the catcher and the
thrower do, but now at the payload level. There
is no general solution for this; it turns out to be
extremely complicated and only works for very
well-defined use cases.
5. Do a combination of the above. For example: only
accept JPEG files, convert those to PNG and drop
all other payloads.

8 | Fox-IT | Protecting confidential information using DataDiodes

5. Could we also do just one of both?
Can a protocol break be implemented without a Secondly: a DataDiode without a protocol break. This
DataDiode? And can a DataDiode be used without a will only work for protocols that are unidirectional by design.
protocol break? Of course, it depends. These are Participants in such a protocol will not notice a DataDiode
interesting questions. between them (as long as it is connected in the right
direction). However, virtually every protocol nowadays is
Firstly, a protocol break without a DataDiode: technically bidirectional. Everything that uses TCP is bidirectional. The
this is perfectly possible. The catcher communicates TCP protocol has provisions to stop sending data when no
directly with the thrower without a DataDiode between acknowledgements are received back from the addressee.
them. It will work. However, there are two caveats. When the addressee is situated behind a DataDiode, the
acknowledgements will never pass back through the
a. Without a DataDiode, there is no strong guarantee DataDiode, and as such prevent the TCP protocol from
that the information will only flow in the desired delivering the data. Almost all protocols that use UDP have
direction. All kinds of provisions will have to be similar provisions by means of extra traffic control data sent
designed in the software to guarantee that there is no in the reverse direction.
communication channel back possible; that there is
no backchannel. The single and notable exception is a subfamily of UDP
Fundamental research has shown that doing this protocols that we call the unidirectional UDP protocols.
in software is extremely complicated; it is a large In these protocols, the sender keeps on sending data even
undertaking to do this to a high level of assurance. if it does not receive any confirmation whatsoever from
Approaches to product evaluation, such as Common the addressee. In general, this is a strongly discouraged
Criteria, provide some level of assurance via peer-review design practice, as it may lead to network congestion when
and testing, but the results cannot be 100% guaranteed. not used very carefully. However, some CCTV streaming
Only a DataDiode can provide a 100% guarantee. protocols and logging protocols use unidirectional UDP.
b. Without a DataDiode, is it very difficult to establish When applied with care, this is perfectly sensible.
whether the ‘protocol break solution’ genuinely provides
a protocol break. The provider of the solution has to Unidirectional UDP protocols, as stated, will work
be trusted that it has not cut corners anywhere in the through a DataDiode. In this case, it is possible to use
design and implementation of the solution. With a a DataDiode without a protocol break. A protocol
DataDiode in the middle, you can be absolutely certain break is still recommended practice, though. The IP
that there is a protocol break: without a protocol break, header of the UDP packet is complex and may be a
the setup would simply not work. Or put in a ‘confusing’ means to deceive routers and switches on either side
manner: the protocol will break when using a of the DataDiode.
DataDiode. There is one exception, this is when a
protocol is unidirectional by design. Unidirectional UDP is supported by almost all DataDiode
vendors. However, only some DataDiode vendors
A protocol is unidirectional by design when all messages provide a genuine UDP protocol break.
that are needed to make the protocol work are sent in
the same direction. In particular, the sender will keep
on working and sending data without ever receiving any
acknowledgement. A protocol that is unidirectional by
design will keep working when a DataDiode is put
between the sender and the receiver. The DataDiode
protocol in particular is such a protocol.

Fox-IT | Protecting confidential information using DataDiodes | 9

 Confidentiality, Integrity and
Availability revisited
So where does all this bring us? The DataDiode prevents Integrity & availability of the downstream network
data leakage from the downstream network to the A unidirectional network connection in itself does not
upstream network. The data that is sent from the prevent attacks that may impact integrity and availability.
upstream network to the downstream network can be Merely using a unidirectional network connection does
divided into traffic control data (i.e., protocol metadata) however already mitigate the impact of an attack, because
and payload data. a successful attack cannot ‘phone home’ for instructions
The protocol break ensures that known and unknown or to exfiltrate data.
attacks in common and not so common protocols cannot
destabilize systems in the downstream network. All traffic To prevent an attack, all traffic passing the unidirectional
control data passing through the DataDiode is fully network connection must be made harmless. This traffic
controlled and designed to be easily rejectable in case of can be divided into traffic control data and payload data.
malformed messages. Thus, the systems in the downstream A protocol break neutralizes attacks that may come with the
network cannot be attacked. Therefore, the integrity traffic control data.
and availability of the downstream networks remains
unchallenged. To be absolutely safe, the payload data must be neutralized
as well. This can be done, but it is very situation specific
The catcher, which resides in the upstream network, is and only when one can predict very precisely what the
potentially susceptible to an attack. In the worst case, this form is of the data that will pass the unidirectional network
would cause the unidirectional traffic flow between the connection. In general cases, one can do a best effort
networks to stop (i.e., to become ‘zero directional’). content check which permits a variety of data formats to
Thus, the availability of the network connection is the flow in, at the price of not knowing whether all attacks have
worst thing that could be compromised. That is still been stopped.
undesirable, but there is nothing that can be done about
that. We might harden the catcher some more. However, Availability of the unidirectional network
because the attacker has access to the upstream connection
network, he could disrupt any other component in the A unidirectional network connection is used to enable
upstream network to make network traffic cease. communication between two otherwise unconnected
systems. The approach described places security controls
Let us end with a systematic assessment of C.I.A.: confi- around the unidirectional network connection, but in its own
dentiality, integrity and availability. In a ‘protecting secrets’ right cannot ensure the availability of the unidirectional
scenario, one aims to protect the downstream network. network connection itself. We have not prevented an
attacker taking control of the upstream servers and
Confidentiality of the downstream network preventing them from sending data to the downstream
A unidirectional network connection or DataDiode network – we have mitigated the risks of the damage an
ensures the confidentiality of the information of the attacker can cause in terms of protecting secrets, but not
downstream network. It prevents data leakage or data from denial of service.
exfiltration
via the unidirectional network connection. Exfiltration To prevent a denial-of-service attack on the network
methods like printing, USB sticks and other unprotected connection, other security mechanisms and architectures
network connections are not prevented by a unidirectional must be used. Discussion of these methodologies is outside
network connection. However, using unidirectional network the scope of this paper.
connections is a key enabler for enforcing strict policies on
portable media usage to prevent such.

10 | Fox-IT | Protecting confidential information using DataDiodes

Concluding remarks
As shown by this assessment, by using a DataDiode in
combination with a protocol break, we have ensured the
best possible protection of the ‘secrets’ in the downstream
network, using a fail-safe approach. Such approaches to
protecting ‘secrets’ have been used in high assurance
environments to protect state secrets for many years.
These solutions are now readily accessible in commercial
markets available to solution and security architects.

Our advice:
• Assess your information assets and determine which
are your most valuable business ‘secrets’, and the impact
of these leaking from your organization.
• Locate these ‘secrets’: are these on networks that are
connected to the Internet?
• Ask yourself: should they be on networks that are
connected to the Internet?

About the authors

Dr. Wouter Teepe
Holds a Master's degree in artificial intelligence and
holds a PhD in computer security from the University
of Groningen.

Colin Robbins
Holds a Joint first class honours Bachelor’s degree
in Computer Science and Electronic Engineering from
University College, London, and is a CESG Certified
Professional (Lead Security & Information Risk Assessor).

Fox-IT | Protecting confidential information using DataDiodes | 11

060-011-EN

Fox-IT
Fox-IT prevents, solves and mitigates the most serious
threats caused by cyber-attacks, data leaks, or fraud
with innovative solutions for governments, defense
agencies, law enforcement, critical infrastructure and
banking and commercial enterprise clients worldwide.
Fox-IT combines smart ideas with advanced technology
to create solutions that contribute to a more secure
society. We develop products and custom solutions
for our clients to guarantee the safety of sensitive
and critical government systems, to protect industrial
networks, to defend online banking systems, and to
secure confidential data.

Fox-IT B.V.
Olof Palmestraat 6, Delft T +31 (0)15 284 7999
P.O. Box 638, 2600 AP Delft F +31 (0)15 284 7990
The Netherlands fox@fox-it.com

fox-it.com Fox-IT is part of NCC Group.