We had an interesting discussion recently with Fortify Software's chief scientist Brian Chess regarding the idea that it is actually not that difficult to control the most frequent defects in software security. Yet disclosures of breaches of sensitive data like credit card or social security numbers are becoming alarmingly routine.
The challenge is that software developers are not security experts and never have been. And with the legacy of Visual Basic and its descendants, which made software development easier and more accessible to music, art history, and philosophy majors, they are supplementing and increasingly taking the place of computer scientists, who in the western world have become a diminishing resource. Not surprisingly, lack of awareness of software security has steadily grown worse.
Developers have traditionally regarded security as somebody else's problem. As it is, they barely have enough time for testing their code for garden variety bugs and defects, not to mention performance.
Consequently, they have typically thrown the problem over the wall to security specialists who largely handle perimeter security, and/or to authentication and access control tools inside the firewall.
Yet, with the Internet, the problem has grown more acute. Lack of awareness about software security has literally become a communicable disease.
Although he does not use those words, Chess would likely characterise traditional strategies of throwing security issues over the wall as the software equivalent of a Maginot Line defense. He has authored a new book discussing common software security holes and how they can be fixed.
Chess concedes that not all security holes can be caught. But he claims that the most common ones, such as cross-site scripting (which allows hackers to deflect incoming HTTP requests to pirate sites), SQL injection (which causes database diarrhea), or buffer overflows (which so overwhelm cache that security measures break down), can easily be eliminated with automated tools without bringing software development to its knees. And even if eliminating these holes solves only half the problem, at least we are halfway better off.
Of course, Chess has an agenda, as his company, Fortify Software provides 'white box' testing that throws software through a battery of security tests to identify those very holes. But agenda or not, he has a point.
Chess does not expect developers to become security experts, but he expects them to become deputised on the front lines to, at minimum, test for obvious holes. While security specialists should set the strategy and be overseers of last resort, Chess contends that they cannot bear the security challenge entirely on their own any more. The world is simply too interconnected for that. He is optimistic that developers can change their ways, as it was not too long ago that most considered the idea of defect-management databases and bug-tracking systems as unmanly.
Chess also believes that corporations will likely enforce a change of ethos because cracks in security, such as unsecured wireless networks that can create a hole for somebody to filch credit card numbers, will cause them to advance security to the front burner in their IT departments.
Nonetheless, we have some doubts. In a global market, there is always room for shoddy merchandise, in this case low-cost code where you get what you pay for. India, which began the globalisation trend, has competed on quality. China, whose manufacturing sector has come under suspicion lately, is also likely to clean up its act. But we fear that development centres in emerging countries, desperate for hard currency, will offer development services at the lowest possible cost with little regard for security. And we would not be surprised if a market emerges for those services, security warts and all.