Software with Security in Mind

Finding the Source

But how did all the software bugs get there? For starters, even the best developers in the world write software that contains bugs. There is no such thing as "unbreakable." Security vendors themselves have problems. The Witty Worm, which recently wreaked havoc with Internet Security Systems' BlackICE firewall, is an example.

But developers have a history of building software that doesn't take security into account at all, or does so only as an afterthought. It's not easy to change coding practices, and secure software is more expensive and slower to develop than stuff that's churned out and thrown over the fence.

Also consider that most programmers aren't trained to build secure software. Educators must start teaching secure coding practices in all facets of their computer science curricula. Application and Web developers must understand when to choose languages that include strong safety and protect their programs from buffer overflows and race conditions. They must learn to follow the principle of least privilege--use only the access they need and no more. A program with administrator access should run in "administrator mode" only when it's essential.

Software packagers must obey this rule as well. Who hasn't installed an application that needlessly required root or administrator access, or that was loose with default file permissions? Developers must know when to let go of risky lower-level languages, such as C and C++. Software architects must build security into their designs. And researchers must develop new languages and methodologies that eliminate common programming errors.Step By Step

As IT professionals, we realize patch management is a good first step. We need to use chroot and other sandboxing technologies to put applications into areas where they can do little harm if attacked. We must limit access to applications. We must protect ourselves from problems we ourselves cause--a misconfiguration or misinstalled program can contribute to an attack as readily as a bug can.

In the end, we are at the mercy of our software developers. It's our responsibility to tell them what we need and expect--that secure software is a requirement, not a nicety. It's our butts on the line, and we must kick and scream until the developers change their ways, or we must find someone else who will meet our needs.

Mike Lee is NETWORK COMPUTING's editor. Write to him at [email protected]