Splunk Enterprise Security vs. Microsoft Sentinel

So what?

Splunk is a flexible, extensible platform and can ingest a broad range of Microsoft data sources. Splunk’s main advantages with Azure data are its vendor-neutrality, ability to correlate with any source, custom data handling, and control over deployment, retention, and automation.

Planning, Preparation, Transformation

Splunk Professional Services treats all migrations as an opportunity for transformation, resisting “lift and shift” methodologies in favour of a Use Case driven approach. In a Use Case driven approach we focus on targeting resources at risks seeking to answer security customer needs, and target our monitoring at what truly scares the risk owners. Following Splunk’s use case based methodology you will be able to better focus on organisational and operational priorities as well as focus on migrating the information of most value.

Migrations are inherently disruptive but this can also be an opportunity. Splunk seeks to capitalise on the disruption by adding extra value through the use of its supporting frameworks whether its reducing analyst fatigue through better prioritisation of alerts using Risk Based Alerting and the Assets and Identity Framework, leveraging Splunk build in response capability with Mission Control and Splunk SOAR or leveraging advanced behavioural analytics, machine learning and AI. Splunk has industry leading tools and services to help harness the disruption of a migration and turn it into a force multiplier for your SOC.

Splunk's structured approach to Sentinel Migration, is divided into distinct phases, within a complete SIEM Implementation package and can be augmented with our cloud or on-prem migration packages as required. Below we’ll take a look at an indicative package migrating Sentinel to Splunk Cloud.

Firstly on project kick-off we would conduct a series of workshops designed to guide the analysis and design of the solution.

PS Architects will deliver a series of workshops tailored to your security needs starting with your security use cases working through the platform architecture, data onboarding patterns and SIEM operation. Below are some of the phases and milestones we have completed in successful migrations. 

So what?

Splunk PS provides a standardised approach to SIEM replacement with Splunk Enterprise Security (ES) SIEM on the Splunk Platform, Cloud or on-premise (Enterprise), driving success through best practice design, rapid adoption and knowledge transfer:

• Splunk Solutions Architect designs plan around your needs
• Best-practice based Splunk design, installation and configuration
• Data onboarding of identified data sources
• Installation and configuration of Enterprise Security
• Prescriptive use case implementation

Migration Strategy

Choosing the right migration approach is critical to ensuring a smooth transition with minimal disruption. The three primary approaches-phased, parallel, and big bang-each have unique characteristics, advantages, and challenges. Here’s a detailed discussion of each approach and the rationale behind their use:

Phased Migration

In a phased migration, the transition happens gradually over multiple stages. This approach breaks the migration into smaller, manageable pieces, focusing on specific components or functionalities at a time.

• Key Benefits: Reduced risk, flexibility to learn and improve during phases, and easier resource allocation.
• Challenges: Longer transition period, dual maintenance of old and new systems, and potential complexity in coordination.
• Best for: Large or complex systems and organisations that prioritise caution and gradual change.

Parallel Migration

With parallel migration, the old and new systems run side by side for a period. This allows the new system to be tested and validated while the old system remains operational as a safety net.

• Key Benefits: Risk mitigation with a fallback option, live testing in a real environment, and minimal disruption to operations.
• Challenges: High resource demands, complexity in keeping both systems synchronised, and added operational costs.
• Best for: High-stakes or mission-critical systems where business continuity is essential.

"Big Bang" - All at once migration

A full cutover migration involves switching entirely to the new system in one event. The old system is decommissioned, and all data and processes are moved at once.

• Key Benefits: Quick transition, simplified management, and elimination of dual-system overhead.
• Challenges: High risk if issues arise, extensive planning required, and potential downtime during the cutover.
• Best for: Smaller or low-risk migrations, or when speed and simplicity are key priorities.

So what?

The choice of migration approach depends on factors such as the complexity of the system, the organisation’s tolerance for risk and downtime, resource availability, and the criticality of the system being migrated. Whatever your size and scale, we can adapt Sentinel to Splunk migrations to align with the business needs, technical challenges, and resource constraints. 

Use Case Migration - Query Translation

When transitioning between Sentinel (which uses KQL - Kusto Query Language) and Splunk (which uses SPL - Search Processing Language), understanding the syntax and functional differences between the two languages is critical. While both are used for querying, their approaches differ. Sentinel’s KQL is declarative and designed for working with tabular data similar to relational databases, while Splunk’s SPL is built to handle data that can be either structured, semi-structured, or unstructured.

Every KQL query starts by referencing a specific table (e.g., SecurityEvent, Syslog). These tables have a defined schema with fixed column names and data types. SPL begins by specifying an index (or source), which contains raw or semi-structured data (e.g., index=security_logs). 

Despite these differences in language because of the flexibility of SPL it is rather simple to convert KQL to SPL. To illustrate the conversion process, let’s focus on a security use case: detecting failed login attempts on a windows server.

KQL

SecurityEvent
| where EventID == 4625
| where TimeGenerated >= ago(1h)
| summarize Count = count() by AccountName, IpAddress
| sort by Count desc

SPL

index=security_event EventID=4625 earliest=-1h
| stats count as Count by AccountName, IpAddress
| sort -Count

Explanation of Query Components

1. Data Source:
   • In Sentinel, the query starts with the table name SecurityEvent.    
   • In Splunk, the query starts with index=security_event to specify the dataset.
2. Filtering:
   • KQL uses where for filtering failed login attempts (EventID == 4625) and time constraints (TimeGenerated >= ago\(1h\)).
   • SPL uses EventID=4625 and earliest=-1h to filter events within the last hour.
3. Aggregation:
   • KQL uses summarize Count = count\(\) to aggregate failed logins by AccountName and IpAddress.
   • SPL uses stats count as Count by AccountName, IpAddress for the same aggregation.
4. Sorting:
   • KQL uses sort by Count desc to sort results in descending order.    
   • SPL uses sort -Count for descending order sorting.

Data Mapping and Transformation

Whilst a simple conversion is fairly straightforward between KQL and SPL, you can go further and make this use case applicable to all your security data sources using the Common Information Model (CIM) and leverage the Authentication data model. The Authentication data model in Splunk is a normalised model that organises all the authentication-related logs (e.g., logins, logouts, failures) into consistent field names, regardless of the original data source.

So lets adapt the original KQL detection into a Splunk search that will search not just the windows server logs for failed log-ins but all failed log-ins across all authentication data in the CIM, regardless of technology. 

You'll need to adapt the query to use the CIM's standardised field names and structure.

Steps to Convert to CIM-Compliant SPL Query

Identify Datamodel and CIM Fields: