Siemens fixes SCADA holes found by hacker Siemens has patched security vulnerabilities in its widely used Simatic S7 industrial computer system that made it possible for attackers to disrupt or sabotage operations at gas refineries, chemical plants and other critical facilities. In an advisory (PDF) issued on Friday, the Industrial Control Systems Cyber Emergency …
Would
1) foolishly assume that being on a private network provides any meaningful protection, despite recent public demonstrations of the opposite
2) foolishly show off his foolishness in public, without even posting as AC
The problem isn't the absence of the private network, it is (amongst other things) the presence of pointy headed bosses who are dependent on Window boxes and their inevitable vulnerabilities, despite engineering best practice that plainly demonstrates otherwise.
With the greatest of respect, the real issue is not specifically with the PLC even if this specific one is, the real issue is with the brainless PHBs who seem to think there's no need for robust system architectures because nothing has gone wrong so far, and even if there's an occasional hiccup, it probably won't be repeated.
The windows dependent monoculture *is* the prime example, but many people are now beginning to realise that the proliferation of insecure communications between stuff that matters is potentially a bit of a problem too.
This kind of insecure stuff probably wouldn't be allowed in the bank-to-bank world, but there's money at stake there. Here, we might occasionally be looking at lives at stake.
Up to now it is being assumed that there are just 2 attack vectors:
- Via the PC (probably Windows based) that compiles/uploads the logic to the PLC - and into that PC in the first place via a USB stick assuming the PC was not net--connected.
- Directly via the internet in a net connected SCADA.
What about vulnerabilities in the communications bus itself? The protocols are usually proprietary rather than TCP/IP BUT any remote sensing/actuator device is a potential point of entry into the bus. These remote points are of necessity... remote and often outdoors. Oil pipelines anyone? Any device could be hot-swapped for a doctored one... to introduce stack overflows via some weakness or to pretend it is a control node.
Most remote PLC's are connected to the server via phone lines in most cases using either ethernet via DSL etc or via outstations that talk to the PLC.
The problem with this approach is that if you have the comms protocol and phone number of the site its easy to try to connect.
Otherwise its down to the same approach as trying to connect to any pc out there.
Also as companies such as Utilities have so many of these things in remote locations it can take months to get round and update the firmware then test all software in the PLC to ensure its still working.
On top of that many of these remote sites don't have any security above a lock on the door or padlock.
Note how easy it was a few months ago to bring down so much of the mobile network a few months ago via a simple breakin........
Where does the PLC program come from in any non-trivial PLC?
Where does the PLC program get backed up to from any non-trivial PLC?
In days long ago that job would have been done by something sometimes called a "programming panel".
Today's "programming panels" are (mostly) PCs. They may even be off the shelf laptops with a bit of special software, although some of them may be more specifically industrialised PCs. But courtesy of the certified Microsoft dependent who have been allowed to take over, the chances are these boxes will be running Windows, and will have all the associated vulnerabilities.
Worse, there is a fair chance that because these boxes are not part of the "IT estate" they will not be fully patched, and a fair chance that they will not have up to date anti-malware. Consequently they will have all the extra Windows vulnerabilities that implies
Some of the time these "programming panels" will be connected to the "secure" automation network to talk to PLCs. Some of the time they will be connected to the office network, to print documentation, download specs, whatever. But there's no problem with that, is there, if the OS is sufficiently secure to not be a malware transfer mechanism?
Are you getting the picture yet?
If anyone can point readers to a non-Windows-based PLC programming system, it sounds like there are readers here waiting to be enlightened, and possibly there are sales opportunities to be exploited. If the PHBs can be persuaded.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
