How often are software testers getting lucky?
By that, of course, I mean how often is our software simply not getting used and abused enough to show whether or not we’ve tested it well?
Take industrial control systems testing, a subject on the radar due to security incidents like the Stuxnet worm . While the Stuxnet attack was sophisticated, researchers and security hobbyists, like the man who pinged the whole Internet , have demonstrated that significantly less-complex vulnerabilities abound. That these vulnerabilities have not been exploited to more detriment of the public speaks not to real security or to the quality of the testing done but rather to the disinterest and perhaps patience of potential attackers.
In December 2012, Chinese hackers infiltrating a decoy water control system for a US municipality were caught by a research project aimed at exposing hacking groups that intentionally seek out and compromise water plant systems. According to security researchers, none of the attacks exposed by the project displayed a high level of sophistication. Researcher Kyle Wilhoit concluded, “These attacks are happening and the engineers likely don’t know.”
Vulnerabilities like these could permit attacks resulting in power outages, environmental damage, and loss of life, yet hacking industrial systems remains quite easy for hackers versed in the workings of them. Of three presentations on control system vulnerabilities at the Black Hat computer security conference earlier this month, all required significantly fewer resources and skill than what was needed for the Stuxnet operation.
But security is tough business, multi-faceted and fed by a small pool of technical talent. Add to that the low incentive value for energy operators and manufacturers of control systems to beef up security and it’s not that surprising that massive vulnerabilities exist.
Even where there’s huge liability and money on the line, however, projects still fail in the wild related to non-security bugs that testing should have caught.
J.P. Morgan, one of the largest banking and financial services firms in the world, lost its rear end over an Excel-based value at risk (VaR) modeling tool designed to help the chief investment officer (CIO) understand the level of risk the company was exposed to, which would help the bank make decisions about what trades to make and when. After a poorly positioned trade resulted in losses that totaled into the billions of dollars between April and June 2012, an investigative committee found that the tool that gave such horrendously bad advice had been poorly designed, developed, and tested .
A J.P. Morgan report detailed how it happened: “Specifically, after subtracting the old rate from the new rate, the spreadsheet divided by their sum instead of their average, as the modeler had intended. This error likely had the effect of muting volatility by a factor of two and of lowering the VaR…It also remains unclear when this error was introduced into the calculation.”
Even a rookie tester with half her brain tied behind her back should have found such a grossly incorrect formula that caused the firm’s VaR to be misreported by a factor of 50 percent. But the investigative committee found that “inadequate resources were dedicated to the development of the model…the model review group required only limited back-testing of the new model, and it insufficiently analyzed the results that were submitted.”
The committee’s report indicated a complete lack of rigor in testing by all who touched the modeler. “Data were uploaded manually without sufficient quality control,” the report claims. “Spreadsheet-based calculations were conducted with insufficient controls and frequent formula and code changes were made. Inadequate information technology resources were devoted to the process.