Want not be hacked? Security Vendors – why less is more!

Original Post on 10-Jul-06 5:30pm
The IT industry loves advanced technology, even to the point of gadgetry. Some immature technologies are adopted simply for the gee whiz factor. Others have a specific niche application, and are money well spent. The IT staff spends time and effort integrating the new application into the enterprise architecture, and then rolls out the first release. Security in the past relied on these new, hot technologies; they were stand-alone, and the architects selected the best of breed product after a trade study or bake-off.

This methodology worked well in the past; each new piece added received its own separate command and control structure and performed its stove-piped duties. Routers begat Firewalls begat Anti-virus begat IDS begat… IT spent more time distilling information, managing products and filing RFPs, and less time making the company more efficient/profitable/secure. Other niche vendors offered Security Incident Management products, hoping to ease the burden and consolidate Syslogs and IPS reports from disparate sources. This produced another product management specialist or further taxed the existing staff.

As happens with maturing industries, vendors consolidated (see Why the Behemoths Buy Startups – The Business of Research & Development and Fortune 500′s.) The larger companies’ integrated products became more easily managed, required less staff, and fewer end operation center consoles. The new product line also reduced operations center specialization. And yes, for you back-office folks, from a business perspective this lower cross-training is a benefit. Have you ever seen the pay checks for a really good UNIX admin?

Single vendor implementations have one other major advantage: outsourcing. A mid-sized restaurant business doesn’t make money on the latest security roll-out, and would be better served paying lower total ownership costs to someone else familiar with those services. The Managed Security Service Providers are more than happy to oblige. MSSPs like dealing with a specific product set. They will take an upfront hit on replacing a few customer security products with their preference for later recurring revenue streams. Replacement simplifies their monitoring through use of the single vendors management and reporting tools bundled with products. And they can claim the latest releases with minimized testing and upgrade headaches. After all, the single vendor is responsible for the interoperation.

Some readers may ask: “What about the best of breed? Firewall product X is 15% more efficient at 95% bandwidth utilization and…” or “Antivirus product Y has 12 more virus signatures with…”. One word: commoditization. Honestly ask yourself, by the time a head-to-head comparison reaches print, do you think Cisco, Symantec, or Microsoft have not already incorporated/road mapped whatever features they lacked? Major vendor mitigation strategies or defense in depth approaches abound, and the small players will not hold the top spot for long. They will be bought, or made inconsequential, as a great idea that everyone else incorporated. Ask the product set vendors. They’re more than happy to tell you how they’ve already overcome those anomalies. Their products are “good enough”, and will surpass any competitive deficiencies through sheer programming muscle

This single vendor solution is by no means perfect. Each new acquisition requires a release just to change the startup screens and badging. After the first major revision, the acquirer’s developers typically figure the new product out, and harmony returns to the vendor’s product set. The “commodity feature” incorporation into existing products may likewise take a programming cycle, maybe even two. Your individual product security may suffer slightly, but the tools working in concert produce a higher security, complete solution. The advantages far outweigh the detractors.


Leave a Reply




You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>