Securing Offshore O&G Platforms - Advanced Threats need Advanced Firewalls

Submitted by Heather MacKenzie on Thu, 2013-06-27 13:52

One of the industries major oil and gas trade shows, the Offshore Technology Conference (OTC) was held last month. Belden and Tofino Security had a very busy booth there, as both safety and security were hot topics with attendees. It is good to see that security is finally making the list of corporate priorities.

Now when engineers look at security, a topic they should know about is Deep Packet Inspection (DPI) and why offshore networks need to use it if they want to be secure.

Let me give you some context. You know that the critical systems managing production and safety on offshore platforms are largely based on legacy SCADA and Industrial Control System (ICS) products and protocols. Many of these products are decades old and were never designed with security in mind.

People like Dale Petersen and his Basecamp team have made an industry out of showing just how vulnerable these devices really are. Unfortunately these same systems are now connected to external systems using Ethernet and TCP/IP. That has been great for efficiency, but it exposes mission critical production systems to malware.

Nowadays Offshore Production Facilities need firewalls with Deep Packet Inspection to protect against advanced attacks.

Given the 20-year life cycle common for industrial systems, it will be many years before more secure SCADA and ICS devices and protocols are in widespread use. This leaves the thousands of legacy platform control systems open to attack from even the most inexperienced hacker, who can then disable or destroy most industrial controllers.

The Problem: SCADA/ICS Protocols Have no Granularity

The difficulty with legacy SCADA/ICS protocols is that they have no granularity. To the average security device, a data read message looks EXACTLY like a firmware update message.

Thus if you allow data read messages from an HMI to a PLC to pass through a traditional firewall, you are also allowing programming messages to pass through. This is a serious security issue.

You are faced with an impossible choice - keep the messages flowing that make the system run, but expose it to attacks, or block everything out. Since shutting systems down is not an option, accepting high risk has been the course taken by many. In a post-Macondo (Deepwater Horizon) world, this is not acceptable.

What can an engineer do about this? Well, fortunately, there is a solution.

The Solution: Deep Packet Inspection

The solution is a firewall that can dig deep into industrial protocols to understand the purpose of a message. This is beyond the capability of IT firewalls and is called Deep Packet Inspection.

Here’s how it works: after traditional firewall rules are applied, the DPI firewall inspects the content of messages and applies more detailed rules. For example, it determines if a message is a read or a write message and then drops all write messages.

In addition, good DPI firewalls can also “sanity check” traffic for strangely formatted messages or unusual behaviours (such as 10,000 reply messages in response to a single request message). These sorts of abnormal messages can indicate traffic created by a hacker trying to crash a PLC and they need to be blocked.

An example of a DPI firewall is Tofino Modbus TCP Enforcer, a product that uses patented Tofino Security technology for securing Modbus communications.

Tofino Security’s Deep Packet Inspection for industrial protocols and Hirschmann’s zero failover RSP Switches on display at OTC 2013. These products work together to provide high availability offshore networks.

Why DPI is Needed Now

According to Eric Byres, five years ago he would have said that DPI is just a nice-to-have capability. However today’s generation of worms and advanced threats make it a must-have technology if you want a secure SCADA or ICS system.

The reason is that today’s malware designers and attackers know that firewalls and intrusion detection systems will spot the use of an unusual protocol instantly. They know that if the protocols on a network are normally HTTP (i.e. web browsing), Modbus and MS-SQL (i.e. database queries) then the sudden appearance of a new protocol like FTP will put the smart system administrator on his or her guard.

Thus worm designers work to stay under the radar by hiding their network traffic inside protocols that are already common on the network they are attacking. For example, many worms now hide their outbound communications in what appear to be normal HTTP messages.

Even if you suspected something was wrong, you would be stuck if all you had was a normal firewall. The simple blocking of all Modbus traffic would impact production. Without deep packet inspection, (i.e. tools to inspect the contents of messages and block suspicious traffic), your hands would be tied.

DPI technology is a very powerful tool in the security tool box. It allows the engineer to block the bad stuff, yet avoid needless impact on the control system. Without it, the designers of modern worms clearly have the upper hand.

Safe, Secure, Reliable Offshore Production

Certainly DPI is not a silver bullet for security – no technology is. At Belden we are working hard to make our cable, connectors, switches and cyber security products work together for a complete solution – a solution that provides safe, secure and reliable offshore production.

In order to stay ahead of the bad guys, DPI has become a must-have in industrial firewalls. How is this affecting your ICS security plans?

Comments

Submitted by Colin Robbins (not verified) on Mon, 2013-07-01 08:26

Default Deny

Hello,
I like the comparison between a firewall and DPI. But I wonder if the malware creators are getting good at hiding malware into protocol streams is looking for and blocking suspicious traffic is sufficient? Would a ‘default deny’ approach be better – i.e., block everything unless you know that element of protocol to be good? Can a view of what is ‘good’ be established by know what business process is being supported, that what subset of protocol is needed?
Colin

Submitted by Eric Byres on Sun, 2013-07-07 13:39

Default Deny is the Right Way to Go

Hi Colin

You have really hit the nail on the head. The bad guys are getting good at hiding malicious traffic in needed protocol streams. Stuxnet's designers were brilliant at that in their use of OPC's underlaying protocols. For more details on what they did, see my discussion of this at http://www.tofinosecurity.com/blog/scada-security-and-deep-packet-inspec...

So we believe that the best security for a control system is to "White List" the network traffic. In other words, build a list of exactly what messages are needed to operate your control system and block everything else. For example, if you have an HMI that is used only for viewing the process, why ever let it send "Firmware Update" commands to PLCs? Just allow it to send data read messages to teh PLCs that it needs to connect to and no more.

Tofino is designed to make it easy to do just that. First the Tofino is designed with a Default Deny policy. Then, to prevent upsets to the process when some critical traffic is overlooked, Tofino has a test mode that allows rules to be tested before being deployed. And finally, the templates offered by Tofino make it easy to define very specific functionality into the network, such as allowing only the "data read or write" commands in a given protocol and blocking all else.

So you are on the right track - we need to allow only what we really need on the control network, and block everything else. And we need to do it with a finer touch than just allowing or blocking whole classes of protocols.

Regards
Eric

Submitted by Raymond C. Parks (not verified) on Mon, 2013-07-01 15:07

Systems Security

Security is a system, just as much for off-shore platforms as on-shore refineries. Systems comprise people, processes, and technology. When designing security, then, one has to consider the people and processes as much as the technology. For that reason, we need to look at the people and processes of off-shore platforms. First, most crew serve in 14/21 shifts (or some variant). The majority of the crew are not computer technical - they work typical oil-drilling/extraction jobs like their on-shore counterparts. There's usually one to a few technical people who provide support for all of the computers and field equipment. Their workload, the pace of operations, and their knowledge level is such that they probably will not be able to maintain a DPI firewall. That doesn't mean a DPI firewall can't be used - but it must be remotely maintained and updated with the platform techs doing the physical actions like rebooting boxen. Down-hole field equipment did not report directly back to shore in the past and is unlikely to send raw data to shore in the future. Control operators on the platform operate field equipment on legacy platforms, but the trend is toward having control centers on-shore with remote access. Historians typically consolidate and process local data on the platform and pass that back to engineers on shore. Some techs on some platforms can make engineering changes to field equipment (PLCs, et.c.) but most such changes are made when someone on the platform says "Houston (or Trondheim), we have a problem" and the on-shore engineers develop the changes and send them to the platform. Like refineries, there are both operations and safety equipment which may be controlled by different organizations from different locations. Bottom line - if you look at how things are working and where they are trending, most types of control and engineering traffic will be valid. Thus, a DPI firewall on the platform will have to allow most types of traffic and understand the contents.

Submitted by Eric Byres on Sun, 2013-07-07 13:20

The "D" in DPI Doesn't Have to Mean "Difficult"

Hi Ray,

Thanks for taking the time to provide such a terrific picture of how things work in the field. Given that we agree on that, let’s look at the best way to protect the control systems operating on an offshore platform.

Our experience is that a DPI firewall is best implemented on controls network as a conduit to zone of controls equipment. This follows the ISA IEC 62443 standards and it means that the purpose of the firewall is specifically to filter traffic going to controls devices. In this situation only a limited amount of traffic should be reaching these devices, such as filtered communications traffic to a platform safety system.

While the entire platform network will be carrying all kinds of traffic, only a very limited amount of that is valid for the equipment being protected. In one installation where our firewalls were installed there was the perception amongst contractors and maintenance people that firewalls make the job of operations and maintenance more difficult.

Some staff had a ‘knee jerk’ reaction to blame the firewalls any time there were network or communications problems. With a thorough testing regime, the SI involved proved that the proper protocols were enabled to accommodate all required operations. Indeed a critical factor to insuring the core PLCs and safety systems were secure was to filter out the very high volumes of broadcast traffic created by the large number and wide variety of devices on the platform’s network.

In terms of ease of use and ease of maintenance, our firewalls are designed to be easy to implement and configure by field staff. This is a core design principle of our products.

Take the case of our Deep Packet Inspection product for the ODVA protocols EtherNet/IP and CIP. Many end users we have met don't know what a CIP service or object is, never mind what ones to allow or block for their control application. But most engineers know if they want a remote HMI to be able to write data to a PLC or what PCs should be programming stations. So we create "templates" for common tasks (such as Allow Data Read-Only or Allow Data Read/Write) to make it easy for the engineer to use the Tofino in the field. And if that is still too complicated, all Tofinos can be managed locally, centrally or remotely.

We believe that security needs to be simple to truly work in the field, even when advanced technology such as Deep Packet Inspection is being utilized.

I appreciate your comment and hope you will consider DPI firewalls in the future. Done right, DPI can be easy.

menu-bar