Question about current security stance of PLCs

electronbee

Member
Join Date
Feb 2012
Location
DC
Posts
4
Referencing, Stuxnet, and the FBI on how smart-power meters can be hacked... I am curious as to what type of security is in place in regards to PLCs and the like. Part of the reason for me to ask this question is that as a beginner, I am not as familiar with the terminology within the industrial controller segment. I do know how to program one now, and I can even get PeakHMI to work! (y)

But, as I am working on this research paper for my senior design project I want to address security concerns. I don't need a detailed explanation as I'd rather have a web link to online articles or some references so that I can read up on it myself.

Most importantly though, which terms to search by. Everything I know is within the realm of computers: TCP/IP, web, Windows, etc.

Thanks in advance!
 
I, for one, have no knowledge of any organized efforts to implement security against outside hacking into PLCs. I've been working in the industry for many years and, until Stuxnet, I was not aware of any attempts at hacking. But then again, I wouldn't expect it, either. PLCs are pretty closed systems with a minimal "WOW" factor should a hacker actually get in and do something. Where is the fun in that?

I think its safe to say that most PLCs are on stand-alone systems that have no connection to the outside world. For these systems we obviously won't be too worried about hacking. On the other hand there are many systems that do have such connections available, but even for those systems, access is typically difficult to obtain. Not only do you need the right programming software, the normal hacking methods for gaining access are not likely to work.

For my facility, I have adopted a method that should be pretty fool-proof. None of my machines can be directly accessed from outside the plant without someone intentionally making a hard-wired connection in advance. We can still gather and network data but this is done using a separate data acquisition system that has extremely limited capability. By the nature of its design, hacker-level (remote) modifications to the data acquisition can only affect it - not the machine's PLC. I feel comfortable that this low-level security method is my best answer.

As for those systems where such isolation is not feasible, I'm not sure what they already do or can do.

Good luck with your research and if you run across some data, please come back and share it with us. I know most people here would be interested in keeping up with any news on this front.

Steve
 
One place to start would be ISA S95 standard.
This would give you a good guidance on what ISA defines for infrastructure - which is not to say everyone has adopted it.
 
Hmi, Scada, PLC systems in general were not built with any kind of security in mind.(This begins to change slowly)

So, you have to use external controls to safeguard them.

Physically isolated interfaces.
Engineered Failsafes.
Air Gaps.
Network Security if networked(firewalls, routers, ACLs, intrusion detection, etc).
Monitoring for code changes and source code management.
Employee Training.
 
PLCs in general will not be "hackable". Only the types that use an OS with code, which most don't. There's usually no way, even with physical access to the PLC, to add something dangerous. To access a PLC, you need a connection, software, and the knowledge on what to do; as said above, the physical aspect is the one you need to watch.

When in a PLC-based system, it's site specific, equipment specific, etc. You have to basically have an engineer's knowledge of how the entire plant/system operates in order to sneak something in. That usually requires the programmer who did it, and that's a short path!
 
Yeah, while it may be true that making a really dynamic change at your facility would be a big WOW for you and your company, its nothing compared to locking up Google or an international bank where their moment by moment activities are monitored by half the world. That's what I'm talking about.
 
PLCs in general will not be "hackable". Only the types that use an OS with code, which most don't. There's usually no way, even with physical access to the PLC, to add something dangerous. To access a PLC, you need a connection, software, and the knowledge on what to do; as said above, the physical aspect is the one you need to watch.

Tom, I have to disagree. It seems to me that the goal of most hackers it to just generally mess things up. AB offers the entire software package necessary to go online with a ML1100 for free to anyone capable of navigating their webpage to the download page. :) Once a hacker figured out the IP address of a ML1100 on a poorly secured network it isn't much of a learning curve to go online and make some edits. Hell, I'd like to think I kind of know what I'm doing and I've successfully screwed up edits. These screwups had less than fantastic results as I take precautionary measures while testing. I doubt a hacker would be as careful. Imagine what you could do to a simple program with some random edits and what the results could be.

Password protecting the program would be an extra layer of protection but anyone who regularly reads this forum can tell you the general consensus on that topic. Keeping the switch in RUN instead of REMOTE would be best I doubt most practice this, I know I do not.

Shawn
 
Whilst I've never had a system "actively" hacked, in my first company I worked for we had the misfortune of picking up a virus (via a personal flash drive which a silly engineer had infected on their home computer and then used on a SCADA terminal). It spread rapidly across our networked machines, causing one to crash repeatedly every couple of hours.

Whilst no PLCs were affected, plant operation was. The operators were not receiving alarms from remote sites and were unable to adjust control parameters as the virus was hogging all system resources and causing the SCADA software to crash. It caused major mayhem and necessitated a 4 hour drive in the middle of the night for me to go and hunt the virus down, reinstall Windows and then isolate segments of the network to prevent re-infection.

Needless to say it was a big wake up call for us. We had sites all over the country that were networked together, and when we started evaluating the state of things after this incident we found plenty of problems:

a) Out-dated or no anti-virus installed.
b) un-passworded network shared drives.
c) SCADA machines typically running old, unpatched Windows XP.
d) firewalls not well set up or disabled.
e) No company security policy for SCADA Machines (the IT guys avoided any SCADA computers like the plague).
f) No active monitoring on our (the 3 control systems guys) part when it came to sites we weren't physically based at.

We had a few important business rule changes after that.

There is a bit of ignorance and arrogance among some control systems guys who think their job is so hard that no one else could do it. While you might have to be a good PLC programmer to make a plant work well, as shawn_75 said it's pretty easy to wreck things without a lot of knowledge.

I've helped out a few clients who have had their control guy leave / contractor be difficult, and it's actually a lot easier than you would think to poke around a network and figure out what's what, just with a Windows command prompt, Ping and a couple of port sniffing tools.

Control system security is something that definitely needs to be taken more seriously these days. the trick is to get a balance between security and usability. If it's locked so tight and no one has the keys to do anything, you might as well just unplug your SCADA Computer from the network anyway. I think that all control systems people should at least have a basic working knowledge of network security, keep themselves up to date on Operating System vulnerabilities and patches, and implement regular checks to ensure things are as they should be.

I found this a reasonably good document to familiarize yourself with different issues relating to ICS security.

http://csrc.nist.gov/groups/SMA/fisma/ics/documents/oct23-2009-workshop/nist-ics3_10-23-2009.pdf
 
Ooh... awesome replies, especially the document links. It would have taken me forever to come to that point on my own!

The reply by Saffa was very informative. Despite that a PLC is a stand alone device, if you have SCADA and you need the SCADA terminals to get plant status and they go down, that is another vector to consider for a security breach, intentional or not.

It seems that industrial control systems are lagging behind all the other industries. I was wondering if there was any form of authentication systems in place when accessing a PLC, or, if its simply assumed that, "if you have the password you belong there", type thing. Nothing that even a wireless network could have with even basic WEP and MAC authentication.
 
For most PLCs, Like information systems in general btw, Physical Access means you OWN it.

Some have passwords to limit what you can do, ie, see the code, edit the code, etc. But most will cheerfully let you wipe em and start over as you see fit, Password or no.
 
I was wondering if there was any form of authentication systems in place when accessing a PLC, or, if its simply assumed that, "if you have the password you belong there", type thing. Nothing that even a wireless network could have with even basic WEP and MAC authentication.

There are moves to implement this on the I/O server side, i.e. to access data from an OPC server your client would need a user name and password. However, as far as I know, there are no common PLCs that have any form of authentication within the PLC itself. Basically, this means that if you were to use an unsecured I/O server or your own software to send a message to the PLC, it would respond regardless of who you are. The DF1 protocol for SLC / Micrologix AB PLCs and of course Modbus protocol are both very simple and there are plenty of open source implementations of both.

You could pretty much guarantee to cause havoc simply by writing zeros to a bunch of registers in the N7 file in a Micrologix for example.

I think in the near future we will see better security implemented directly in PLC hardware, but probably only in the higher end controllers.

Until then, careful network design to minimize exposure, and PC security is the only real defense.

Of course as Dravik said, if someone can physically walk into the plant that doesn't help either. I've arrived at remote treatment plants before and found the gates unlocked and the key under the mat... Too much effort to lock up!
 
If PLC were implemented on a scale that required wireless this would be bad. As, I can successfully clone any given wireless device, MAC address and all, and take over. I've done this for a few labs of mine and it takes some time to crack the WEP or use WPS to get the WPA key. But, if one were determined enough to spend 8 hours on it, it could be done to 98% of wireless out there. :/

Any ways, good info for the uninitiated. I appreciate the responses.
 

Similar Topics

I have a Pump 1 Current in my Local:5:I.Ch00Data address. I need to add this to my ladder logic program as the goal is to have it eventually be a...
Replies
2
Views
1,466
Hello, I'm using a Micrologix 1100 (1763-L16BBB) and have a question on what current I would be getting out of one of the transistor outputs...
Replies
4
Views
2,211
I'm using a 40HP variable frequency drive to power a 30HP motor. The manufacturer specs list 60A as the input current of the drive. Is that 60A...
Replies
5
Views
4,873
So I am working with a 1769-L32E and I have two input modules 1769-IF8 and one output module the OA8. I know that you can only power 8 module...
Replies
2
Views
1,438
I am currently looking for a solution to provide proving status of a DC motor. The DC motor I have draws maybe .4 to .5 DC amps. very small. I...
Replies
6
Views
2,513
Back
Top Bottom