SIEM & Logs To Collect

As we increasingly deploy the SIEM within client networks, we’re learning some good lessons.

Generally, there seems to be a misunderstanding of what data should be collected. Spoiler alert, the answer is “all”. Everything on a network that has an IP address most likely produces logs.  And these logs need to be collated.  Even then, that’s insufficient. Things happen on a network that may not be properly logged.  For example, malicious traffic in particular tends not to leave traceable logs. Therefore, logs aren’t the only thing needing to be amassed.

It’s also important to compile layer 3 anomalies as revealed by an IDS and this encapsulates every server, every workstation, every router, switch, printer, AP, etc.  Everything.  IDS logs too.

Why, you ask?

Imagine this situation.

You spend copious amounts of time convincing the board that a SIEM is worth investing in but, to save a few pennies, you choose to forego a device (say a printer). Then the unthinkable happens and there’s a breach so you review the logs, and these reveal that the breach came through said printer.  Of course it did.  The investigation stalls because you don’t have the printer logs anymore. Standing in front of the board once more,they ask “what happened?” and you say “yes, you gave me the money, but it wasn’t enough so something had to go. I didn’t keep the printer logs and now we don’t know what happened.”

What you’re saying in essence is, “yes, we spent money and no, we still don’t have a clue”.

Do you really want to find yourself in that situation?

Moving on.

Oh, psst.  Don’t forget also DVRs, cameras, and IoT!!!

Once you’ve decided all the logs are necessary, you’ll be in for a surprise, I can guarantee, because you’ll find that there are a lot more devices than you’d envisioned.  Furthermore, IP addresses add up quickly and if you attempt everything at once, it can prove daunting indeed. So, plan well and do it step by step. And by that I don’t mean taking a year from planning to implementation.  I mean set realistic goals and acknowledge that Rome wasn’t built in a day.

Define the scope of your SIEM deployment, isolate objectives, take stock of existing security protocols and see how these will fit into your prospective SIEM implementation plan.  Assess and test it out in phases, evaluating each after the fact, and that way, you strategically ease into SIEM.

Keep In Mind

A SIEM is not only a security and forensics tool, but also (and, for many, primarily) a compliance tool.  Accordingly, your company’s particular list of compliance requirements must be compared with the features of each SIEM you’re evaluating.  This not only narrows down the number of partners to appraise, it’ll also force you to be mindful of your log data needs. An example that applies to all – most compliance regulations require you to have an offsite backup of your data.  As such, set the bar with “data storage in the cloud” capabilities, and eliminate all those who don’t offer it. Don’t choose a vendor who collects your data onsite and pay extra to store a backup somewhere else.

Keep in mind also that SIEMs isolated to your environment alone are becoming obsolete. When collected in the cloud, your data is integrated with that of all the other clients your vendor protects, and is analyzed against a set of threat intelligence data that is  updated (in true real-time). Correlation analysis conducted in this manner raises incidents much sooner, and alerts you far quicker of impending dangers.

Which brings me to the next topic.

Correlation rules

Many vendors don’t seem to have any correlation rules and all they’re selling is an empty bucket with a powerful rule-generating tool. But you’re practically on your own in generating said rules. Which means you’ll end up spending a lot more than you thought since you now need to engage a third party to create those rules for you. Question is, why are they making you pay twice for this? These rules have already been created for previous clients, why can’t they give them to you, as part of their product offering? A SIEM should be viewed as a service (not just a product) so when you subscribe to it, you have access to every single rule previously created.

Some customization is still necessary, and that’s a good thing.

No two clients are identical and rules are made so that certain parameters are adjustable. For example, if a user locks himself out 3 times or 5, do you want to be alerted? Or do we call you if you appear to have logged on at 3AM? Such things vary from client to client. A SIEM is designed to detect and uncover connections between events that otherwise go unnoticed, so begin with pre-configured rules, and work your way backwards, disabling/enabling (striking off/keeping), changing parameters, according to what’s needed and what’s not.

So what are you collecting?

Everything ‘everything’?

Or can I leave some stuff out?

There’s an easy partial answer. Some data is illegal to collect, so that’s a no brainer. Also,you aren’t collecting actual data. Logs contain metadata, mostly. You certainly don’t want to risk collecting data which might contain PII or PHI, passwords, encryption keys; anything that could be a really bad idea to store in a log.

What you certainly want to collect includes:-

>> authorization successes and failed attempts
>> changes to user privileges – especially escalation of privileges
>> application errors and performance issues
>> opt-ins like terms and conditions
>> all actions undertaken by users with admin privileges

A happy medium

What you’re wanting is to strike a balance between collecting enough data to create a comprehensive view of your network and not so much that the sheer volume is overwhelming.

Deploying the right SIEM and adopting best practices is only half the battle won.  You absolutely need an incident response plan so you can act upon what the SIEM uncovers, with pre-designated roles for every security personnel such as:-

>> who needs to do what
>> how to prioritize and document said events
>> the format in which a breach is to be reported
>> who’s responsible for communicating with whom
>> establishing backups and disaster recovery solutions

You should also have a “sensitive data” recovery plan on hand in case it’s needed.

One final word

A SIEM does not operate on a “fire and forget” policy.

Pre-implementation planning and management are essential, yes, but a culture of continuous refinement and improvement must also be cultivated.

Coming next, a downloadable SIEM Best Practices Cheat Sheet.

Photo by Alexandre Debiève on Unsplash