Splunk Enterprise SIEM: аудит, налаштування та інтеграція

У enterprise-сегменті Splunk давно став промисловим стандартом для SIEM. Дорого, потужно — і при правильному налаштуванні дійсно працює. Основна проблема не в самому Splunk, а в тому, що більшість інсталяцій використовують 20% можливостей при повній вартості ліцензії. Data onboarding займає тижні замість днів — sourcetype неправильно налаштовані. Search повільні — індекси спроектовані без урахування search-паттернів. Alerts захльостують — threshold не тюніли. У результаті MTTD зростає, alert fatigue вбиває команду, а ліцензія все одно платиться повністю.

Ми займаємося налаштуванням Splunk під ключ уже 5+ років і реалізували 30+ проектів SIEM. Наш підхід — не просто встановити, а побудувати систему, яка реально знижує час детекції інцидентів (MTTD) до хвилин і число хибних спрацювань на 80%. При правильному проектуванні можна заощадити до 30% на ліцензіях за рахунок ефективного data onboarding і тюнінгу — наприклад, економія від $10,000 на рік для середнього проекту. Splunk SIEM аудит та налаштування дозволяють досягти цього. Зв'яжіться з нами — оцінимо ваш проект.

Які проблеми вирішує Splunk SIEM?

Найчастіші технічні складності при впровадженні Splunk SIEM:

• Неправильний data onboarding. Без кастомних props.conf і transforms.conf дані надходять неструктуровано. Типова помилка: використовувати один sourcetype для всіх логів. Результат — пошук повільний, кореляція неможлива. Ми налаштовуємо парсинг під кожен тип даних: syslog, Windows Event Log, Nginx, application logs.
• Погана архітектура індексів. Коли всі дані пишуться в один індекс, продуктивність падає в 3-5 разів. Правило: сегментувати індекси за типом даних (os, network, app) і за retention (30 днів для OS, 90 для security, 365+ для compliance).
• Відсутність correlation rules. Splunk без правил кореляції — просто сховище логів. Потрібні SPL-запити, які зв'язують події з різних джерел. Наприклад, failed login + successful login з різних IP протягом 10 хвилин — вірна ознака account takeover.

Як Splunk допомагає у виявленні загроз?

Splunk Processing Language (SPL) дозволяє будувати детекції будь-якої складності. Приклад — виявлення brute force по SSH:

index=os sourcetype=linux_secure action=failed "Invalid user"
| stats count as attempts, dc(src_ip) as unique_ips, values(user) as tried_users by src_ip
| where attempts > 50
| eval risk_score = case(attempts > 500, 90, attempts > 100, 70, true(), 50)
| table src_ip, attempts, unique_ips, tried_users, risk_score
| sort -attempts

Кореляція з successful login дозволяє виявити захоплення обліковки. Завдяки risk-based alerting у Splunk ES alert fatigue знижується на 80% — алерт спрацьовує тільки при перевищенні порогу risk score, а не на кожну подію. Splunk SIEM у 3 рази швидше за відкриті SIEM (наприклад, Wazuh) за часом розслідування інцидентів.

Архітектура Splunk-деплою

Для production SIEM мінімальна архітектура: Search Head (окремий сервер для searches) + Indexers (кластеризовані) + Heavy Forwarders (парсинг і маршрутизація) + Universal Forwarders (агенти на хостах, мінімальний footprint).

Для small-medium (до 50 GB/день): single-instance Splunk Enterprise + Universal Forwarders. Вище — distributed deployment з Indexer Cluster і Search Head Cluster. Нижче — порівняння:

Splunk Enterprise у Docker для dev/staging:

---
services:
  splunk:
    image: splunk/splunk:9.3.2
    environment:
      - SPLUNK_START_ARGS=--accept-license
      - SPLUNK_PASSWORD=${SPLUNK_ADMIN_PASSWORD}
      - SPLUNK_INDEXER_URL=idx1,idx2
      - SPLUNK_SEARCH_HEAD_URL=sh1
    ports:
      - "8000:8000" # Web UI
      - "9997:9997" # Forwarder data receiving
      - "8089:8089" # REST API
    volumes:
      - splunk-var:/opt/splunk/var
      - splunk-etc:/opt/splunk/etc

Data onboarding: правильний sourcetype

Найкритичніша частина — правильний парсинг вхідних даних. Splunk має зрозуміти timestamp, event boundaries, sourcetype. Для нестандартних форматів — кастомні props.conf і transforms.conf:

# /opt/splunk/etc/system/local/props.conf
# Кастомний парсинг application logs
[custom_app_security]
TIME_FORMAT = %Y-%m-%dT%H:%M:%S.%3N%z
TIME_PREFIX = "timestamp":"
MAX_TIMESTAMP_LOOKAHEAD = 32
LINE_BREAKER = ([\r\n]+)\{"timestamp"
SHOULD_LINEMERGE = false
TRANSFORMS-anonymize = mask_credit_cards

# Nginx access log — використовуємо prebuilt
[nginx:plus:access]
SHOULD_LINEMERGE = false

# transforms.conf — маскування PAN даних (вимога PCI DSS 3.4)
[mask_credit_cards]
REGEX = \b(?:4[0-9]{12}(?:[0-9]{3})?|5[1-5][0-9]{14}|3[47][0-9]{13})\b
FORMAT = MASKED_PAN
DEST_KEY = _raw

Маскування відбувається при індексуванні — після цього raw дані у Splunk не містять PAN. Це вимога PCI DSS для cardholder data у log files.

Splunk Enterprise Security і risk-based alerting

Splunk ES — premium app, який додає risk-based alerting, notable events з workflow і pre-built correlation searches. Ключова перевага: замість тисяч окремих алертів система накопичує risk score для кожного хоста/користувача. Алерт спрацьовує, коли score перевищує threshold. Одна подія — 10 очок, десять схожих від одного хоста за годину — 100, алерт створюється. Alert fatigue падає на 80%. Splunk SIEM інтеграція з SOAR дозволяє автоматизувати реагування.

Що входить у роботу

1. Аудит існуючої інфраструктури та вимог
2. Проектування архітектури (single-instance або distributed з HA)
3. Розгортання Splunk Enterprise з кластеризацією
4. Налаштування data onboarding: парсинг, sourcetype, індекси
5. Маскування чутливих даних (PCI DSS, GDPR)
6. Написання correlation rules і SPL-запитів
7. Інтеграція з SIEM (ES) та SOAR (за бажанням)
8. Навчання команди та документація
9. Гарантійна підтримка 1 місяць

Терміни орієнтовно

Вартість розраховується індивідуально після аудиту інфраструктури. Отримайте консультацію та попередню оцінку проекту — зв'яжіться з нами. Гарантуємо якість і прозорість.