Tip

An indictment for applications development

Many transformations begin with an indictment. Two notable examples are Martin Luther's 95 Theses criticizing the Catholic Church, which began the Reformation, and Ralph Nader's denunciation of the auto industry with Unsafe at Any Speed. An indictment of the software industry and its indifference to writing secure software has been published in Building Secure Software: How to Avoid Security Problems the Right Way by John Viega and Gary McGraw.

Twenty years into the client-server revolution and a decade into the Internet revolution, it's a measure of inadequacy of secure coding that only now are the first books being written on how to secure software -- the very foundation of information systems.

Software developers who code without taking

    Requires Free Membership to View

security into consideration are potentially as dangerous as a physician prescribing a drug without knowing its side effects. As a society, we should tolerate neither.

While security products such as firewalls, encryption devices, event monitoring and intrusion-detection systems are needed to secure networks; it must not be forgotten that behind every security problem is a common enemy -- insecurely written software.

Building secure software is not rocket science. Writing secure code doesn't mean turning every developer into a world-class cryptographer. It simply means training them in the fundamentals of how software works, including security. If corporate end users can be trained not to send inappropriate (sexist, racist, confidential, etc.) e-mail via corporate servers, then software developers can certainly be trained to write secure software programs.

The revolution needed in software development is to integrate security into software engineering. The current approach in software is to patch problems after they occur. In fact, 2003 saw the rise of many patch management companies; a sector that only came to be recently. Endless patching is a downward spiral that only serves to treat the symptoms, not the true problem, and only in a reactive manner. Had those same programmers been trained in writing secure code, much of the problems would have been obviated and billions of dollars saved in the interim.

It's all the rage to send development offshore in the name of saving money. If companies understood how much more money could be saved by building secure software from the get-go, rather than bolting security on as an afterthought, wouldn't they do the same?

It's frightening to think that in just a matter of years, everything but the food we eat will have an IP address attached to it. When the time comes that your family vacation commences with a flight on a pilot-less airplane, here's hoping the developers of the navigation and control systems knew the rudiments of writing secure software.

About the author
Ben Rothke, CISSP, is a New York-based security consultant with ThruPoint Inc. McGraw-Hill has just published his book, Computer Security: 20 Things Every Employee Should Know.

This was first published in March 2004

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.