Slashdot Mirror
Is Analog the Fix For Cyber Terrorism?
chicksdaddy writes "The Security Ledger has picked up on an opinion piece by noted cyber terrorism and Stuxnet expert Ralph Langner (@langnergroup) who argues in a blog post that critical infrastructure owners should consider implementing what he calls 'analog hard stops' to cyber attacks. Langner cautions against the wholesale embrace of digital systems by stating the obvious: that 'every digital system has a vulnerability,' and that it's nearly impossible to rule out the possibility that potentially harmful vulnerabilities won't be discovered during the design and testing phase of a digital ICS product. ... For example, many nuclear power plants still rely on what is considered 'outdated' analog reactor protection systems. While that is a concern (maintaining those systems and finding engineers to operate them is increasingly difficult), the analog protection systems have one big advantage over their digital successors: they are immune against cyber attacks.
Rather than bowing to the inevitability of the digital revolution, the U.S. Government (and others) could offer support for (or at least openness to) analog components as a backstop to advanced cyber attacks could create the financial incentive for aging systems to be maintained and the engineering talent to run them to be nurtured, Langner suggests." Or maybe you could isolate control systems from the Internet.
Rather than bowing to the inevitability of the digital revolution, the U.S. Government (and others) could offer support for (or at least openness to) analog components as a backstop to advanced cyber attacks could create the financial incentive for aging systems to be maintained and the engineering talent to run them to be nurtured, Langner suggests." Or maybe you could isolate control systems from the Internet.
the terrorists are like cylons and we need to disconnect all networked computers for humanity!!!
Sounds to me like you need a better A/C system.
Or you need to not consider an HVAC system to be so critical that it can't be on the network. Or, perhaps you need to design the HVAC system to take only the simplest of input from Internet-connected machines through interfaces like RS-422, and to otherwise use its not-connected, internal network for actual major connectivity. And design it to fail-safe, where it doesn't shut off and leave the data center roasting if there's an erroneous input.
And anything that is monitored three-shifts should not be Internet-connected if it's considered critical. After all, if it's monitored three shifts then it shouldn't have to notify anyone offsite.
Do not look into laser with remaining eye.
analog is actually more suceptable to interference generated by rather simple devices, as there is no error checking on whats being fed to the system
the problem is your reactor is for some fucking reason hooked to the same network as facebook and twitter
As a compromise, one can always do something similar to this:
1: Get two machines with a RS232 port. One will be the source, one the destination.
2: Cut the wire on the serial port cable so the destination machine has no ability to communicate with the source.
3: Have the source machine push data through the port, destination machine constantly monitor it and log it to a file.
4: Have a program on the destination machine parse the log and do the paging, etc. if a parameter goes out of bounds.
This won't work for high data rates, but it will sufficiently isolate the inner subsystem from the Internet while providing a way for data to get out in real time. Definitely not immune to physical attack, but it will go a long ways to stopping remote attacks, since there is no connections that can be made into the source machine's subnet.
There's a lot to be said for this. Formal analysis of analog systems is possible.The F-16 flight control system is an elegant analog system.
Full authority digital flight control systems made a lot of people nervous. The Airbus has them, and not only do they have redundant computers, they have a second system cross-checking them which is running on a different kind of CPU, with code written in a different language, written by different people working at a different location. You need that kind of paranoia in life-critical systems.
We're now seeing web-grade programmers writing hardware control systems. That's not good. Hacks have been demonstrated where car "infotainment" systems have been penetrated and used to take over the ABS braking system. Read the papers from the latest Defcon.
If you have to do this stuff, learn how it's done for avionics, railroad signalling, and traffic lights. In good systems, there are special purpose devices checking what the general purpose ones are doing. For example, most traffic light controllers have a hard-wired hardware conflict checker. If it detects two green signals enabled on conflicting routes, the whole controller is forcibly shut down and a dumb "blinking red" device takes over. The conflict checker is programmed by putting jumpers onto a removable PC board. (See p. 14 of that document.) It cannot be altered remotely.
That's the kind of logic needed in life-critical systems.
That's because CS is math, not engineering. Computer Engineering is engineering, Computer Science is the study of the mathematics of computer systems. CE is a lot rarer than CS though, so a lot of people with CS degrees try to be engineers, but aren't trained for it.
Not a sentence!
Such systems are not insecure because they are digital or involve computers or anything. (seriously I doubt the guy even understands what digital and analog means) Such systems are insecure because they are unnecessarily complex.
Let's take the Stuxnet example. That system designed to control and monitor the speed at which centrifuges spin. That's not really a complex task. That's something you should be able to solve in much less than a thousand lines of code. However the system they built had a lot of unnecessary features. For example if you inserted an USB stick (why did it have USB support) it displayed icons for some of the files. And those icons can be in DLLs where the stub code gets executed when you load them. So you insert an USB stick and the system will execute code from it... just like it's advertised in the manual. Other features include remote printing to file, so you can print to a file on a remote computer, or storing configuration files in an SQL database, obviously with a hard coded password.
Those systems are unfortunately done by people who don't understand what they are doing. They use complex systems, but have no idea how they work. And instead of making their systems simpler, they actually make them more and more complex. Just google for "SCADA in the Cloud" and read all the justifications for it.
There's a lot of misconceptions on slashdot about how these "critical infrastructure" plants actually run. I've spent a lot of time working in chemical plants, and these plants are heavily instrumented, with all parameters recorded. These are accessible in real time to the plant engineers, who typically don't sit in the control room, and often aren't in the same state (there's a very limited pool of people available who are "experts" at some of these processes, and when a serious problem occurs companies want the best person to look at the data ASAP).
The guys who sit in the control room are not engineers. They're plant operators, and their job is to keep the plant running as smoothly as possible, and escalate the issue to an engineer if there's a non-standard problem. Most plants these days are so heavily automated that for normal, stable operation only two operators are required on site per say $100 million of plant (as a guesstimate - more during the day when scheduled maintenance is occurring).
The engineers at these sites are actually classed as management. That's because they have ultimate responsibility for the plant when problems happen, although they don't control the day to day operation of the site. Most of an engineer's day on a chemical plant should be spent looking at whether the plant is configured optimally, and trying to troubleshoot longer term problems which require a more theoretical viewpoint. However, they do have to get out of bed at three in the morning if something's gone wrong. They also have to manage the operators, and have a promotion path to "real" management - refinery managers (for example) are usually engineers.
However, what the article totally missed is that these sites already have two layers of control system - the Distributed Control System (DCS), and the Safety Instrumented System (SIS). The wikipedia contains a lot more detail, but essentially these SIS's are hard wired systems that aren't programmable at all, so they are intrinsically resistant to an internet or software based attack. However, they're very expensive (every trip needs to be built as a dedicated circuit), so these systems are only used to ensure that the plant fails in a safe manner, not continued operation. Priority is given to safety of people in the vicinity over integrity of the plant equipment - these systems wouldn't typically be used a stop a pump or centrifuge (for example) from running too fast, unless that could cause some consequential (human) damage.
Finally, an analog system would be a big step backwards from a safety viewpoint because it wouldn't allow the plants to automatically shut down safely when a problem occurs. Plant shutdowns are typically a multiple step process, and in a refinery (for example), large quantities of high temperature, high pressure flammable gases need to be disposed of, which would simply not be possible to safely "program" in an analog environment. Before digital systems came along, plant trips were "all hands on deck" incidents, with operators frantically adjusting adjusting setpoints on dials to bring the plants down. Of course, the risk of operator error was high, so automated shutdowns were a big step forwards in plant safety.