Data diodes can create architectural complexity despite design simplicity of the data diodes themselves, but do they increase security?
The concept of a data diode – a hardware device that only lets data out of the perimeter and prevents any data from coming in – isn’t new, but it’s been adopted recently in the critical infrastructure sector, and in so doing limiting the visibility needed to protect against targeted attacks. The North American Electric Reliability Corporation (NERC) is certified by the Federal Energy Regulatory Commission (FERC) to establish and enforce reliability standards for the bulk-power system. NERC develops and enforces reliability standards, and monitors the bulk power system, among other responsibilities.
NERC has developed a number of standards, of which the most widely recognized is NERC 1300, a modification/update of NERC 1200, called CIP-002-1 through CIP-009-2 (CIP=Critical Infrastructure Protection). These standards are used to secure bulk electric systems although NERC has created standards within other areas.
CIP-002 requires the identification of Critical Cyber Assets (CCAs) that must be protected through stringent controls and procedures subject to auditing per the guidance in the rest of the NERC standards. In plain language, if it’s an important server, it needs strong protection.
As one would expect, CCAs must be protected within a security perimeter with well-defined access control. Data diodes presumably protect the CCAs from attacks and possible compromise.
Sounds ideal on the surface, but is it really practical?
The first problem is that data diodes exclude any application that uses TCP communications since TCP is bi-directional. This restricts data to one-way UDP communications. First off, UDP datagrams are limited to just under 1,500 bytes; it’s sort of the Twitter of IP communications.
Since I’m in the security intelligence (SIEM, log management, risk management, etc.) world, my first thought is how do data diodes affect event collection and centralization? Syslog uses UDP by default, which works in this context, although there are other protocols for log collection, all of which use TCP (Windows DCOM/WMI, Check Point OPSEC/LEA, JDBC, FTP, SCP, SDEE, to name a few). As a reminder, many SCADA systems are built on Windows, and many Windows server events exceed 2,000 bytes, blowing past the UDP datagram limit. So already, centralized log management is hampered.
But what about transferring files from inside the protected perimeter to the general purpose network? Some of the data diode solutions accept TCP connections, such as FTP or SMTP, to a specialized server on the protected side of the perimeter, carve up the data into UDP datagrams, and send them across the diode to another specialized server on the other side that reassembles the datagrams and initiates a new connection to the eventual destination. The manufacturers have effectively created an application proxy firewall composed of a data diode sandwich.
There’s no doubt that data diodes can create architectural complexity despite the design simplicity of the data diodes themselves, but do they increase security? Are they really a better mousetrap? Don’t forget, the early bird may get the worm, but the second mouse gets the cheese.
One-way communications security only works if you never need to send data from outside the perimeter to a highly secured zone. Clearly, all CCAs will eventually need updates: to the operating system, to the SCADA software, and to drivers that support both. It’s also likely that other files will need to be copied to CCA at some point. Since the data diode prevents network-based file transfer, there have to be other options.
In talks with manufacturers of data diode solutions, they suggest using sneaker nets or dial-up. The latter is just a side-door to bypass the data diode, and removable media is just as effective, if not more, at infecting machines. Let’s not forget that Stuxnet is thought to have contaminated the Iranian nuclear enrichment plant’s SCADA systems through USB sticks brought into the facility.
The point is that data diodes only provide armor for one attack vector: the network. And they impose a level of difficulty in performing occasional, yet routine, tasks that doesn’t justify the purported increase in security over a well-managed firewall.
The only benefit of data diodes over firewalls is they remove the negligent user and developer factor. Because data diodes are implemented at the hardware level, users can’t misconfigure a data diode, and because of its simplicity, it’s unlikely that a data diode has a latent design flaw, or at least one that will let data flow back into the protected perimeter.
Common firewall technology, on the other hand, imposes access control in software or firmware. I’m not as concerned about product defects: when is the last time a dedicated firewall solution was compromised due to a software bug? Certainly there have been some, but none catastrophic enough to allow full-on bypass of rules. Assuming the rules only allow inside-out, UDP-based communication, and there is no misconfiguration in the firewall, I can’t recall a firewall exploit that would allow an external attacker to gain access into the CCA perimeter.
Misconfiguration is another issue altogether. The human factor is always the weakest link in any security program. But what makes the most sense is risk management, not risk avoidance. Humans will make mistakes in misconfiguring firewalls; they’ll also make mistakes by inserting a USB drive that hasn’t undergone rigorous anti-malware scrutiny.
My view has always been that you can spend 20% of your security budget on protection technology and cover 80% of your risk. All too often organizations eat the the remaining budget trying to cover the remaining 20% security risk with the diminishing returns endemic to the long tail without ever reaching absolute protection, which is a pipe dream.
Most organizations don’t need a new protection technology like data diodes. Sure, we need active defense, but only insofar as it balances the security benefits with the operational burden and complexity. What I’m saying, is deploy traditional firewalls configured for the specific needs of CCA protection, and add configuration management and behavior profiling with anomaly detection. Whenever a change happens on a firewall, have the event trigger an automated configuration validation against the perimeter traffic policy. Monitor traffic in real-time and detect when data is heading into the CCA perimeter and put a stop to it before the attacker finds a way through. And produce regular reports that informs both technical administration and management of activity in and around CCAs—some threats require the human mind to detect.
Read More of Chris’ Columns Here.
