Blog

Managed Services in a Security Management 2.0 World

By Mike Rothman

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.

No Related Posts
Comments

Hi the information on this blog is just amazing it keeps me coming back time and time again ,personally i met my wife using this site so i couldnt like it any more i have done my best to promote this blog as i know that others need to read this thing ,Thanks for all your effort spent in making this fabulous resource ! ok,nice one Jake


<Link deleted>

By Anonymous Jake


This is one technology that I would love to be able to use for myself. It’s definitely a cut above the rest and I can’t wait until my provider has it. Your insight was what I needed. Thanks

By Managed Services


Mike – this is an extraordinarily well written piece.  Thanks for the incredible insights.

By Ben Rothke


Solid advice Mike. Very extensive.

I think some of the “hybrid” SIEM + MSS models seen today are as much a result of not being able to cast off sunk investments in earlier generation SIEM tools. The SIEM tool is initially purchased with a 24x7 SOC use case in mind. That doesn’t pan out as expected (lots of risks involved), so they bring in a MSSP for 24x7 monitoring of security devices and critical servers. The SIEM tool is still there, but being used for log management and compliance. That being said, the other examples you provided are out there too.

Yinal provides some great advice. Provider responsiveness and transparency go a long way toward making the MSSP relationship successful. It sounds cheesy, but being able to trust and verify that the MSSP is doing what they said they would is critical. The MSSP’s portal is a big enabler of that, so that’s definitely an area to dig into.

A security research team is important too, but dig under the covers to see how they really add value to what you get as a MSS customer. Lots of claims are made by MSSPs about threat research and cross-customer visibility, but it’s doesn’t help you if that intelligence isn’t applied at ground level operations and technology. Few MSSPs really live up to using security research to deliver capabilities you couldn’t replicate internally. Don’t just accept their claims at face value. Confirm they really have a substantial, dedicated research team (not just a handful of SOC engineers with new titles, and not a time-share research team that spends 90% of their time supporting other security products) and that research findings are applied to the MSS in meaningful ways.

You should also pay close attention to the support model. Yinal hit on this with a dedicated technical account manager. This is good to have, but you also want to understand who you’ll be interacting with the rest of the time. A TAM isn’t going to be there 24x7 and likely won’t be the first one to escalate a security issue to you since they aren’t SOC analysts.

How is operational support structured? How many junior techs do you have to go through to reach someone that can answer your question or solve your issue? What are the base qualifications of the analysts looking at your security events? What level of person would actually be calling you to escalate that 2am security incident?

Lastly, pay attention to what the MSSP does to get feedback from its customers. Unlike product vendors, MSSPs are delivering an ongoing service. How are they measuring the quality of that service? In my opinion, the steps any service provider takes (not just MSSPs) to get feedback and measure satisfaction is a strong indicator of the quality of service you’ll get with them.

Disclosure: I work at a major MSSP and have spent 6.5 years in the industry.

By Stacy Shelley


Mike,
Well organized post, thank you. Having spent my past life on MSSPs here is my checklist:

1) Information security know-how of existing workforce. People matters; the engineers who will be handling complex operations are a key element. Check retention rate, average years of INFOSEC experience, certifications, network know-how etc

2) 3rd party security certifications. Customers give the keys of all of their assets to MSSP. MSSPs must be audited , tested by 3rd parties regularly, check for ISO 27001, SAS-70 or similar certifications . Ask for the scope and the results of audits - not the certificate/

3) Redundancy and resilience. MSSPs must have more than 1 security operation center (SoC), all of your data cannot be risked in a single location. Operation of customers’ business should not be effected with a failure of any single component on MSSP side. Ask about replication/sync options.

4) Privacy Concerns. Make sure that the MSSP understands the privacy as well as the security. Verify regional privacy requirements (it gets complex when the data starts crossing borders)

6) Support for a large set of over the counter security appliances(Ask names). Most of the MSSPs can only support a small subset of security devices, this will limit the functionality at customer side

Security devices make less than 5% of enterprise. Support for managing security on non-security appliances/solutions is a critical requirement (Even if a SIEM is involved). Managing security on network hardware, virtualization infrastructure, servers, end points storage and enterprise apps are as important as managing security of dedicated security solutions.

7) Event correlation engines and algorithms. Security Event Management is a key feature. Verify that the MSSP can correlate alerts among multiple systems, brands, locations etc. This is a very complex business when billions of alerts are received.

8) Device management capability. Managed security is not just about remote monitoring, sometimes MSSPs need local presence at customer premises. Large scale MSSPs do not rely on centralized management consoles in their SOCs, they develop their own customer premises equipment. These devices allow customer premises log collections, local alert correlation, backups, out-of-band access, power control, dial-backup, bare metal installs etc. MSSP CPE allows 1 single connection from MSSP to customer instead of hundreds of punches on external firewalls.

9) Vendor relationship, if the MSSP is managing an information security appliance, there will be times where strong vendor support is required, make sure that the MSSP has highest vendor partnerships, and maximum number of product certified engineers . Ask for certification levels / trained engineers

10) Portal. All customer facing operations should be available on portal with extensive reporting. Access must be controlled with strong authentication. Portal should have its own application server to increase functionality and speed (instead of a database interface).

11) 7X24X365 multilingual phone support. Ability create ticket, requests via alternative channels (portal should not be the only interface)

12) Rock Solid Service Level Agreements.(SLAs). SLAs must be detail oriented and they should cover all the corners. There must be clear response times, availability promises, escalation procedures. A charge back schema is essential when SLAs are not met.

13) Full support for ITIL stack:  Change Management, Problem Management, Incident Management, Configuration Management and other major tasks must be well documented, and MSSP must provide these services for the customers

14) GRC Stack. MSSP should better support clients’ GRC requirements. Also gnerating necessary data/report/monitoring for compliance is a great add-on (e.g. PCI)

15) Dedicated technical account manager (TAM). Customers should not be talking with a new face when they have questions. Customers need a technical contact who understands their resources, network, requirements etc.

16) Solid QA process, quality of the services must be monitored by an independent QA process

17) Integration with 3rd parties. MSSP should be able to communicate with customer hosted or internet hosted services, like telecom service providers, cloud service providers,remote infrastructure management services, enterprise apps, compliance packages, risk management systems, content security providers, DR Services etc

cheers,
- yinal

By Yinal Ozkan


If you like to leave comments, and aren’t a spammer, register for the site and email us at info@securosis.com and we’ll turn off moderation for your account.