Posts

,

The problem with ICS security improvements

In the BruCON workshop on ICS and SCADA security (which you can read about here), we learned how to hack ICS systems using Wireshark. In the progress of which we also came to some conclusions about problems with ICS security in real life.

One problem with ICS and SCADA systems is the limited hardware. Old PLCs run very limited chipsets, not at all comparable to the hardware that now runs our small devices. These systems were only designed to handle a very small set of data and logic actions. Even if you wanted to include them, there just isn’t any room for advanced software features like proper authentication or encryption.

Furthermore, many industrial facilities are now using unsupported PLCs. Upgrading security would mean replacing all of these old devices.

Then, if you decide to do so, making changes in the PLC environment is not so simple, when the environment is live. The focus of the business is on uptime. Awareness of ICS security is too low, so security improvements are not held in great value by the business, compared to the cost of stopping a production line.

,

Workshop ICS Pentest 101: A Junior’s View

Last month I attended Brucon 2017, the leading Belgian security conference held at the University of Ghent. The conference offers talks by renowned speakers and you can get your hands dirty in a variety of workshops. I attended ‘ICS Pentest 101’ by Arnaud Soullié and Alexandrine Torrents from Wavestone, a French consulting company. Since I had no prior knowledge of SCADA and Industrial Controls Systems (ICS) whatsoever, I was on unfamiliar ground.

I tried to imagine beforehand what pentesting ICS and SCADA systems would look like: some Hollywood style hacker plots came to mind, like scenes from ‘Mr. Robot’. Hackers can easily take control of machine rooms, robots, elevators and ventilation systems with rather unrealistic hacking methods.
I did not realise those scenes weren’t too far from the truth.

First, Alexandrine gave an introduction about how these systems actually work. She showed us how Programmable Logic Controllers (PLCs) of known manufactures, like Siemens and Schneider, function. She provided us with virtual machines to experiment with and we played around with simulated PLC software.
In Mr. Robot, when Elliot wants to take control over a factory or power plant, he simply needs to physically plug in on the network where all the PLCs are placed, to gain control over the machines. Because there is no data encryption or any form of authentication, he can simply intercept the traffic and make changes on the fly to tamper with the network traffic that is being sent to the machines.
This is exactly what we experienced during the workshop. We intercepted network data with Wireshark and edited it to change a machine’s behavior. We also learned to attack the unpatched PLC itself to take control of the system.

If these systems were critical for safety, holy *% !

,

How do you build a (modest) ICS testing & training lab?

Part of training people into becoming ICS security specialists is providing them the opportunity to test or train certain things in a ‘safe’ environment. Which means you’ll need a (modest) ICS testing & training lab. There are some great labs out there (Idaho National Labs for example), that offer every test set-up you can think of. But not all companies have the resources to build a lab of that scale.  For most companies or organisations a testlab environment limited to simulations of their own processes is just fine. There’s quite a bit of information you can find online about building such a lab. And usually it’s suggested that building it is fairly easy. Is it really?

You need ‘real’ stuff…

To build a representative lab you should have ‘real’ stuff in it. And with ‘real’ stuff I don’t mean having one or two Progammable Logic Controllers (PLC) combined with some Remote Terminal Units (RTU). A real ICS lab should contain everything that is present in a real environment. To simulate a power plant for example, you would need an actual Distributed Control System (DCS) that connects to several PLC’s, RTU’s, sensors etc. so that those devices can be taken into account during a simulated test/training. It is also important to have a real (physical) process running behind it so that physical impact of attacks can be observed properly.

…and network environments

And that’s just the process side of the testing lab. Your ideal lab should contain more than just that. This means that supporting environments for the process side should be included (think about the fire detection system, physical access systems, PI/OPC gateways, etc.). And don’t forget to include a simulated office environment with all regular business services in it (e.g. email server, file sharing, intranet, etc…) as well as a “simulated Internet”. These should be included to simulate different attack scenario’s and investigate different possible attack paths. You can play the role of an attacker on the “simulated internet” and try to get in or you can assume that you have physical access to the corporate offices and put yourself into the simulated office environment.

Where to start?

You have several options, depending on how much you are willing to spend on your lab. You can check eBay and buy several old or decommissioned RTU’s/PLC’s, or you can look out for decommissioned plants and buy their equipment. Another option is to procure training kits from big(ger) SCADA vendors such as Siemens, Phoenix, ABB, Scheider Elecric, etc. Or you can build things yourself with small devices such as Raspberry PI or other alternatives. Don’t be afraid to experiment and combine several things/vendors together. Make sure you also have servers (for virtualisation purposes), switches, hubs, routers, firewalls etc. and learn how to use them. By building your own testing environment you will certainly learn a lot on basic networking skills.

Testlab procedures

Once your lab is ready to be used, make sure to create some procedures. Take especially good care of staging, as this is often forgotten. Nothing is as frustrating as losing a lot of time to get your lab back to its original state after a successful ‘attack’. At this stage you will be very happy if you have a (tested) staging procedure which gives you an easy step-by-step guide to revert to a known good state of the lab.

Got any experiences with building or using ICS test labs? Then let us know via the comments below.