You need a SIEM.  So after reviewing data sheets, seeing a product demo, and participating in a proof-of-concept, you make your choice.

And everything is fine.  For a while.

Then you start to notice things.  Like the fact that as more data is added, queries start taking longer.  Or those custom data sources that you were told could easily be added don’t show up in the out-of-the-box reports.  Or that the product takes a lot more support than you anticipated.

A year down the road, a compliance or security incident comes to light that needs to be investigated.  Critical questions need to be answered, and they need to be answered fast, such as:

• What exactly happened?
• Has this ever happened before?
• What data was affected?
• What users are involved?
• What users/customers are affected?

Answering these questions is critical to securing your data, meeting your compliance requirements, and maintaining your organization’s reputation.  So you begin your investigation, only to find that:

• Analyzing a year’s worth of data actually requires accessing two different data repositories; your SIEM’s short-term database and its long-term “log depot.”
• The short-term database uses out-of-the-box SQL reports to extract data and returns formatted reports with column headings to help user comprehension.
• The long-term log depot uses indexed searches and returns raw data records with the matched values highlighted, requiring the user to understand the data source’s log format.
• It’s up to *you* to correlate the results from both data repositories in order to answer the remaining questions.
• All of this takes a great deal of time, effort, and knowledge.

So when you needed a single place to analyze your data, you got two different repositories.  When you needed efficiency, you got two different methods of analyzing data (sometimes three).  When you needed accuracy, you got two different levels.  When you needed understanding, you got raw log records.  And when you needed quick analysis, you got to manually correlate query results.

That’s because architecture matters.  And because you probably didn’t take that in to account in your evaluation process.

When you saw the product demo, you saw the short-term repository because that’s where the best looking dashboards and reports are.  You might not have even known at that point that there was another repository.  When you did the proof-of-concept it was only over a week so there was no need to involve the long-term log depot.  When you asked questions about retention you were told that was what the log depot was for.  When you asked about investigations, you were told that was what the log depot was for.  But you never saw it.

If you asked about integration, you were told that the short-term database could import data from the long-term log depot to allow you to do the analysis in one place.  While that feature actually exists, its ludicrous to think that you could import a year’s worth of data (or longer) into a database that has to be archived every 30 days.

That’s because architecture matters.

It matters when investigating a security incident.
It matters when trying to size a data privacy breach.
It matters when time is of the essence.
It matters when accuracy is required.
It matters when total cost of ownership is viewed beyond the implementation price.

So architecture should matter to you.

In the coming weeks I will be expanding on this theme and others relating to why SenSage is uniquely positioned to solve your most complex SIEM challenges.  But in the meantime, you can start to see how SenSage’s architecture sets it apart from the rest by starting here:

http://www.sensage.com/products/event-data-warehouse.php

permalink