SIEM-05 · EXPERIENCE

I build Splunk SIEM that surfaces signal, not noise

I stand up Splunk and turn it into something your team actually uses. That means clean index design, sources onboarded and parsed correctly, data normalized to CIM, and alerts tied to real attacker behavior instead of a wall of meaningless events. The goal is a console where the things that page someone are the things that matter.

01 · What I do

The actual work

  • Deploy and size Splunk for your environment, whether single instance, distributed, or forwarder-based collection.
  • Design indexes and retention by data type so search stays fast and storage stays sane.
  • Onboard sources cleanly with correct sourcetypes, timestamps, line breaking, and field extraction.
  • Normalize logs to the Common Information Model so searches and detections work across vendors.
  • Engineer alerts and correlation searches mapped to MITRE ATT&CK techniques, tuned to cut false positives.
  • Build role-based dashboards for SOC triage, leadership visibility, and audit reporting.
  • Document detection logic and tuning so the team can maintain and extend it without me.

02 · What you get

What you are left with

  • A working Splunk deployment with indexes and retention that fit your data and budget.
  • Sources onboarded and CIM-normalized, so a single search covers many vendors.
  • A tuned alert set mapped to ATT&CK that pages on real threats, not noise.
  • Dashboards your SOC, your leadership, and your auditors can each actually read.
  • Written documentation of every detection, source, and tuning decision, so the system outlives the engagement.

03 · Tools and knowledge

What I work with here

04 · How I approach it

Planned, scoped, and owned

I start with a 30-minute scoping call and send a same-day written fit assessment so we both know what is realistic. Before I touch anything in production, I write a documented change plan with a rollback, including data and config backups so we can return to a known state. Onboarding and detection changes go in inside a defined window, validated against gates like correct parsing, CIM field coverage, and alert fire-rate, with the rollback owned the whole way through. I tune in passes rather than all at once, because good detection is iterative and I would rather show you the noise drop than promise it.

Credentials and standardsMy detection work is built on MITRE ATT&CK so alerts map to real adversary techniques, and aligned to NIST 800-53 audit and accountability controls for log coverage and retention. My CompTIA Security+ background covers the security operations side, and my Cisco CCNA helps me onboard network, firewall, and syslog sources correctly rather than dumping raw data into an index.

05 · Questions

Good questions, straight answers

Can you work with an existing Splunk install instead of a fresh deployment?

Yes. A lot of my value is cleaning up what is already there: fixing broken sourcetypes and timestamps, normalizing to CIM, pruning noisy alerts, and rebuilding dashboards. I assess what you have before recommending any rebuild.

How do you keep alerts from drowning the team in false positives?

I map detections to specific ATT&CK techniques, baseline normal activity first, and tune in passes while watching fire-rate. An alert that pages should be worth waking someone for, and I document the logic so you can adjust thresholds later.

Do you only do Splunk, or other SIEM platforms too?

This page is about Splunk, which is where I go deepest on index design, CIM, and detection engineering. The underlying method, clean onboarding and ATT&CK-mapped alerting, carries to other platforms, but I will be straight with you about depth before we start.

06 · Related experience

Adjacent work I do

Need this handled?

Tell me what you are trying to move and where it is stuck. A few sentences is plenty to start, and it goes straight to my inbox.