Sumo Logic, the Bay area-based machine data analytics platform, recently released a new offering that uses aggregated AWS customer data to let customers benchmark themselves against other AWS cloud infrastructure adopters.
The idea of the “Global Intelligence Service” (GIS) for Amazon GuardDuty, AWS’s threat detection service, is intended to help users assess their cloud security posture. Computer Business Review put some questions about the service to Sumo Logic co-founder and CTO Christian Beedgen in a bid to understand more and see where it fits into an increasingly competitive cloud security marketplace.
How is AWS Benchmarked? And Why GuardDuty for the First GIS?
We of course know today that there’s a tonne of opportunity when you use the cloud. You can outsource a lot of the undifferentiated heavy lifting, and you can reduce the time to market. At the same time, the cloud introduces new approaches, technologies, and abstractions. So there’s more power to the people, but this comes with some amount of new complexity.
The question then becomes, as a cloud user, how can I figure out whether I am doing it right? And frankly, it doesn’t even just have to be cloud usage. The same questions arise if you keep stuff on-prem––you will still want to know how to really run say Kubernetes well. Sometimes, there is no scientifically correct “right” answer and so you want to understand whether what you are doing follows convention and best practice.
The idea behind the Global Intelligence Service is to look across what we are seeing for many of our customers and derive useful insight. We are fully multi-tenant and so our systems can carefully aggregate anonymized data in various automated fashions and present them back to individual customers. Benchmarking and baselining is a way to extract convention and best practices and the ways to responsibly aggregate the data are well understood.
We are starting with security as this is a really obvious choice – AWS GuardDuty provides threat intelligence for IT teams, and so GIS for GuardDuty provides insight into which threats others are seeing and at which rate. Our customers are telling us that this really helps them prioritize which small subset of the many alerts they are getting they should really focus on.
What Role does Data Play here?
I think cloud security has gone from being a situation where people didn’t trust the public cloud providers, to now being something where you have to have a good reason not to deploy in the cloud. Behind this, however, I think there is still a lot of work that needs to be done on building up processes and working practices around cloud security.
Take the Security Operations Center – when you have so many moving parts internally, SOC analysts need help to keep up.
Now add cloud into the mix, and you have much more data coming in all the time and a shared responsibility model to bear in mind as well. You have to work on how to collaborate with your suppliers or vendors, or with your key partners and their own SOC teams. You will all rely on each other to get the job done quickly.
Without some data on how well you are doing, it’s difficult to convince people to do things differently. When you benchmark, you can point out whether you are doing a good job or whether you are behind the curve.
Why Hasn’t AWS Simply Built this Itself?
Frankly, they could build GIS for GuardDuty if they wanted to. But one vendor can’t do everything all the time, and so in this case, we can provide additional value. I think in general what you will see in the context of GIS as we continue to add data sources and use cases is that we have a different aperture than AWS in terms of data.
We don’t just see what AWS sees, but we also see what say the applications are doing themselves, the actual logs and metrics telemetry. This is not something that AWS necessarily sees. Even more importantly, as much as AWS has a massive presence, workloads still run in many other places, and we see all of that as well.
What does this Data help Companies do in Practice?
Every security alerting system ever has had to, and likely for some time to come will have to, deal with alert overload and fatigue. Once you start looking for stuff, you will find things. Dialing in automated detection to a degree where it only surfaces true positives that you need to act on is a very hard and generally unsolved problem. But there is nothing wrong with getting good and better signals.
AWS GuardDuty is a very neat way to get high-value signals. Customers love it, and they are telling us that it would be great if they could understand whether the alerts they are getting are the same as other customers get. Because there will be a fair amount of alerts, and now you need to decide which ones to look into first. We found that exposing how they stack up in terms of the distribution of alert types to a larger set of customers made it very easy for them to focus on what is important. We also learned that understanding low-frequency alerts in terms of community overall community frequency was a good indicator for actual rare-ness of an alert––another great signal for prioritization!
See also: ESET Agrees to Furnish Google’s Chronicle with Threat Data
