Editor’s Note — August 19, 2020: The Elastic Endpoint Security solution mentioned in this post is now referred to as Elastic Security. The broader Elastic Security solution delivers endpoint security, SIEM, threat hunting, cloud monitoring, and more. Future mentions of Elastic endpoint security will refer to the specific anti-malware protection that users can enable in Ingest Manager.
Given the complexity of large enterprise environments, coupled with the diversity of the vendor landscape, there is no single, agreed-upon “best” way to buy security. The battles continue between CAPEX or OPEX, net-30 or net-90, annual or multi-year, perpetual or subscription.
One thing we do know, however, is that all too often the consumer pays for something they do not use. For example, in the endpoint security space, an organization of 50k endpoints that is planning to deploy an EDR or EPP solution over the course of the year will purchase licenses for 50k endpoints on day one. In practice, however, an organization of that size might take over six months to fully deploy their newly purchased solution(s).
For the first six months, the buyer is over-subscribing since they are not fully deployed. Purchasing licenses based on forecasted usage and paying in advance for capacity not yet needed results in overpayment. This type of per-endpoint purchasing also makes expansion difficult if a customer decides to increase its coverage, since doing so usually requires re-engaging with the vendor in the middle of the contract period in order to increase the allowable footprint.
In addition to per-endpoint pricing, another well-established (and equally problematic) model is ingest-based pricing — common in the SIEM market. This pricing model is based upon measuring the consumption of data upon ingest before the consumer can extract any value from that data. Vendors with this pricing model force the buyer to choose what data may be most valuable at the time of contracting, before a full environmental analysis and risk assessment can be performed. Pricing on ingest essentially asks users to make a choice about the data they will store while providing little ability for the customer to make smarter decisions after data analysis has been performed. The net result is that organizations are forced to build security risk plans based on budgets, not on security outcomes.
The case for resource-based pricing
Rather than subscribing to traditional per-endpoint or ingest-based pricing models, what if we looked at data consumption through a different lens? One that maximizes an organization’s optionality and predictability — whether they are using an endpoint, a SIEM, or both?
At Elastic, we are providing our customers with a consumption-based model that does not force them to over-purchase by pricing per-endpoint or force them to limit the data available for analysis by charging per-byte ingested. So, if Elastic doesn’t price security per-endpoint or per-ingest, what the heck are we charging for? We call the model resource-based pricing. It may initially sound too good to be true, so let us explain.
The simplest way to understand resource-based pricing is this: You only pay for data usage – not ingest, document, or any other metric. And usage boils down to compute, storage, and memory; the speed with which you want to extract value from your data. Install Elastic Endpoint Security on all your endpoints, collect and store all the data from those endpoints, then make the informed decision on how long to keep the data searchable (actionable) and what type of query time is right for your organization.
Remember, Elastic powers sites like Wikipedia, so we’re well capable of making your large database of security data searchable in milliseconds. Most organizations are used to other vendors taking hours or longer to execute queries, so our Elasticsearch-based technology — budget-friendly options aside — still blow minds with the speed at which it returns information.
Key challenges to traditional pricing models
Let’s address some of the challenges current enterprise security buying models face:
As mentioned above, buyers usually budget and purchase for their enterprise when agreeing to their per-endpoint, annual, or multi-year subscription. And they almost always underestimate the time it will take to deploy the protection across their environment. The result is a buyer paying for the endpoints they have not yet installed/protected for months. A model where a buyer pays for what they use allows them to deploy on their schedule without penalty.
SIEMs started as a way to prioritize the alerts from other security products and allow analysts to strive for the always-out-of-reach single pane of glass. And as SIEMs grew in capacity to store not just alerts, but also security event data, we realized that SIEMs could begin to find threats missed by other tools. In the dawn of threat hunting, SIEMs were the tool of choice to analyze all the ignored events to find anomalies, outliers, and correlations that could only be detected at the centralized location – finding the proverbial needle in the haystack.
However, as data has become increasingly important to security users, some vendors decided to price the collection of the data in a consumer-unfriendly way — forcing the decision of data collection on ingest. The buyer started throwing “hay” on the floor in order to save money, and since there was no analysis done on the data, many “needles” were dropped as well. Buyers began to revert back to SIEMs collecting alerts, and not a whole lot else, due to predatory vendor pricing. Resource-based pricing, by contrast, allows users to make the decision AFTER the data is collected and analyzed. Buyers can decide if certain data should be kept, for how long, and what kind of query time is acceptable — giving them the ability to pull in all their data and find threats others miss in a cost effective way.
The nightmare of every CISO is waking in the middle of the night to the dreaded call informing her: “We’ve been breached.” When a potential breach is found, the first priority is scoping and remediating, not negotiating a larger purchase with a security vendor. What happens if there is a business unit that needs to be remediated that was not in the initial endpoint security purchase? Or a new group of servers whose data needs to be analyzed immediately for signs of infection?
In the antiquated per-endpoint or per-ingest models, the buyer either needs to turn off protections on some amount of systems to “swap the coverage over” or begin vendor negotiations for expanded capability. The first reduces your security risk posture on those systems and the second is the last thing a CISO wants to do while trying to stop the bleeding. In a resource-based model, the buyer simply expands their coverage. Maybe the queries get a little slower (minutes instead of seconds), or they retain 45 days instead of 90 days, but they get to solve their mission now, without delay.
Some consumption-based pricing models are associated with unpredictability due to the dynamic nature of the scaling (i.e. cloud infrastructure). At Elastic, we pair the benefit of a consumption-based model with the predictability of “consumption capping.” A customer can always decide to grow their resource usage, but we do not silently scale the cluster and surprise them with a new, higher bill. They make that conscious and deliberate choice. The sizing is capped to their predicted spend to give them the peace of mind that their bill will be what they expect AND allows them the flexibility to surge when needed.
Purchase order nightmares
Raise your hand if you are duplicating data. Triplicating data. Quadruplicating data. The market is rife with features masquerading as products, each requiring a copy of your information to make their unique and informed analysis. This means that an expansion from enterprise security to an adjacent market like observability involves a new vendor, new architecture, some new data model, new workflows, more training, more services, and your data replicating over and over again. Elastic provides many ways of looking into a single data store. And the resource-based commercial model means you do not fall victim to death-by-line-item on your purchase order.
You do not pay for use case; you pay for resources. If you want to provide site reliability engineers access to Elastic to use the data we are already collecting to monitor uptime and availability using our Observability solution, you can easily do so and only pay a minimal increase for the new resource consumption. You do not need to purchase an entirely new product, pay to store that data in new servers or in some new cloud, and there is no training cost since it’s all in the same product your team has been using for years.
Now repeat this same process for enterprise search, custom machine learning development, geo-spatial use cases, business analytics, and more. All your data, in one place, for one price.
Closing the case for resource-based pricing
We at Elastic believe that resource-based pricing is the model most likely to result in good security while also allowing for operational ease and business predictability. It’s a new model for endpoint and SIEM users, and like all new ideas it requires some explanation. If the challenges mentioned we discuss here sound familiar to you, let us introduce you to Elastic Security firsthand.
Want to give Elastic Security a spin? Experience our latest version on Elasticsearch Service on Elastic Cloud. Already have ECS-formatted data format in Elasticsearch? Just upgrade to 7.6 of the Elastic Stack to get on the hunt.