1

The current trend goes to make every device accessible from the Internet for convenience, economic reasons and so on (sometimes even including the control station of a power plant).

But many industrial solutions like SCADA systems, Motor Control Units of cars, industrial robots, railway control, medical devices like X-ray machines, and so on run not updated for decades because:

  • The manufacturer does not provide updates
  • Updates would require revalidation/recertification (internal or by an external organisation/governmental authority)
  • Updates are not allowed (manufacturer officially supports only a specific patch-level of the underlying OS, and so on)
  • "Never change a running system" (especially if the update might cause life threatening situations/liabilities)
  • From some insiders of these branches I heard that some of them are only allowed to use compilers 5 years or older, because this way they think about all bugs in the compiler are found in the 5 years and use the official list of bugs of that compiler and use the workarounds for them.

Running Windows NT 4 is not unheard of in these environments for these reasons.

My first step would have been to use HTTPS/SSL to secure the channel but most of us have heard of Heartbleed, POODLE, Diginotar, etc. which require updates within days or faster. But this would be impossible because revalidation normally takes weeks or months and leaves the system vulnerable in the meantime. Next there could be vulnerabilites in the network-stack, authentification, and other subsystems.

So how would one design security in Internet/network-facing industrial devices running for decades where malfunctions could cost lives?

(This is just a hypotethical question since I am not involved in developing such devices and the insiders I know could not answer my questions. This question mainly focuses on the embedded device or the computer/device controlling the device and an attacker trying to gain access to it/control it.)

closed as too broad by Steffen Ullrich, Xander, Neil Smithline, schroeder Dec 29 '15 at 2:48

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • One would probably first make a detailed threat analysis for the specific use case so that one can focus on the relevant problems instead of trying to fully resolve the very broad problem you describe here. Therefore I consider this question as too broad. – Steffen Ullrich Dec 28 '15 at 21:55
  • @SteffenUllrich now better? (added "and an attacker trying to gain access to it/control it") – H. Idden Dec 28 '15 at 22:02
  • Not really better. If you want to protect something you have to first make a detailed threat analysis. Such a broad problem description you have only allows a shallow analysis which will only result in shallow and thus more or less unusable advice. – Steffen Ullrich Dec 29 '15 at 7:11
3

Your 'first step' is actually the trap the industry fell into. By believing that there is a way to put these systems online without a thorough understanding of the security domain, and without providing a way to upgrade the security components without compromising the integrity of the rest of the systems, they trapped themselves with process dependencies on ancient, insecure protocols. By that, I mean they offered the promise of cheap remote-controlled maintenance, so they eliminated the need for expensive experts to travel to remote sites. They reduced head-count; which left themselves utterly dependent on the remote control systems. They can't shut them off now even in the face of a cyber-security emergency, because they depend on that control to keep them running.

The first step is to segregate the internet facing components from the rest of the systems. Leaving the system controller online and hoping its integrated sign-on page from 2003 will keep it safe is a failure.

Because SCADA networks are so vulnerable, the entire ICN needs to be firewalled from every other system; including other internal systems and networks. View yourself as the SCADA operator and assume that everyone else in your organization, including your sysadmins and network admins, is attempting to hack into your SCADA network - then defend that.

It may be that you have no adequate defense, or that the risk of compromise is too great in terms of safety. An air-gap is the last, best defense; even then, it's not perfect. Stuxnet was an example of an ICN attack that leapt the air gap using a 0-day exploit on a USB drive.

  • So encapsulating them from the internet and all other systems is the only way? So no remote-hands for failing cars like some upper-class cars provide? No remote support for heating/home-automatisation like many vendors sell today? Would this mean that the whole "Internet of Things" thing will bring us an unavoidable security-fiasko as it is not even possible for high-cost systems? – H. Idden Dec 29 '15 at 0:24
  • @H.Idden, I never said "no remote", I said that it couldn't be adequately secured based on risk. For example, I have a sprinkler system that's online that I don't think is very secure, so I keep it firewalled outside of my home network. Yes, the IoT is a security fiasco in the making, but because it's a million tiny things, there isn't going to be a single big newsworthy event. – John Deters Dec 29 '15 at 6:05
2

Don't embed the internet-facing part of the software in the device itself. Ideally the device should only have simple software (running on a microcontroller) that's responsible for basic functions of the device (like checking safety interlocks before turning on dangerous things or handling features that require precise timings) and communicates with the outside world via a simple, standard interface like a serial port.

Everything else should be handled via software developed for a general-purpose OS, so it can be updated independently from the vendor (strangely enough, I would actually recommend Windows for this - its backwards compatibility is pretty good, I can still run XP-era software just fine on Windows 8.1) rather than binding the software to an entire OS that can't be updated once the vendor doesn't provide updates. Also the protocol to talk to the device should be published so that a third-party can reimplement the original software should it no longer be able to run on a modern OS.

Also the recurring costs for keeping the device secure (including rewriting the software if needed) should be accounted for in the total cost of ownership/maintenance of the device.

Finally don't put things on the Internet if they don't require it - it's a risk versus trade-off situation as no software is secure, and in this case I'd say putting the device on the internet should be a last resort solution due to the cost of a compromise (a loss of human life can't be expressed in $$$), and if it was decided to put the device on the net then proper precautions should be taken, like hiding it behind a VPN gateway and training users about correct security practices (I've seen lots of SCADA devices with default passwords, meaning that it is no longer a technical problem but a human one)

  • 1
    Just an FYI, a human life can indeed be expressed in terms of money. Our state's DOT has a finite budget for safety improvements. If a roadway has some safety issue (like a stop sign that should be a traffic signal) and a person is killed in an accident as a result, they will install upgrades if the cost is less than that amount. A long time ago it was about $250,000, but now I seem to recall it's around $3,000,000 per life lost. – John Deters Dec 29 '15 at 6:15
  • when you're working in security, especially in risk management, you are constantly evaluating risk vs. cost. If you said "my team and I are responsible to do everything possible to protect life", then I certainly admire you, but your organization's safety budget is still only your team's salary plus your team's budget - it's not infinite. That means your organization has placed a value on a human life. No one has an infinite budget, so safety protection has boundaries. Even though it's distasteful to discuss human life in terms of money, it's irresponsible not to. – John Deters Dec 29 '15 at 14:00

Not the answer you're looking for? Browse other questions tagged or ask your own question.