Code writers now occupy the front line in the battleground of software security as the defence shifts from perimeter protection to prevention function that’s built in during the application development phase.
How these new frontline fighters are able to fortify applications will ultimately determine how much or how little additional security will be needed throughout the rest of IT. In this next stage of the war against malicious IT attacks, security defense begins in application coding. And like soldiers going into battle, the ability of source code developers to fend off attackers will be as good as the weapons and ammunition at their disposal.
A 2005 Microsoft Corp. survey of business software developers found that 64 per cent of them say they don’t feel confident enough to write secure applications. It brings into question whether software companies provide enough of the necessary tools and training that allow developers to write more secure code.
At last month’s RSA Conference in San Jose, Calif., IT security professionals from both the business world and academia agreed that, when it comes to software security, the industry could and should do a lot more.
Experts believe fortifying the entire software security chain begins at the first link – in the writing of application code. Secure coding lets software companies minimize or prevent application vulnerabilities, says Howard Schmidt, CEO, R&H Security Consulting in Issaquah, Wash. and a former White House cybersecurity advisor.
One of the first steps in secure code development is performing analysis, which involves a review of the code as it’s written, Schmidt says. Some source code analysis tools in the market automate the process by running code against a long list of known vulnerabilities and remove the flaws as these are detected. Automated testing is key, says Schmidt, especially if developers are dealing with millions of lines of coding.
Penetration testing follows after the code is compiled and created into a binary and executable file. This test probes the application by simulating real-world attacks to identify flaws that can potentially be exploited.
Another step, says Schmidt, is testing the application in a production environment to ensure that the software security level is not diminished as a result of software buyers writing their own applications that interface with the product.
“The individual coder has to understand the environment in which he is going to be operating and make sure that he pays better attention to (writing) secure coding,” says Schmidt, a former CSO for both Microsoft and eBay.
But secure code development may not be a priority requirement for some software companies. In some cases, programmers are pressured to make compromises in order to meet deadlines, budgets and innovation demands, says Schmidt.
The software industry’s tendency to rush products to market is a contributor to generally poor software security, says Jeff Williams, CEO of Aspect Security in Columbia, Md., a firm that specializes in custom applications security. “It seems to me that we’re rushing into new areas much faster than the security community can establish best practices.”
It’s a problem which code writers face as they struggle to develop new applications with specific functionalities and within a narrow timeframe, Schmidt says.
He says the most major complaint heard from code writers in authoring more secure applications is the tremendous pressure under which they are placed in order to get applications to market sooner, with more features and in less time.
Schmidt is quick to add, however, that for the sake of building more secure products responsible software companies are adopting a “time-flexible” approach. That means no application will be released prematurely. “Overall, good employers are saying, ‘I understand there’s a time cycle we have to work with, but we’re not going to wind up undermining security to get something out the door quicker.’ “That’s a good thing because they’re placing more attention on security,” says Schmidt.
While Schmidt applauds the increased focus on software security, Aspect Security’s Williams is not so optimistic. He says the industry still has not learned from past mistakes and says application security “hasn’t improved and might be getting worse.” He cites buffer overflow attacks for instance – a type of vulnerability discovered more than 25 years ago. Despite the fact that buffer overflow is a well understood problem, the condition still occurs in many vulnerability disclosures within commercial products from firms that should know better, Williams says.
“The only [way] that we are going to stop making that particular kind of error is if people stop using languages that are susceptible to [this vulnerability],” he says. “Even in these new languages, like Java and .NET that aren’t susceptible to buffer overflows, we’re going to continue to make the kinds of errors that we make because we’re not really learning from our mistakes.”
Schmidt and Williams agree, however, that software security should be a shared responsibility among builders and buyers of software, and the programmer education community.
“The whole market is working to (improve) the level of security that exists in software that we are currently getting, which is really not very good,” says Williams.
Most service agreements between software buyers and vendors lack security provisions. When software buyers don’t demand secure software, a vendor might be encouraged to think security isn’t an important consideration, Williams explains.
He says it is essential to place security provisions in service contracts. These should spell out which party bears the burden of liability should any security breach occurs.
Schmidt seems to disagree, however, and says the market will police itself by demanding greater security built into software. Litigation alone will not solve the problem, he says.
“I don’t think (legal recourse) is necessary,” he says. “We are very much in a mode where the market has responded, and in a market-driven society, you find you get your best results by letting the market drive the direction.”
QuickLink 067906
