With security, you get what you pay for

When it comes to security, you get what you pay for. Most consumers won’t purchase a $50 electronic device without looking for an Underwriter’s Laboratory sticker, yet they purchase software at a thousand times the price that they use for running their enterprises, with no consideration of product security mechanisms.

Everyone wants to use the Internet to securely connect partners and customers directly to their systems, but in this environment, it’s not just the technical security measures that are important, it’s the confidence you can place in those measures.

The security equivalents of Underwriter’s Laboratory can establish consumer confidence in software purchases. There are standards to establish information security "assurance" – that is, validation that a product does what it claims to do in terms of security – by means of formal security evaluations.

Third-party evaluator

Vendors submit their products to a third party (i.e. a government-certified laboratory) that evaluates the security claims against formal criteria such as the international Common Criteria (ISO-15408), and US Federal Information Processing Standard (FIPS)-140.

The Common Criteria, the de facto worldwide evaluation standard, has the added benefit of mutual recognition by many countries, including the United States, the United Kingdom, Germany, Canada, France, Australia and New Zealand. Vendors complete one security evaluation that is valid in many countries. Consumers have assurance that the vendor is not blowing smoke because it is someone other than the vendor validating security claims. (Let’s face it, all vendors claim they are secure, even the ones who issue security patches for their products every two days.)

Security evaluations have three main benefits:

* A more secure product. Evaluators find security vulnerabilities, which must be fixed as a condition for completing the evaluation.

* A secure development process. Security evaluations include a review of product security architecture, functional, design and test specifications, and they ensure that the secure development process is repeatable.

* A culture of security. Completing a security evaluation – or many of them, year after year – changes the corporate culture. Security becomes part of the corporate DNA, wired into the fabric of the organization. Security evaluations require a substantial (and expensive) long-term commitment by a vendor to build and maintain secure software.

They are so important that the US government requires security evaluations for all systems involved in national security. (An added benefit: if a product is secure enough for the National Security Agency, it ought to be secure enough for anybody.)

Consumers can check vendors’ security evaluations by referring to the certification bodies’ websites, such as http://www.cesg.gov.uk/assurance/iacs/itsec/cpl/index.asp,

http://csrc.nist.gov/cryptval/140-1/140val-all.htm and http://www.radium.ncsc.mil/tpep/epl.

Vendor’s track record

Even though security evaluations are important, not all products are evaluated. What else can consumers of information technology do to ensure that the systems they purchase are secure? One option is checking the vendor’s track record on security vulnerabilities (bugs).

There are many security vulnerability reporting entities such as Carnegie-Mellon’s Computer Emergency Response Team (CERT), or the hacker forum of choice, BUGTRAQ, on securityfocus.com.

Every product has bugs, some of them security bugs. However, a vendor who issues security patches on a daily basis is cause for alarm: it indicates that the vendor uses customers as their quality control organization. For these vendors, security is an afterthought, which means they consider their customers’ security to be an afterthought too.

Customers must factor into their purchasing price the cost of applying security patches to production systems to make them acceptably secure. If there are too many patches issued too frequently, it’s not merely the expense of patching "n" systems times "m" patches, it’s the likelihood that an organization will miss a patch, and their systems will be compromised.

Last year’s spate of viruses – SirCam, Code Red, Nimda – exploited unpatched security vulnerabilities to the tune of $13 billion in damages. When you factor in security holes, the lowest purchase price isn’t necessarily the lowest cost of solution.

Security is too important to be an afterthought. Consumers simply must make security a purchasing criterion because it’s impossible to bolt on security that is not built into a product, just as it is impossible to put a lock on a door made of cheap plywood and expect it to keep out intruders who can just kick down the door. How a vendor builds security is ultimately more important than what the vendor builds, and it is only by knowing the "how" – for example, through formal evaluations – that you can be sure that the "what" was done correctly.

(The author is the chief security officer of Oracle Corp. She is responsible for Oracle’s product security, corporate infrastructure security and security policies, as well as security evaluations, assessments and incident handling.)