Failure of controls...Spanair crash caused by a Trojan
Several readers have pointed us to an article about the preliminary report of the Spanair flight that crashed on takeoff in 2008 killing 154. The article suggests that a Trojan infected a Spanair computer and this prevented the detection of a number of technical issues with the airplane. The article speculates that if these issues had been detected the plane would not have been permitted to attempt take off.
There is still a lot that is conjecture and unknowns at this point in the investigation and I will try not to add to the speculation, but it made me think about the parallels to information security.
In information security we often speak of controls. There are three types of controls; preventive, detective, and corrective. Predominantly in information security we deal with preventive and detective controls.
Preventive Controls aim at preventing issues before they occur. Some examples of preventive controls are policies, standards of operation, procedures, checklists, segregation of duties and change controls. From an IT technology point of view firewalls and intrusion prevention systems are popular technological preventive controls. The airline industry also has procedural and technological controls. Airlines have operating protocols covering most aspects of operations from when it is safe to fly to how to maintain the equipment. Pilots have pre-flight and in-flight checklists to ensure safe operation of the aircraft. Modern airliners have similar interlocks and safety systems to attempt to protect the aircraft from mechanical failure or human error.
Detective controls aim to detect an issue when it does occur, or as soon as possible after. In the words of Dr. Eric Cole, a notable SANS instructor, “Prevention is ideal, but detection is a must!” If at all possible we would like to prevent the event from occurring, but if we can’t prevent the event we want to know it happened so we can adequately respond. The obvious IT detective controls are host and network based intrusion detection systems (IDS). But less technological processes such as audits are also a detective control aimed to detect and correct anomalies before they become more serious. Modern airliners also have detective systems to detect events before they are service affecting. One quote from the article, indicates a failure in a detective control occurred ... “The plane took off with flaps and slats retracted, something that should in any case have ... triggered an internal warning on the plane.”
I am not a pilot, so I cannot speak with authority on how to fly a passenger airliner, but it seems clear to me that this accident was caused by the failure of a number of controls leading to a disastrous outcome. Clearly the SpanAir diagnostic system (a detective control) designed to detect anomalies in the airliners system failed, possibly due to a Trojan. Also it appears the pilots bypassed part of their pre-takeoff checklist, leaving the flaps and slats in a position not recommended for takeoff. As ISC reader Frank pointed out that is most likely because the pilots had aborted the initial attempt to takeoff and most likely resumed the pre-takeoff checklist (a preventive control) too low in the checklist and missed a significant step. It is also clear that for some reason an internal system (a detective control) that should have detected the misconfigured flaps and slats for some reason did not alert the pilots to this condition.
In information security, the stakes are rarely so high as human lives, but failures in controls often lead to unexpected consequences. A misconfigured firewall rule allowing more permissive access to systems, a false negative in an IDS/IPS system, a user violating policy by plugging in a personal USB stick etc. The moral of the story is don’t take your control systems and processes for granted. Audit and test them regularly to ensure they are operating correctly.
-- Rick Wanner - rwanner at isc dot sans dot org - http://rwanner.blogspot.com/
Comments
itinsecurity
Aug 22nd 2010
1 decade ago
1. there are many interests at stake in this unfortunate accident: professional pilots, technical staff mechanic, airline, rescue operations managers, managers of AENA (government) and ... the worst ... politicians.
2. the computer has been infected say is that incidents are recorded, no actual aircraft equipment. Is the flaps were not deployed at takeoff but it has nothing to do with the virus (if that is true about the infection and is that is true the flaps were not deployed).
3. Has anyone thought that a company has all its ticketing system in an unprotected pc and without security measures?. Please be serious (SANS has always been serious, yes?). I think that someone is interesting to wring the lump and to blame to the computer science (or to the computer engineers) of this russet.
4. much is at stake here, and some want to divert more of the account. The accident investigation report says a different story than the article leads us to believe and still there is no final report. Do not bite the hook and let out the final conclusions. Thanks Rick.
Luk.
luk
Aug 22nd 2010
1 decade ago
And so I shall be...
Has anyone else noticed that a computer onboard an aircraft was possibly infected with malware?
No matter how critical (or not) the system, if any of the aircraft processes was dependent on the system's security state, then it should have been adequately protected.
If the story turns out to be true, isn't this where the controls have ultimately failed?
Prontissimo
Aug 22nd 2010
1 decade ago
But what struck me as odd, was the claim that power to a seemingly critical alarm could fail like that, without raising a red flag anywhere.
That's also what makes me a bit sceptical to the contents of the story.
There's a lot more to this than what that story is telling.
@itinsecurity
Aug 22nd 2010
1 decade ago
Other newsstories refer to details from the original spanish articles that also specify that it wasn't. The MSNBC story hints at it ("central computer system").
The plane in question wouldn't have this kind of computer on-board anyway. The MD-80 is a "good, old-fashioned" aircraft, not a modern hi-tech, digital toy.
If you google "flight 5022 crash", there are more articles that have popped up which make a lot more sense of the whole thing.
And if they are correct, then I think it's safe to say that in no way did a trojan crash this plane.
@itinsecurity
Aug 22nd 2010
1 decade ago
These are closed systems like you've probably never seen before. No Windows, no Linux, no Unix. Almost every piece of equipment uses its own custom processor and language especially suited to its function. All software updates must have FAA approval (in the US) before it can be deployed. Certain systems, like traffic conflict and avoidance warning, are only allowed to run the same specific version on all vendors to assure interoperability. And most systems of this vintage are not updatable unless you remove and replace ROMs.
This one all boils down to inadequate training and a lack of professional behavior. They had to have had ample indications that certain systems were not working, they didn't follow the checklists and they didn't abort when they failed to reach certain speeds at certain points during the takeoff roll.
I don't care what kind of ground-based controls could have alerted them. Just like in the information security field, you can't use technology to fix stupid.
JJ
Aug 22nd 2010
1 decade ago
Frank
Aug 22nd 2010
1 decade ago
JJ
Aug 23rd 2010
1 decade ago
http://en.wikipedia.org/wiki/Therac-25
kkdu
Aug 23rd 2010
1 decade ago
Probably just as likely is the pilot pulling the P40 circuit breaker to silence the take-off config warning during single engine taxi to the threshold and for whatever reason forgot to put it back. There must of been something that kept the pilots from getting the flaps down during the the pre take-off checklists. To me it sounds more eerily like a possible rerun of NW 255.
rerun
Aug 25th 2010
1 decade ago