Previous articles have discussed program testing and also the difficulties of testing microcontroller software placed on smart cards and embedded systems. One reader wrote to me that an Royal Air Force helicopter crash was probably caused by a software failure and, reading the file on the crash, I believe I agree with him. One or more software errors have probably caused the several failures in Mars exploration vehicles. The forensics referred to here relate to software failure and not to cybercrime.
Nuclear reactors are controlled by dozens of microcontrollers, as are cars, airplanes and pipelines. Jet engine manufacturers use two microcontroller networks for their engines, one to run the engine, the other to keep track of safety issues.
In any situation there is always a reluctance by management to blame systems they have approved, laying the blame elsewhere. In the helicopter crash, management blamed pilot error, even though an EDS reviewer, after seeing only 18 per cent of the software, found close to 500 anomalies.
Safety-critical software is prevalent everywhere and requires thorough checking whenever a change is made to the application, including re-checking whenever there is a change to the compiler or operating system in use, causing huge cost escalations.
Major needed changes to planes like the F-18 are delayed for years (potentially putting pilots’ lives at risk) because of the high cost of verifying changes. Even outside the safety-critical scene, systems are just as vulnerable, in financial institutions, in networks, in black boxes carried by vehicles and airplanes, in home safety systems, in appliances. While not life-threatening, they threaten individual or corporate economies.
Software forensic analysis is a much-needed field of endeavor and is one that does not seem to be addressed in any significant way. We are hearing more and more instances of banking errors caused by poorly tested software, but these are the more obvious indications. How many planes and cars have crashed, caused by software failure, how many pipelines have ruptured, how many nuclear ‘incidents’ have occurred, where management has hushed things up so that their IT investment is not jeopardized?
Potential problems increase with the complexity of networks, the mind-boggling ‘bloatware’ used by business, and the atrocious operating systems we have to put up with, with their multiple flaws — but is anyone really looking to application software or operating system failure as a possible cause of incidents?
Any forensic software work has to be able to produce evidence that will hold up in Court. I was once asked to be an expert witness in a case involving two oil company consortia. One group claimed that the other group, by directional drilling, was stealing oil from the other. The issue was settled out of Court but had it gone to Court I would have had to verify the formulae used in the oil reservoir engineering segment, and also comb the software and its parameters with a fine-tooth comb to see exactly what the other group was doing.
Assuming an incident is being looked at, the first requirement of software forensics is that the expert have in-depth experience of the language used for development, and also of the assembler language for the computer system being evaluated. If it is a microcontroller (which dominate the hardware industry in units installed), a thorough knowledge of the hardware structure and machine language is also a necessity. It also helps if the expert has considerable experience in debugging (some people are good at this, others quite hopeless.) The expert must then determine how data is received by the program and how it transmits results.
In doing the analysis, the expert must document every fault and every conclusion because management will have its lawyers fight like fury to cast doubt. Every finding must be backed up by supporting material easily readable and understood by a judge, whose knowledge of software will be minimal.
Forensics could well be a growth area for IT, especially when augmented by cybercrime issues.
QuickLink 057746
Hodson is a theoretical physicist, speaker and writer. He can be reached at bernie@genetix.ca.