Bit9

At last week's VirusBulletin in Ottawa, Peter Allor of IBM gave a bit of an untraditional talk for VB, discussing security issues with SCADA systems. The list of fears and problems is long and wide. After all, most of the SCADA systems are designed to be working for 10-20 years. You do not expect to be changing power generation equipment whenever Microsoft releases a major OS upgrade. Yet what struck me was how little U.S. Government, amidst all the activity surrounding SCADA security, discusses the specific ways that these systems are exposed or could be improved. There's much to talk about when some of these systems are built on top of Windows 95, do not have encrypted command & control protocols, and can be damaged by simple operator error. Try starting and stopping turbines 10 times in a row. It will not look good. It runs over IP. Adding security software to some of these systems is absolutely out of question as they have been timed and tuned to do one thing only.

Is it simply that the situation is so hopeless that retrofitting security into these systems is too futile? Do we hope that noise raised will force the legislators to mandate that old and insecure software are replaced by newer more up to date variety? Economic chaos on the Wall Street will not help us in the short run. Still, SCADA vendors and Government users should be open to specific discussions surrounding threat exposures in their systems. That's the only way to devise a meaningful set of policies and requirements that a future of SCADA should be implementing. This has to go beyond encryping communications protocols, logging of all the activities and investing in negative QA testing cycles. Security infrastructure has to be required from security code inspection and review (think of Fortify or Veracode) to actually locking down software execution policies on each SCADA system.