Dead Letter Networking
About two weeks ago, the Northeast United States suffered a major power hit when a cascading failure shut down a whole bunch of power stations. In light of this whole event, lots of pundits have bitched and moaned about how power station control networks should not be publically available to the Internet. I'll not make light of the fact that they are right, but the problem is deeper than that.
In today's day of on-demand pricing and real-time management, the ability of the operators of complex control structures, nuclear power producers and electrical grid managers, to manipulate and manage pricing in the face of increased or slack demand is necessary in order to make maximum profit. The dilemma comes when interfacing the sales prediction tools to the control network, so that appropriate decisions can be made.
Someone, much smarter than myself, came up with the idea of a secure syslog, the goal of which was to ensure that no hacker could eliminate his tracks completely after compromising a system. The basic premise of the system was that there is an independent machine located on the same network segment that has no IP address, no way of being reached from the networks it's monitoring. Said machine listens for UDP packets sent to a null/unroutable address, and snags them. It also has provisions for throttling, in the event someone tries to overload the syslog with the hopes of eating up all the available diskspace.
The mechanisms of how the syslog provides it's security and robustness really do not apply in the particular case I'm outlining. It only serves to demonstrate a mechanism by which a control system can output information to a management station, without having to compromise itself by being publicly addressable. The control systems can be private-iped systems that are unreachable from the internet, indeed, systems which have no addresses at all, but output their data to local repeater hosts which are publicly accessible, and can be used to retrieve logistical data necessary for the operation of today's real-time infrastructures.
The opposite end of this spectrum is how to provide information back to the control system to alter it's operation. This is where no true system can be 100% impenetrable. But by decoupling the machine from the network completely, no known attacks, no publicly available rootkits or cracks are exploitable against it (except perhaps the lowest level ICMP attacks, but even this could be mitigated against if ICMP is not necessary to the machine). If the machine is only programmed to look for particular bits of data, say a control message encrypted with a 3DES/Blowfish and signed with a particular authorization code that can change every day, the machine can unpack, analyze, and reject the control request as required.
Such is system isn't exactly an off-the-shelf component nowadays, but the design offers benefits to todays information specialists, particularly in the arena of ecommerce. What organization doesn't want some secure means of processing credit card orders in way that allows them to deny an attacker the means of retrieving and abusing those same credit card numbers? What organization doesn't want to secure the power infrastructure that makes this great country of ours function? Why not give plant operators the very best in management and real-time data, while still allowing hard-wired failsafe control systems to be utilized alongside secured, inaccessible remote automated control stations?
The very design of this interface, coupled with a strictly designed and moderated message allows for a properly audited interface, that also allows the system to change it's own operating parameters, say, the particular message signature changes each day, to foil the ability of attackers to construct valid messages that alter or destroy the ability of the control station to function.