To SIEM or Not To SIEM

What Is It? The amount of information generated on your network is the stuff nightmares are made of but making sense of it and separating the wheat from the chaff make that nightmare seem like a daydream.


Logan Daley

a year ago | 7 min read

What Is It? The amount of information generated on your network is the stuff nightmares are made of but making sense of it and separating the wheat from the chaff make that nightmare seem like a daydream. A SIEM (pronounced interchangeably as “SIM” or “SEEM”) can make the difference between making sense of it all and living a waking nightmare. One of the primary drivers for adopting a SIEM is visibility.

With the Notifiable Data Breach (NDB) amendment to the Privacy Act now hovering over us here in Australia, the ability to reasonably determine if there has been a breach is more critical than ever.

A SIEM consists of two parts. First, the Security Event Manager (SEM) looks after the real-time events as they happen on your network. The second is the Security Information Manager (SIM), looking after the longer-term data retention and analysis.

Together, these two parts make a SIEM a valuable addition to any network by managing events as they happen and generating reports and trend analysis over time.

The second part is also essential as Indicators of Compromise (IOC) do not always appear immediately, but they can over time when there are more distinct patterns. It’s nice to believe we can stop every eventuality as it happens, but then you may as well put on your tinfoil helmet and move to a cave.

Beyond these two primary components, a SIEM breaks them down further by handling aggregation and correlation, alerting, providing dashboards, achieving compliance, and in the longer term, offers data retention and forensic analysis. A lot of power, I know, and we must respect it.

Traditionally, a long-standing objection to SIEMs was their cost and, having implemented several; I can understand that. Currently, considering the wealth of hosted services and cloud computing on offer, it mustn’t be that way. You can get all the goodness mentioned above without the massive costs if you go about it the right way.

Ask yourself if you REALLY need a SIEM all your own; I bet you will find a Managed Security Operations Centre (SOC) a much more reliable investment that will generate a return on that investment much faster. Just the same, having your own SIEM can be attractive.

Where Do I Start? First things first. Ask yourself if you know exactly (well, mostly) what is happening on your network at any given time and able to do so without extensive digging through multiple tools and manual processes. Probably not. It’s all right; you’re not alone. You’re in good company.

You probably have some or most of the pieces needed but get a bit overwhelmed with how to go about it. Having a single firewall, switch, and router is one thing, but if you have dozens, if not hundreds of devices, then it gets crazy very fast.

Do you use any centralised logging platform at present? SYSLOG or something similar? Do you go to each machine individually and dig through the logs? When was the last time you took a good look at your Windows server logs? You’re probably quickly realising how big the mountain of data is and when you ask anyone what you should be logging, they look up from their cup of coffee with a glazed look, mumble “everything”, and quickly turn and walk away. Or, more likely, run like hell.

A more important question is asking what information is important because while a SIEM has “Security” in the name, it often handles everything else. Prioritise your data first and start small. Leave “The Big Bang Theory” on the television and not in your project plans.

If you are most concerned about failed access attempts on the firewalls, start there. After that, figure out what kinds of information mean the most and not be afraid if something gets left out; you can add it later. Implementing a SIEM is like eating an elephant… one bite at a time!

With a prioritised list of what you want to get out of a SIEM, it’s time to start looking for the one that suits your needs. If you don’t have the budget for one in-house, look at managed services where you ship your data off securely and let someone else look after the munging.

Between systems, you can own and operate yourself and techniques others use to deliver the services; you have many options. Take your time and select the offering that will provide what you want.

Be mindful, however, of data retention as the more you collect, analyse, and preserve, the more it will cost. The scalability of a solution and storage must be right up there with capacity and performance.

If you sell yourself short on the resolution, you may find yourself no further ahead with an incomplete or limited data set. Getting the right people involved, including service providers, vendors, and your stakeholders, should help mitigate a lot of these issues. Failing to plan is planning to fail!

How do I make It Work? Now that you’ve figured out what you’re going to feed into your SIEM and that it can scale up, have selected a solution or a partner to help, have allowed for growth, performance, and data retention, then what? Time to act.

Establish your SIEM or at least your managed services SIEM using the appropriate resources for performance, growth, and retention. If using a third-party provider, follow the onboarding process and be sure to ask a lot of questions and double-check everything.

These companies are very good at what they do but will do what you ask. Same thing if you set up your SIEM. Be very specific. Spend a lot of time fine-tuning when starting with a smaller data set — you can apply the lessons learned to go forward.

Be sure the systems at both end and all connection points in between are secure. Encryption is a must — no plain text here, folks! Treat it like a big hub and spoke where any of the spokes could be an attack vector.

Enable the logging on the monitored devices, starting high and working your way down (i.e. begin with ONLY critical events first and then add… it’s easy to get overwhelmed if you start at the bottom and try to lean it out — those low priority events will stick around and be a thorn in your side.

Before you add any more, check, re-check, and check again to ensure everything is working as expected. Are events getting aggregated to ensure you don’t get the same issue a hundred times from a hundred devices? Are events being correlated to give more intel about them and a more reliable way to act? Are alerts being generated and forwarded as needed to the dashboard and sent out by email or SMS? Are you capturing enough forensic data for trend analysis and reporting? Be like the mechanic with a race car, hovering over the carburettor with a screwdriver, adjust until it’s exactly the way it needs to be. When you hit that sweet spot, go back and start again with something else to add more usable data.

Pitfalls? Too much, too soon, can kill the enthusiasm of even the sturdiest SIEM devotees amongst us. Growth must be planned and gradual, and every time you plan to feed something in, know what you need to get out of it.

Adding in all your aggregation and access switches on top of the core switches? Be selective as things can get noisy very fast. A new application that generates a lot of logs? Perhaps refine what gets sent to the SIEM and what can remain on the server. Adding a new device to feed into the SIEM doesn’t mean blindly dumping everything in. Ever heard of the old programmer term “Garbage in, Garbage out — GIGO?) Exactly.

Another pitfall is failing to plan for data retention. Too little yields little usable trend and forensic data. Too much ends up costing a fortune. Therefore, figuring out what you want out of the SIEM is so important upfront; you can design and plan accordingly. There are many others, but getting the right people involved from day-dot should help mitigate many pitfalls.

Ghosts in The Machine? Because of how vital the data is (provided it has been appropriately configured to capture the correct information), you need to safeguard the SIEM system and access it in line with the data it contains.

If you have a SIEM on a highly classified network, the SIEM server and the information it contains, even log files, must be treated as highly classified as well. The days of the wide-open SYSLOG server might be well and truly behind us, with data being a new gold commodity. Another place where you want to use Multi-Factor Authentication, for sure!

Anything Missing? Be sure that includes your SIEM solution in your security testing. Just because it contains security data doesn’t mean it is secure itself! Oh yes, please make sure to harden the system and keep the patches up to date. Always remember the ACSC Essential Eight, especially when dealing with other security strategies.


Created by

Logan Daley

Information Security Manager

Information Security Manager. Cybersecurity Writer & Presenter. Humanity, not machinery.







Related Articles