My last column on security ("Wolf at the Cyber Door?" September 2012, ) touched a nerve.
You might remember that a water plant SCADA system apparently was hacked, and a pump failed. These two unrelated events were forcibly related. One was because of the other. This was shown to be untrue, but the psychological effects of such behavior linger in the depths of us control guys.
I had some very concerned responses to my last column, and those people should be concerned. Regardless of the size of the installation or the process, the lack of security can be costly.
One reader was adamant that having control systems available on the Internet is a disaster waiting to happen. While certain pieces of information are needed to find a SCADA server, a denial of service (DoS) attack can happen at any time by using common data structures such as Hash Table and/or Hash Map and storing POST data. Should a DoS attack happen, the operators would be unable to perform actions such as responding to alarms.
The code to perform this DoS attack was published Dec. 27, 2011, and can be active on any web platform. Scary, eh?
Another example involves a hacker trolling for certain data packets. The company that was targeted makes automotive parts. The IT guy had set up the company's Internet service with AT&T and, of course, the router tables reflected the local setup, along with a static external IP, which was required for remote monitoring and configuration, as well as remote site access into the system.
The hacker(s) "learned" the IP address of the router, and tried to break through the user and password combinations. The IT guy was alerted and, after a few hours, determined what was happening. He changed the IP address of the router with AT&T, and within 10 minutes, the hacker was at it again. How did he get the new static IP so quickly? Still a mystery, but he altered the rules on the router to simply reject all traffic except for specific MAC addresses and associated IP range.
If the password rules had been lax, much damage could have resulted. Another reader lamented that when he asks for a password for the operators, he gets "1234." That's just asking for trouble.
I write in Visual Basic (VB) for various reasons. In that community, there are many developers, and I found a complete VB project for a network client/server application that facilitated file transfer from one machine (client) to another (server).
How many developers use scripts and ActiveX-type controls in their applications that no one knows about? I suspect many.
Not surprisingly, malware has become very smart. Polymorphic malware is auto-morphing, which means it changes on its own. So normal detection might work once, but not a second time because of the way these viruses are detected. Should a network connection such as a remote connection into the firewall be compromised, software can be loaded onto the target computer, and can go many places from there if allowed.
Another reader sent me a link to an article about how IT needs to help secure industrial control systems. For a municipal SCADA upgrade I'm involved with, I asked who in the IT department looks after their servers and client machines. They told me it was their system integrator. Huh? I can tell you they use pcAnywhere for remote access, and the SI uses the same password for all projects. Yikes!
No IT involvement, so I can tell you that they are not that secure, except that the Access Control List is kept by a wireless company. They are protected, but if it was a typical LAN/WAN setup, not so much.
How can we help ourselves? Some of the more simple things would be a password process, involve IT for security and access, and if necessary have a control network firewall that is separate from the company network.
In the end, ask questions of your integrator and/or your own developers. Trust with verification is paramount, and disable all USB and CD activity. A thin-client approach might be able to thwart local sabotage, since many actions are initiated from inside the firewall.