Why SIEM Is a Process, Not a Product

That is a question still asked every day. Is a SIEM (Security Information and Event Management) solution right for your business? To answer this question, you must first understand a crucial truth: SIEM is more of a process or way of life than it is a product. SIEM is something you do—not something you buy.

Using SIEM Effectively

Security is a standing wave, forever driven forward by the exponential speed of technological change and the ability to profit or achieve some other mission by disrupting computer systems. In the never-ending effort to provide internal and external assurance, organisations turn to publications and analysts to understand their options. Audit processes and reports highlight specific gaps, which relate to tools available on the market, in various guises.

SIEM is one of these that suffers with bias on the technology corner of the golden triangle. Tooling that can be purchased are defined as “a SIEM” and seem to promise the outcomes inherent in the acronym. We all know a tool alone is not enough in most cases, depending on the rate of change, complexity of the IT environment, and the adversary involved in the equation.

As an “adversary”, the traditional tape drive may seem like a challenging foe, but its variables are limited—as is the process of backups. Yet, most organisations have at least one backup guy to babysit the process and ensure success.

The adversary in security is another human being who can profit directly, or gain satisfaction, from the success of their actions. In reality, these things are not even comparable—and yet relatively few organisations have a person dedicated to monitoring security to ensure success.

SIEM Tools also come with inherent bias in the requirements they are framed within, or the technical requirements that a tool can deliver, such as:

1. Log Ingestion
2. Event correlation
3. Reporting
4. Single pane of glass

Managing Complexity and Overcoming Bias with a SIEM System

Where an organisation is lacking security expertise, this can lead to prioritisation of easier to understand requirements over and above the security outcomes, which were the real needs of the organisation to begin with.

The trouble is that the complexity means that management of detection within that single pane of glass—with a many-faceted dashboard of dials and levers and flashing lights—mean that trust in these systems is lost by most organisations in short order as they flood teams with alerts. There are a few ways of processing the raw or analysed data.

Tools categorise and funnel. They count and compare on limited dimensions.

Machine learning applies classification to things—sometimes in a fuzzy way—to understand the likelihood of a thing being another thing.

Human beings have the ability to discover the new, intuit the impact, take the best path for the context and deal with a huge number of informational facets. But sometimes miss two words in a row can have inherent bias.

Take Where’s Wally* for example. Humans tend to assign behaviour to Wally so look over the image in a particular way, assuming he is hiding somewhere as they would.

We could write a simple piece of software that would look for certain concentrations of red and white or something but I am bound to get a load of false positives.

The bottom line is that finding things quickly requires different approaches, a lot of organisations will have a bias towards certain methods and types of technology skewing their visibility. This is partially why we have such a long lead time to breach discovery, on average.

Cybersecurity Is a Process, Not a Product

No matter what we call it, SIEM, MDR, MSS, etc – the requirements we have usually go something like this:

1. Assess change
2. Check and maintain configurations
3. Update software
4. Monitor for threats

The number of breaches in the past 5 years that didn’t have numbers 2 or 3 directly attributable and wouldn’t have been found sooner, before any real damage was caused, if robust monitoring was in place can be counted on one hand.

Traditional SIEM itself is prone to being limited in its approach with respect to the scope of data included, thus the complexity of its configuration and difficulty interpreting output evolved from there, like taking a wrong turn down a country road and ending up in a maze. Traditional SIEM focuses on log data, bolting on of other solutions onto the side and eleventy million rules that will generate a handsome stack of needles to dig through for the really sharp ones.

Ticking boxes for IDS Software and other technologies and bolting them on the side results in a connected but unintegrated approach and with a disjointed set of decisions made around the original data the defenders dilemma is made even harder by the lack of integrated approach across the different components.

When approaching a new challenge, or the chance to re-do an old one, we must return to our original guiding principles and focus on the business requirements that are our actual goals. Do not begin the process with an assumption or bias that includes a specific technology or approach.

*That’s Waldo for those of you on the other side of the Atlantic.