Splunk Enterprise SIEM: аудит, настройка и интеграция

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

Мы занимаемся настройкой Splunk под ключ уже 5+ лет и реализовали 30+ проектов SIEM. Наш подход — не просто установить, а построить систему, которая реально снижает время детекции инцидентов (MTTD) до минут и число ложных срабатываний на 80%. При правильном проектировании можно сэкономить до 30% на лицензиях за счёт эффективного data onboarding и тюнинга. Свяжитесь с нами — оценим ваш проект.

Проблемы, которые решаем

Самые частые технические сложности при внедрении 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-деплоя

Для 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%.

Что входит в работу

• Аудит существующей инфраструктуры и требований
• Проектирование архитектуры (single-instance или distributed с HA)
• Развёртывание Splunk Enterprise с кластеризацией
• Настройка data onboarding: парсинг, sourcetypes, индексы
• Маскирование чувствительных данных (PCI DSS, GDPR)
• Написание correlation rules и SPL-запросов
• Интеграция с SIEM (ES) и SOAR (по желанию)
• Обучение команды и документация
• Гарантийная поддержка 1 месяц

Сроки ориентировочно

Стоимость рассчитывается индивидуально после аудита инфраструктуры. Получите консультацию и предварительную оценку проекта — свяжитесь с нами. Гарантируем качество и прозрачность.