Air Traffic Control and Cyberterrorism



airtraffic-small.gif On June 3 2004 the air traffic control system in the UK shut down for one hour (7am -8am) causing flights to be delayed, cancelled and grounded. The Flight Data Processing System was being tested (testing on a live, critical infrastructure system?) in preparation for an upgrade when errors were detected. It was decided that a reboot (always the best option?) was the appropriate solution. Service was eventually restored. A similar incident recently occurred in Texas, USA.

These events will no doubt make their way into “security” literature with the addition of “what if” scenarios in which the disruption was cause by hackers or cyberterrorists rather than the unappealing reality of bugs, glitches and upgrades.

The disruption of air traffic control has been one of the long standing and often repeated attack scenarios envisioned by cyberterrorism experts who craft extravagant and fanciful scenarios in which cyberterrorists break into air traffic control computers and crash planes into one another. In Feb. 2002 former White House cyber security czar Richard Clarke suggested that air traffic control systems were vulnerable to cyber attack because they relied on the Internet. (He was, however, corrected by the Federal Aviation Administration�s chief information officer, Daniel J. Mehan, who pointed out that Air traffic control does not use the Internet.)

There is also the celebrity case of the hacker (sic) who disabled telephone service to the Federal Aviation Administration Tower at the Worcester Airport in 1997 so often used as an example of what cyberterrorists could do.

But this is not the first time the system in the UK has had problems, including an incident in which a jumbo jet and a Boeing were put on a collision course. However, “a crash was only averted when the pilots and the air traffic controller realised data on the two planes had been transposed.”

However, as proven in this case, and argued by Mark Pollitt, there is sufficient human involvement in the air traffic control process to avoid such a catastrophe. First, the computers do “do not control anything” but simply “provide an aid to the human controller”. Secondly, Pollitt states that pilots, the second human buffer in the system, are trained in “situational awareness” and routinely correct errors made by air traffic controllers. Finally, pilots and air traffic controllers are trained for bad weather and other conditions in which the air traffic control system may not be operating at all.

Now, I�m not at all suggestion that critical infrastructure systems should be lax about security. On the contrary, I�m arguing that they should be realistic about it. They should actively secure their systems against real life threats both technologically and through maintaining, what Trapped in the Net author Gene Rochlin calls, human buffering capacity. In terms of air traffic control, this means maintaining flight progress strips (FPSs), manually marked up pieces of paper with air craft information, that air traffic controllers insist on maintaining even while computerized systems are operational.

The mantra of efficiency, and threat of the “insider” have led to the rush to automate; to replace humans with technology, which in turn makes us vulnerable, which leads to the rush to electronically secure it. Critical infrastructure security requires a holistic approach that takes into account technological; security and human buffering capacity. It must also place proportionate emphasis on the true sources of insecurity and not fall victim to the tall tales of snake oil salesmen.

Post a comment.