Daftar Isi
- Pendahuluan SIEM
- Arsitektur Splunk
- Instalasi dan Konfigurasi
- Data Inputs
- Search Processing Language (SPL)
- Alerts dan Notifikasi
- Dashboards
- Correlation Rules
- Best Practices
- Quiz
Apa itu SIEM?
Security Information and Event Management (SIEM) adalah solusi keamanan yang mengumpulkan, menganalisis, dan mengkorelasikan log dari berbagai sumber dalam infrastruktur TI. SIEM memungkinkan tim keamanan mendeteksi ancaman secara real-time, melakukan investigasi forensik, dan memenuhi persyaratan compliance.
Splunk adalah salah satu platform SIEM paling populer di industri. Splunk mengambil pendekatan berbasis data yang memungkinkan organisasi memantau, menganalisis, dan bertindak atas data keamanan dalam skala besar. Dengan arsitektur yang scalable dan bahasa query SPL yang powerful, Splunk menjadi pilihan utama bagi banyak Security Operations Center (SOC).
Splunk mendukung lebih dari 300 integrasi data source out-of-the-box, memiliki Search Processing Language (SPL) yang powerful dan fleksibel, serta menawarkan ekosistem aplikasi yang luas melalui Splunkbase. Selain itu, Splunk menyediakan Enterprise Security (ES) yang merupakan premium SIEM solution dengan fitur advanced threat detection.
Komponen Utama SIEM
Sebelum masuk ke Splunk, mari kita pahami komponen utama dari sistem SIEM:
- Data Collection - Mengumpulkan log dari berbagai sumber seperti firewall, IDS/IPS, endpoint, dan sistem operasi
- Normalization - Mengubah format data menjadi standar yang konsisten agar mudah dikorelasikan
- Correlation - Menghubungkan event-event terpisah untuk mendeteksi pola serangan
- Alerting - Memberikan notifikasi ketika kondisi keamanan tertentu terpenuhi
- Reporting - Menghasilkan laporan untuk compliance dan analisis tren
- Dashboards - Visualisasi real-time dari data keamanan
Arsitektur Splunk
Memahami arsitektur Splunk sangat penting sebelum melakukan deployment. Arsitektur Splunk Enterprise terdiri dari beberapa komponen utama yang saling bekerja sama untuk mengumpulkan, memproses, dan menyajikan data.
1. Universal Forwarder
Universal Forwarder (UF) adalah agen ringan yang dipasang pada mesin sumber data. UF mengumpulkan data dari source dan mengirimkannya ke Indexer melalui TCP. UF tidak memproses data sama sekali, sehingga sangat hemat resource CPU dan memory. Ini menjadikannya pilihan ideal untuk dipasang di production server tanpa mengganggu performa aplikasi.
# Konfigurasi inputs.conf pada Universal Forwarder
[monitor:///var/log/secure]
sourcetype = linux_secure
index = security
disabled = false
[monitor:///var/log/auth.log]
sourcetype = linux_auth
index = security
disabled = false
[monitor:///var/log/messages]
sourcetype = syslog
index = os
disabled = false
# Menggunakan TCP forwarding ke Indexer
[tcpout]
defaultGroup = my_indexers
maxQueueSize = 512000
useACK = true
[tcpout:my_indexers]
server = indexer1:9997, indexer2:9997
compressed = true
2. Indexer
Indexer adalah komponen inti yang memproses, mengindeks, dan menyimpan data. Setiap event yang masuk akan diparsing, diindeks berdasarkan field-nya, dan disimpan dalam struktur yang efisien untuk pencarian. Indexer menggunakan arsitektur bucket-based storage yang mendukung hot, warm, cold, dan frozen tiers.
# Konfigurasi indexes.conf
[security]
homePath = $SPLUNK_DB/security/db
coldPath = $SPLUNK_DB/security/colddb
thawedPath = $SPLUNK_DB/security/thaweddb
maxTotalDataSizeMB = 512000
frozenTimePeriodInSecs = 31536000
maxHotBuckets = 10
maxWarmDBCount = 300
[firewall]
homePath = $SPLUNK_DB/firewall/db
coldPath = $SPLUNK_DB/firewall/colddb
maxTotalDataSizeMB = 256000
frozenTimePeriodInSecs = 15768000
[os]
homePath = $SPLUNK_DB/os/db
coldPath = $SPLUNK_DB/os/colddb
maxTotalDataSizeMB = 128000
frozenTimePeriodInSecs = 15768000
[web]
homePath = $SPLUNK_DB/web/db
coldPath = $SPLUNK_DB/web/colddb
maxTotalDataSizeMB = 256000
frozenTimePeriodInSecs = 31536000
3. Search Head
Search Head menyediakan antarmuka pengguna untuk menjalankan pencarian, membuat dashboard, dan mengkonfigurasi alert. Search Head menerima query dari pengguna, mengirimkannya ke Indexer, dan menggabungkan hasilnya. Dalam deployment yang besar, Search Head bisa menggunakan Search Head Cluster untuk high availability dan load balancing.
4. Deployment Server
Deployment Server mengelola distribusi konfigurasi ke Forwarder secara terpusat. Ini sangat memudahkan pengelolaan ketika Anda memiliki ratusan atau ribuan forwarder yang tersebar di berbagai lokasi.
# serverclass.conf pada Deployment Server
[global]
restartSplunkWeb = true
restartSplunkd = true
[serverClass:linux_servers]
whitelist.0 = linux-*
whitelist.0 = ubuntu-*
[serverClass:linux_servers:app:unix_ta]
restartSplunkd = true
stateOnClient = enabled
[serverClass:windows_servers]
whitelist.0 = win-*
whitelist.0 = dc-*
[serverClass:windows_servers:app:windows_ta]
restartSplunkd = true
stateOnClient = enabled
[serverClass:network_devices]
whitelist.0 = fw-*
whitelist.0 = switch-*
[serverClass:network_devices:app:cisco_ta]
restartSplunkd = true
stateOnClient = enabled
Cluster Architecture
Untuk lingkungan enterprise, Splunk mendukung Indexer Cluster dan Search Head Cluster:
- Indexer Cluster - Menggunakan Master Node untuk mengelola replikasi data dan failover
- Search Head Cluster - Menggunakan Deployer dan Captain untuk distribusi search
- Multi-site Cluster - Replikasi data antar lokasi untuk disaster recovery
Instalasi dan Konfigurasi Awal
Berikut langkah instalasi Splunk Enterprise di Linux yang umum digunakan di production environment:
# Download dan install Splunk Enterprise
wget -O splunk-9.1.0.deb \
'https://download.splunk.com/products/splunk/releases/9.1.0/linux/splunk-9.1.0-linux-amd64.deb'
sudo dpkg -i splunk-9.1.0.deb
# Jalankan Splunk untuk pertama kali
sudo /opt/splunk/bin/splunk start --accept-license
# Masukkan password admin saat prompt
# Enable boot start agar Splunk otomatis berjalan
sudo /opt/splunk/bin/splunk enable boot-start --accept-license
# Verifikasi instalasi dengan REST API
curl -k https://localhost:8089/services/server/info \
-u admin:yourpassword
# Cek status Splunk
sudo /opt/splunk/bin/splunk status
Setelah instalasi selesai, akses Splunk Web di http://localhost:8000 dan login dengan kredensial admin yang telah dibuat. Pastikan port 8000 (web) dan 8089 (management) terbuka di firewall.
Instalasi Universal Forwarder di Server Target
# Download Universal Forwarder
wget -O splunkforwarder-9.1.0.deb \
'https://download.splunk.com/products/universalforwarder/releases/9.1.0/linux/splunkforwarder-9.1.0-linux-amd64.deb'
sudo dpkg -i splunkforwarder-9.1.0.deb
# Konfigurasi deployment client untuk terima config dari Deployment Server
sudo /opt/splunkforwarder/bin/splunk set deploy-poll splunk-deploy:8089 \
-auth admin:changeme
# Set forwarding ke Indexer (dengan load balancing)
sudo /opt/splunkforwarder/bin/splunk add forward-server indexer1:9997 \
-auth admin:changeme
sudo /opt/splunkforwarder/bin/splunk add forward-server indexer2:9997 \
-auth admin:changeme
# Mulai forwarder
sudo /opt/splunkforwarder/bin/splunk start --accept-license
# Tambahkan data inputs
sudo /opt/splunkforwarder/bin/splunk add monitor /var/log/secure \
-sourcetype linux_secure -index security
sudo /opt/splunkforwarder/bin/splunk add monitor /var/log/auth.log \
-sourcetype linux_auth -index security
# Enable boot start
sudo /opt/splunkforwarder/bin/splunk enable boot-start
Data Inputs
Data Inputs adalah konfigurasi yang menentukan dari mana Splunk mengumpulkan data. Mendesain data input strategy yang baik adalah kunci keberhasilan implementasi SIEM.
Jenis Data Input yang Didukung
| Jenis Input | Deskripsi | Penggunaan Umum |
|---|---|---|
| Monitor (Files) | Memantau file dan direktori secara real-time | Application logs, system logs |
| TCP/UDP | Menerima data streaming via network port | Syslog, network events |
| HTTP Event Collector | Menerima data via REST API endpoint | Custom apps, cloud services, IoT |
| Script | Menjalankan script secara periodik | API polling, status checks |
| Windows Event Log | Membaca Windows Event Log secara native | AD, System, Security logs |
| WMI | Windows Management Instrumentation | Remote Windows monitoring |
| Modular Input | Custom input via Python/Java | Custom protocol, proprietary system |
Mengkonfigurasi HTTP Event Collector (HEC)
HEC adalah metode yang sangat fleksibel untuk mengirim data ke Splunk, terutama dari aplikasi cloud dan microservices:
# Aktifkan HEC di inputs.conf
[http]
disabled = 0
port = 8088
enableSSL = 1
serverCert = /opt/splunk/etc/auth/mycerts/server.pem
dedicatedIoThreads = 2
maxSockets = 0
maxThreads = 0
# Contoh pengiriman data via HEC menggunakan curl
curl -k https://splunk-server:8088/services/collector/event \
-H "Authorization: Splunk YOUR-HEC-TOKEN" \
-d '{
"event": {
"src_ip": "192.168.1.100",
"dest_ip": "10.0.0.50",
"dest_port": 443,
"action": "blocked",
"rule": "suspicious_traffic",
"severity": "high"
},
"sourcetype": "firewall_event",
"index": "security",
"host": "fw-dc01"
}'
# Contoh pengiriman data via Python
# pip install splunk-hec
Python HEC Integration
import requests
import json
from datetime import datetime
class SplunkHEC:
def __init__(self, url, token, verify_ssl=False):
self.url = url
self.headers = {
"Authorization": f"Splunk {token}",
"Content-Type": "application/json"
}
self.verify = verify_ssl
def send_event(self, event, sourcetype, index, host="unknown"):
payload = {
"event": event,
"sourcetype": sourcetype,
"index": index,
"host": host,
"time": datetime.now().timestamp()
}
response = requests.post(
self.url,
headers=self.headers,
data=json.dumps(payload),
verify=self.verify
)
return response.status_code
def send_batch(self, events, sourcetype, index, host="unknown"):
batch = ""
for event in events:
payload = {
"event": event,
"sourcetype": sourcetype,
"index": index,
"host": host
}
batch += json.dumps(payload) + "\n"
response = requests.post(
self.url,
headers=self.headers,
data=batch,
verify=self.verify
)
return response.status_code
# Penggunaan
hec = SplunkHEC(
url="https://splunk:8088/services/collector/event",
token="your-hec-token"
)
hec.send_event(
event={"src_ip": "10.0.0.1", "action": "blocked"},
sourcetype="firewall_log",
index="security"
)
App dan Add-on untuk Data Collection
Splunk menyediakan Technology Add-ons (TA) yang memudahkan pengumpulan dan normalisasi data:
- Splunk Add-on for Microsoft Windows - Windows Event Log collection dengan CIM normalization
- Splunk Add-on for AWS - CloudTrail, VPC Flow Logs, S3 access logs, CloudWatch
- Splunk Add-on for Palo Alto Networks - Firewall dan threat log collection
- Splunk Add-on for Cisco - ASA, ISE, Umbrella, Meraki logs
- Splunk Add-on for Unix and Linux - System metrics, log, dan inventory collection
- Splunk Add-on for Microsoft Office 365 - Audit logs, Exchange, SharePoint
Field Extraction
Field extraction memungkinkan Splunk mengenali dan mengekstrak field dari data mentah. Tanpa field extraction yang tepat, Anda tidak bisa melakukan filter, statistik, atau korelasi dengan efisien.
# props.conf - Field extraction untuk SSH logs
[source::/var/log/secure]
TRANSFORMS-ssh_fail = ssh_failed_login
TRANSFORMS-ssh_success = ssh_successful_login
TRANSFORMS-ssh_session = ssh_session_open
# transforms.conf - Definisi extraction
[ssh_failed_login]
REGEX = Failed password for (?:invalid user )?(\S+) from (\S+) port (\d+)
FORMAT = user::$1 src_ip::$2 src_port::$3
DEST_KEY = _raw
[ssh_successful_login]
REGEX = Accepted (?:password|publickey) for (\S+) from (\S+) port (\d+)
FORMAT = user::$1 src_ip::$2 src_port::$3
DEST_KEY = _raw
[ssh_session_open]
REGEX = session opened for user (\S+)
FORMAT = user::$1
DEST_KEY = _raw
# Inline field extraction via SPL
# | rex "Failed password for (?:invalid user )?(?\S+) from (?\S+)"
Search Processing Language (SPL)
SPL adalah bahasa query Splunk yang powerful untuk mencari, memfilter, dan menganalisis data. SPL menggunakan pipeline model yang memungkinkan chaining dari banyak perintah dengan operator pipe (|).
Dasar SPL Search
# Pencarian dasar - semua event yang mengandung "Failed password"
index=security sourcetype=linux_secure "Failed password"
# Filter dengan field dan time range
index=security sourcetype=linux_secure "Failed password"
| where _time > relative_time(now(), "-24h")
| where NOT cidrmatch("10.0.0.0/8", src_ip)
# Top 20 IP dengan failed login terbanyak
index=security sourcetype=linux_secure "Failed password"
| rex "Failed password for (?:invalid user )?(?\S+) from (?\S+)"
| top limit=20 src_ip
| sort -count
# Statistik login per jam untuk setiap user
index=security sourcetype=linux_secure "Accepted password"
| timechart span=1h count by user
| where count > 10
SPL untuk Security Analysis
# === DETECT BRUTE FORCE ===
# Lebih dari 5 failed login dalam 5 menit dari IP yang sama
index=security sourcetype=linux_secure "Failed password"
| bin _time span=5m
| stats count as failed_attempts values(user) as target_users
dc(user) as unique_targets by _time src_ip
| where failed_attempts >= 5
| eval severity=case(
failed_attempts >= 50, "critical",
failed_attempts >= 25, "high",
failed_attempts >= 10, "medium",
true(), "low"
)
| sort -failed_attempts
# === PORT SCAN DETECTION ===
index=firewall sourcetype=firewall_log action=blocked
| bin _time span=10m
| stats count values(dest_port) as ports
dc(dest_port) as unique_ports by src_ip _time
| where unique_ports > 20
| sort -unique_ports
# === NETWORK RECONNAISSANCE ===
# Mencari pola scanning: banyak port berbeda dari satu IP
index=firewall action=allowed OR action=blocked earliest=-1h
| stats count dc(dest_port) as port_count
values(action) as actions by src_ip
| where port_count > 50
| sort -port_count
# === LATERAL MOVEMENT DETECTION ===
# Satu user terhubung ke banyak host berbeda
index=security sourcetype=linux_secure "Accepted"
| stats values(dest) as connected_hosts dc(dest) as host_count by user
| where host_count > 5
| eval risk = case(
host_count > 15, "critical",
host_count > 10, "high",
host_count > 5, "medium"
)
| table user connected_hosts host_count risk
# === PRIVILEGE ESCALATION ===
index=security sourcetype=linux_secure ("sudo" OR "su:")
| where NOT match(user, "root")
| stats count values(command) as commands by user
| where count > 3
| sort -count
Advanced SPL Operations
# Correlation antara firewall dan authentication events
index=security (sourcetype=linux_secure OR sourcetype=firewall_log)
| eval event_category=case(
match(_raw, "Accepted password"), "auth_success",
match(_raw, "Failed password"), "auth_failure",
match(_raw, "DENY|DROP|REJECT"), "firewall_block",
true(), "other"
)
| stats count by src_ip event_category
| xyseries src_ip event_category count
| fillnull value=0
# Transaction-based analysis - menggabungkan event terkait
index=security sourcetype=linux_secure
| transaction src_ip maxspan=30m
startswith="Failed password" endswith="Accepted password"
| where eventcount > 3
| table src_ip duration eventcount user
| sort -eventcount
# Statistical anomaly detection
index=security sourcetype=linux_secure "Failed password"
| timechart span=1h count as failures
| eventstats avg(failures) as avg_failures stdev(failures) as stdev_failures
| eval upper_bound = avg_failures + (3 * stdev_failures)
| where failures > upper_bound
| table _time failures avg_failures upper_bound
Lookup Tables untuk Data Enrichment
Lookup tables memungkinkan enrichment data dengan informasi eksternal seperti asset database atau threat intelligence:
# Menggunakan static lookup untuk threat intel enrichment
index=security action=allowed
| lookup threat_intel.csv ip AS src_ip
OUTPUT threat_level description ioc_type
| where isnotnull(threat_level)
| table _time src_ip dest_ip dest_port threat_level description
# Automatic lookup configuration di props.conf
[firewall_log]
LOOKUP-threat_lookup = threat_intel ip AS src_ip OUTPUTNEW \
threat_level, description, ioc_type
# KV Store lookup (dynamic, bisa diupdate via API)
| outputlookup create_in_app=true threat_intel_kv
Alerts dan Notifikasi
Alert di Splunk memungkinkan notifikasi otomatis ketika kondisi tertentu terpenuhi. Alert yang dikonfigurasi dengan baik sangat kritis untuk tim SOC dalam mendeteksi dan merespons insiden keamanan secara cepat.
Jenis Alert di Splunk
- Real-time Alert - Dijalankan secara real-time, cocok untuk event kritis yang membutuhkan respons segera. Namun sangat boros resource.
- Scheduled Alert - Dijalankan secara periodik (menit/jam), lebih hemat resource dan cocok untuk kebanyakan use case.
- Per-result Alert - Triggered setiap kali query menghasilkan satu atau lebih hasil.
- Rolling-window Alert - Mengevaluasi data dalam window waktu tertentu, cocok untuk threshold-based detection.
Contoh Alert: Brute Force Detection
# Alert Query - Brute Force Detection (Scheduled, setiap 5 menit)
index=security sourcetype=linux_secure "Failed password"
| rex "Failed password for (?:invalid user )?(?\S+) from (?\S+)"
| bin _time span=5m
| stats count as failures values(user) as targets
dc(user) as unique_targets by src_ip _time
| where failures >= 10
| eval severity=case(
failures >= 50, "critical",
failures >= 25, "high",
failures >= 10, "medium",
true(), "low"
)
| table _time src_ip failures targets unique_targets severity
# Alert Settings:
# - Trigger: Number of Results > 0
# - Throttle: 300 seconds per src_ip
# - Action: Send email + Create notable event
Alert Actions Configuration
# alert_actions.conf - Email notification
[email]
from = siem@company.com
to = security-team@company.com
cc = soc-manager@company.com
server = smtp.company.com:587
use_tls = true
subject = [SIEM Alert] $name$ - Severity: $severity$
# Webhook untuk integrasi dengan SOAR/ticketing system
[webhook]
url = https://soar.company.com/api/v2/alerts
payload_format = json
payload = {
"title": "$name$",
"severity": "$severity$",
"description": "$description$",
"src_ip": "$result.src_ip$",
"count": "$result.count$",
"timestamp": "$trigger_time$"
}
# Script-based action untuk auto-response
[script]
filename = auto_response.py
passauth = true
results_file = /tmp/alert_results.csv
Saved Searches dan Notable Events
# savedsearches.conf - Advanced alert configuration
[Suspicious DNS Activity]
search = index=dns earliest=-1h
| lookup dns_whitelist.csv domain OUTPUT is_allowed
| where isnull(is_allowed)
| stats count by src_ip dest_ip domain
| where count > 50
dispatch.earliest_time = -1h
dispatch.latest_time = now
dispatch.max_count = 10000
alert.severity = 3
alert.track = 1
alert.suppress = 1
alert.suppress.fields = src_ip
alert.suppress.period = 1h
action.notable = 1
action.notable.param.severity = high
action.notable.param.rule_title = Suspicious DNS Query Detected
action.notable.param.security_domain = network
action.notable.param.drilldown_name = Investigate Source IP
action.notable.param.drilldown_search = index=firewall src_ip=$src_ip$
Dashboards
Dashboards menyediakan visualisasi real-time dari data keamanan. Dashboard yang baik membantu tim SOC memahami situasi keamanan secara cepat dan mengidentifikasi tren atau anomali.
Dashboard Security Operations Center
<dashboard theme="dark">
<label>SOC Security Overview</label>
<description>Security Operations Center Monitoring Dashboard</description>
<row>
<panel>
<title>Failed Logins (24h)</title>
<single>
<search>
<query>
index=security "Failed password" earliest=-24h
| stats count
</query>
<earliest>-24h</earliest>
<latest>now</latest>
<refresh>5m</refresh>
<refreshType>delay</refreshType>
</search>
<option name="rangeColors">
["0x53a051","0xf8be34","0xdc4e41"]
</option>
<option name="rangeValues">[50,200]</option>
<option name="underLabel">attempts</option>
</single>
</panel>
<panel>
<title>Unique Attack Sources</title>
<single>
<search>
<query>
index=security "Failed password" earliest=-24h
| stats dc(src_ip) as unique_sources
</query>
</search>
<option name="underLabel">unique IPs</option>
</single>
</panel>
<panel>
<title>Active Alerts</title>
<single>
<search>
<query>
index=_audit action=alert_fired earliest=-24h
| stats count
</query>
</search>
</single>
</panel>
<panel>
<title>High Risk Events</title>
<single>
<search>
<query>
index=security severity=high OR severity=critical earliest=-24h
| stats count
</query>
</search>
</single>
</panel>
</row>
<row>
<panel>
<title>Security Events Timeline</title>
<chart>
<search>
<query>
index=security earliest=-24h
| timechart span=1h count by sourcetype
</query>
</search>
<option name="charting.chart">line</option>
<option name="charting.drilldown">all</option>
</chart>
</panel>
</row>
<row>
<panel>
<title>Top Attack Sources</title>
<table>
<search>
<query>
index=security "Failed password" earliest=-24h
| rex "from (?<src_ip>\S+)"
| top limit=20 src_ip showperc=true
</query>
</search>
</table>
</panel>
<panel>
<title>Targeted Accounts</title>
<table>
<search>
<query>
index=security "Failed password" earliest=-24h
| rex "for (?:invalid user )?(?<user>\S+)"
| top limit=20 user showperc=true
</query>
</search>
</table>
</panel>
</row>
<row>
<panel>
<title>Attack Geographic Distribution</title>
<map>
<search>
<query>
index=security "Failed password" earliest=-24h
| iplocation src_ip
| geostats count by Country
</query>
</search>
</map>
</panel>
</row>
</dashboard>
Correlation Rules
Correlation rules adalah fitur paling powerful dari SIEM. Aturan korelasi menghubungkan beberapa event untuk mendeteksi pola serangan yang kompleks dan multi-stage yang tidak terlihat jika masing-masing event dianalisis secara terpisah.
Multi-Stage Attack Detection
# Correlation Rule: Reconnaissance -> Brute Force -> Lateral Movement
# Menggunakan subsearch untuk mengkorelasikan multiple stages
# Stage 1: Detect port scanning (reconnaissance)
| makeresults
| eval src_ip = "placeholder"
| append [
search index=firewall action=blocked earliest=-1h
| bin _time span=10m
| stats dc(dest_port) as port_count by src_ip _time
| where port_count > 20
| eval stage = "reconnaissance"
| fields src_ip _time stage
]
# Stage 2: Detect brute force attempts
| append [
search index=security "Failed password" earliest=-1h
| rex "from (?\S+)"
| stats count as failed_count by src_ip
| where failed_count > 10
| eval stage = "brute_force"
| fields src_ip failed_count stage
]
# Stage 3: Detect successful exploitation
| append [
search index=security "Accepted password" earliest=-30m
| rex "for (?\S+) from (?\S+)"
| eval stage = "exploitation"
| fields src_ip user stage
]
# Correlate all stages
| stats values(stage) as attack_stages count as total_events
by src_ip
| where mvcount(attack_stages) > 1
| eval risk_score = mvcount(attack_stages) * 30
| sort -risk_score
DNS-based Threat Detection
# Detect DNS tunneling - unusually long domain names
index=dns earliest=-1h
| eval domain_len = len(query)
| stats avg(domain_len) as avg_len max(domain_len) as max_len
count as query_count by src_ip
| where avg_len > 50 AND query_count > 100
| sort -avg_len
# Detect DGA (Domain Generation Algorithm) domains
index=dns earliest=-1h
| rex field=query "^(?[^.]+)\."
| eval domain_len = len(domain)
| eval consonant_ratio = (
len(replace(domain, "[aeiouAEIOU]", "")) / domain_len
)
| eval has_numbers = if(match(domain, "\d"), 1, 0)
| where domain_len > 12 AND consonant_ratio > 0.7 AND has_numbers = 1
| stats count by src_ip domain
| sort -count
# Correlate DNS with threat intel
index=dns earliest=-24h
| lookup threat_intel_domains.csv domain AS query
OUTPUT threat_type confidence
| where isnotnull(threat_type)
| stats count values(src_ip) as sources
values(threat_type) as threats by query
| sort -count
User Behavior Analytics (UBA)
# Detect impossible travel - login dari lokasi berjauhan
index=authentication "Accepted"
| rex "from (?\S+)"
| iplocation src_ip
| sort user _time
| streamstats current=f last(Country) as prev_country
last(_time) as prev_time by user
| eval travel_time = _time - prev_time
| eval distance_km = if(Country != prev_country,
6371 * 2 * asin(sqrt(
sin((to_radians(Lat) - to_radians(prev_Lat))/2)^2 +
cos(to_radians(prev_Lat)) * cos(to_radians(Lat)) *
sin((to_radians(Lon) - to_radians(prev_Lon))/2)^2
)), 0)
| where distance_km > 500 AND travel_time < 3600
| table user Country prev_country distance_km travel_time src_ip
# Detect off-hours access
index=authentication "Accepted" earliest=-24h
| eval hour = strftime(_time, "%H")
| eval is_off_hours = if(hour < 6 OR hour > 22, 1, 0)
| where is_off_hours = 1
| stats count values(src_ip) as sources by user
| sort -count
Best Practices SIEM dengan Splunk
- Data Normalization (CIM) - Gunakan Common Information Model untuk memastikan konsistensi data antar sourcetype. Ini sangat penting untuk correlation rules yang melibatkan multiple data source.
- Index Design - Pisahkan data berdasarkan tim kepemilikan, compliance requirement, dan retensi period. Hindari menyimpan semua data dalam satu index besar.
- Role-Based Access Control - Implementasikan RBAC untuk membatasi akses data sensitif. Gunakan Splunk roles untuk memisahkan akses SOC analyst, SOC manager, dan compliance team.
- Performance Optimization - Optimasi search dengan indexed fields (INDEXED, INDEXED_VALUE), summary indexing untuk report yang sering dijalankan, dan data model acceleration.
- Data Quality - Pastikan timestamp dikonfigurasi dengan benar, source type assignment akurat, dan field extraction lengkap sebelum data diindeks.
- Capacity Planning - Monitor license usage harian, storage consumption, dan search concurrency. Rencanakan kapasitas 12-18 bulan ke depan.
- Backup dan DR - Backup konfigurasi, metadata, dan saved searches secara rutin. Rencanakan disaster recovery untuk deployment cluster.
- Tuning - Lakukan tuning alert secara berkala untuk mengurangi false positive. Gunakan suppress dan throttle untuk menghindari alert fatigue.
Selalu pastikan untuk tidak menyimpan data sensitif seperti password, API key, atau PII dalam log Splunk. Gunakan SEDCMD di props.conf untuk menyensor data sensitif sebelum diindeks. Pastikan juga akses ke Splunk dilindungi dengan SSL/TLS dan multi-factor authentication.
# props.conf - Sensitive data masking
[security]
SEDCMD-mask_password = s/password=[^\s,]+/password=****/g
SEDCMD-mask_apikey = s/api[_-]?key=[^\s,]+/apikey=****/g
SEDCMD-mask_email = s/[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}/[REDACTED_EMAIL]/g
SEDCMD-mask_credit_card = s/\d{4}[-\s]?\d{4}[-\s]?\d{4}[-\s]?\d{4}/[REDACTED_CC]/g
SEDCMD-mask_ssn = s/\d{3}-\d{2}-\d{4}/[REDACTED_SSN]/g
Quiz: SIEM dengan Splunk
🎯 Uji Pemahaman Anda tentang SIEM Splunk
1. Komponen Splunk yang bertugas mengumpulkan data dari sumber dan mengirimkannya ke Indexer tanpa memproses data adalah?
2. Bahasa query yang digunakan di Splunk untuk pencarian dan analisis data adalah?
3. Fitur Splunk untuk menerima data dari aplikasi eksternal via REST API disebut?
4. Untuk menyensor data sensitif (seperti password) sebelum diindeks di Splunk, konfigurasi yang digunakan adalah?
5. Standar normalisasi data yang direkomendasikan Splunk untuk memastikan konsistensi field antar sourcetype adalah?
Kesimpulan
Splunk adalah platform SIEM yang sangat powerful untuk security monitoring. Dengan pemahaman yang baik tentang arsitektur, data inputs, SPL, alerts, dashboards, dan correlation rules, Anda dapat membangun sistem deteksi ancaman yang efektif. Ingat bahwa implementasi SIEM yang sukses membutuhkan perencanaan yang matang, tuning berkelanjutan, dan kolaborasi antara tim keamanan dan operasional TI.
Mulailah dengan use case sederhana seperti brute force detection dan login anomaly, lalu tingkatkan secara bertahap menuju advanced threat detection dan user behavior analytics.