I have been hearing a lot about security breaches occurring in the last year like these:
http://www.wired.com/threatlevel/2011/03/scada-vulnerabilities/
How is Ignition different than the systems quoted (Iconics, Siemens, Datac, 7-technologies etc…)??
And what would you guys recommend to protect against hackers?
I believe that Ignition has everything that you need to implement a secure setup. That said, designing a secure system involves all the other pieces of your network. There really is no magical silver bullet.
I can’t speak to every product out there, but we can discuss trends. The SCADA market was incredibly weak with respect to security in the late 90s, early 2000s. I would say that integrators and end users alike valued availability (is the system up) and put little importance in security. For example, how many times have you heard people never do operating system updates on SCADA systems for fear of breaking it? While substantiated in the Microsoft dominated industry, it promotes poor security practice. Better yet, how many plants have you seen where all the operators share a single username and password? Very little pressure was put on vendors to encourage secure practices. Users would typically buy software from the company that sold them hardware without a second thought.
The gaping vulnerabilities that come to mind are the result of old technologies and poor practices. For example, DCOM (which is the basis of OPC-DA) presents security issues. The Siemens issue of hard coding the database password also comes to mind. There are actions that you can take to mitigate these issues. Use an OPC tunneller, isolate networks, patch and update your software, etc.
Ignition was created by individuals with IT backgrounds. By design, it leverages proven technologies. Traffic may be encrypted with SSL, database connections are standard (ODBC/JDBC/etc), minimal ports are used, minimal “home written” components or concepts are applied when standards exist, etc.
Implementing SCADA security in Ignition is about the same as securing any other IP network. Use a “defense in depth” model of layered security. Implement firewalls, turn off services that you don’t need, patch your devices, etc, etc. Consider an isolated network if possible.
Thanks, Nathan. Good information.
It would be interesting to take all of the advisories that he published (you can find them here) and go through each one and see how susceptible Ignition would be to each category of attack. Since I don’t have the time to do it this minute, I’ll make the following observations:
Most of his attacks are buffer-overflow errors, where more memory is allocated than expected by the program, or something similar. This is a point where we benefit from using a modern language like Java, which checks array bounds automatically for each call. The result of these attacks are, in the worst case, the ability to run arbitrary code, and in the best case, crashing the server. With Ignition, and Java (thanks to structure error handling), the range becomes worst case program crashes or some functionality stops, best case an error is logged an everything continues. I would suspect there are parts of Ignition that probably wouldn’t handle this in an ideal manner, but you definitely wouldn’t end up with hackers running arbitrary code.
Other attacks come from the applications listening for commands on an open port. From what I gathered by his descriptions, it really is a tcp port listening for commands like “download file” and “write value”. This is horrible. Of course, since all of our communication is going over tcp from the client to the gateway, you might think that we’re susceptible to something like this. There are a few things that help us: first, sessions. To do anything, you must have a user session, and must have authenticated either through encrypted password, or with active directory, etc. With a session established, it would still be possible for a hacker to gain access- at any point after the session is created, it could grab that session id and start using it. This is a well known attack called “session hijacking”, and can be prevented with SSL. And then, all of this assumes they have access to the network that this is hosted on, which is something that all of these articles like to say is improbable. With firewalls, VPNs, etc., it probably is improbable, but our goal is that the system should stand on its own even fully exposed to the public (as much as it’s in our control).
If you read through those advisories and come up with another category of attack, please post it and we’ll see if we can analyze it!
Regards,