back to article 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 …


This topic is closed for new posts.
  1. Charles Manning

    Only a complete fool....

    ...would set up SCADA on an open network.

    SCADA should always be on a private network. If you need to allow remote access then only do it via VPN.

    1. John Smith 19 Gold badge

      @Charles Manning

      "Only a complete fool....

      ...would set up SCADA on an open network."

      You might like to review the recent history of attacks on pumping stations and other bits of industrial machinery and utilities.

      There are quite a few of them about.

  2. Christian Berger

    Only a complete fool....

    ...would build a SCADA system based on MS-SQL using all those fancy 1990s Windows features making the code impossible to port.

    SCADA systems should be simple monolithic systems which you can just pop into a rack without complex installation.

  3. Anonymous Coward

    Only a complete fool


    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.

    1. Filippo
      Thumb Down

      More complete fools

      I wish people would stop copy'n'pasting Windows-bashing comments on every security-related article without even reading it. This has absolutely zero to do with Windows. The issue is with the PLC.

      1. Tom 13

        If the PLC is completely unconnected to potential malcontents

        it is completely secure. The malcontents seem to gain their access mostly through compromised Windows PCs. So I'd say this is a 50-50 split on whether or not it has anything to do with Windows.

      2. Anonymous Coward

        "The issue is with the PLC".

        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.

  4. Filippo

    firmware patches

    Considering how things go in the industrial world, most systems won't get patched for years or decades. This vulnerability is here to stay. SCADA should definitely always be behind VPN. At the moment, due to the prevalent mindset, there is simply no way to make it secure.

  5. Nigel R Silver badge

    what about the comms bus as an attack point?

    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.

    1. Anonymous Coward

      Don't worry, the Chinese are on our side. Really they are.

      I believe in the backbone telecom world this is called the "oh f***, we let Huawei get the business" scenario.

  6. Big_Ted

    Open network........of course its open.

    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........

  7. Anonymous Coward

    "If the PLC is completely unconnected to potential malcontents"

    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.

This topic is closed for new posts.

Biting the hand that feeds IT © 1998–2021