Three reasons why you should segment your SCADA networks
The recent report on eWeek regarding how attackers managed to get a foot hold into an energy company through a phishing attack is not something new. It is not magical because stuff like this happens elsewhere on a more frequent basis. What makes this so noteworthy is the fact that the company was in control of a nation’s critical infrastructure: its energy. Also noteworthy is the fact that it was even reported. This sort of thing is usually kept hushed. That is until something really bad happens.
Now, onto the unsurprising stuff. I’ve been onsite in Oil & Gas exploration and production plants in the Middle East. They’re quite impressive plants run with the strictest of controls and paramount importance given to health and safety. As a security consultant, I was, however, appalled at the lack of security awareness the plant personnel have. Understandably, this is to be expected. The plant production teams have only one thing on the mind: ensure the plant functions and production is not hindered. Availability is paramount. Security is secondary.
In a SCADA* environment, there are two major domains. The Production Domain is where you’ve got all your components like the Control System, Remote Terminal Units and/or Programmable Logic Controllers, communications network, Human Machine Interface and the Data gathering system. The Enterprise Domain is where you have all your daily supporting infrastructure. So your Microsoft Windows Domain, file servers, print servers, etc will reside here. Your Internet connections will also reside here; so people can browse and check their email.
* I’m referring to SCADA here to encompass everything. Including the DCS, RTUs/PLCs, HMIs, network, etc.
I don’t care what anyone says, these two domains need to be kept separate; at least until there is a much better understanding of the technology and security within the SCADA environment. There should be no reason why the two have to ever touch. Sadly, this is still something that has not begun to filter down to the various companies owning and operating such large scale critical infrastructures. During my project in the middle of the desert, I had first hand experience where these two domains were hopelessly enmeshed. As a matter of fact, I was there to separate the two domains by using a firewall. I collected a considerable amount of data. A high percentage showed well known virus and worm activity on the network. So here are the reasons why you should segment your SCADA networks.
Reason 1: SCADA Computer systems run older patch levels of operating systems
SCADA system vendors design and develop their software based on a specific revision of an operating system. If you are running different versions of the operating system, older or newer, they will refuse to support you. Well, they will insist that you bring your OS revision down to the correct version before going any further. This is not something uncommon, I’ve seen the same setup in the Banking industry where Internet Banking system or Core Banking system will depend on specific versions of Oracle or Tomcat. If you run a different version the vendor says, “Well, we don’t really support that version.”
In most cases, vendors of such software will never be able to keep up with the incessant flood of updates and security patches to operating systems. Bottom line, you will always be running an older version of an operating system which will be prone to publicly disclosed vulnerabilities.
By segmenting and keeping this set of unpatched systems away from the high-threat environment of the Internet is plain good sense. Sure, its not the ideal situation (like having a patch management system in place), but its a start.
Reason 2: SCADA system operators will not know not to click on that link in the email
Take the case in eWeek with the energy company. One of the operators fell victim to an email asking him to click on the attachment. As I stated before, the production or process team guys are only interested in production. SCADA is a vast, specialized and complex subject. You can spend quite a while studying its myriad of topics and subtopics. The process team guys are not going to spend any extra time getting to know topics on information security.
I believe that there should be a security awareness project that is more or less entwined into the everyday lives of the operators – much like you have a health and safety program. However, that’s a topic for another post.
Splitting the two areas will act as a barrier between a compromised operator’s PC and the sensitive production servers.
Reason 3: The inconvenience provides a grounding on the topic of security
Having to shuttle between two PC’s to do ones job is a pain in the ass. I’ve done it before. Back when I was working at one of the Telecommunications providers we had a PC for the corporate network (no Internet access) and a PC that was capable of Internet access. I still think that in my case it was stupid (although the corporate network never suffered any external attacks), but in a SCADA environment, it will give the operators an idea of how important it is to have distinct networks like this. It sets the foundation for rolling out a SCADA security program. (It really looks like I need to write that topic in the future.)
Lets face it, the vendors will care about security, but most likely not to an extent where it is attended to in minute detail. Further, vendors doing security is usually a recipe for failure and a conflict of interest. I’ve seen at least 7 banking systems fall victim to this. You need to have your systems audited by a third party if you are to have a true picture of how capable you are of withstanding attacks. Having said this, jumping in and hacking a live SCADA network is an even bigger recipe for disaster. The approach to SCADA security should be a carefully built one. I will cover more topics on this in a future post.
