“A Successful SIEM deployment: truth or fantasy”…a controversial opening statement one might say for a consultant who works for a SIEM provider (LogRhythm) and preaches the virtues of the technology. Am I saying that a successful SIEM deployment is a mere fantasy? Is SIEM not the silver bullet which we have been led to believe?
During the years I have worked at LogRhythm, I have been involved in a number of high profile global SIEM projects, as well as small localized deployments, all of which have been successful and have provided much value to my customers, but has this success been solely down to the technology? No.
To quote LogRhythm’s VP of International Markets, Ross Brewer, “LogRhythm is software, not magic.” I cannot tell you how true this statement is for any size deployment of any SIEM technology. Too often, I am involved in technology replacements or are working with customers to rescue their deployments from the cobwebs which are now surrounding their implementations, all because of one simple and common reality… lack of process.
You are deploying software not magic
SIEMs are fantastic. I have worked across a variety of technologies within the security and cyber security space over the last 10 years and SIEM is the technology which brings everything together in order to deliver actionable intelligence—and for what it’s worth, I believe that LogRhythm does an excellent job of balancing features and functionality with price.
SIEMs are not anti-virus software that you deploy, configure and forget. SIEMs are your eyes and ears on the ground. They tell you, in real-time, what is happening and where as well as give you the ability to respond in order to prevent all manner of apocalyptic scenarios.
But what good is a Ferrari if you don’t drive it let alone look at it? The same is true for a SIEM – what good is the keeper of all your security intelligence if you don’t look at it? More importantly, what good is this highly sophisticated, borderline terminator-like machine in its ability to autonomously learn if you don’t listen to what it has to say?
SIEMs require care and maintenance and anyone who tells you otherwise unfortunately is not a speaker of truth. SIEMs can be deployed in all manner of scenarios, from reactive to proactive, but in all cases, the SIEM is only as good as the information which is fed into it and is only as relevant as the systems it monitors. So, what does it take to deploy SIEM successfully?
Below I have shared my experiences of what I have found to make a SIEM deployment successful. This is not an all-encompassing list. This is not gospel. This is just what I have seen that has proven to work for both the customer and myself and has resulted in good use of the technology and more importantly, the avoidance of some disastrous situations.
Define The Purpose
Why are we here today talking about SIEM? Do you have a compliance project (PCI-DSS / ISO / GPG / SOX / Nerc etc.) which requires the monitoring of key assets? Do you want to improve your overall security posture? Have you been breached and want to prevent it, or be alerted to it before it happens again? Do you need to satisfy an internal audit? “Know your enemy” they say. By fully understanding why we are here discussing SIEM will put you in a much better position to define the next key point, scope.
Scope, Scope, and Scope Some More
Scope is key. SIEM vendors understand (or at least I hope they do) that the scope you define is only really a point in time. Things change, we know that and so do you but still scope what you want to capture today to meet your defined purpose above. Be smart with your scope. Understand every device/system/application which is defined by your requirements above and stick to it.
If you want to monitor an application which resides on an operating system, does your definition require monitoring of both or just the application? Does monitoring the operating system alone meet your audit requirements? Do you need to perform SQL table monitoring or is just monitoring the authentication for now good enough? These are questions which you should be asking yourself and the vendor and depending on your requirements the answer may vary. If it’s security monitoring you may want to monitor more extensively than you would for say, PCI-DSS compliance which typically has a defined scope.
If you are new to the security world or as not as experienced as the team within LogRhythm, that’s fine as we are here to help. We can help you work through your use cases and then help you define what systems need to be monitored as part of those use cases.
Stick to Your Scope
Too often I have seen a scope run wild once the technology is introduced to the wider organization because everyone can see the value it can bring and, therefore, everyone wants to be able to monitor their applications/systems too.
Be cautious about trying to capture every system and the kitchen sink too early on in the process. Visibility is great and is essential in your security monitoring practice, but conversely too much visibility too early can lead to distractions and not being able to see the wood through the trees. Be strong, stick to your definition and prove value and results from the original requirements to gain support for growth.
Nothing screams success than people banging on your door wanting a piece of new technology. How often does that happen in a technology rollout these days? Scope ahead. Scoping should always include growth. We are positive thinkers and assume as an organization you are going to grow, but don’t get carried away. There is often little point in scoping a solution which can handle X hundreds or thousand of devices or Y throughput per second/day when you only require a tenth of that right now.
A SIEM implementation should be able to grow organically with the business, so define what you need today and add some headroom on top and then stop. When the time comes to grow your deployment, you can do that by adding more capacity/processing power etc.
Assign Owners and Resources
Nothing will kill a SIEM project quicker than a lack of ownership. If there is no single user/team responsible for maintaining your SIEM, no fancy use case or statistical trend monitoring will stop your organization from falling foul to an attack. With that in mind, designate an owner (or owners). Who will be responsible for adding new devices? Who decides on new use cases to deploy? Who will monitor the health of the system?
Answer these questions before you start to deploy. SIEMs are needy beings, they require “feeding and watering” to ensure they are kept in-step with your requirements and deployed technologies (systems which require monitoring), so designate administrators of the system.
The owner of the system does not necessarily need to be the same person as the individual administrating the system. The owner is the individual who ensures the health and relevance of the system in line with the defined requirements.
Process is King
How will the owner/administrator know when a new system is deployed which requires monitoring? What will happen when an incident is detected? Will an email be sent? To whom? Will a ticket be raised within your ticketing solution? What are your internal SLA’s for responding to alerts? What’s your incident response plan?
These are not simple questions to answer and too often people rely on the technology to make the decisions for them, which is wrong. Yes the technology can detect when a new device is added to your network, but that doesn’t mean that you will want to monitor it. So how will the owner of the system know which systems to monitor?
There are a dozen ways this can be achieved which is something which I will leave for a blog on its own. My favorite question is “What’s your incident response plan?” You are investing in a technology which will help detect and thwart nefarious activity from occurring, but what do you do when you detect this activity?
Incident response plans are key to the prevention of both data loss and more crucially reputation loss. Think about your workflow and try to incorporate the SIEM into your existing workflow as much as possible.
Another aspect of process which is often missed is privacy. SIEMs give you insights which you’ve never had before. For example, you can see the types of websites your colleagues browse where they really wouldn’t want you to know. You can see the emails users are sending to their secret lovers etc. But are you allowed to see this information? Is your company allowed to gather this information, even inadvertently? Are your employees aware that this level of monitoring is happening and have they signed up to it?
Remember the contracts that the employees signed may have existed a long time before you as an organization decided that this level of monitoring is required, so have the appropriate basis for monitoring. I’m not suggesting for one moment that if you are legally allowed to capture this level information that you do it for the fun of it. What I am saying is respect the privacy of your employees as you are deploying a powerful tool which can potentially show you more than you were expecting.
Plan the Deployment
Ready, aim, fire!!! Avoid the scattergun approach. Plan your deployment wisely but firstly prepare. I can’t speak for how other SIEM vendors do this but I know at LogRhythm we has this point well covered. Understand and complete the prerequisites before having the engineer on site. Speaking from experience, there is nothing worse than driving/flying several hours to be sat behind a desk twiddling thumbs. It’s a waste of time and your money. Start small and grow big and take a measured approach.
Rinse and Repeat
Once you have successfully deployed your SIEM, stopped a conspiracy to take over the world and are now classed as the savior of your organization. Take a moment to reflect on your glory, then rinse, repeat and start again.
A SIEM deployment can be an ongoing project that is ever growing and changing. Just because you have taken the beach doesn’t mean the war is over. Your organization will grow, it will change, new compliance mandates will come into force and old ones will change. New threats will emerge while old ones will become patched and remediated and your SIEM will need to be kept in-step with these changes—hence the need for an owner.
Follow these guidelines and you will be well on the way to a successful deployment and the notion of a successful deployment won’t just be a fantasy. Deploying a SIEM is akin to having a child (and I can say that as a father of two), feed them, nurture them and never take your eyes off them and watch them grow into successful beings of which you can be proud.