Elastic is going closed-source. Where does that leave MSSPs?

Elastic moved from an open source license for Elasticsearch and Kibana to a “source available” (aka closed source) license. It was supposed to shut down SaaS companies, but what does it mean for Managed Security Service Providers?

Managed Security Service Providers, or MSSPs, are a growing segment in the security business. These firms specialize in deploying security infrastructure, aggregating monitoring and event data, and proactively hunting threats. As a result, they are popular with small companies lacking a security practice, mid-size businesses with heavy brick-and-mortar presence, and large enterprises streamlining operations.

Many traditional Managed Service Providers, who have historically focused on IT infrastructure and applications, are building security practices to complement their legacy businesses. For MSSPs and MSPs deploying log aggregation for observability and SIEM, the ELK stack has been a popular choice, but there are new challenges ahead — more on why later.

Doubling Down on “Open” Source?

Elastic, the company behind Elasticsearch and Kibana, has made a change to their licensing. They’ve taken a unique approach to “doubling down on open”: customers can now choose between two non-open source licenses. 

After years of licensing the main codebase under the fully-open Apache-2 license and their proprietary code under the restrictive, closed Elastic License, they have moved to two restrictive licenses for Elasticsearch and Kibana: the Elastic license and the “fauxpen” (faux open, or false open) Server Side Public License (SSPL).

That the Open Source Initiative (OSI) accepts neither license, the body that governs these things, is apparently irrelevant. The OSI, an independent nonprofit founded in the late 1990s, established the criteria by which we judge which licenses are actually open source. They explicitly rejected the SSPL as fitting the bill.

As Elastic points out in their “doubling down” blog posts, the move isn’t meant to benefit their customers or the community (and certainly not the community of contributors who volunteered their time to build the codebase). It is contrary to both the spirit and the letter of open source law. Elastic has been very clear: they’re just trying to stop AWS from making money using their code.

Open Source vs. SSPL: Implications on Security Providers

Which is fine, but it may be a little short-sighted, since AWS and Logz.io just announced an open-source fork of the codebase, along with a growing set of contributors and organizations, to build a community-built and community-driven alternative.

AWS has the resources to build its own community both inside and outside its walls. If the intention was to lock out competition at the expense of the community, it doesn’t seem to be working. It makes the prospects for a Kibana or Elasticsearch fork quite positive.

The implications of this licensing move for SaaS companies incorporating the formerly open-source Elasticsearch or Kibana are clear enough. Both Elasticsearch licenses — the SSPL and the Elastic License — prevent offering the product as a service.

The Elastic License already prohibited using either source or compiled object code to run any kind of managed service. But prior to the change, anyone (e.g., AWS or Logz.io) could use Elastic under Apache-2, build on top of it, and sell it. This is how Open Source works! The move to SSPL is designed to prevent that possibility.

MSSPs: Integrating from Firewalls to SIEMs

Which brings us to Managed Security Service Providers. Many MSSPs use a best-of-breed approach to security tooling. They work with a few vendors integrating their products — firewalls, network detection, endpoint protection, SIEM — into a custom platform. This means standing up the products themselves, creating custom APIs between them, aggregating data, and potentially building an interface for end users. This platform forms the core intellectual property that MSSPs offer their customers (along with the people managing it, of course).

In 2021, as their customers’ cloud strategy becomes reality, they’re looking to modernize their stack with cloud-native products. The Elastic technology stack was a fantastic option for MSSPs: it’s interoperable, it’s flexible, it’s scalable. A great candidate to back a managed security platform. Some of Logz.io’s Cloud SIEM customers are new to Elastic, but many also operated their own ELK stacks for years. They were simply tired of the cost of operating it themselves.

So the old Elastic License was bad for MSSPs but our friend Apache-2 was perfect. How does the SSPL compare? The relevant text in the license is this:

“If you make the functionality of the Program or a modified version available to third parties as a service, you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License.”

Okay… but what is included in the Service Source Code? Oh, just this:

“…management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available.”

So essentially, under the SSPL, if you’ve stood up ELK as part of your overall offering to customers, you must release all of your intellectual property to the whole Internet. Seems like a business model killer to me.

Elasticsearch Fork Offers Hope

Logz.io’s decision to fork Elasticsearch and Kibana happened quickly, partly because we recognized the threat to MSSPs’ operations and competitiveness.

MSSPs were already one of Logz.io’s Cloud SIEM fastest-growing customer segments. That’s on account of interoperability, cost, and our in-house security analysts (plus our world-class Support and Customer Success teams).

I expect we will soon add “Elastic came for my business” to the reasons MSSPs choose Logz.io Cloud SIEM.