Reading the headlines from this story leads one to believe that a trojan was used in a deliberate attempt to bring down an airliner. Digging further into the facts of the story, nothing could be further from the truth.
The aircraft in question is a 150,000lb twin turbofan MD-82 airliner. Aircraft like these do not ordinarily make "no flap" takeoffs. The pilots failed to follow the checklists properly, and applied takeoff power with flaps retracted, and stalled when exiting ground effect.
 |
| Source: CIAIAC |
The aircraft's crew made two passes through the pre-takeoff checklist. The first pass, the flaps were correctly set to 11'. However, before reaching the runway the crew noticed an abnormal RAT (ram air temp) indication and returned to the ramp for maintenance. The ground crew "resolved" the issue with the RAT sensor by disabling it, and the MD-82 again began taxiing for takeoff. However, the cockpit voice recorder captured several signs of trouble, indicative of a forthcoming cascading chain of failure.
 |
| Source: CIAIAC |
 |
| Source: CIAIAC |
Upon applying takeoff power, the TOWS (take off warning system) should have provided an audible warning that takeoff flaps/slats were not set properly. This did not happen. So the TOWS system was infected with malware/trojans, right? NO. The TOWS system itself was disabled, but this is an onboard aircraft system with no IP connection, no USB ports, and no operating system familiar to everyday malware authors. There is quite a bit of misinformation being spread on this point, with security boffins and AV vendors latching on to the malware point. No, it was not the onboard TOWS system which had been infected. So why did the TOWS fail to callout a warning?
 |
| Source: CIAIAC |
The issue with the energized ram air temp heater was indicative of a relay failure which would put the aircraft's systems in "flight mode" which would not only explain the high RAT (the probe has a heating element which is enabled in flight but disabled on the ground) but also the disabled TOWS (which only operates in 'ground mode').
So, in a nutshell, if the ground sensing system fails to flight mode, we would have a situation where the TOWS would be disabled, and the ram air temp heater (among other things) would be enabled. So how would we know if the ground sensing system had failed?
Well, digging deeper, we find that on this particular aircraft, there were numerous instances of high RAT readings on the ground:
 |
| Source: CIAIAC |
So in three days prior to the accident we had six abnormal RAT readings, while the aircraft was on the ground, as recorded by the digital flight data recorder (DFDR). Surely the crew would start to pick up on the fact that something was not right.
 |
| Source: CIAIAC |
No, because the three RAT abnormalities that were actually entered into the aircraft's technical log book (ATLB) were reported by three different crews. Doh!
So this is (finally) where the malware issue starts to enter the picture. The off-board system in question was responsible for correlating, scoring and alerting on situations just like this. A computer system is ideal for this type of scenario, where the air crews and maintenance personnel rotate frequently. So why didn't the system fire an alert?
On this issue the official report from the CIAIAC is silent, though perhaps the forthcoming inquiry [2] will shed some light. Perhaps the threshold for RAT anomalies wasn't reached. Maybe this was because the system was only made aware of the 3 anomalies that were actually entered into the ATLB, rather than the 6 that were detected by the DFDR on board the aircraft. Or perhaps the malware present on the scoring and alerting system prevented the system from working as expected.
In any case, this tragic event is typical of so many in aviation. It's primary cause, in the opinion of this security consultant and pilot, is what we aviators call "Get There Itis". The flight was delayed, the cabin was hot, the copilot had dinner plans, and the passengers and flight attendants were grumpy. The pilot breezed through the "takeoff imminent" checklist, repeating from memory "11" degrees of flat deflection rather than verifying the position of the flaps/slats on the numerous indicators present in the cockpit.
The throttles were pushed forward, the stick was pulled back, and the jet momentarily became airborne before stumbling out of ground effect into a fireball that killed 154 people.
Did malware have anything to do with this tragedy? Perhaps. But it's certainly a tertiary factor. A number of recommendations came out of the post accident investigation, and these were specifically to:
- Recommend that TOWS systems are checked for proper operation before each flight, rather than once per day
- Recommend that checklists be streamlined to ensure that critical items (such as setting flap/slat deflection for takeoff) are performed without interruption, and verified
 |
| Source: CIAIAC |
As to malware on maintenance systems? Of course that's undesirable. However, modifications to checklists and operational procedures are our best and most important defense against similar accidents going forward. Keeping airlines' computer systems free of malware is a completely reasonable requirement. Would a malware-free maintenance system have prevented this accident? Perhaps. But properly trained and professional aviators certainly would have mitigated this tragedy.
[1] http://www.skybrary.aero/bookshelf/books/777.pdf
[2] http://www.theregister.co.uk/2010/08/20/spanair_malware/
