4 ms·

Were the affected systems running Windows? They should make it illegal to run critical systems on Windows.

by magduf 8y ago

voidmain0001 8y ago
Ah the immunity of non-Microsoft operating systems: https://www.intego.com/mac-security-blog/osxshlayer-new-mac-malware-comes-out-of-its-shell/ https://www.intego.com/mac-security-blog/osxshlayer-new-mac-... https://www.zdnet.com/article/eset-discovers-21-new-linux-malware-families/ https://www.zdnet.com/article/eset-discovers-21-new-linux-ma...
- magduf 8y ago
  Any actual incidents of these things causing real outages for critical systems anywhere? (I'm going to guess it's a big NO on the first one, because no one uses Macs for critical systems.)
bdamm 8y ago
Aside from being outdated advice, this is also globally impossible. Microsoft Windows has got a major lock on the industrial control systems industry. Almost anything being produced today has a Windows machine in the workflow doing something critically important, from monitoring fluid flows to running microchip programmers and test stations.
- magduf 8y ago
  Then people shouldn't be too surprised when stuff like this happens, and they should just pay the ransom: it's what they accepted by using Windows. "That's the way it's always been" isn't a valid excuse for continuing to make something unsafe.
  - bdamm 8y ago
    The advice is outdated because it is entirely possible for Windows machines to be secured well enough for this work. Windows security, like Linux security, is not a binary state with either a zero for no security or a one for security. They did not accept crippling ransomware by using Windows. Nobody does. This attitude is fatalistic and somewhat juvenile. They may have implicitly accepted crippling ransomware by not having sufficient internal security processes.
    - olavgg 8y ago
      You are right, but still using an operating system with such large attack surface like Windows is a worldwide industry problem. No one is saying Linux is much better either, but there are other solutions like IncludeOS(http://www.includeos.org/technology.html#security http://www.includeos.org/technology.html#security) which has a very low attack surface, if not 100% impossible. I'm not saying IncludeOS would work in this case, but secure systems has come a loooong way the recent years.
michaelt 8y ago
Even if a power plant's control systems are airgapped, if you can knock out payroll they'll be in a pretty bad place :)
kjetijor 8y ago
The problem isn't just windows - it's more along the lines of "narrow software" being very much sold "as is" with "strict and boneheaded compatibility requirements (run known vulnerable software/os)", combined with either consciously or unconsciously taking on the risk of doing so, with or without appropriate mitigations in place. Control software, or for that matter, software for a sufficiently narrow domain, tends to come "with bugs" and "for compatibility reasons you need to run this on OS/release version X (which is probably what the vendor ran at the point in time when the software were minted/released). I've had the displeasure of crossing paths with both the linux and windows variety of this. In some cases you can ignore the vendors and just upgrade, and jump through some amount of hoops to make it work. I'm sure in most cases you could engineer around this with isolating it from the world, although it may be non-trivial since it'll probably want to communicate over a network of some sort. Although - exactly what is needed in terms of achieving that may be less than well documented, it costs time and money, and is maybe not really budgeted for, there's aggressive installation timelines, and the security part is probably the first thing to get slashed from when the installation timelines starts slipping. The vendor just wants to sell you a black box, and preferably not touch it ever again after they've sold it to you. (Actually - some even do sell you a branded, badly engineered, stock PC running some variety of windows or linux or bsd, to control your winch/navigation/foundry/whatnot). I have witnessed "IT for offshore", in which a vessel is docked for X days, here's a list of things that we need to do, after X days the vessel will depart. You may have a few days on top of X days if you can leave somebody at the vessel, after X+Y days, the vessel needs to be somewhere in an operable state, because we have a commissioned work to perform. For say running a foundry, I'm sure much of this is similar, except the foundry doesn't have go anywhere - but having your foundry do nothing is exceedingly expensive, and making changes during production comes with a different set of risks. People have probably complained somewhere along the road, disagreeing with the risks, and somewhere higher up in the chain, the choice were made to take on the risk.

Were the affected systems running Windows? They should make it illegal to run critical systems on Windows.

by magduf 8y ago

Were the affected systems running Windows? They should make it illegal to run critical systems on Windows.

Ah the immunity of non-Microsoft operating systems: https://www.intego.com/mac-security-blog/osxshlayer-new-mac-malware-comes-out-of-its-shell/ https://www.intego.com/mac-security-blog/osxshlayer-new-mac-... https://www.zdnet.com/article/eset-discovers-21-new-linux-malware-families/ https://www.zdnet.com/article/eset-discovers-21-new-linux-ma...

magduf 8y ago
Any actual incidents of these things causing real outages for critical systems anywhere? (I'm going to guess it's a big NO on the first one, because no one uses Macs for critical systems.)

bdamm 8y ago

Aside from being outdated advice, this is also globally impossible. Microsoft Windows has got a major lock on the industrial control systems industry. Almost anything being produced today has a Windows machine in the workflow doing something critically important, from monitoring fluid flows to running microchip programmers and test stations.

magduf 8y ago
Then people shouldn't be too surprised when stuff like this happens, and they should just pay the ransom: it's what they accepted by using Windows. "That's the way it's always been" isn't a valid excuse for continuing to make something unsafe.
- bdamm 8y ago
  The advice is outdated because it is entirely possible for Windows machines to be secured well enough for this work. Windows security, like Linux security, is not a binary state with either a zero for no security or a one for security. They did not accept crippling ransomware by using Windows. Nobody does. This attitude is fatalistic and somewhat juvenile. They may have implicitly accepted crippling ransomware by not having sufficient internal security processes.
  - olavgg 8y ago
    You are right, but still using an operating system with such large attack surface like Windows is a worldwide industry problem. No one is saying Linux is much better either, but there are other solutions like IncludeOS(http://www.includeos.org/technology.html#security http://www.includeos.org/technology.html#security) which has a very low attack surface, if not 100% impossible. I'm not saying IncludeOS would work in this case, but secure systems has come a loooong way the recent years.

michaelt 8y ago

Even if a power plant's control systems are airgapped, if you can knock out payroll they'll be in a pretty bad place :)

kjetijor 8y ago

The problem isn't just windows - it's more along the lines of "narrow software" being very much sold "as is" with "strict and boneheaded compatibility requirements (run known vulnerable software/os)", combined with either consciously or unconsciously taking on the risk of doing so, with or without appropriate mitigations in place. Control software, or for that matter, software for a sufficiently narrow domain, tends to come "with bugs" and "for compatibility reasons you need to run this on OS/release version X (which is probably what the vendor ran at the point in time when the software were minted/released). I've had the displeasure of crossing paths with both the linux and windows variety of this. In some cases you can ignore the vendors and just upgrade, and jump through some amount of hoops to make it work. I'm sure in most cases you could engineer around this with isolating it from the world, although it may be non-trivial since it'll probably want to communicate over a network of some sort. Although - exactly what is needed in terms of achieving that may be less than well documented, it costs time and money, and is maybe not really budgeted for, there's aggressive installation timelines, and the security part is probably the first thing to get slashed from when the installation timelines starts slipping. The vendor just wants to sell you a black box, and preferably not touch it ever again after they've sold it to you. (Actually - some even do sell you a branded, badly engineered, stock PC running some variety of windows or linux or bsd, to control your winch/navigation/foundry/whatnot). I have witnessed "IT for offshore", in which a vessel is docked for X days, here's a list of things that we need to do, after X days the vessel will depart. You may have a few days on top of X days if you can leave somebody at the vessel, after X+Y days, the vessel needs to be somewhere in an operable state, because we have a commissioned work to perform. For say running a foundry, I'm sure much of this is similar, except the foundry doesn't have go anywhere - but having your foundry do nothing is exceedingly expensive, and making changes during production comes with a different set of risks. People have probably complained somewhere along the road, disagreeing with the risks, and somewhere higher up in the chain, the choice were made to take on the risk.