Sign in to follow this  
Followers 0
streaker69

SCADA Hacking...Your Impressions

6 posts in this topic

I'm currently doing some research for an upcoming presentation on SCADA Hacking and I'm wondering if maybe some of you guys that have extensive experience in PLC networks feel about the security of the networks that you work on. Mostly I'm wondering in your experience, what have you guys seen in the way of security? What do you feel are good security practices? What are some of the biggest issues you've seen that could be exploited? Feel free to post any comments or anecdotes that may apply. My presentation shall be video taped, and posted online a few weeks after it is presented. I shall return then and post a link to the video for anyone that is interested. Thanks.

Share this post


Link to post
Share on other sites
I think you're going to be scared with the results you get. I'll come back and provide my opinion on your questions a little later. I have a feeling that I'll be typing for longer than I have time now.

Share this post


Link to post
Share on other sites
Some simple almost cliche thoughts. 1. The first level of security is physical security. The more exposed you are the more risk. 2. I've not seen a lot of scada hacking. Most scada systems I've worked with were subnetted and not Internet exposed reducing their risk. 3. What is the return on investment from a scada hack. SHort of a terrorist attack to shut down infrastructure scada presents little gain to most hackers.

Share this post


Link to post
Share on other sites
Make the control network (and potentially SCADA) separate from the IT network. That is rule #1. You don't want office traffic screwing up your SCADA/HMI system. That also helps with security. And administration (IT people don't really understand control networks). Placing the PLC's on a separate VLAN is a good idea too, for the same reason. Setting up 3 separate physical networks however is probably not worth the effort. If you are running any "web-based" HMI stuff, make sure that you protect it with passwords and be rather gestapo about the passwords. In fact, view-only is best (that's what mine is). Don't let users have passwords if at all possible. Passwords are like keys...managing them becomes a major headache. You can expect to find post-it notes, little scrawled messages, etc., with the passwords on them. However, if you set up HMI security so that a particular PC is associated with access to a specific part of the network (plant), problem solved. I have no "passwords" except for a few specific areas ("backdoors" used specifically for backup/emergency use only, not for normal everyday use, and the distribution on the passwords is controlled) and the security problems have all but vanished ever since. SCADA/HMI "backends" are frequently very weak in terms of security and they don't like to document it very well. Best to treat it as "probably insecure" and treat it as such (firewalled/subnetted, etc.).

Share this post


Link to post
Share on other sites
I'm actually well aware of measures to take to prevent hacking. I guess I'm more interested in any anecdotes regarding poor implementations you might have run across in the field. Sanatized stories of course, don't want to embarrass anyone. Also, if you guys have heard of anyone that has hacked a SCADA network I'd be interested in any of those stories. I've found three instances on Google News so far, and all of them were people with intimate knowledge of the network. I'm looking to see if anyone has a documented case of someone with no previous knowledge of the network attacking one and actually making a noticeable process change. I've seen the CNN video of that generator self destructing, but I don't think their actual test was an adequate test of what a hacker could actually do.

Share this post


Link to post
Share on other sites
All right. I can't point to a specific incident. Only to the utter chaos that was going on in a plant I worked in. It was a Cimplicity system (server/client arrangement). The original configuration stored the user names and passwords on each client, and it tended to cache the passwords quite easily. Plus they only effectively had 2 accounts for the entire network (operator and administrator). So if the administrator accidentally left the password behind, goodbye security. It was pretty simple from there for some creative (bored) operators to figure out that the menu bar at the top of the screen (also insecure) had an "open window" command that included all the most recently opened windows...including other parts of the plant. And lo and behold...they could control things since there was effectively no security other than obscurity. Needless to say, the level of "pranks" and "strange things happening" depended on whether the operator screwing around with other parts of the plant was curious, mischievious, or even downright bent on settling some sort of score. Another problem with the "password cache" is that every so often if a password was erased, someone would come along that didn't know the plant password and would shut down a production line while someone had to go out and type in the password again. I am pretty darned sure that at least one person was routinely erasing the password cache and logging the machine out every time they wanted a smoke break. When I started there, I made three key steps. First, I divided the plant into functional areas and implemented security that didn't allow everything to comingle the way that it was before. Operators had view-only within their respective areas. Second, I fully rolled out the web-based viewing system that was always present but was never implemented for management/supervisors. Third, I actually intentionally created navigation screens that allowed anyone to "browse" the entire network without needing to know how to use the "open window" command. The result was that all of the control-related shenanigans disappeared. Supervisors were using the "remote view/web view" in all kinds of creative ways from "status displays" to "watching over someone's shoulder" to troubleshooting. Operators were using the new-found ability to watch other parts of the plant partly as curiosity but they were also starting to get used to the idea of how upstream/downstream operations affect each other. If you want chaos...we had one day where an entire production line went down suddenly in the middle of a run for 3 hours. I got called in. After the usual troubleshooting steps, I checked out the PLC. The electricians swore they didn't change the code but there were bugs in the code that suddenly appeared and crashed one of the machines in such a way that it would never run. While I was watching, RS-Logix (this was an AB PLC-5) came up with a message of standby, "program changed"...uploading new version, or something like that. Then another bug appeared. At this point, we implemented security (pulled the Ethernet cord out of the processor) and made local changes to get things running again after a few minutes. Turns out that a controls engineer from the corporate office was making changes without contacting anyone and for no apparent reason WHILE THE LINE WAS RUNNING. Unfortunately, this individual was son of a board member and thus blessed with teflon skin.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0