Anatomy of a SIEM use case: the brute force example

If you were ever presented with a list of potential SIEM use cases, brute force was among the first in the list. Identifying several failed logins, potentially followed by a successful one, provides a perfect example of how correlating multiple events facilitate real world attack detection. In addition, event normalization and categorization ensures that login events from any device look the same, enabling a single use case to cover any existing or new event source. This does seem like a quick win: a relatively simple correlation rule can detect brute force attacks from any source, actually even across sources!

If it was so easy. In this article, I will drill down into the real world challenges of the brute force use case. My personal take is that the complexity involved implies that such a use case should be implemented by experts and might not be a good choice for internal development in an organization. So unless you or your organization are willing to invest heavily in creating and maintaining this use case, ask your vendor for it or remove it from your list.

Skeptic? Let’s get to the details. Continue reading

Understanding SIEM: Semi-Structured Search

No discussion of SIEM technology can ignore the new king in town: semi-structured search. Gartner recently declared Splunk the market leader in the SIEM space. Talking with users certainly proves Gartner is on mark as “Splunk SIEM”, once an oxymoron, is now a prevailing term.

The significant aspect of this shift is that Splunk does not have a correlation engine, or at least the in-memory correlation engine typical to traditional SIEM products. Instead, Splunk uses structured search. Semi-structured search, an oxymoron by itself, seem to match well the semi-structured nature of machine data for both interactive investigation and for automated tasks.

In this article, we will learn about semi-structured search and explore its unique properties. This will enable us in a future article to explore how structured search can replace in-memory correlations in certain cases. Continue reading

Understanding SIEM: triggers, the less known side of correlations

This article is essentially a footnote of the overview of correlations basics article. For most people, correlation rules simply match a condition and perform an action based on the condition. In reality, things tend to me more complex, especially for multi-event correlations.

One example is action triggering, a little known or understood but important part of complex correlations: when to trigger and perform actions is simple for basic correlation rules but becomes quite complex for join and aggregate correlations which are “active” over a period of time and not just at a singular point in time.

If nothing else, and as most readers will never implement correlation rules with that level of complexity, the discussion presents the vast potential of correlation rules and the associated challenge and form a base for a later discussion on what correlation rules are for, who should use them and how. Continue reading

Understanding SIEM: correlation basics

Correlation: “a mutual relationship or connection between two or more things.”

The dictionary definition above implies the correlation deals with connecting things. In the SIEM paradigm the term “correlations” has evolved to mean any form of processing of the event stream on entry to the SIEM.

While events are a mandatory part of SIEM, as the acronym implies, correlations are not. That said, they became a synonym to the term SIEM. Should they be considered a core element of SIEM? Are they useful at all? To answer that we first need to examine what they are and what they can be used for. Continue reading

Bobby Tables real life coutnterpart

If you are a member of the application security community, you are bound to know this hilarious xkcd cartoon. It is so good that it found its way to non-expert circles. I once got it physically framed as a birthday present from friends.

tables

Like most of you, I though that this is a great way to explain SQL injection. For most of us, this is what it is. For a few, it is a real life problem

My dear friend Or Katz published an even more hilarious blog post outlining the challenges of someone who happens to have a first name which is an SQL keyword. His post is also a very good discussion of the use, or rather abuse, of signatures for web application security. A great and worthwhile read.

Understanding SIEM: Events, Alerts and Logs

Security information and event management systems (SIEMs) present us with a conundrum: those are expensive and feature rich systems, which “make sense” to users. That said, across the board, organizations have been disappointed with their SIEM implementation and as they leave behind SIEM solutions, users opt for alternative “big data” technologies.

To start resolving this conundrum we first need to understand SIEM better and the best place to start is understanding the events and information the acronym’s middle section refers to. While SIEM handles diverse data elements, the core is, as the name implies, events.

Events are collected from sources which log them. Such sources include operating systems, networking equipment, security systems and applications. However not all “events” are born equal and in this distinction lies a lot of the challenge SIEM systems face. To sort them out, we will divide those events into three groups: alerts, events and logs. Let’s discuss each. Continue reading

Anniversary to the ModSecurity Core Rule Set celebrated with a new major release

I have a very warm place reserved for the ModSecurity Core Rule Set (CRS). I created it a decade ago. Actually the first release in the readme file, labeled 1.1, is dated to October 2006, so this is an anniversary. And what a great present I got for the Anniversary from Chaim Sanders, Walter Hop and my dear friend Christian Folini: a brand new major release!

If you don’t know what the CRS is, a short introduction is due. Continue reading