With this post, I am about to answer the question everybody wants to know the answer for …
… is Chronicle a SIEM?
However, if you are impatient and need to get the answer right now, here it is: Chronicle can address many modern security use cases that you would typically use a SIEM for.
Before I give a more nuanced answer, let’s agree on the foundations. Today’s technology and threat realities mean that there is a set of security monitoring capabilities that CISOs and their teams need.
Historically (since the late 1990s), most of such capabilities have been bundled together into a thing called “a SIEM.” Over the years, this SIEM concept has gathered more and more capabilities ranging from compliance reporting to security workflow management and machine learning algorithms for threat detection.
However, not every historic capability retains its relevance as times change. As I personally recall, in a 2002-era SIEM, management of large volumes of IDS alerts was at the center of the universe (features that correlated IDS alerts with firewalls logs were a big deal). Then by 2005, everybody was obsessing about compliance reports (one vendor claimed 13,000 reports out of the box). This may have made sense in an era when “buy for compliance, use for security” was the mantra and many SIEMs were paid out of compliance budgets.
But what is the center of gravity for today’s SIEM? Put differently, how would SIEM look like if it were invented in 2020?
Let’s think about it together. To start, every organization has a need to collect security (and other) telemetry, analyze it to find non-obvious problems (detection), investigate alerts/incidents, look for badness beyond alerts (threat hunting), initiate and support a response, and prove that the security architecture is working (reporting). Today, the budget line item for this is some form of SIEM and the product used is typically called some flavor of SIEM.
However, I bet if SIEM tools were born in 2020 and not in 1996, it would be cloud-based (hence essentially maintenance-free), blazing fast even on petabytes of data, able to collect data without onerous intake filtering, be effective for detection, investigation and hunting, use threat intelligence a lot and would present clean and enriched data to the users in the form of timelines and stories. On the other hand, it will focus less on compliance reports and pleasing auditors.
In essence, both technologies and use cases have shifted over time. Appliance SIEM was designed for a world of terabytes. This was “big data” 10–12 years ago. I remember a time when a “scalable” “enterprise” SIEM was able to retain a whopping 40TB of logs — imagine that! Can you “expand” such a toolset to handle petabytes? Maybe, but it won’t be pretty, and won’t be performant — and likely won’t be affordable. Can you upgrade your 1980s gasoline car to run on electricity? Eh … yes, some hobbyists in fact have done that. Will it be ideal for today’s requirements? For sure, the answer is no. Still, modern electric car makers didn’t invent a new category, even though very little in (say) a Tesla technology is similar to what a 1980s car had.
Similarly, can you optimally use an old on-premise SIEM for large scale searches, threat intel matching or even heavy analytics? No, because the amount of compute resources it would have access to is fixed. Hence you can operate primarily on the present, not past and present. This means that rules generally are focused on present-time detections, not deeper historical analysis. Incoming data is normalized into buckets, but not fused into timelines and enriched with past data.
Back to the topic, so is Chronicle a SIEM? We do serve an ever-increasing number of threat detection and monitoring use cases. Ultimately, it depends whether you believe SIEM should be mired in the past or started afresh for the future.
1. Do you think SIEM is a product that does compliance reporting on logs? If this is your main defining criteria, then we are not a SIEM today. However, note that compliance reports are much easier to build compared to, say, retroactive threat intel matching and sub-second enriched data search….
2. Do you think SIEM is a technology that detects threats using data and helps you manage security alerts? In this case, we are very much a SIEM, or at least as close to one as to make no difference. We also offer capabilities that few SIEMs have such as coverage of EDR and traffic data alongside with logs, and threat intel matching. At the same time, we have not yet finished building some features most other SIEMs have (like, say, traditional reports)
Finally, if not a SIEM, then what? “Security analytics” has been the favorite for some people. While I was not a fan of using this to label a product in the past, I can see its appeal, especially for a product that does not quite fit some of the narrow SIEM definitions. Some analyst firms in fact do use it to label product categories. In light of this, security analytics is the best alternative choice here, if you are not convinced by my logic about the modern SIEM use cases.
To summarize, use us like you would a SIEM — if SIEM were invented today!
*** This is a Security Bloggers Network syndicated blog from Stories by Anton Chuvakin on Medium authored by Anton Chuvakin. Read the original post at: https://medium.com/anton-on-security/so-chronicle-are-you-a-siem-67ea6c750577?source=rss-11065c9e943e------2