The State of ICS Security: The Good, The Bad, and The 6 Steps to Take Now

I’ve had an interest in security for a long time. When I was first introduced to the automation industry years ago, I was surprised (read “appalled”) at the state of security. I worked for a small system integrator out of Sacramento, California, and coming from the IT world before that convinced me that the software and hardware available at the time were wholly inadequate for protecting just about anything. Frankly, it scared me.

Recently, I attended the ICS Cyber Security Conference in Atlanta, Georgia, and it was interesting to see where things have changed. Gone are the days of universal backdoors (i.e., “ABUNLOCK”), and most vendors are taking security a lot more seriously. However, this is a recent change of focus. There are a number of products on the market that tout upcoming secure features but don’t have current support. Only a handful have secure features today. Clearly, we as an industry still have a long, long way to go.


Are Your Connections Secure?

As far as Ignition, we have support for encryption in practically every connection, and deep support for authentication, credentials, and a slew of other security features (see our Ignition Security Hardening Guide). However, we’re a bit of a pioneer when it comes to offering first-class support directly in a platform like ours.

When it comes to security, any system is only as good as the lowest common denominator. If you’re connected to an insecure PLC (and almost all PLC protocols today are unencrypted), you can view that connection as a “line” that is insecure. The same goes for other devices, database connections, software systems, and the list goes on.

So, how do you protect your system? Here are some basic, actionable steps that I often recommend:


1: Diagram Your Controls Traffic

You probably have network diagrams already, but this is different. Create a diagram that shows all network traffic from PLCs, devices, external software systems, and Ignition (or your chosen HMI/SCADA/MES/IIoT platform). Draw each of the connections as simple lines and draw lines between each device that talks to each other. Then color the lines to indicate which connections are encrypted and which are unencrypted. Add any firewalls in your network to the diagram.


Diagram Your Controls Traffic


2: Consider Using Encryption

Take a look at each unencrypted connection from Step 1 and consider encrypting it. Each connection will require a certain amount of effort to encrypt. A database connection would be easy to encrypt from Ignition, for example. A PLC connection could be very difficult (PLC connections can be secured by setting up encrypted VLANs, VPN tunnels, or if using Ignition, by installing a data collector). Examine the firewalls that are in place and decide which connections should be encrypted. If there are connections that aren’t encrypted, make sure access to that network is secured.


Consider Using Encryption


3: Consider Investing in an Intrusion Detection System (IDS)

Having an IDS for your controls network allows you to easily detect if an unauthorized contractor or employee plugs a laptop into the network. If you have unencrypted traffic over this network, an IDS is even more valuable, as it could be a key part of your security. Do keep in mind that an IDS isn’t going to detect things like someone installing a network tap that can read unencrypted data (if you’re unfamiliar with the concept, just think of a phone tap).


4: Consider Using a Data Diode

If you have an extremely sensitive network that doesn’t need outside data, consider a data diode. This is a device that only allows data to flow out of your network, but not flow into it, thus completely cutting off one major vector of attack.


Consider Using a Data Diode


5: Decide What’s ‘Secure Enough’

Unless you’re investing seven-plus figures in security, you won’t be able to use all the current techniques, but you’ll be much better off having a target than just buying “secure hardware” or “secure software” and hoping it helps. For example, you might decide that your corporate network must be separated from the controls network, and that the controls network needs to have an Intrusion Detection System (IDS) on it, but you draw the line before encrypting all PLC traffic or replacing current physical devices with new secure models. Hire a security consultant if you don’t have in-house expertise to determine where that line will be.


6: Know Your Software’s and Hardware’s Security Options

We’ve put a lot of focus on security and a few other companies in this space have as well. Be familiar with the options and the limits of your selected software and hardware. If your software won’t do encryption out-of-the-box, you’ll need to put either software or encrypted networking devices in place to wrap the system if you want to use encryption. The same goes for support of authentication methods, secure communication protocols, remote access, and anything else that has to do with security.

Taking these steps can significantly reduce your risks. If you choose to do nothing else, I highly encourage you to go through the exercise in Step 1. Having more information and being aware of the security surroundings is essential for us to start changing the picture and the typical conversation around industrial security.


Why I’m Optimistic About Security

Am I still appalled by the state of security in the industry? In a word, yes. That said, I’m actually optimistic at the same time. I feel we’re going in the right direction. Companies like Bedrock Automation have popped up who are deeply focused on security. Existing players in the market have started embedding OPC UA and MQTT with encryption in their products. Intrusion detection systems are starting to catch up to the needs of our controls networks.

I’ll be writing a short series of posts around security topics going forward, so stay tuned. The better informed we all are, the better we’ll do with security. And if we can prevent the next attack against our networks, it’s good for everyone.


AUTHOR
Kevin McClusky
Chief Technology Architect & VP of Sales / Inductive Automation
Kevin McClusky joined Inductive Automation in 2011, and previously served as the Co-Director of Sales Engineering and Director of Design Services. In his current roles as Chief Technology Architect and VP of Sales, Kevin helps drive widespread adoption of Ignition, oversees sales, and provides long-term architectural design guidance to the Ignition community through relationships with key customers, white papers, articles, speaking engagements, webinars, and conferences. Kevin also provides insights to the CEO and CTO on customer needs, customer and industry trends, and new technology adoption.