Like any tech company, we are both suppliers and consumers. Not only we provide SIEM and SOAR solutions to our customers, but we also need one ourselves.

This is the first episode from the “documentary series” about our own journey to improved SecOps.
You will read about the decisions we made and the struggles we faced during the ongoing transition to a new SIEM/SOAR solution. As there is no single “right” way to implement, I hope that by combining technical and business reasoning these series will serve as a guiding rail for implementing SIEM/SOAR solution in your company and hopefully let you avoid some rabbit holes along the road.

With any series, the first episodes are highly experimental and we will do it as long as you will read them, share them, like them. So, let’s get started…

Episode 1 (The one that management should read) – How and why did we choose Azure Sentinel

We used to have SIEM in our own infrastructure for quite a while. Initially, it was implemented primarily for investigative purposes - we wanted an isolated room where we could walk in and know what’s happened outside even if the rest of the house was burnt. When we started to look for a new SIEM solution, it felt like the existing SIEM Gartner quadrant solutions were too heavy, inflexible, and often incompatible with our other tech stack expertise.

So, we chose a fresh player in the market - Azure Sentinel, a cloud-based SIEM/SOAR solution. Cloud for us was a way to isolate that room (make it entirely separated from our own infrastructure) and not worry about the storage requirements.

For us, the question was not “Do we need SIEM?”, but rather “Should we really change something or procrastinate?”.

We cannot highlight a single factor that triggered the decision to migrate to a new SIEM in our case, but rather a combination of several factors:

1. The change in strategy from the existing vendor
   Existing vendor after many investment rounds changed regional strategy gravitating mostly towards the US market. We felt it under our skin with decreased support availability. Not only did it hurt us, but also put in danger our customers. Since we practice what we preach, the same SIEM product used internally was also used by our consulting practice for customer engagements.
   
   
2. Switching to the cloud required additional needs
   We decommissioned one of our data centres, and many workloads were moved into the cloud. Fortunately, our existing SIEM actually was cloud-based and we didn’t have capacity issues, but we started to feel a lack of connectors from the existing SIEM vendor. Amplified by decreasing support.
   
   
3. Continuous improvements and change in SIEM solution
   Over the years, existing SIEM had received extensive customization by multiple employees. As we shuffled around workloads, impact surface to SIEM was increasing and we had to reconfigure increasingly many things just to keep data flowing. We had also some major data ingest disruption incidents.
   
   
4. Increased volume of security and business-related demands
   Our existing solution was really SIEM – collector of data allowing to query that data, proving trend data, etc. But it did not have any response and automation capabilities. While the existing vendor also started to implement SIEM-specific capabilities into the product, it became clear that either we stay with the existing vendor or choose another, we have to redo our safe room mostly from scratch. Pandemic, remote work, and shifting threat landscape certainly put another spark to the fire as well.

So, the decision was made – we have to change.
Change both the solution and processes how we use it, taking the opportunity to clarify the split of responsibilities between teams and move from investigative to pre-emptive and pro-active cadence of our operations.

Wrapping up this warm-up episode, here are the TOP 3 main takeaways for any company considering implementing or upgrading SIEM solution: 

SIEM implementation (or SecOps in general) is not an IT project.

Don’t do it because you read that “everyone should have it”.
It must be aligned with the overall strategy, and only management can ensure it. Find the highest-ranking sponsor in your organization for the SecOps process and make this person really involved. Make this project his or hers.

SIEM is not enough anymore. 

Threats are a lot different today than they used to be even 5 years ago.
You must be able not only to investigate events post factum, but you must be able to detect them at early stages (this is not a simple task, especially for multi-stage attacks) and respond to them. SOAR – Security Orchestration, Automation, and Response – is the industry buzzword for this.

Plan for changing your processes.

From the very beginning – start thinking about the process – step by step – who and how will use SIEM/SOAR solution.
As the next episodes will show, that is not as trivial as it might seem. Some vendors try to pitch the approach “just get as many data sources connected and the magic will come”, but we don’t believe that this approach is right. You will definitely get a larger bill, but it can actually complicate using SIEM and give you less value from the product (just google “alert fatigue”, “paralysis by analysis”, “coffee break SIEM”).

In the next episode – The instant benefits you get from Azure Sentinel deployment.