Based on the discussion in the first post, you’ve made the decision that you want to move towards a managed security monitoring service. Awesome! That was the easy part. Now you have to figure out what kind of deployment model makes sense and then do the hard work of actually selecting the best service provider for you.
And that’s a pretty important distinction to get on the table right up front. Vendor selection is about your organization. We know it’s sometimes easier to just go with the brand name. Or the name in the right quadrant to pacify the concerns of senior management. Or the cheapest one. But those may not be the best solution for your requirements. So starting the selection process requires having an open mind and then doing the work. You may end up with the brand name. Or the cheapest one. But at least then you’ll know you’ll have the best fit for you.
Deployment Options
In terms of deployment, the decision really comes down to answering two questions:
Who owns the security monitoring platform?: Who buys the monitoring platform? Is it something provided as part of the service or do you have to buy it up front? Who is in charge of maintenance? Who pays for upgrades? What about additional scale? Are you looking at a multi-tenant monitoring platform, which would obviously be the property of the service provider?
Where is the SOC? And who staffs it?: The other key question concerns the operation of the security monitoring platform. Is the central repository and console on your premise? Is it run in the service provider’s data center? Does it run in the cloud? Who fields the staff, especially if some part of the platform is going to run on your site?
To break down the chart above, here are the options you have depending on how you answered the questions above:
Traditional: In the traditional model, the customer buys and operates the security monitoring platform. Alternatively, the provider could buy the platform and the customer pays monthly, but that has nothing to do with operations. In both cases, the monitoring platform runs on customer premises and is staffed by the customer. This is not managed security monitoring.
Hybrid: In a hybrid model, the customer owns the monitoring platform and it resides on customer prem, but the service provider manages it. The provider handles the alerts and assumes responsibility for maintenance and uptime of the system.
Outsourced: In this model, the service provider owns the platform that resides on customer prem. Similar to the hybrid model, the provider staffs the SOC and assumes responsibility for the operations and maintenance of the platform.
Single-tenant: The service provider runs the monitoring platform in their SOC (or the cloud), but each customer
has their own instance and there is no intermingling of security data.
Multi-tenant: In this model, the service provider has a purpose-built system to support many clients within the same environment, running in their SOC (or the cloud). The assumption is that there are application security controls built into the system to ensure customer data stays restricted to only authorized users, but that’s definitely something to check as you do diligence on the provider’s architecture.
Selecting Your Provider
We could probably write a book about selecting (and managing) a security monitoring service provider, and perhaps someday we will. But for the time being here are a few things to think about:
Scale: You want a provider that can support you now and scale with you later. Having many customers roughly your size, as well as a technology architecture capable of supporting your plans, should be among the first selection criteria.
Viability: Similarly important is the financial grounding/stability of the provider. Given the time it takes to migrate elsewhere, and the importance of the security monitoring service, having a provider go belly up would put you in a precarious situation. Many of the managed security monitoring leaders are (now) part of giant technology companies, so this isn’t much of an issue anymore. But if you are working with a smaller player make sure you are familiar with their financials.
Technology architecture: Does the provider use their own home-grown technology platform to deliver the service? Is it a commercial offering they have customized to meet provider needs – adding capabilities such as support for multi-tenancy? Do they provider have their own collection device, and does it support all of the security/network/server/database/applications you have? Where do they do their analysis and triage of alerts – within their system or do they use a commercial monitoring platform running on their site? How many SOCs do they have, and how is the data replicated between the sites? Understand exactly how their technology works, so you can assess whether it’s a fit for your particular use cases and scalability requirements.
Staff Expertise: It’s not easy to find and retain talented security analysts, so be sure to vet out the typical background of the folks the provider has handling your account. Obviously you can’t vet all of them, but understand the base qualifications of the analyst team, like years of experience, years with the provider, certifications, ongoing training requirements, etc. Also make sure to dig into their hiring and training regimens, since they’ll have to both find new analysts and make the productive quickly given industry growth and inevitable attrition.
Industry specialization: Does the provider have many clients in your industry? This is important because there are many similarities in both traffic dynamics and attack types within an industry, and you want to be able to leverage the provider’s expertise. Given the maturity of most managed security offerings, it’s reasonable to expect a potential provider to have a couple dozen customers in your industry with similar characteristics.
Research capabilities: One reason to consider a managed service is to take advantage of resources you couldn’t afford yourself, but which the provider can amortize across all their customers. Security research and the resulting threat intelligence is a good example of this. Many providers have full time research teams to investigate emerging attacks, profile them, and keep the collection devices up to date. So get a feel for how large and capable a research team the provider has, how their research applies to the services, and how you can interact with the research team to address specific answers you need.
Customization: The service provider will deliver a reasonably standard service – leveraging a core set of common features is how they can be profitable. That means you may not get as much customizability with a managed offering. Or if you do it may be expensive. Some providers may argue that, but be very wary of those willing to highly customize their environment just for you, because it’s hard to make that model work at scale.
Service level agreements: Finally make sure the service level agreements that govern the provider relationship give you realistic assurances. Look for a dedicated account team, reasonable response times, clear escalation procedures, criteria for scope expansion/contraction, and a firm demarcation of responsibility – before you sign anything. Once the deal is signed you have no leverage to change terms, so use your leverage during the courting process to ensure your SLAs reflect the way you do business. Ultimately you need to trust that the provider will do their job and resolve issues as they emerge.
You may also want to consider taking the service for a spin as part of the selection process. Similar to the proof of concept (PoC) process we outlined above, start small by collecting data from a handful of devices and run through the typical use cases driving the purchase. With a service offering it is as much about the interface and user experience as anything else, but be sure to test out the alerting process, as well as escalation procedures for when the provider doesn’t reach expected service levels.
Checking References
There are at least two sides to every story. We have seen very successful security monitoring engagements, with customers large and small. We have also seen train wrecks. Of course the customer can be as responsible as the service provider when things go off the rails, but ultimately it’s your responsibility to do sufficient due diligence when selecting a provider to learn the good, the bad, and the ugly regarding any potential provider.
That means talking to both happy and unhappy customers. Obviously the provider is unlikely to introduce you to disgruntled or former customers, but they are always happy to introduce you to happy customers who chose them over another provider. Or a customer who threw out one vendor to go with another. Leverage all the vendors competing for your business to assemble a set of both positive and not-so-positive references for all your potential providers.
Specifically, you should dig into a few areas:
Deployment/Migration: Make sure you understand the process to move to the provider’s platform. How will they deploy the collectors? Can they import your existing data? What kind of project management oversight governs the deployment and cut-over? These are key questions to bring up during your reference calls. Ask for a very specific migration plan up front.
Responsiveness: What kind of experience have their customers had getting alerts and investigating issues? Have their analysts been helpful? Do they provide enough information to do your own investigation? Remember, when the bad guys come knocking you don’t have time to deal with bureaucracy or any other issues that might get in your way. You need the data and you need to get the investigation moving – the provider must not hinder that process. Build responsiveness metrics into your agreement, along with escalation policies and penalties for insufficient responsiveness.
Expertise: Do they know what they are talking about? Did they do a bait and switch with the analysts monitoring customer networks? How accurate are their alerts? Everything looks great during the sales cycle, but you want to make sure the A team (or at least the B+ team) is who works your account on a daily basis.
SLA violations: Not everything goes well. So learn how the provider deals with issues. Are they responsive? Do they work until the problem is solved? Have they been sued for breach of contract by other customers? This is where discussions with the former clients can provide very useful information. There is usually a reason they are former clients, so find that out and factor it in. The provider should have a boilerplate SLA for you to review.
Account management: How does the relationship evolve over time? Is the account rep just there to sell you more services? Does the provider check in periodically, just to see how things are going? Do they take your feedback on product shortcomings and feature requests seriously? A service provider is really a partnership, so make sure the provider actually acts like a partner with the customers.
Mismatched Expectations
As when an on-premise security monitoring implementation goes awry, the root cause can usually be traced back to mismatched expectations. When dealing with a monitoring service, always keep in mind what the service does, and don’t expect it to be something it’s not. Don’t count on deep customization, or deep off-menu capabilities unless these are agreed upon up front.
Using a service provider for security monitoring can certainly help provide both resources and capabilities you don’t have in-house. That being said, you have to make sure to do your diligence to ensure that you’ve got both the right fit and the right structure in place to manage the provider.
- Mike Rothman
(0) Comments
Subscribe to our daily email digest