Managed SIEM services case study: tailored Splunk Enterprise Security for an Australian financial services platform
A large Australian consumer-facing financial services business asked us to take their Splunk Cloud environment from “we have the platform” to “we have detection content that actually fires on what matters in our estate”.
Over a three-phase engagement, dotSec delivered 205 customised detections across 13 log sources, nine behavioural analytics models targeting data exfiltration, a risk-based alerting model, and a single-pane operational health dashboard for the Splunk Cloud environment itself.
This post walks through how managed SIEM services work in practice when they are built around the client’s actual log sources and threat model, rather than lifted from a vendor catalogue.
The challenge
The client already had strong point capabilities in place: endpoint detection and response, network detection and response, cloud access security, web application firewalling, and cloud security posture management. Correlation across those signals lived in Splunk Cloud and Splunk Enterprise Security, but detection content had not yet been tailored to the client’s actual log sources and threat model. Out-of-the-box detection content does not map cleanly to a real environment. What the client needed was Splunk Enterprise Security configured against the specific log sources they ingest, with detection rules that fire on what genuinely matters in their estate.
Specifically, they wanted:
- Detection coverage across identity, cloud, network, endpoint, and email log sources
- A risk-based alerting model so analysts work from prioritised, correlated findings rather than per-rule alert floods
- Behavioural analytics for data exfiltration risks that signature-based rules cannot reliably catch
- Operational health visibility into the Splunk Cloud environment itself, covering ingestion gaps, skipped searches, and storage utilisation
- Clean isolation of client-specific detection content from other Splunk apps, so updates and rollbacks would not affect unrelated platform configuration
Why dotSec was chosen
dotSec has provided Australian managed SOC, SIEM and EDR services for over 15 years, backed by more than 25 years of broader cyber security experience. We have run Splunk Enterprise Security as the core of our managed SIEM platform for 10 of those 15 years. We are an ISO 27001-certified and long-standing PCI DSS-compliant service provider, and our managed SIEM engineers hold a range of certifications including Splunk Enterprise Security Certified Admin, and Splunk Cloud Certified Admin credentials. That combination matters here. Building useful detection content on Splunk Enterprise Security is not a tooling exercise; it is a knowledge exercise. It requires people who have spent years operating SOCs, investigating incidents, and tuning correlation searches against real attacker behaviour.
Our approach: three phases
dotSec ran the engagement as a phased programme. Each phase followed the same internal loop. First, confirm log ingestion. Second, analyse what the logs actually contain. Third, map relevant detections against the MITRE ATT&CK framework. Fourth, build and test the detections in Splunk Query Language. Finally, tune for noise before promoting to production.
Phase 1: core log sources. Integration of the foundational identity, cloud, network, endpoint, and SaaS log sources. Asset and identity data was also onboarded to enrich findings and drive risk scoring later in the project.
Phase 2: secondary sources, threat intelligence, and risk-based alerting. Additional business systems were integrated, threat intelligence feeds enabled and tuned, and risk-based alerting configured. Rather than alerting on every individual rule hit, the platform now assigns and accumulates risk against users and devices, with findings raised when correlated activity crosses defined thresholds.
Phase 3: behavioural analytics and platform health. Phase 3 was added to the original two-phase scope after Phases 1 and 2 came in within budget. Hours freed by descoping log sources already covered by the client’s existing point tooling were reinvested into behavioural exfiltration detection using the Splunk AI Toolkit (formerly known as MLTK), additional detection coverage for the secure email gateway and the cloud security posture platform, and a purpose-built operational health dashboard for Splunk Cloud.
Engineering decisions worth highlighting
Dedicated app for client-specific content
All knowledge objects (detections, lookups, and tags) were deployed inside a dedicated custom Splunk app. This isolates the client’s detection content from other apps, makes export and backup straightforward, and makes it obvious what is and is not in scope for change control. When the client’s internal team need to review or modify a detection, they know exactly where to look.
CSV lookups for noise reduction
Where filtering was needed to suppress expected-but-noisy activity, dotSec used CSV lookups referenced inline in each detection’s search in additional to Splunk Enterprise Security’s suppressions. Filtering inside the search pipeline drops irrelevant events earlier, reducing resource consumption on the search head. The lookups also scale to hundreds of entries without modifying the underlying SPL, and they can be reviewed, imported, exported, and edited by the client’s team directly.
Risk-Based Alerting tuned to the client’s asset model
Base risk scores were aligned to detection severity. Risk factors then multiplied those scores where the user or destination warranted elevated attention, for example accounts flagged as administrative or contractor, or assets flagged as high priority. This means analysts see correlated findings against the entities that matter most, rather than chasing every individual rule hit. Risk-Based Alerting (RBA) is not magic; it works only when the underlying asset and identity data is populated with meaningful priority and ownership signals. Getting that data right was part of the engagement.
Behavioural baselines for data exfiltration risk
Statistical models built with the Splunk AI Toolkit established per-user baselines over the previous 60 to 90 days, regenerating nightly, for both email and file-sharing channels. Detections fire only when activity exceeds the upper bound of the model and the absolute size of the deviation is practically significant. This combination keeps the alerting useful rather than producing noise on every small daily fluctuation. The same approach underpins our data exfiltration detection case study for a national law firm, which we wrote up separately because the detection problem deserves its own treatment.
Scope discipline
Six log sources from the original proposal were removed during execution because the client’s existing point tooling already provided equivalent coverage. The hours freed were reinvested into the Phase 3 capabilities described above. This is worth noting on its own: detection coverage is not a function of how many sources end up in Splunk; it is a function of which sources add genuine signal that nothing else in the stack provides. A good managed SIEM provider should be willing to descope items that do not earn their place, even when those items are billable hours.
Where the detections come from
This is worth addressing directly, because it is the question that separates serious managed SIEM services from box-tickers.
dotSec’s detection content is a blend of three sources. The first is the Splunk Enterprise Security Content Update (ESCU) repository, which contains roughly 2,000 detection rules maintained by the Splunk Threat Research Team. We enable, tune, and adapt the ESCU analytics that are relevant to each client’s log sources. That work is not trivial; ESCU content needs filter lookups, severity tuning, asset-context enrichment, and validation against the client’s actual data before it produces useful findings.
The second source is bespoke detection content written by our DEXRR team, drawing on patterns we see day-to-day across managed SOC operations, penetration tests, red team engagements, and incident response work. Every Splunk Enterprise Security deployment we touch ends up with detections you will not find in any vendor content pack, because they are written to catch behaviours we have personally seen attackers use against real organisations.
The third source is SAIINT (Secure AI-Integrated Notable Triage), dotSec’s proprietary AI-based SIEM enhancement. SAIINT operates within our Managed SOC platform as augmented intelligence for analysts. It reviews and triages findings to exponentially increase analyst efficiency, flags genuine threats that may seem benign activity as first, highlights patterns that suggest rule tuning, and provides consistent recommendations regardless of alert volume. SAIINT is unique to dotSec’s managed SIEM service. Like the rest of our detection content, it was developed in-house, based on the real triage patterns our analysts work through every day.
What was delivered
By the close of the engagement:
- 205 security detections operational across the 13 integrated log sources, mapped to the MITRE ATT&CK framework
- Risk-Based Alerting configured with three correlation-style alerts that surface findings only when a user or device crosses thresholds for distinct sources, distinct ATT&CK techniques, or cumulative risk over a 24-hour window
- Nine behavioural models targeting data exfiltration via email and file-sharing channels, with three-layer noise reduction across CSV allowlists, statistical thresholds, and Enterprise Security suppressions
- A single-pane operational health dashboard tracking log source availability, scheduler skipped searches, storage utilisation, and infrastructure health
- A documented maintenance schedule covering daily, monthly, quarterly, six-monthly, and annual tasks, handed over so the client’s internal team can keep the content current
The scope changes deserve a mention too. The original proposal defined two phases. We descoped six log sources where existing point tooling already provided coverage, brought one item forward from Phase 2 into Phase 1, and added five new items (including the entire Phase 3 capability set). The result was significantly more detection capability delivered within the original budget envelope, because the hours that would have gone into onboarding redundant log sources were redirected for implementing additional advanced behavioural analytics for enhanced security monitoring.
Why tailored managed SIEM services produce better outcomes
The client now operates a Splunk Enterprise Security environment with detection content built against its actual log sources and asset model, rather than generic out-of-the-box content. Analysts triage prioritised, risk-scored findings rather than per-rule alert volumes. Behavioural analytics extend coverage to data exfiltration scenarios that signature rules cannot reliably address. The operational health dashboard makes it obvious, in one place, when the underlying telemetry that detection depends on is missing or degraded.
Equally important, the work is documented and maintainable. Knowledge objects are isolated in a dedicated app, filter lookups are versioned and reviewable, and the maintenance schedule sets out exactly what the internal team should do to keep coverage current as the environment evolves.
The pattern that shows up across dotSec’s managed SIEM work is consistent. First, detection content has to be built against the client’s actual environment, because the same log source can carry very different signal depending on the business. That means investing in log analysis before writing rules, not after. Second, scope discipline matters: removing redundant work and reinvesting the hours where they add coverage produces a measurably better outcome than mechanically delivering the original line items.
FAQ: DEploying a SIEM and managed SIEM
What are managed SIEM services?
Managed SIEM services combine the platform (a SIEM tool such as Splunk Enterprise Security) with the people and processes needed to actually use it: log onboarding, detection content, alert triage, threat hunting, and ongoing tuning. dotSec’s managed SIEM service is delivered by Splunk-certified engineers operating under documented processes, with detection content tailored to each client’s specific log sources and threat model.
How long does a Splunk Enterprise Security implementation take?
It depends on the scope. The engagement described in this post ran across three phases over several months, integrating 13 log sources and developing 205 detections. A simpler scope (a smaller set of core log sources, a baseline set of detections) can be delivered in a few weeks. We typically scope each phase with the client and validate the value of each log source before onboarding it, rather than treating every available source as in-scope by default.
Should we use Splunk ESCU detections or build our own?
Both. ESCU provides roughly 2,000 detection rules maintained by the Splunk Threat Research Team, covering well-known attacker techniques across common log sources. They need tuning and filter lookups for each client environment, but they are a strong starting point. Bespoke detections written from real incident response and managed SOC experience cover the patterns that vendor content packs do not catch, particularly around insider risk, post-compromise behaviour, and environment-specific signal.
What is Risk-Based Alerting in Splunk Enterprise Security?
Risk-Based Alerting (RBA) is a Splunk Enterprise Security feature that shifts the alerting model from per-rule findings to accumulated risk scores against users and devices. Each detection that fires assigns a base risk score to the entity involved. Risk factors then multiply those scores based on user or asset attributes (administrative privileges, asset criticality, and similar). Findings are raised only when an entity crosses defined thresholds for cumulative risk. For example, an asset or a user triggering distinct detection searches over a certain period of time, or distinct MITRE ATT&CK techniques over a 24-hour window. The result is fewer, higher-fidelity findings for analysts to investigate.
What is the Splunk AI Toolkit used for in managed SIEM services?
The Splunk AI Toolkit (formerly the Machine Learning Toolkit, or MLTK) lets you build statistical models that establish behavioural baselines and detect anomalies. In managed SIEM services, the most common use is behavioural detection of data exfiltration via legitimate channels, where signature-based rules cannot reliably catch the activity. Models are typically built per-user, regenerated frequently, and combined with practical-significance thresholds to keep alerting useful.
Want to talk about your environment?
If you are considering managed SIEM services for an Australian organisation, or if you have an existing Splunk Enterprise Security deployment that needs tailored detection content, get in touch. dotSec’s managed SOC, SIEM and EDR service is delivered by Australian engineers with Splunk, CrowdStrike, PCI DSS, and ISO 27001 credentials. Our detection content is shaped by 15 years of real-world managed SOC and incident response work, including a decade of running Splunk Enterprise Security as the core of our managed SIEM platform.
More case studies are on the way. The behavioural exfiltration detection work we did for this client deserves its own deep-dive, and we will publish that separately.
Premier Australian cyber security specialists
