I want to know what is the proper way one has to follow when dealing or converting a stand alone PLC to a network of PLC in a plant using a normal computer network and TCP/IP to control a plant from Unix or VMS workstations. Is ther a guideline. Are there special ways to do this or is it a common practice. Would just a firewall provide adecuate security or more drastic measures have to be taken for the PLC's on our network.

In reference to a previous posting, involving the Siemens 545 PLC, a Unix or VMS workstation, and development of an NITP protocol to communicate through a CTI2572 ethernet, the isuue of protection against hacker attacks came up. We are going to incorporate this card into aour normal computer network. The security of our plant, personnel and ecquipment is an issue that came up. I am asking from the PLC community to guide me to find perhaps a document can shine some light to this problem. I need information that explains how to handle such security issues, what are the critiria that influence the topology of the network in installations of PLCs in large plants such as ours. How can we ensure that the plant or personnel here won't be compromised my a malishous attack into our computer network? Are there any new measures besides a regular firewall? Are there eny documents out there that can inform me about the techniques that are implemented for plants that use a network of PLC's hooked up by a common etherenet medium. Are there any records of instances that a plant's PLC have been compromised by a hacker and the domain that certain plc control was at the mercy of a hacker?

Please advise.
Thank you in advance.
Any link to a site or a related PDF file would be helpful.

 

Eric J. Byres of British Columbia Institute of Technology (BCIT) has written a number of articles and has been quoted extensively. Here's one of the articles:

http://www.manufacturing.net/ctl/index.asp?layout=articleWebzine&articleid=CA68320

To find more search the internet using: "Eric Byres", security

 

Use Google to find any of the hundreds of fine security sites for UNIX or VMS. Best is to completely isolate your control network from the internet or outside world. If this is not possible secure the gateways or machines that do connect to the outside. If you are considering securing your network "once and for all", forget it, and do a separate network. Nothing will be secure without vigilence and administration. Nothing will be secure unless you have a good grasp of what you are doing.

A Windows machine that has been exposed to the net except behind a professionally administered firewall can be assumed to be compromised and should not be attached inside your network. This includes your notebook. Other machines should be suspected of being compromised. This is simply the reality today. A box directly on the net will be probed and scanned dozens of times a day. This should give you a start. And always remember that almost all knowledge of security comes from a successful attack.

Regards
cww

 

This article mentions accidents. One specific case I dealt with was where a four node (ethernet) data collection system was connected to other plant data systems by an IT student looking for a spare connection.

He simply saw a hub with unused ports and connected it to the plant backbone that happened to be in the same rack. He didn't know any better, and nobody warned him. The result was loss of data.

The moral of the story: separate and clearly label systems that need to be isolated.

Anthony Kerstens P.Eng.

 

I have to ask a couple of rhetorical questions about this kind of stuff.

1. Why would anyone allow a student (or any other unqualified individual) access to their IT equipment at all?

2. Why was the data collection network stuff not in a seperate, locked enclosure?

3. Did anyone learn anything from this fiasco?

BTW-I am not all that thrilled about relying on labeling as a means of preventing this kind of thing. The labeling tends to be ignored by those who do not know any better, or think they know more than they do. Physical barriers (such as locks and/or seals) are the way to go for critical systems. Makes them think a little before doing something stupid.

Bob Peterson

 

A ponderable...

Why is blame always assigned to the lowest person on the totem pole. To paraphrase a popular song "Where had all the experts gone?"

In virtually all catastrophe (my definition) investigations I've been involved in, none, I repeat, NONE, were the fault of anyone higher in the hierarchy than the tech, trainee, or helper.

Revisiting my earlier story about DCS lockup due to a tidal wave of alarms. One year later the condition had not be corrected... the official reason, "What are the chances of it happening again?" My friends lightning can, and often does, strike in the same place.

If you want more examples of "the learned ones should have known better" just ask!

Regards, Phil Corso, PE (Boca Raton, FL) [[email protected]] {[email protected]}

 

Hi Phil

Nothing ponderable in that. It's the way of the world. To put it delicately, Excrement follows the law of gravity. This is the very essence, the principle reason for _having_ a hierarchy. Even when it was just God, Adam and Eve, Adam tried to blame it on the new gal.

Regards

cww

 

I did say separate and clearly label. I'm all for as much labeling as is practical. As for the separation, some customers simply don't have the desire to have physical barriers because of the additional up-front cost. And you can't go around p-ing off customers.

Either way, this was a case of the customer getting exactly what he asked for, despite recommendations for something better. We only learned of it when we received a service call because "it's not working". I personally would have liked to see the hub in a box out on the floor in close proximity to the PC's, or even in the same box as one of the PC's.

With some customers, it seems to just go in one ear and out the other.

Anthony Kerstens P.Eng.