Making the Business Case for Managed Security Services

Solutionary Blog and Bloggers

Solutionary is an information security company. What does that mean? Simply put, we help businesses protect their assets, remain fully secure and safe online, and maintain and adhere to compliance regulations and standards. Solutionary's blog is a place to learn about, and discuss, a wide variety of security and compliance topics.

For more information about Solutionary, click here.

To read the Solutionary blog comment policy and disclaimer, click here.

Solutionary Bloggers:

Brad Curtis, Compliance Manager              Jon Heimerl, Director of Strategic Security  Mike Hrabik, President and CTO             Don Gray, Chief Security Strategist       Court Little, Director of Strategic Security Joseph Blankenship, Director of Marketing 
Doug Picotte, Regional Technical Manager
Rob Kraus, Director of Research               Erik Barnett, Regional Technical Manager Jose Hernandez, Security Consultant
Jozef Krakora, Sr Product Manager      Robert Jeffries, Research Analyst, Security Engineering Research Team (SERT)

Subscribe to our blog

Your email:

Browse by Tag

Solutionary Minds - Your Information Security Blog Source

Current Articles | RSS Feed RSS Feed

Making the Business Case for Managed Security Services

Posted by Brian Reed on Tue, Sep 14, 2010 @ 09:32 AM
  
  
  
  

My entire IT career, I have been solely focused on building, positioning and selling security products.  I have been continually asked over the years to help prospects and customers to make business cases or present facts based upon their business drivers as to why they should buy/change a particular product.  Since coming onboard at Solutionary, I have had a very similar question from prospective customers to "make the business case" for managed security services.

Realizing I could write a book on this topic alone, I wanted to simply present two points as to why MSSP makes more business sense than trying to acquire/grow/retain IT security talent internally in your organizations.

1.  All security products are actually pretty equal.

This is actually a pretty bold statement, and no product vendor will ever openly admit this.  Certainly some vendors do a better job than others at manageability and scalability of their products, but by and large most security products are fairly equal in their security coverage and basic features (the differences is in their security contact backed by research, and their speed/accuracy in delivering the end result to market).  However, many security technologies could certainly be considered "commodity" technologies, and I would include endpoint anti-malware security, network IDS/IPS, network firewalls, email security and web security. 


When was the last time someone switched firewall vendors primarily due to the technology?  In fact, firewall migrations from one platform to another, are largely attributed to business drivers, such as Company A merges/acquires Company B, where Company B uses Firewall Y where A uses Firewall X.  Endpoint security works the same way - typically whoever has the greater incumbent footprint wins, since touching each endpoint for a migration from one vendor to another is painful.  Switching products could also result from a product vendor’s maintenance renewal being too expensive, or a competitor running a specific promotion to displace a competitive product.

If we can agree that all security products are more or less equal, why wouldn't you have a third-party monitor/manage this for you?  Let a trusted MSSP worry about training costs, and those hidden switching costs if your business changes result in a technology shift?  Seems to make a lot more sense than hiring full-time staff to do this, which leads to …


2.  How are you going to pay to keep up the products in your environment?

The question most vendor sales reps don't want you to ask (I used to be one).  "Forget about the price - so how much is my actual TCO going to be for 3 years, or 5 years?"  If you are a vendor sales rep selling a new solution, or one that requires the customer to send people to training, this question hurts.  It is a barrier for you to sell your product (especially if it is new or complex, or both), because a customer buying new technology is going to need to train at least one person (preferably 2-3 or more) on your product.    That's a lot of capital expense upfront to send people to training, not to mention the time away from supporting the environment and their daily tasks. 

As an end-user of security technology, you also need to have a strong grasp of what your own internal employees do today to support your infrastructure.  Is your staff focused on the security initiatives you deem critical, or is their attention split between "analysis paralysis" or working on "pet projects" that may or may not be addressing business risk in your environment.  Finally, if you have compliance drivers, are you able to get provable metrics and data internally, or should you really be getting this verified by an independent third-party source?

Why wouldn't you employ a MSSP that already has multiple people on staff trained on your new or existing products, and free up your own staff to support security initiatives that you cannot offload to a trusted third-party? 

 


describe the image

Tags: 

COMMENTS

Brian,  
 
 
 
I agree with the general thrust of your argument; however, arguing that all security products are "more or less equal" is to oversimplify in the service of boldness. I would argue theat Palo Alto Networks' firewall, for example, is much different than the Cisco PIX it might replace. 
 
 
 
What you say is generally true of mature security solutions - but when a new vendor innovates on an existing platform, decisions are made by "Type A" customers (as Gartner likes to call them) on the basis of security goodness. 
 
 
 
Then there are the point solutions (NAC, DLP, etc) that eventually either gain enough critical mass to remain distinct markets, get folded into mature platforms, or disappear. So long as none of those three endgames have happened, decisions on these immature technologies are almost always made on the basis of security and the customer's particular use case.  
 
 
 
All of that said, you are correct that, generally, security technologies commoditize over time.

posted @ Tuesday, September 14, 2010 1:18 PM by Adam H.


Adam, 
 
When I stated that "all security products are more or less equal", I should have clarified that this was equality in basic functionality. Product equality of basic features certainly DOES NOT mean that all products are "the same". That was not my intention - and in fact products and services backed by security knowledge and research should be referenced more frequently as a key differentiator by all vendors. 
 
I agree with your general assertion, but I would also contend that for any given product/service, you will be hard pressed to find a customer using 100% of all of the available features at a single point in time. That does not mean that products aren't out there making innovations into established product markets and features or even creating their own market categorizes. 
 
Different solutions will be better aligned based upon a variety of factors, such as location, business problem or ability to mitigate security risk. The art of this process is in selecting the most appropriate product, implementing it properly and managing it in a way that provides actionable information in a cost effective way. Vendors continue to innovate and develop products that address evolving needs and industry challenges. 
 
The point of any blog is to provide points to the reader that will in turn promote open dialog, which we have created and I thank you for your comment. Blogging should not be a uni-directional form of communication - in fact my goal (and hope) was that readers would key on the point about security knowledge and research being the key differentiator in products. 
 
Thanks, 
Brian

posted @ Thursday, September 16, 2010 2:34 PM by Brian Reed


Post Comment
Name
 *
Email
 *
Website (optional)
Comment
 *

Allowed tags: <a> link, <b> bold, <i> italics