As we posted the Security Management 2.0 series, we focused heavily on replacing an on-premise option with another on-premise option. We paid a bit of lip service to the managed SIEM/Log Management option, but not enough – the reality is that, under the proper, circumstances a managed service presents an interesting alternative to racking and stacking another set of appliances. So consider this a primer for managed services in the context of our Security Management 2.0 discussion. We will go through the drivers, use cases, and deployment architectures for those considering managed services. And we will provide cautions for areas where a service offering might not meet your expectations.

Drivers for Managed Services

We have no illusions about the amount of effort required to get a security management platform up and running, or what it takes to keep one current and useful. Many organizations have neither the time nor the resources to implement technology to help automate some of these key functions. So they are trapped on the hamster wheel of pain, reacting without sufficient visibility, but without time to invest in gaining that much-needed visibility into threats without diving deep into raw log files. A suboptimal situation for sure, and one that usually triggers discussions of managed services in the first place. Let’s be a bit more specific about situations where it’s worth a look at managed services.

• Lack of internal expertise: Even having people to throw at security management may not be enough. They need to be the right people – with expertise in confirming exposures, closing simple issues, and when to pull the alarm and escalate to the investigations team. Reviewing events, setting up policies, and managing the system, all take skills that come with training and time with the product. Clearly this is not a skill set you can just pick up anywhere – finding and keeping talented people is hard – so if you don’t have sufficient sophistication internally, that’s a good reason to check out a service alternative.
• Scalability of existing platform: You may have a decent platform, but perhaps it can’t scale to what you need for real-time analysis. As we discussed in the Platform Evaluation post, this is common for those deploying first generation database-based SIEM products, who then face a significant and costly upgrade to scale the system. This can also happen to acquisitive organizations, who bring on significant assets and need to integrate management capabilities quickly to get sufficient leverage. With a managed service offering scale is not an issue – any sizable provider is handling billions of events per day.
• Risk Transference: You have been burned before – that’s why you are looking at alternatives, right? You’re not sure what solution to select for the long haul. Why risk the investment when you can drop that monkey on someone else’s back? This allows you to focus on the functionality you need instead of vendor hyperbole and sniping. Ultimately you only need to be concerned with the application and the user experience, and all that other stuff is the provider’s problem. So selecting a provider becomes effectively an insurance policy to minimize your investment risk. Similarly, if you are worried about your ops team’s ability to keep a broad security management platform up and running, you can transfer operational risk to a safer outside team. Once again, that operational risk goes to the provider, who assumes responsibility for uptime and performance.
• Geographically dispersed small sites: Managed services also interest organizations which need to support many small locations. Think retail or other distribution-centric organizations, where the central site may have sufficient expertise but there is very little capability at the remote sites. That might work well – particularly if event traffic can be centrally aggregated. But if not, this presents a good opportunity for a service provider who can monitor the remote sites.
• Round the clock monitoring: Some organizations need to move from a 8-hour/5-day monitoring schedule to a round-the-clock approach. Whether this is driven by a breach, a new regulatory requirement, or some kind of religious awakening in the executive suite, staffing a security operations center (SOC) 24/7 is a huge undertaking. But a service provider can leverage that 24/7 staffing investment across many customers, and might be in a much better position to deliver round-the-clock services.

Of course you can’t outsource thinking or accountability, so ultimately the buck stops with the internal team, but under the right circumstances managed services can address skills and capabilities gaps. So let’s dig into a few of the use cases that provide a good fit for managed SIEM or Log Management.

Favorable Use Cases

Many providers offer a managed SIEM/Log Management platform as the equal of an in-house solution, and that may be the case. Or it might not – depending on the sophistication of the implementation, as well as the capabilities of the provider’s technology and internal processes. Under the right circumstances you can get a managed SIEM offering to do (almost) everything you could with an in-house option, but in reality we very rarely see that.

More often we see the following use cases when considering a service alternative:

• Device Monitoring: You have a ton of network and security devices and you don’t have the resources to properly monitor them. That’s a key situation where managed security management can help. These services are generally architected to aggregate data on your site and ship it to the service provider for analysis and alerting. The provider should have a correlation system to identify issues, and a bunch of analysts who can verify issues quickly and then give you a heads-up.
• Compliance Reporting: Another no-brainer for a services alternative is basic log aggregation and reporting – typically driven by a compliance requirement. This isn’t a very complicated use case, and it fits well with service offerings. It also gets you out of the business of managing storage and updating reports when a requirement changes. The provider should take care of all that for you.
• CapEx vs. OpEx: As much as it may hurt a security purist, any buying decision comes down to economics. Depending on your funding model and your organization’s attitude toward capital expenses, leasing a service may be a better option than buying it outright. Of course there are other ways to turn a capital purchase into an operational expense, and we’re sure your CFO will have plenty of ideas on that front, but buying a service can be a simple option for avoiding capital expenditure. Obviously, given the long and involved process to select a new security management platform, you must make sure the managed service meets your needs before economic considerations come into play – especially if there’s a risk of Accounting’s preferences driving you to spend big on an unsuitable product. No OpEx vs. CapEx tradeoff can make a service meet your requirements.

Of course there are offerings and situation where managed services make sense, which have nothing to do with those nice clean buckets. We have seen implementations of all shapes and sizes, and we need to avoid overgeneralizing. But the majority of service implementations fit into these categories.

Hybrid Architectures

One of the emerging deployment architectures we see is a hybrid model, where an organization uses both a service and an in-house option. You know the quote from the movie Contact: “Why buy one, when you can buy two for twice the price?” In reality, this model fits a number of the use cases described above. In particular, it enables organizations with experienced analysts to reserve them for high-value investigations. Due to the limited application and database support of a managed SIEM, these offerings can’t really Monitor Up the Stack, so more sophisticated identity and application-oriented monitoring require an in-house platform to collect and analyze that data. We also see this approach used by organizations with in-house forensics teams which need direct access to the data; they can use the internal platform for forensics and the managed service for security alerting and compliance reporting.

So why pay for both? It only makes sense when there’s no good either/or answer to the buy versus build decision, and greater flexibility in resource utilization is needed. Do you have valuable resources with more important things to do than collect and analyze data from network and security devices? Can a service provider do that more cost effectively? Do you want to staff up your security operations center for 24/7 support? Can you realistically support all your far-flung locations? Most sophisticated organizations need to collect data internally for forensics and investigations, but there is no prize for doing everything yourself. Hybrid models address some of the scaling and expertise issues in a sophisticated investigations environment.

Selecting Your Provider

We could probably write a book about selecting (and managing) a 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 who 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.
• Provider 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 management service, having a provider go belly up would put you in a precarious situation. Many of the managed security services 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 have their own collection device? As described above, the technology platform is the provider’s problem/decision, but it will either enable or constrain what you can do with their service. Understand exactly how their technology works, so you can assess whether it’s a fit for your particular use cases and scalability requirements.
• 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 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, and how their work provides value to you.
• Out of the box capabilities: 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 won’t get as much customizability with a managed offering. Or if you do it will 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. But if you need to do simple correlation, event reduction, or forensic analysis, a service might be a good option.
• Service level agreements: Finally make sure the service level agreements that govern the provider relationship give you realistic assurances. Look for reasonable response times, escalation procedures, scope expansion/contraction, and clear 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.

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 in the Security Management 2.0 series, 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 situation. We have seen very successful security management engagements, with customers large and small. We have also seen some 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 their implementation? These are key questions to bring up during your reference calls. Ask for their 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? 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.

Mismatched Expectations

As when an on-premise security management implementation goes awry, the root cause can usually be traced back to mismatched expectations. When dealing with a managed 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. The service provider has built a profitable and viable business by standardizing their offerings and generating as much leverage as they can. Provider viability is high among the selection criteria, so that’s no a bad thing.

But you won’t have all the knobs and buttons of an on-premise solution. Don’t forget that.