The increasing complexity of enterprise IT environments has made Security Information and Event Management systems (SIEM) an integral part of almost every large organisation’s security arsenal.

However, same as with almost any other technology tool, there comes the time where SIEM has to be replaced by a solution that has been determined to be a better fit for the organisation’s needs and requirements. There are several reasons which could lead to this decision.

Budget, capabilities, functionality of the solution and quality of support by the vendor are all examples of deciding criteria on whether to renew a soon-to-be expired SIEM license.

Regardless of the motives, when organisations finally decide to migrate to another solution, they usually find themselves in front of a major challenge, since SIEM migration is a not yet a well-documented and mature subject, in terms of the procedures that should be followed.

Therefore, through this blog, we attempt to address some important steps (especially at the pre-deployment phase) that are often overlooked, as well as to provide some tips and caveats that will help your migration process and hopefully make it a success story or at least reduce the risks to an acceptable level.

Step 1

The most important piece of work belongs to the planning/pre-deployment stage. Organisations should first perform some sort of information gathering on their current SIEM’s state. Ideally, you would be able to answer questions similar to the following: which log sources are currently logging on your existing SIEM, which devices per log source, which use cases are being implemented, which rules/alerts are currently enabled/disabled, etc.

This is a very important step as it provides the input for the upcoming stages of the migration. In addition, it gives an extra advantage: security teams have the chance to re-evaluate use cases and rules, and maybe decommission some unnecessary ones or the ones that do not apply to your environment anymore. This will reduce significantly the “noise” in your SIEM and make your operations more efficient.

Step 2

Prior to the actual deployment and once the above information has been gathered, the next critical step would be the prioritization of data sources. This would include crafting a migration strategy plan that describes the order in which the log sources will be forwarded to the new SIEM, as well as the log forwarding technique used for each source.

It would not be ideal to start the data onboarding process without having set a plan beforehand and improvise along the way, as this might lead in significant delays.

Step 3

Setting a Minimum Viable Product (MVP) could be proven very useful in complex projects like a SIEM migration. Formally, MVP is “that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort”.

In our case (i.e. SIEM migration), MVP would be that version of the SIEM that consists of only basic log sources and use cases, just so that it can be successfully adopted by the security team and offer immediate value to the security operations. Another simplified (yet not so accurate) way to think of the MVP is as a first major milestone of the project.

Step 4

Provisioning the infrastructure modifications that the new SIEM might require is a step that should not be missing from the planning stage. Different SIEM’s often have different requirements, for example in terms of network configurations, so appropriate adjustments might have to be addressed prior deployment.

The need for this step is imperative, especially if you are making radical changes, like moving from an on-premise to a SaaS solution. Make sure you include all related technology teams at the planning stage discussions in order for them to address any concerns or issues as early as possible.

Step 5

If you are migrating from a traditional, “static” SIEM to a next-gen, behaviour-based solution, there is one more thing to remember: forget “duplication”. It is essential to first understand in depth the capabilities and functionalities of your new SIEM, as well as the value it can add to your security operations, since there can be significant implementation differences from product to product.

After you have gained an understanding of your new SIEM, next step would be to perform a deep-dive analysis of your cyber security use cases in order to implement them successfully on the new product and avoid losing existing security visibility.

Step 6

Last thing to remember before moving to the execution stage is to make sure to scope enough time and stick to the scoped items. As mentioned earlier, SIEM migration is a complex project, consisting of many moving parts and experience has shown that delays can be caused by several factors.

Failure in any of the previous steps will potentially introduce severe delays on your project. Another common source of delay can be the dependency on different teams’ and departments’ availability for the execution of an assigned task.

The collaboration and synchronisation between multiple teams is always a challenge, and often the larger the size of the organisation the more difficult it is for teams to communicate efficiently.

Step 7

While on the execution stage, bear in mind that the original SIEM will typically still be running. That means that there might come up a need to adjust/fine tune some existing rules or add some new rules in order to address a newly found security vulnerability.

Think of a SIEM as a “living organisation” – it changes constantly according to the needs of your organisation and to the ever-advancing threat landscape, even during a migration. Make sure you document these changes and plan accordingly.

Step 8

Another helpful step would be to provide knowledge transfer to the security analysts who will use the product during migration. This way, the time taken to operationalise the new SIEM will be reduced significantly, since the analysts will be ready to use it right after the migration is over.

A migration is not completely done when the new product is deployed – part of a successful migration is also making sure that the transition of the security operations is done properly and smoothly, and that the organisation’s security posture is not damaged by this transition.

Step 9

Last but not least – SIEM migration evaluation. Once the deployment of the new SIEM is complete, organisations should validate the output, by checking that all requirements set at the preliminary stages are met and all use cases have been implemented according to plan.

Migration tends to be a tedious process but with the right planning and execution it can be a very fruitful one.

---

To conclude, there are specific tasks in a SIEM migration whose importance is often ignored, and which can affect the timeline of the project significantly. Patience, good communication between the different teams and transparency are key factors of success.

Again, the steps and tips presented above do not guarantee that your project will be successful, since each organisation will have its own internal challenges. However, they will definitely lay the foundation for a success story and will help you overcome relatively easily any obstacle that comes in your way.

As always, be prepared for things to go wrong and de-rail (or – from a more optimistic point of view – to not always go according to plan), but also be prepared to bring it back on course.

To find out more about RiverSafe’s SIEM solutions click here: https://riversafe.co.uk/cyber-security/siem/