In-Depth
Four Criteria for Evaluating a Security Vendor
When evaluating security products for your enterprise, make sure you also evaluate the vendors themselves using these criteria.
Security is a process. No one solution protects against all threats, and no product remains unchallenged by the ever-evolving threat landscape. As threats evolve, so, too, does our security posture—the specific tools and policies we use to protect ourselves.
In this way, security products are fundamentally different from other applications. You can buy a word processor and not worry about it for a few years; if there are bugs, you can probably work around them. For security products, the bar is much higher. Even simple design flaws and bugs will be exploited by hackers. Security vendors therefore have a much greater responsibility to their customers; their software has to be extraordinarily robust from the day it goes out, and they must respond quickly to security events, being willing and able to update their product often throughout its lifecycle.
An application vendor merely sells you a commodity; a security vendor is, in a very real sense, your ongoing partner. Not every company can function like this. Application software companies, in fact, are built differently from security software companies in four critical ways. When evaluating security products for your enterprise, make sure you also evaluate the vendors themselves, using these criteria.
Product Design
Many application software vendors design their products almost by a simple feature/function checklist. (Can it save documents in format X? Can it print? Is it Internet-enabled?) If an application vendor can deliver 90 percent of the functionality desired by the marketplace, it can ship that product and make money. However, security software companies that adopt that strategy—delivering a product that is secure only 90 percent of the time—disappear quickly. For security, the question is not "Does this have most of the features I want?" but rather "Does this keep me safe?"
As any certified information systems security professional will tell you, you cannot simply bolt security onto a product. You have to design it securely from the ground up. You don't take a product with ten million lines of code, and expect it suddenly to be secure by adding 50,000 more. We have seen both of these scenarios play out when application software vendors get religion about security and try to add security to their products—as if it were simply another item on a checklist.
Development Cycle
Application companies and security companies are geared to ship products at different speeds. New versions of regular applications are released every year or two—operating systems as infrequently as every four or five years. Even minor upgrades normally take months of development time. Compressing that timeframe for emergency patches introduces risk. One vendor famously released a "security" patch that caused more trouble than it fixed, requiring a patch of a patch!
Security vendors, by comparison, are ready to spring into action any time, any day, when vulnerabilities happen. That means not only do they have QA teams and processes ready to handle such emergencies, but their overall development organization is built around them occurring. Their development cycle is by default much shorter—they routinely have only a day to deal with issues.
Distribution and Support
In a sense, a security program is alive, constantly being updated to adapt to its environment. That requires entirely new support and distribution mechanisms, compared to traditional applications. Once the security product's development team creates an update, it is pushed to all customers in short order. The support and publishing teams must have flawless procedures and tools that allow them to execute within hours.
Antivirus companies are the most well-known example. The value of antivirus software comes not only from the product you buy, but largely from the most recent antivirus patterns that you download automatically. Likewise, support content and procedures have to be "fresher" for security companies. Indeed, the whole business model is usually closer to subscription-based than built around bi-annual upgrades.
Public Track Record
No product is flawless. How a vendor responds to vulnerabilities reveals the true character and quality of your would-be partner.
As part of your evaluation process, investigate earlier product versions. You might not be able to engineer a security test yourself, but read the vendor's release history; search the Web for news and reviews. Is the vendor a trusted brand? If vulnerabilities have been discovered, do they reveal serious problems with the underlying architecture—are there new problems every few days, or are the same types of vulnerabilities continually uncovered? It's critical to know if vendor responds quickly to vulnerability reports or ignores them for as long as possible, hoping the furor will die down.
Security companies must acknowledge vulnerabilities, and work quickly in service of their top priority: keeping their customers protected. The best companies have been around long enough that their security has been "battle-tested"—its defenses hardened even further thanks to years of attacks.
About the Author
Irfan Salim is President and Chief Operating Officer of Zone Labs, a Check Point company. He has grown world-class businesses in the security and office productivity markets with executive leadership roles at Trend Micro, Lotus Development Corporation and Software Publishing Corporation in both the US and Europe. He also spent seven years in consumer marketing at Texas Instruments.