ESG's Jon Oltsik and Anton Chuvakin of Google Chronicle discuss SOAPA, part 2 of 2
Watch more in this series:
Read the related ESG Blog(s):
- SOAPA Interview with Dr. Anton Chuvakin of Google Chronicle, Part 1
- SOAPA Interview with Dr. Anton Chuvakin of Google Chronicle, Part 2
Jon: We're back with Part 2 of my SOAPA video with Anton Chuvakin, head of solution strategy at Google Chronicle. Welcome back, Anton.
Dr.Chuvakin: Thank you.
Jon: So, when I looked at Google Chronicle, when I first became aware of it, one of the things I noticed is that it can be a very, very large data lake. You can put a lot of data there and almost unlimited, low cost of storage. So, what's the use case for that and sort of, alternatively, let me challenge you, are we at the point where we're collecting, processing, and analyzing too much data and we can't manage it, or am I missing something?
Dr.Chuvakin: In many cases, what we observe is people collect data and it's kind of dirty data. It's the data they can't use. So, at Chronicle, we did spend a lot of attention on making sure that we have data that's cross-correlated, enriched, fused into a timeline. So, to me, it's very often not about the too much data, too little data or the wrong data or not enough data, it's kind of about dirty data.
So, to me, it's not so much about can we collect petabytes? Sure, we can. But can we make it useful and can we collect it in a way that doesn't break the bank? And the answer is yes to both for Chronicle. That is for sure.
Jon: If I'm collecting that much data, in Chronicle, what are your customers saying is the use case?
Dr.Chuvakin: It's sort of traditional list of security use cases. We have the incident response use case. So, we are investigating something, by default, the data stored for a year. And there's no extra charge for a year worth of data, which is a big departure from pretty much anybody else. If you have an incident, you have to go back a year, you can go back a year. There's no need to debate and more over, the data is contextualized to the right point in time.
So, like say DNS/DHCP data is relevant for the past. Definitely, hunting is a use case. Admittedly, threat hunting is a more of an enlightened use case and more mature customers do it. And I kind of like to say that this is the first security analytics or SIEM tool that has hunting as a first-class use case and not a later edition. And, of course, the other big one is detection. Recently, we launched a new model.
You asked me about detection as a code and DRL. So, to me, the detection is, for us, a more recent use case, but it's definitely there. We do have some clients that perhaps use the data, store the data for a year for compliance reasons, but we haven't been talking about this at all. And we haven't been frankly, doing much here simply because most of our customers demand a tool for investigators, for hunters, and now for detecting threats, not so much for data retention.
Jon: So, when I came up with SOAPA, it was all about integration of different tools, but what I'm now hearing from SOC managers is please don't tell me I need another user interface or portal. So, how do we make security operations more efficient, more effective without making it more complex?
Dr.Chuvakin: So, some of the challenges with the old tools, with SIEM, was that they made it more complex. To me, I think we can make it simpler, but we can't make it simple, because the challenge is hard. As far as security operations, will we ever get to one platform? XDR is our current shot at this, but to be honest, I'm not so sure that we will ever have with one tool for SOC.
I think that something on the attacker side would evolve that will make it unlikely. I've been watching the industry for a good number of years, and I feel like the best of breed connected using APIs have beat the suites. I think that suites or the single product approach is waning, except for possibly smaller organizations. So, I feel like the connectivity between tools making them into somewhat coherent whole is the best hope we have.
I don't think they're going to wait for one vendor to do it.
Jon: Yeah. I'm watching the abstraction of the UI from some vendors and federated search from others, but I tend to agree with you that if we can do a better job of API level integration, that's best we could do.
Dr.Chuvakin: API or some other like coherent joint operation as opposed to a single tool, I think the single tool hopes...we have seen too many of them and like, where are they now? Where is the...I don't want name vendors, but where is the secured by X, X being a vendor network, where is the secured by X environment?
I don't think so. I don't think that exists. I don't think it can exist.
Jon: Okay. So, way back when, when we could actually travel for business, I took a trip to New York City and I met with a bunch of financial services companies, and they all talked about SOC modernization or a fusion center. So, you know, you hear these terms, but what does SOC modernization mean to you?
Dr.Chuvakin: I would say they expand the domain of tools, processes, and people, so all three buckets. On the tool side, I think that SIEM centrality is gone. Like the SOC of 2005 was basically a SIEM and friends, and not many friends at that. Today, the SOC may be based on a different model, maybe there is no SIEM, maybe the SIEM as an auxiliary, maybe there is something else.
So, to me, the SIEM centrality is the traditional SOC model. On the people side, I would say that the rigid model -- Level 1, Level 2, Level 3 -- is kind of waning and adjusting and becoming more fluid. We have people who are divided by skill and by level. We've seen people, I've seen SOCs where the early alert triage is a skill set, not a seniority.
So, essentially, Level 1 is the early alert triage skill set, and it may be a senior guy, not a junior guy. On the process side, I would say that moving away from just doing alert triage is very much \ a tribute of modern SOC. The SOC of the old times that's modeled on the help desk, at least spiritually, was, kind of, here's an alert, handle it, here's an alert, handle it. Today, it's kind of... there's a lot more hunting, there's a lot more exploration of data, there's a lot more what to do if there is no alert.
But to me, these are some of the modernization elements from people, process, and technology.
Jon: So, final question: the future of SOAPA or the SOC, so SOAPA, the ESG term, not the Gartner term. But the future that you see, will there be more integration? Will there be more automation? Will there be better detection algorithms? What are your thoughts?
Dr.Chuvakin: I would say that one element that would remain true is that humans would probably retain a hugely important if not central role in this. A lot of security is about people countering the bad people. So, I don't think it's ever going to be automated. And I think the vision of the future that involves automation and algorithms would be incomplete without humans and without the huge role the skilled, motivated, dedicated, passionate humans would play.
I don't think we're getting away from that. I don't think it's possible.
Jon: Yeah. I anticipate more community participation. So, you have a SOC, I have a SOC, and we'll somehow collaborate more intelligently. I also believe we'll see artificial intelligence for process improvement, not just detection improvement, but I'm right there with you. I really appreciate you coming, and you're welcome back anytime. I could talk to you all day like I said. So, thank you for watching everyone, and stay tuned for the next SOAPA video very soon.