Cyber Security for the Control System


Thread Starter

Kevin Cooper

As an extension to the Stuxnet thread (, I would like to pose a question to all those on this forum.

Since no mass exodus to Linux is forthcoming (or a more secure OS of any sort), what are some steps that you are taking to avoid infections that might cause serious problems in your control systems?
I'm waiting for someone to say A) "Keep your patches and virus protection up to date" and B) "Isolate the plant network" and then try to tell us how they reconcile A and B.

If you're using MS Windows, there really are no good options. If there were, you could be making a very nice living telling all the people running MS Windows business networks how to do things, as so far they've had absolutely no luck with this despite pouring billions of dollars into the effort.

One thing that I can recommend to mitigate some of the problem is to keep the I/O networks on each machine isolated from the supervisory network. That way if the supervisory network gets DDOSed (so much traffic from viruses or worms that the legitimate users can't get a word in edgewise) then your I/O networks are not directly affected.

If you are writing custom software it is quite feasible in a lot of applications to write your software to be platform independent. If down the road you decide you do want to run it on Linux, BSD, OS/X or whatever, then you at least do have that option.
The trend to isolate networks for my clients seems to be growing. Most take one of 2 forms:

1. Use of dual ControlNets (or other industrial networking connections), one for I/O and drives with a second as an interprocessor and HMI interface. Ethernet connections are for programming and supervisory systems which allows the plant to continue running locally if there is a problem from the Internet.

2. Use of separate managed switches (Stratix 8000 and similar). This also allows the I/O, drives and HMIs to be on one network isolated from the "outside the plant" systems. Even the supervisory system may be on this. A single PC is then used to access the Internet which can be disconnected if needed.

Neither method prevents the Stuxnet type of attract but the simple denial of service gets stopped before seeing the PLC-HMI-I/O.

I have the view that industrial security is similar to securing your house from robbers; if you make the place just a little more difficult to get in, the thief will go down the street to easier pickings. High profile targets can't get away with this as there is always some looking for a "big payday" so those places need to do more, just like your well off neighbor should do. Good enough security isn't always adequate but the cost for security vs. potential loss has to be factored in. Maybe what you pay to secure your network is justified when you look at the risk but then again...

Russ Kinner, Phoenix, AZ
You can isolate two Ethernet networks without a switch provided you have two interfaces and the system is set up as non-routable. If you are doing a project with a PC, adding a second card is easy and cheap. There are also quite a few small (Mini-ITX) PCs with dual ports which are intended for security applications. This can be a lot easier and cheaper than a fancy switch.

There are also operational advantages to this if you have multiple installations of the same machine as it lets you use the same I/O configuration without conflicts. It also prevents addressing mistakes from causing general chaos which one machine starts controlling the I/O that belongs to another machine.

Kevin Cooper

Rockwell touts the Stratix managed switches (of course the higher end models) for this kind of thing- any thoughts?
Managed switches are yet another device to configure, maintain, and update. They can also be very difficult to get right. The AB Stratix switches that you mention are re-packaged Cisco switches. I haven't looked at the record of those ones in particular, but typically you have to patch and update Cisco managed switches just like any other computer.

They're really meant for IT professionals to let them manage large scale networks. I wouldn't consider them to be a security device. I can see them being used for the interface between plant networks and factory networks, or in exceptionally large factory networks. On the other hand, I've more commonly seen people just use ordinary IT style switches for those applications without any problems. If you are tight for space in a dirty environment however, the Stratix switches may solve a difficult installation problem.

On the other hand, the problem you might be trying to solve is that the PLC you are using only has one Ethernet port, and you need it to do two different jobs. In that case you are just really using the managed switch as sort of a port "splitter". If that's the only solution you have, then the problem is that you don't have a good solution available to you. If you are using a PC, then either get one with two ports, or just put another card in (those are a lot cheaper than a switch).

If you're looking for an industrially oriented firewall, then Tofino sells them.

There is also an open source Netfilter extension for Linux, but using that's a do it yourself job (getting that put into one of the standard firewall distros is the project that I was trying to convince Curt Wuollet to take on). Most security firewalls are just a copy of Linux with some Netfilter extensions and an nice front end menu system to configure it (and a good configuration system is important). I don't know if Tofino is simply re-packaging the open source Netfilter extension, but it wouldn't surprise me (there is still a lot of value in having that packaging done for you, however).

In either case, if you are using Modbus/TCP the firewall can control access right down to which function codes it allows through. That's one of the benefits of open protocols - other people can build on it in ways the originators may not have anticipated (or even understand, for that matter).

I haven't used the Tofino product so I can't make a recommendation one way or the other, but from the literature it looks pretty good. Keep in mind though that you have to configure them properly for them to be of any use to you, and if you get that step wrong you still have a big security hole. Firewalls are a useful tool, but they're not a panacea, and of course they would be no help at all in the case of a Stuxnet type virus.

If you want to give an office system access to a specific PLC while restricting what it can do, then something like that could be a good solution. That is, provided you are using Modbus/TCP. I'm not aware of anything equivalent to this for AB Ethernet/IP or Siemens Profinet.

Wassim Daoud

Something to think about as well is OPC Security... Native support for the OPC Foundation's OPC Security specification is crucial for implementing secure OPC architectures. Instead of relying on global, DCOM based, "all-or-nothing" OPC data access permissions, this function offers complete control over item browsing, adding, reading, and writing on a per-user-per-item basis. Granular control over data access helps prevent accidental or intentional un-authorized OPC data access. This role based security adds another layer to a system's overall Defense-in-Depth strategy.

Here is a link to learn more:

Wassim Daoud
Global Solutions Architect
Most important is to isolate plant network. Remove access to any hardware than specific HMI devices (mouse and keyboard only). On the other hand comes subjective factors as always. So all the shifts should be very well instructed what will happen if they cause a infection or crash during the shift as usual related to removable devices (flash drive,pen drive etc.) with autorun.inf worms, trojans,etc....and of course massive fines they have to pay and go to jail for example. maybe this sounds very un-human, but it's efficient :)))

curt wuollet

Yep, blaming it all on the user has been letting MS skate for decades. But we do want to exhaust every conceivable scapegoat before simply dumping the world's most often compromised system. Or, we could use what the security experts use for firewalls, etc.

OK this thread has tempted me out of retirement.

I am disappointed to find everyone concentrating on the technical. The "solution" to this problem cannot be found in hardware and software alone. I put the speech marks in because in reality as others have alluded to there is no complete solution.

Here's the basics.

The plant owner ultimately accepts the risk of doing business in every other way he must do so with computer/SCADA/DCS security. It is therefore essential that he has a policy/philosophy in this area. He should do this internally or by getting good advice.

Ideally groups of customers should get together to influence vendors to produce appropriate products.

Those giving advice should be professional. There has been a tendency to over hype this.

The measures adopted as part of the implementation of this policy should address
- protection (the well argued technical bits)
- detection (technical but also procedural)
- response (largely procedural but also technical)

All these measures should be cost effective. From a business point of view it makes no sense to spend lots of money on a digital security risk and less on an equally significant physical/plant risk.

Responsible vendors should address the plant owners concerns without being prompted.

There's lot of good guidance now from the ISA, NIST and NERC in the US. Look on their websites.

Its all based on the above + defense in depth (don't put all your eggs in one basket).

My own advice would also include - be skeptical of anybody offering a panacea whether its a firewall, a particular operating system (standby for a torrent), or a service (am I undermining myself here ;)! ).

If you have something specific in mind let me know. I'll monitor this thread for a while.

Hope this helps.

In reply to DaveMH:

>Ideally groups of customers should get
>together to influence vendors to produce
>appropriate products.

There's no shortage of people posting messages on this web site to try to influence vendors. So long as people keep buying the same products however, there is no real incentive for vendors to listen.

>Responsible vendors should address the
>plant owners concerns without being

The vendors will not change until customers change their purchasing habits. At this point most customers are still in denial about a problem even existing.

What Stuxnet showed was that no security is stronger than the weakest component in the system. Security has to concentrate on removing weaknesses and reducing the amount of damage that the remaining weak points can cause. What makes industrial automation different from IT systems is that there is a very strong need for *simplicity* in any solutions as the system must be maintainable by people who are not full time IT professionals. On the other hand, automation systems don't have the huge variety of software that IT systems have to deal with, and those PCs that are running on the plant floor are almost always performing a single task.

I think the most promising line of approach for SCADA/HMI vendors to take is to try to deliver complete out of the box solutions for dedicated applications. That is, they should deliver a software "appliance" with everything already configured for security. A software "appliance" is when you package the OS and application together on a single disk and you just install the entire works on the computer without regards to whatever might already be there.

While this doesn't guaranty that there won't be any security problems and it isn't the only security issue that needs to be addressed, it does put that part of the equation in the hands of people who are more likely to know what they are doing.
Hi Dave

No torrent from here.

Actually I find that a good overview of what has to change and be done with a couple of things being glossed over.

People need to know the risk to accept the risk. This is a big problem as the risk is seldom even discussed, let alone fully understood. And the people parts have an extremely long way to go as bringing up security in a serious fashion tends to be one of those items where, if your hair isn't standing on end, you aren't paying attention. The norm so far, has been blissful ignorance and the selling side is loathe to disturb that.

I do concentrate on the technical as there are glaring problems there that make the people side pale in comparison. One of the largest, is that the software side is a monoculture which is the worst possible case. A related issue is that there is no choice except the monoculture. And when that monoculture is built around perhaps the worst possible choice as demonstrated by actual security breach frequency, I think what people do is quite a ways down the list of solutions as far as efficacy is concerned. This is actually quite fortunate as factory people as a rule seem to despise most anything done in the name of security. I think meaningful security cannot depend heavily on people doing as you would like them to do unless that somehow aligns with what they find most convenient, because that is what they will do.

Dave is right, there's no out of the box solution to this issue, couple of things need to be addressed, as mentioned, prevention, detection and response.

The standard ISA99 is a good reference, although it is not fully completed, but what is available on part 1 and 2 gives a good start.

In reply to M Griffin:

>> Ideally groups of customers should get together to influence vendors to produce
>> appropriate products.

> There's no shortage of people posting messages on this web site to try to
> influence vendors. So long as people keep buying the same products however,
> there is no real incentive for vendors to listen.

View this as a journey, a process that will get better. I do work on the client side for major companies and things are changing. I have also made the acquaintance of people in the security field and even they are sitting up and taking notice of our little field of engineering.

>> Responsible vendors should address the plant owners concerns without being
>> prompted.

> The vendors will not change until customers change their purchasing
> habits. At this point most customers are still in denial about a problem even
> existing.

Maybe not but vendors should. It may offer them a commercial advantage and it is the professional thing to do. Also refer to my answer above.

I think you've kind of missed the point of my post although I agree with the statements re simplicity.

Hi Curt

You are correct. In an effort to summarise the big picture I have indeed glossed over some important aspects.

The assessment and perception of risk is indeed important and often avoided. I am in this situation now with a customer. In this respect Stuxnet may well have done our industry a favour.

I understand the argument regarding what you call the monoculture.

I disagree with you on the point regarding the people side. Changing the way people act is as difficult as the technical side. I do agree that our systems need to be robust and tolerate errors (deliberate and inadvertent) from people involved in the system lifecycle. We must also encourage people to behave as we would like through the provision of security that supports their work. That way they will not be incited to circumvent the controls in place.

Some vendor's developers read this website. :) We also have plenty of incentive--if we can market our DCS as more secure than our competitors, we've got a significant advantage. If it really IS more secure, we've also reduced costs on our services contracts. Those competitive advantages also mean I have to sit on my hands a lot in these forums, as our competitors also read this forum. Otherwise I'd have a lot more to say on this topic. :)

I think the idea of the plant management having a security philosophy is important. Most of the vectors for general, non-targeted attacks boil down to carelessness by people who are not aware of the sophistication of modern malware. Every infection I've seen on a control network PC was preventable with common sense--not plugging in that personal USB drive to copy MP3s to the HMI for example. :) Infected laptops brought in by sub-contractors and TAs is another major vector, and can be prevented simply by not allowing those laptops into the building without an IT screening.
It sounds like we said the same thing different ways on the people point:^)

The degree to which they can buy in, makes up the difference in importance. Scary:^)


James Ingraham

M Griffin: "I'm waiting for someone to say A) "Keep your patches and virus protection up to date" and B) "Isolate the plant network" and then try to tell us how they reconcile A and B."

That's actually not TOO hard, assuming a Windows environment. The plant network is not connected to the Internet. There is a domain controller for the plant network. The domain controller must also have Internet access, but it is possible to keep the two essentially separate. Updates are downloaded by the domain controller and the PCs get their updates from there. Granted, there is some slim possibility of bridging through, but it can be made pretty unlikely.

There are problem with this even so. (1) For starters, Stuxnet attacked no less than FIVE zero-day exploits. So being up to date did no good. (2) Isolating the plant network also makes it difficult to pull the data out that helps you run your business. Not impossible, but the more connected you are the more vulnerable, and the less connected the less useful. This also increases complexity. (3) One bozo can still wreck everything by plugging into the wrong port. (4) A malicious employee can do an awful lot of damage. A lot can be done if you have physical access to the network, even if you don't have passwords and privileges. And if you DO have passwords, well, you get the UBS logic bomb. (5) COMPLETE isolation is impossible. For example, I bring my laptop in to a client site to connect to the machine we sold them. If I've got a virus, they're hosed. (In reality, we have never infected one of our customers, but twice customers have infected our laptops.)

There's no such thing as perfect security. People have broken in to banks, and escaped from Alcatraz. Stuxnet was, from what I've heard, extremely well done. It was going to work. I don't care WHAT security you had in place, that sucker was unstoppable. It wasn't some script-kiddy who figured out how to rootkit a Siemens PLC.

I'm not saying give up and not try, by the way. One large company (that you've definitely heard of) requires laptops to be physically secured when not being transported. If you go to a meeting with your laptop you bring a locking cable with you. They have a sophisticated IT department with a security strategy, and anything networked runs through them. Outside people who bring in laptops are not allowed to connect to the network. They may be more overboard than most, but from what I've seen they have a pretty good setup.

Still, that or any other security system is vulnerable somehow. The most obvious is the human element. If you've got a million bucks to bribe someone with, there's not a lot networks that would stop you.

Anyone else notice that "Security" is not even one of the categories for posts?

-James Ingraham
Sage Automation, Inc.
In reply to DaveMH: You said: "I think you've kind of missed the point of my post". I originally started writing a point by point discussion of your post, but erased most of it because it just amounted to nit-picking. There wasn't much about what you said to disagree with.

There's several stages that a company has to go through however before solving anything.

1) Recognize that a problem exists.

2) Decide that something must be done about it.

3) Figure out what *can* realistically (and economically) be done about it.

4) Implementing the solution.

Most people haven't gotten to step 1 yet. The people debating the issue here are trying to figure out how to do step 3.

Yes a company policy is necessary, as that provides the financial justification. However, successful policies tend to come out of solutions, rather than solutions coming out of policies. We need to figure out that "A" and "B" will be effective, but "C" won't.
In reply to Demigrog: At present, most customers support security the same way they support world peace. They think it's a fine idea provided it doesn't require any action from them personally.

The IT industry has been wrestling with MS Windows viruses for a couple of decades now by reacting to problems after the fact and they're no further ahead now than they were when they started.

The solution however isn't saying we need more "common sense" or "being more careful". We could say the exact same thing about the quality of the products going down the assembly line - "if only the operator had been paying closer attention those bad parts wouldn't have gotten out the door". Any modern manufacturer knows that sort of answer doesn't help anyone. If what we're doing isn't working, then just doing the same thing harder seldom has anything more than a marginal effect.

If a SCADA, HMI, or DCS vendor with an established product wanted to try a completely different approach to things, I think it would take them several years to get to the point of having a version of their product ready to ship. That's plenty of time for public panic to stampede lots of customers to someone else's product which just fortuitously happened to be in a better security position.

While Stuxnet itself may not have much long term impact due to the peculiar nature of it, in the event of a virus attack on a large pipeline, oil refinery, power plant, or other such target, then "panic" and "stampede" will probably be the reaction.