The trend to move the SIEM to the cloud is very clear by now. Even vendors known to sell appliance-based products are now offering or (the slower ones) working on their cloud SIEM product. But one important thing to consider when selecting a cloud SIEM is knowing how “cloud native” each product is.
Why does cloud native matter?
First let’s see the many different ways you can offer a “cloud SIEM”. The most basic one is putting the same software product you offer to customers to deploy on premises and let them run it in their own IaaS environments. In the end the product will be, in fact, running in the cloud, but that’s where it stops. The customer’s responsibilities remain the same, so they cannot get rid of some operational work, such as patching operating systems. For me this is really “fake cloud”. Some vendors doing this may change their license from perpetual to a subscription as a way to validate the “as a service” thing, but this model will not provide most of the benefits you can get from using a cloud SIEM.
A better option is where the vendor runs the same software in their own cloud environment, or somewhere else not managed by the customer. In this model the customer will be able to offload responsibilities to the vendor and will be able to redirect the resources that previously worked on those “running the SIEM” operational tasks to more important, “using the SIEM” work. Many, if not most of the SIEM vendors that started with traditional software are here.
The best way SIEM can be offered from the cloud is as a native SaaS solution. Here the product is developed and operated from the start as a cloud application. My friend Anton properly described this as a SIEM “that was built as SaaS using cloud technology and operational practices”. (Note that it does not mean the vendor is cloud native; the important consideration here is the solution is designed and developed as a cloud solution. Securonix started with traditional software products, but it didn’t try to run the same software from the cloud, it developed a native cloud solution as its SaaS offering)
The difference between the basic alternative and the others is clear, as the amount of work in the hands of the customer is different. But are there any real differences for the customer between the better and the best options?
Well, imagine you are hiring a company to provide transportation from your organization headquarters to the city airport. One supplier owns just one compact car that will be used to provide the service. The other provider owns a full fleet of vehicles of different types, from compact cars to vans, buses, and even a helicopter. Let’s suppose you select the company with just one car. You may start using the service only occasionally, one passenger at a time. In these conditions, you would probably not notice any difference between the two services.
But one day your entire team needs to go to the airport. They come to pick you all with the small car. How are you supposed to fit dozens of people in that vehicle? The driver looks at you and say: “don’t worry, it’ll take a few trips, but I’ll take you all there…eventually.” That’s what happens when a SIEM provider takes shortcuts trying to offer traditional software as SaaS: It may seem to work for the simple cases, but it’s just one change in scope, size, or use case from failing.
One great example of how Securonix architects its solution as a cloud native application is how we leverage cloud exclusive services such as AWS EMR and AWS Athena.
Our analytics leverage Spark jobs, which would normally run on a traditional Hadoop cluster. But if you want to host a Hadoop cluster in the cloud you’ll need to figure out the best way to do a number of things: Scale the infrastructure up and down, optimize storage access performance, manage the cluster, the operating system and base software components running on each node, among others. So apart from the main part of the solution, the analytics, you need to build a huge instrumentation and support layer to make it robust enough to be offered as a multi-tenant SaaS application.
Enter AWS EMR. AWS EMR, or “Elastic MapReduce”, provides a serverless service to run MapReduce jobs in a scalable and elastic way. It is optimized to access data stored on S3. Because all optimization is done through proprietary AWS code, it would be very hard to get the same performance from your own cluster using Apache libraries (s3a). And that’s just one of the benefits. There is dynamic orchestration, which we can use to maximize resource utilization, which translates into our ability to offer a per user-based license instead of by ingested data volume. EMR also monitors the slave nodes and replaces any unhealthy node with a new node, allowing us to achieve high levels of availability.
Just like any other SaaS SIEM vendor, we must navigate between our own cloud utilization bill and the revenue from our product subscription. Vendors who do not know how to optimize cloud resources will either offer extremely expensive solutions or penalize you with underwhelming performance and hard utilization limits. But those architecting their solution as a cloud application can leverage the best cloud service for each solution component. Our way of using AWS Athena is a perfect example of that.
Offering long term retention in the cloud is challenging. There is no point in offering to store data for a long time if searching it takes forever. Many vendors are caught in a situation where they need to oversubscribe to the same expensive compute and fast storage services they use for the hot, online use cases to search data stored for longer periods. You see how it ends in you bill. And it hurts.
Enter AWS Athena. Athena provides a SQL interface for data stored in files in S3. A pay by query, very fast query service. Securonix identified in Athena the perfect tool to provide SearchMore, our long-term retention solution that delivers low cost and great search performance. It is the approach that allows us to offer 50% or more in savings over the cost from Splunk cloud.
This is a real native cloud, SaaS SIEM.
When you are evaluating a SaaS SIEM solution, check out the solution architecture; you may find that single compact car behind the shiny web based “SaaS” interface. It may work initially, but you may find yourself late to your flight when your requirements evolve.