One of the more popular endeavors many firms have been undertaking recently is migrating from a Legacy SIEM (Security Information and Event Management) solution to Splunk and/or Splunk Enterprise Security (ES). There are many benefits to such a migration, primarily in that Splunk can do everything the other SIEMs can do, often better. It is important, however, from the onset to temper expectations about how similar to a legacy SIEM Splunk will be, it is not always an “apples-to-apples” migration. Management often fears losing visibility on alerts they rely upon, while some analysts are just more comfortable doing what they already know. Both of these factors can make legacy SIEM migration to Splunk an ugly affair if the expectations are not made clear up front.

Why SIEM Migration?

First, why migrate at all? A SIEM is a SIEM, right? Typically, the most common reasons for SIEM migration are lack of flexibility in use case implementation and a lack of support post-sales. Splunk excels in both of areas, hence why many organizations make the switch. The main query language in Splunk, SPL, is extremely useful for returning granular searches very quickly, whereas other SIEMs have a rigid and clunky interface with limited search options.

Reliable support is critical for a maturing organization. Many SIEM vendors (once they make the sale) become ghosts, having already cashed in from the sale. Splunk’s capitalization model is based on how much data is ingested, which creates the incentive for Splunk support to help firms get value and want to expand. Once you get Splunk, you’re part of the family.

Use Cases vs. Rules

When migrating SIEMs remember, migrate use cases, not rules. The most important thing to stress is that a SIEM should be an alerting mechanism based use cases, not a storage dump for orphaned rules. Elaborating on that last point, many firms do not document use cases, they simply believe migrating their existing rules is what a migration is all about. This is a dangerous mentality. For one, most all SIEMs use completely different query languages, thus rules cannot simply be copied and pasted or rewritten from the legacy SIEM to Splunk.

Secondly, what good is migrating rules not based on a use case? If the rule was worth making, it should be worth noting why it was made at all.

Lastly, a point that cannot be stressed enough when being asked to simply do a rule-rule SIEM migration, the phrase: “it’s just the way it’s always been done”, as some of the more tenured or more bureaucratic corporate cultures often claim. Remind them that certain cultures once thought that without a human sacrifice the sun wouldn’t rise.

Painless (and possibly fun!) SIEM Migration

Use case development seems to be the easiest thing no one does. It simply requires figuring out what you want your data to tell you and then writing it down. That’s it! The benefit of documenting use cases, and if possible getting senior management to sign off on them, is to help safeguard the firm’s security posture regardless of current SIEM platform or employee turnover.

The best way to make a SIEM migration painless, and possibly even fun, is to bring your use cases to the table and then figure out how you want to see them brought to life in Splunk. It’s still fun even if you’re starting a new program from scratch, just adopt the out-of-the-box uses cases that come free with some Splunk apps, such as Splunk Security Essentials or the Cisco Security Suite, and build a program around those until you get your feet under you.

Running a security a program without use cases is like coaching football without a playbook – it’s barely controlled chaos! Your data deserves better.