Yes, says Continental Airlines' Andre Gold; software vendors must ensure the security of products that, by their own admission, are key to business success. No, responds Security Innovations' Ed Adams: Despite software vendors' best efforts, some acts of the malicious imagination are almost impossible to predict.

October 01, 2006
URL:http://drdobbs.com/should-software-vendors-be-held-more-acc/193004974

Imagine what it would be like if airlines like ours operated the same way most software and hardware vendors do when they develop products. Instead of operational goals of clean, safe, and reliable, we'd focus on timely departures and arrivals ("time-to-market"), total cost of ownership (TCO), and extending the feature set of our products. Sounds great, right? Maybe the airline industry could learn something from the hardware and software vendors out there.

In an effort to ensure time-to-market, what if we cut out those preflight checks? We rarely find anything wrong anyway. Next, considering the ever-increasing cost of crude—part of TCO—why don't we simply do away with routine maintenance? We'll perform maintenance only when a passenger informs us that smoke is coming from one of the engines, or that the plane is making a loud, clunky noise during flight. And as far as extending our product, well, we don't have much capital to do that, but I assure you that on my airline, we'll continue to offer food at mealtime.

To suggest that an airline would put anything before safety and reliability is absurd. But this is the environment consumers of technology have been forced to operate in for years, and it's what they've come to expect from vendors. For an airline, safety and reliability are operational values that are integral to the product/service we deliver to our customers. Is it unreasonable to expect the same precision, quality, and accountability from technology vendors, which will be the first to say that their products are playing an increasingly critical role in the success of businesses? I don't think so.

Nevertheless, the imposition of onerous penalties for failing to meet minimum security levels is probably not the best answer, since it would primarily help the big vendors that can absorb the cost of accountability or pass it on as a price increase. Small vendors and open-source projects would undoubtedly suffer more from such an initiative.

Technology consumers can do their part in holding vendors accountable by not buying insecure products, but this might be unrealistic for most organizations.

A more plausible alternative is to demand visibility into how vendors address security throughout their software-development life cycle, and to require them to provide customers and third parties with a clear means of assessing whether the vendors are fulfilling their stated, and self-imposed, policies. I know at least one vendor, Microsoft, that does this.

We need vendors to state publicly what their security policies and processes are, and then handle security incidents in a transparent-enough manner to let third parties verify their compliance. This would make it possible for current or potential customers to view software-security vulnerabilities as part of their risk-management process, where they can identify the risk associated with the use of software from a vendor and deploy risk-mitigation strategies commensurate with that risk.

From a policy perspective, this would help organizations decide whether or not they could tolerate the risk of using a technology that may provide a competitive advantage when deployed, but could cost too much for them to continue to operate, manage, and remediate over time. And if customers decided the risks outweighed the benefits, vendors would be forced to develop more security-conscious products. At Continental Airlines we've done this, for both products and services. In some cases, we elected not to use the product. In others, the business accepted the risk.

André Gold is chief information security officer at Continental Airlines. Previously, he served as technical director of Internet and network services, also at Continental.

As someone involved in helping organizations bolster their information security, I've long thought that software vendors should be held accountable for adopting effective security practices in their software-development life cycle. But recent attacks by hackers and terrorists have brought these acts to a new and unimaginable level, forcing me to soften my stance. These acts of malicious imaginations are virtually impossible to anticipate, and testing for them becomes incredibly costly.

Granted, software vendors should strive to make products as secure as reasonably possible by considering common abuse cases. The industry is riddled with careless vendors that ship products without the slightest bit of security design, assessment, or disaster planning. But to require software vendors to make products that span all possible abuse cases would mean the end of usable and affordable software—something businesses would be unwilling to accept.

Should the more sophisticated software vendors—the EMCs, Microsofts, Oracles, and SAPs of the world—be diligent? Yes, and they are. The biggest security challenge in the software industry today is the lack of accepted standards and guidelines for the proper construction and assessment of applications.

This isn't a defense of poor software security, but a legitimate excuse for vendors. Unlike other technology disciplines, the software industry has no organizations that create global standards for security. Although groups such as AppSIC, Mitre, and NIST have made some progress in certain areas, the fact remains that there are no accepted industry standards for measuring application security. There's also no consumer-advocacy group with clout, and until the software market catches up with other sectors with respect to legal and industry regulations, we can't expect vendors to monitor themselves for complete software safety. That wouldn't be practical, as there's no end game to testing efforts where acts of the imagination are concerned.

Vendors should employ third-party certification to give customers comfort that their application has been tested by an independent source; this would help the vendors sell more products while boosting consumer confidence. But even this is suspect, as one can't be sure exactly how the application was assessed, given the absence of standards for measurement.

The usability problem is another conundrum: To make a product more secure, you must impact its usability and/or speed. Imagine taking this to the ridiculous level of requiring software vendors to anticipate every way in which a creative and malicious user might exploit their software. The software would be released years behind schedule, cost 200 times more, and be extraordinarily cumbersome to use.

So if software vendors can't be held entirely accountable for failures of imagination, what can you do to protect your organization from some of the more sophisticated attacks?