Oversold? Field Security Devices

23 Oct 2012 | 2012

SCADA Firewall

I have a problem with field security devices. Well, not really A problem, but multiple problems.

1. Avoiding The Root Cause of Insecurity

There is a tendency in the ICS community, and even among those considered ICS security gurus, to promote building higher walls around insecure by design products and protocols rather than adding even minimal security controls to those ICS products and protocols.

Many loyal blog readers are shouting at their browser — Field Security Devices Are Compensating Controls! True, and they have their place as an interim strategy. However every critical infrastructure owner/operator who is considering buying and deploying field security devices should be simultaneously demanding their vendor provide a plan (features, cost and timetable) to add security to their PLC or RTU. If the vendor says no, go to another vendor until you find one willing to produce and sell a secure PLC.

By the way, this avoiding the root cause of insecurity goes well beyond proponents of field security devices. Take a look at NERC CIP, ISA99, ISASecure certification and other standards and community efforts and you will see the higher wall approach.

2. PLC’s Still Expose Vulnerable Services (by necessity)

In most SCADA and DCS there is still a need to access the PLC in a way that a field security device can not prevent or protect. Write function codes typically must be allowed through. If you want to use the multitude of capabilities in a Modicon Quantum you need to let function code 90 through the field security device. Since these protocols lack even basic authentication, an attacker with a spoofed IP address will be able to attack through the security device.

Similarly, many owner/operators, particularly those with geographically dispersed SCADA systems, have operational requirements for insecure PLC management protocols such as Telnet, FTP and TFTP. The activities that are required for remote management are the activities an attacker would use.

3. Overselling The Benefits

I don’t blame a field security device vendor for promoting their product and every possible benefit, it’s their job, but others should be a bit more skeptical. In a recent blog entry: SCADA Security: Tofino Provides an Alternative to Patching, Eric Byres discusses how security profiles in Tofino can detect and prevent attacks on known vulnerabilities in the PLC it is protecting. For example, it could detect an attempt to login to the FTP with default or hard coded credentials. Or if a known string causes the PLC to crash, it could be blocked.

There is some benefit to this, but if the ICS protocol or other required protocols allow writes, ladder logic changes, firmware updates, etc., how much risk have we actually reduced. In addition, these same restricting feature could be configured in infrastructure routers or switches in a much more efficient manner. Or some of the PLC’s allow you to turn off vulnerable management services such as the http or telnet service.

I guess if you have deployed Tofino’s it is another way to take advantage of a paid for and deployed device, but it hardly would be a reason to recommend a field security device. To be fair to Eric and Tofino, he flat out states it is not a panacea for all PLC security faults.

The Place For Field Security Devices

After that rant, you may think I don’t believe in field security devices. Not true. They have their place including:

  1. The read only models are useful for segmenting DCS from Safety Systems (SIS). For example, the Tofino Read Only Modbus firewall allows the DCS to pass properly formatted read requests packets to the SIS, but it blocks writes, diagnostics and all other function codes. We have seen a few owner/operators use this with great success.
  2. In front of fragile PLC’s that crash with malformed or unexpected traffic. An attacker can still compromise the PLC, but the vast majority of PLC failures have been from non-malicious but unexpected traffic hitting the PLC interface. I have wondered if vendors such as Honeywell chose to sell a firewall in front of their controllers rather than fix fragile protocol stacks.
  3. As more granular ICS protocol support is added, the potential benefits increase. Everyone starts with Modbus TCP because it is such a simple protocol, but you could come up with a set of non-invasive capabilities (an extension of the read only idea)
  4. Integrated into the Ethernet card of the PLC as one of many embedded security features. This is the future.