How To Dismantle An Atom Bomb?

August 24, 2005

How To Dismantle An Atom Bomb?

How To Dismantle An Atom Bomb?

by Robin Bloor, Partner, and Fran Howarth, Principal
 
Once upon a time, software developers didn?t need to worry about security. They wrote applications that were implemented on secure computers, and that was that. The realm of application software was locked up tight. End of story. But along came the Internet, and gradually those computing environments ceased to be secure. Indeed, right now they are vulnerable to attack from seasoned hackers with a whole arsenal of cracking skills that can gain them access to a once-secure domain. What should have been the end of the story has turned out to be just the beginning of a grim tale. The security of application software is now a pressing issue ? one that must be addressed and one that does not necessarily promise a fairy tale ending.
Who Bears the Unwelcome Responsibility?
 
Software developers, of course. The mandate to identify and prevent security weaknesses falls upon the stooped shoulders of the much-beleaguered developer. Whether they develop in-house applications or work for software vendors, software developers must ferret out security weaknesses in their work and eliminate them. Security bugs are not a minor problem that can be swept under the carpet. They are the most expensive bugs of all. When hackers gain unauthorized access to computer networks, the damage often runs to millions of dollars ? whether the intruder steals data, creates false transactions, or simply trashes a whole system.
 
The techniques that intruders use to intrude are legion and often extremely clever. Web sites are often susceptible, for example, to SQL injections, a technique whereby the hacker enters SQL statements rather than data into a web form and thereby runs a SQL request on the underlying database. This technique has been used by hackers to open a door into a network or to change data in an underlying database. There are even automated SQL injection tools that test for the appropriate fault on a web site. And yet SQL injection is not difficult to prevent. You just have to write the program in the correct way.
 
Another common exploit is the buffer overflow, which allows a hacker to directly inject executable code into a program by entering data in a buffer and then adding instructions at the overflow point (which can by default be the next instruction to be executed). The technique is sophisticated but it is simple to prevent.
The Cost of Security Vulnerabilities
 
The ?cost multiplication? that is inherent to the correction of software bugs is less well known than it should be. It works like this: If a problem is discovered at the software design stage, the cost of fixing it will be relatively small. If caught at the coding stage it will cost two to three times as much. If not caught until program testing the multiplier is again between two and three. If caught in integration testing, the cost multiplies by a similar factor again – and again on acceptance testing and then again when the application goes live. Ultimately, this multiplier effect means that an error can cost 20 or 30 times more to correct if it is not caught until the system goes live.
 
However, this particular cost profile takes into account only the cost of fixing the error – which can easily escalate to the thousands of dollars level – and not the cost of the damage done. In the case of security bugs, this cost is hardly ever less than tens of thousands of dollars – the likely cost of checking the network to assess what the intruder did – and may be much more if the intruder succeeds in stealing data or injecting a fraudulent transaction.
Secure Software ? How to Dismantle Security Vulnerabilities
 
Secure Software is in the business of helping programmers avoid and eliminate security bugs in the software they write. To this end it has developed vulnerability remediation and prevention technology that tests for known security weaknesses in programmer code. This has been designed for use on a variety of development platforms including the popular Eclipse, Java and .Net environments. It also dovetails with existing testing software.
 
However, Secure Software?s approach to resolving software vulnerability extends beyond software testing. It is much more comprehensive. The Irish Rock Band, U2, offered advice on ?How to dismantle an atomic bomb?. Their solution was: ?Don?t build one.? Secure Software offers advice on how to dismantle security vulnerabilities and its solution is similar: Don?t create them.
 
Secure Software has recognized that the most effective and efficient solution to the problem of security bugs is for programmers never to produce such bugs in the first place. Consequently, Secure Software not only provides programmers with security testing technology but with a security testing methodology they can adopt as well.
Secure Software?s methodology goes by the acronym CLASP: Comprehensive, Lightweight Application Security Process.
 
CLASP is actually a set of documented processes that define best practices at all the stages of the software development process, covering a range of sub-processes from the definition of requirements, through initial design, and all the way to code sign-off. The processes ensure that security is fully considered and implemented as an inherent part of software development. And, as should be expected, Secure Software provides a consultancy service to help its customers carry out the implementation.
Addressing the software security issue means being up-to-date with new hacking techniques and exploits. Consequently, Secure Software also maintains a knowledge base for its customers, which tracks all known vulnerabilities. This serves to ensure that all possible flaws are uncovered. As you?d expect, vulnerabilities based on application behaviour, such as whether a software product accesses the Internet or whether it could include a backdoor, are in the knowledge base, but so are software quality issues, such as how memory allocation is best handled.

Good practices in such areas close loopholes and can prevent exploits from being launched. Using the knowledge base helps in identifying resources that may be at risk from attack and thus potential vulnerabilities can often be designed out at an early stage. The knowledge base naturally serves as a training aid to developers who will reference it to learn more about security vulnerabilities, but are also likely to alter their programming habits once they have a deeper understanding of how security vulnerabilities arise.

The Bottom Line
In essence Secure Software provides a full environment for the development of secure software; it educates the developer, defines the process, and delivers the testing tools. And, importantly, it covers every stage of development from design to implementation. Secure Software is built for developers of all kinds, whether they work in the enterprise or in a consultancy or for software vendors. And it is built for scalability.
 
The testing software now comes with a management console that provides a centralized view of development and security testing throughout the organization ? wherever the testing software is deployed ? and includes other useful features, such as the capability to model how a particular threat impacts an enterprise. Organizations have tried implementing all manner of security technologies in recent years to protect themselves from security breaches. However, few of these organizations have any protection at all from the security errors that they themselves may build into the business applications on which they rely.
Hurwitz & Associates is impressed with the comprehensive and intelligent capability that Secure Software brings to bear on the thorny issue of application security risk. If properly implemented, Secure Software quickly and inexpensively stops most software security errors before they even occur and can catch those that manage to sneak into the process. Developers can perhaps begin to dream of a happy ending to the story. In any case, Secure Software will make a difference.

 

Newsletters 2005
About Robin Bloor

Leave a Reply

Your email address will not be published.