JavaScript hole exposes form data (July 9, 1997); Microsoft posts another bug fix (July 1, 1997); Sun downplays Java bug (June 23, 1997); Group cracks 56-bit encryption (June 18, 1997); Netscape finds bug, promises fix (June 13, 1997).
As these headlines from C|Net's news.com (www.news.com) point out, discovering new security holes in widely used Web products or technologies is practically routine, and this is only a sample of recent headlines.
For as long as computers have stored sensitive data, security has been a critical issue for system administrators, developers, and managers. Now, as electronic commerce explodes over public networks, security has become a stop-and-go issue for consumers and end users. During this July's major league baseball All-Star game, an IBM commercial spotlighted several friends and family members asking incredulously why someone they know is shopping on the Internet. Gasp! "Is it safe?" they asked. The commercial ends with a pitch for IBM's electronic commerce solutions based on the Secure Electronic Transaction (SET) protocol.
If they haven't already, expect your users to begin questioning the security of your internal corporate systems, even if these systems have no contact at all with the outside world. Do you have a good answer ready, or has security been an afterthought -- something you get to at the end of a project?
Make no mistake: a security breach is a bug, and security bugs can enter your system during any phase of the system development life cycle. Analysts must pay even more attention to specifying security requirements clearly. Architects and designers must detail explicitly how security permeates through all parts of a system; programmers must carefully craft applications that enforce security; and last, but not least, testers and quality assurance staff must thoroughly assess the security protections throughout a system. Many companies have security administrators whose sole charter is to protect corporate information. I think that's wise, but that should not let other development team members think that security is someone else's job. Like quality, security is everyone's responsibility in one way or another. Discussing security and quality in the same breath reminds me of an unfortunate reality of software testing: The most rigorous testing procedure can only tell you that no bugs have been discovered -- yet. Unless a system is extremely simple, you can never really say it is 100% bug free. It's important to level with your end users about this real world limitation. Don't promise 100% security if you can't deliver it. The first breach will blow away any credibility you might hope to preserve.
What can you do in the face of perennial security pitfalls? Make every effort to secure your system, but also arm yourself with an effective crisis-intervention plan and react quickly if a breach occurs. A swift and effective reaction can often reassure users. Waffling or delays will feed users' fears. Be prepared to accurately identify the effect of a breach, to undo as much damage as possible, and to close the hole as soon as possible.
Ultimately, I believe that electronic commerce will continue to accelerate rapidly, even in the face of frequent news of security flaws. Many of the news items admit that no real loss occurred, or that extreme measures were required to find the hole.