Why You Need A Security Information and Event Management (SIEM) System
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 adoption of a SIEM is visibility and with the Notifiable Data Breach (NDB) Scheme 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, there is the Security Event Manager (SEM) that looks after the real-time events as they happen on your network. The second is the Security Information Manager (SIM) which looks after the longer-term data retention and analysis. Together, these two parts make a SIEM a valuable addition to any network by being able to manage events as they happen and generate reports and trend analysis over time. The second part is also important as breaches may not be detected immediately, but over time they can be detected when there is more of a pattern to work with. 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 it must be respected. Traditionally, a long-standing objection to SIEMs was their cost and, having implemented several myself, I can understand that. Currently, considering the wealth of hosted services and cloud computing on offer, it doesn’t must be that way. You can get all the goodness mentioned above but without the massive costs if you go about it the right way.
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. In fact, you’re in good company. You probably have some or most of the pieces needed but get a bit overwhelmed 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 kind of 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.
A more important question is asking what information is important because while a SIEM has “Security” in the name, it often ends up handling everything else as well. 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 don’t 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 systems others use to deliver the services, you have a lot of options. Take your time and select the offering that will deliver what you want.
Be mindful, however, of data retention as the more you collect, analyse, and preserve, the more it will cost. Scalability of a solution and storage must be right up there with capacity and performance. If you sell yourself short on the solution, 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 own 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 on-boarding 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 only what you ask. Same thing if you set up your own SIEM. Be very specific. Spend a lot of time fine-tuning in the beginning 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 can be an attack vector. Enable the logging on the monitored devices, starting high and working your way down (i.e. start with ONLY critical events first and then add… it’s easy to get overwhelmed if you start at the bottom and try 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 make sure everything is working as expected. Are events getting aggregated to make sure you don’t get the same issue a hundred times from a hundred devices? Are events being correlated to give more intelligence 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 carburetor 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 among 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. New application that generates a lot of logs? Perhaps refine what get 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 up front; 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 important the data is (provided it has been properly configured to capture the correct data) you need to safeguard the SIEM system and access to it in line with the data it contains. If you have a SIEM on a highly classified network, the SIEM server and the data it contains, even just 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 include 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 your Essential Eight, especially when dealing with other security strategies.
Disclaimer: The thoughts and opinions presented on this blog are my own and not those of any associated third party. The content is provided for general information, educational, and entertainment purposes and does not constitute legal advice or recommendations; it must not be relied upon as such. Appropriate legal advice should be obtained in actual situations. All images, unless otherwise credited, are licensed through ShutterStock