Comprehensive software reviews to make better IT decisions
Making Sense of SIEM Pricing: Pricing by Data Volume
As the Security Information and Event Management (SIEM) market continues to grow, organizations now have more options than ever to decide which SIEM is right for them. While SIEM vendors continue to innovate and add to the breadth of features already available, decisions around which SIEM is right for organizations sometimes comes down to price. In the second of this five-part series on SIEM pricing, we will dive into pricing by data volume.
Before diving into the traditional pricing model, let’s understand what is generally required upfront. Typically, organizations can expect to put forward a large capital expenditure when purchasing a SIEM if they are managing it on-premises. There are many different deployment models that have implications for how to manage the SIEM including:
- On-premises:
- Managed internally
- Managed by service provider
- Managed internally and with service provider
- Hybrid on-premises and cloud:
- Managed internally
- Managed by service provider
- Managed internally and with service provider
- Cloud:
- Managed internally
- Managed by service provider
- Managed internally and with service provider
These deployment models each require different strategies for managing the resources that will be fed into the SIEM. The management of the SIEM may be dictated by in-house expertise versus efficiencies made available by hybrid management between internal personnel and with a managed security service provider.
This leads us to the topic of pricing by data volume. Data volume can be priced based on events per second or based on Megabytes or Gigabytes indexed per day. On average, organizations tend to assign more value to vendor capabilities than to costs and may begin their SIEM search by looking at the breadth of capabilities. However, when organizations solely look at the breadth of features, initial capital expenditure plus operational expenditure from licensing based on data volume is usually met with staggering sticker shock.
This is because organizations do not generally consider the many preparation efforts needed before approaching SIEM vendors. To begin with, determining the amount of data that will be fed into the SIEM is difficult because organizations do not typically have that calculation on hand. For instance, if you need to feed your firewall logs into the SIEM, is it clear how much data will be ingested and how often that ingestion needs to take place? Generally, some data should be fed at near real time for incident response and prevention as well as for automation and correlation rules. While other data should be fed in non-real time for operational/informational goals such as event and problem management, vulnerability management, and for regulatory compliance. Knowing these will drastically impact your understanding of the number of events or data that will be fed per day.
Once you have defined these goals, you will need to map out the assets that you want to feed into your SIEM initially and plan for what will be added in the future. Furthermore, you will need to determine how much data all these resources will produce so that you have an idea of how to plan your licensing and your initial SIEM implementation.
Finally, organizations need to consider their data retention policies for all the different data types that will be fed into the SIEM. Some of these configurations may require different policies depending on regulatory compliance, but others should be preserved depending on your needs:
- Hot log retention: 1 to 60 days for real-time analysis
- Warm log retention: 61 to 120 days for determining if something is historically inconsistent
- Cold log retention: 121 to 180 days that triggers a threshold review
- Frozen log retention: 181 days to 6 years for limited searching capability
Source: Security Incident and Event Management at SoftwareReviews, Report Published October 2019
Our Take
All these considerations factor into data volume pricing, which does not simplify things for IT security shops that are strapped for time and cash. However, pricing by data volume can save organizations time and money if done effectively, since there are other costs associated with implementing a SIEM besides data ingestion. For instance, if the above can be done internally, deployment will be that much easier because the security operations team will understand how to configure resources to be sent to the SIEM and potentially save costs in hiring consultants for deployment. Furthermore, knowing what needs to be ingested at both near-real time and non-real time will potentially reduce the costs of data ingested per day or events per second. Finally, knowing log retention will be important for strategically using the data beyond security incident response and prevention, which can draw in other business units’ interest in using the SIEM for their own event and problem management. As many SIEM vendors still price their solutions by data volume, understanding the various deployment models, resource data volume, resource inventory, event management ingestion timeframes, and log retention periods are crucial when starting your SIEM search.