Dr. Dobb's Journal November 2006
At Starbucks the other day I overheard two software developers talking about which web browser they used and why. One was a staunch supporter of Microsoft's Internet Explorer, the other a militant Firefox user. The battle raged; they talked about everything from interfaces and extensibility to who would win in a bar fight—Clippy (the Microsoft Office animated paperclip) or the wily (fire)fox.
The topic then turned to security and went something like this:
IE Guy: We don't know who's writing that code; most of those guys probably don't have a clue about security. And what about somebody putting in a time bomb or a backdoor?
Firefox Guy: What about it? You're telling me that IE doesn't have the same problems? What's even worse is that I can't get the thing off my machine...At least in Firefox I can look at the code.
IE Guy: Have you? I'll bet that no one you even know has looked at the code. At least Microsoft has a process for security, and they don't pull "Learn C++ in 21 Days" washouts from off the street to write its software.
The conversation continued like this for about 20 minutes—with no resolution. I'm willing to bet both guys went back to their desks, navigated to Google, and felt they'd made the safer and more informed browsing choice for security.
I've heard debates like this a thousand times, with different target applications and platforms—Windows, Linux, BSD, Exchange, Oracle, DB2, and on and on. I've also heard it rage on different scales, from college students in labs to IT executives about to bet millions of dollars on solutions they "felt" better about. Recently, legislation (think Sarbanes-Oxley), standards (such as the PCI Data Security Standard enforced by Visa, Mastercard, and the like), and high-profile breaches have driven enterprise customers to demand that in addition to being usable, affordable, and extensible, the software they purchase and use be demonstrably more secure. The problem is that they want security but don't know how to demand it—security isn't a particularly easy thing to measure and weave into a Service Level Agreement.
Many vendors I've talked to have started to receive some piercing questions about security: What's your vulnerability response process? What process improvements have you made based on vulnerabilities reported in your software? What training does your development team get on security? What is your patch release strategy? What guidance do you provide for secure deployment/maintenance? What is your vulnerability disclosure policy? What are the terms and period of your security support agreement? And answers to questions such as these are starting to define what's shaping up to be one of the most crucial battles in software.
For many enterprises, "security" and "compliance" are nearly synonymous, and many are still reeling from compliance ambiguities. For example, translating Sarbanes-Oxley into practical steps to secure software can be more frustrating than using Tarot cards to recover forgotten passwords. Some requirements, however, are more straightforward. While more focused on network security, the PCI Data Security Standard does offer some guidance for developers.
Given that customers are subject to these regulatory requirements, we have to make sure that our security requirements are in sync with theirs. For example, many of the new disclosure laws have "safe harbor" clauses that can save a company incalculable reputation damage (by not needing to disclose a breach) if data is strongly and properly encrypted when stored. This could potentially mean adding an encryption requirement to applications. Given that regulations are nonnegotiable for enterprises, the costliest "security" mistakes in software may not be buffer overruns, but failure to meet the evolving security requirements of users.
So what does all this mean? At the highest level, the development community needs to step up its security game to compete in the world of new security-aware consumers. We need to gather security requirements along with functional ones, think about abuse as well as use, and embrace secure coding and testing practices. In a world where most application data zooms unscathed past network defenses, ingraining security into our applications is the only option.
As for the Clippy vs. (fire)fox bar fight, I guess that the fox wins by default given Clippy's semi-retirement. It would have been one helluva brawl though.