Channels ▼

Should software vendors be held more accountable for 'failures of imagination'?

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?

  • Ask your vendor key questions: Has the security of your products been tested by an independent third party? What are your policies for patching and support once a vulnerability is discovered? What process improvements have you made as a result of vulnerabilities reported in your software? Do you implement best practices for every phase of the software-development process?

  • Seek security training for your developers, testers, and analysts as well as for your procurement and management teams.

  • Obtain secure-implementation guidelines from your vendor to ensure that you deploy purchased applications as securely as possible.

  • Continue to use a multilayered defense at each critical layer: data, application, network, and access controls.

    The situation isn't hopeless. But until an industrywide standard is adopted, the most we should expect is for vendors to take reasonable precautions against foreseeable threats.

    Ed Adams is president and CEO of Security Innovation, a Boston firm that provides risk-analysis, risk-mitigation, and consulting services to global organizations.

    Do you think software vendors should be held more accountable for security vulnerabilities? Tell us.

  • Related Reading

    More Insights

    Currently we allow the following HTML tags in comments:

    Single tags

    These tags can be used alone and don't need an ending tag.

    <br> Defines a single line break

    <hr> Defines a horizontal line

    Matching tags

    These require an ending tag - e.g. <i>italic text</i>

    <a> Defines an anchor

    <b> Defines bold text

    <big> Defines big text

    <blockquote> Defines a long quotation

    <caption> Defines a table caption

    <cite> Defines a citation

    <code> Defines computer code text

    <em> Defines emphasized text

    <fieldset> Defines a border around elements in a form

    <h1> This is heading 1

    <h2> This is heading 2

    <h3> This is heading 3

    <h4> This is heading 4

    <h5> This is heading 5

    <h6> This is heading 6

    <i> Defines italic text

    <p> Defines a paragraph

    <pre> Defines preformatted text

    <q> Defines a short quotation

    <samp> Defines sample computer code text

    <small> Defines small text

    <span> Defines a section in a document

    <s> Defines strikethrough text

    <strike> Defines strikethrough text

    <strong> Defines strong text

    <sub> Defines subscripted text

    <sup> Defines superscripted text

    <u> Defines underlined text

    Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

    Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.