Open source SIEM: минимально полезное внедрение Wazuh и Elastic

Зачем нужен SIEM и что значит «минимально полезно»

SIEM простыми словами - это место, где собираются события из разных систем (серверы, рабочие станции, сеть, почта), чтобы быстрее замечать подозрительное и разбирать инциденты. Ценность SIEM не в «складировании логов», а в ответах на практичные вопросы: что произошло, где, когда, кого затронуло и что делать дальше.

Важно различать: «мы собираем логи» не равно «у нас появилась безопасность». Если события приходят без точного времени, контекста и правил, вы получаете шум и усталость от уведомлений. SIEM начинает приносить пользу только тогда, когда подключены минимально нужные источники, есть базовые корреляции и понятный процесс реакции.

Минимально полезный результат (MVP) для open source SIEM - это небольшой набор сценариев, которые реально ловятся и реально отрабатываются. Обычно MVP выглядит так:

• подключены 3-5 ключевых источников событий и они стабильно отдают данные;
• 5-10 простых корреляций дают понятные оповещения без лавины ложных срабатываний;
• есть дашборд для ИБ и короткий отчет для руководителя (что нашли, как отработали);
• определены границы ответственности ИБ и ИТ: кто чинит источник логов, кто расследует, кто закрывает инцидент.

Через 1-2 месяца MVP обычно дает видимость входов и неудачных попыток, базовый контроль критичных серверов и первые расследования «по цепочке событий». Не стоит ждать «полной защиты», автоматического расследования всего подряд и идеального покрытия всех систем.

В небольшой организации MVP часто начинается с контроллера домена, пары важных серверов и нескольких рабочих мест бухгалтерии. Этого уже хватает, чтобы поймать массовый подбор паролей или запуск подозрительных инструментов.

Роли ИБ и ИТ: кто что делает и за что отвечает

Даже аккуратно настроенный open source SIEM не даст эффекта, если заранее не разделить обязанности. В MVP важно не «закрыть все», а договориться о правилах работы: кто подключает источники, кто решает, что считать инцидентом, и кто поднимает трубку ночью.

ИБ обычно отвечает за смысл и качество результата: какие риски снижаем, что считаем подозрительным, какие алерты нужны, а какие - шум.

ИТ отвечает за то, чтобы данные вообще появились и приходили стабильно. Без доступов, точного времени на хостах и дисциплины изменений корреляции быстро превращаются в фон.

Практичное разделение обязанностей в MVP:

• ИБ задает требования: какие события нужны, какие пороги и реакции допустимы, что такое «инцидент» и кто его подтверждает.
• ИТ подключает источники: включает аудит, ставит агенты, открывает порты, выдает сервисные учетные записи, следит за обновлениями и изменениями на хостах.
• ИБ принимает качество: проверяет полноту, точность времени, уровень шума, согласует исключения.
• ИТ обеспечивает надежность: резервное копирование, место на диске, мониторинг доступности компонентов.

Владение контентом (корреляции, исключения, справочники) - частый спор. Для MVP обычно работает простая модель: ИБ владеет правилами и исключениями (что важно и что игнорируем), а ИТ - техническими параметрами сбора (где включить логирование, как не сломать сервис, какие изменения допустимы).

Чтобы не перегрузить команду, сразу фиксируйте режим сопровождения. Например: в рабочее время ИБ разбирает алерты и заводит задачи, а ИТ подключается по заявке. Дежурства вводите только для «красных» сценариев (например, массовые блокировки учетных записей) и только после недели-двух настройки шумоподавления. Это дешевле, чем круглосуточно реагировать на ложные срабатывания.

MVP-архитектура Wazuh и Elastic простыми словами

MVP на Wazuh и Elastic Stack можно представить как конвейер: собрать события, привести их к понятному виду, найти подозрительное и показать это людям. Это не «идеальный SOC», а работающий минимум, который реально поддерживать.

На серверах и рабочих станциях ставятся агенты Wazuh: они читают журналы, следят за целостностью файлов, фиксируют базовые признаки компрометации и отправляют данные дальше. Wazuh Manager принимает поток, применяет правила, формирует алерты и обогащает события (например, добавляет уровень важности и категорию).

Дальше используется Elastic Stack. В Elastic (индекс) попадает то, что нужно хранить и искать: события и алерты. Kibana дает просмотр, поиск, дашборды и отчеты.

Полезно различать, что где находится:

• сырые события - исходные логи (как их отдал Windows, Linux, сетевое устройство);
• нормализованные поля - те же события, но с едиными именами полей для поиска и фильтров;
• алерты - результат правил и корреляций, то, с чем реально работают.

Для MVP чаще всего выбирают один сервер, где живут Wazuh Manager и Elastic. Это быстрее в запуске, но требовательнее к дискам и резервному копированию. Если событий много или нужна надежность, роли разносят: отдельная машина под Wazuh Manager и отдельная под Elastic (плюс Kibana).

В качестве базы обычно берут обычные серверы, в том числе локального производства (например, стойки уровня GSE S200 Series). Но критичнее не бренд, а ресурсы, понятная гарантия обслуживания и стабильная поддержка.

Чтобы система не «сломалась тихо», с первого дня держите под контролем четыре вещи: точное время (NTP), место на дисках (особенно под индексы), ротацию и срок хранения, а также регулярные резервные копии конфигураций и индексов.

Источники событий: что подключать в первую очередь

В MVP важно не собрать «все подряд», а получить сигналы, которые отвечают на базовые вопросы: кто вошел, откуда, что запускал, какие права получил, что было заблокировано на периметре. Для Wazuh и Elastic это означает: сначала самые «говорящие» точки, потом расширение.

Начните с активов, где чаще всего видны и атаки, и ошибки админов. Обычно это доменные контроллеры, несколько ключевых серверов (файловый, почтовый, виртуализация), а также админские рабочие места. Эти источники дают максимум пользы даже при небольшом числе правил.

Приоритетный набор на старт:

• Windows Security Log на доменных контроллерах и критичных серверах (входы, блокировки, изменения учетных записей и групп)
• Sysmon на части систем, если команда готова поддерживать правила и фильтры (процессы, сетевые соединения, создание файлов)
• Linux auth и sudo на серверах (успешные и неуспешные входы, повышение прав)
• VPN (кто подключился, с какого адреса, куда получил доступ)
• прокси или веб-шлюз, если он уже есть (категории, блокировки, подозрительные домены)

Сетевые устройства тоже полезны, но подключайте их осознанно. Логи firewall часто дают быстрые победы: сканирования, запреты, неожиданные исходящие подключения. Маршрутизаторы и IDS стоит добавлять, если есть понятный владелец данных и вы заранее понимаете, какие алерты будете смотреть.

Что лучше отложить: редкие бизнес-приложения, «экзотические» форматы логов и попытку охватить весь парк за неделю. Для организации на 200 рабочих мест обычно разумно начать с 2 доменных контроллеров, 5-10 серверов и 10 админских ПК, отладить качество данных и только потом расширяться.

Качество данных: время, шум и нормализация

В open source SIEM быстро становится очевидно: ценность дают не только корреляции, но и качество входных данных. Если время «плывет», события дублируются, а поля называются по-разному, расследование превращается в угадайку.

Время: NTP, часовые пояса и дрейф

Самый частый провал на старте - несогласованное время. Один сервер пишет UTC, рабочие станции - местное время, а часть систем еще и отстает на несколько минут. В итоге цепочка атаки «ломается»: вход в систему может оказаться «после» запуска процесса.

Минимальный набор проверок:

• включен NTP на всех узлах (серверы, рабочие станции, сетевые устройства);
• выбран один стандарт (часто UTC на серверах и в хранилище);
• часовые пояса на источниках указаны и корректно парсятся в стеке;
• дрейф контролируется регулярно, а не «один раз настроили и забыли».

Шум, дубли и нормализация

В первую неделю почти всегда видно лавину событий: обновления, сканирования, «нормальные» ошибки приложений. Добавьте дубли (например, одинаковые Windows-события с разных каналов или повторную доставку агентом), и алерты станут бесполезными.

Обычно помогает простой порядок действий. Сначала договоритесь о единых полях: пользователь (в одном формате), хост (FQDN или инвентарное имя), IP (без «как получилось»), критичность (одна шкала). Затем включайте фильтрацию аккуратно: не «глушить все», а убирать повторяющееся и заведомо безопасное.

Исключения (whitelist) лучше вести как небольшой процесс:

• ИБ предлагает исключение и обосновывает риск.
• ИТ подтверждает техническую причину (почему это шум и откуда идет).
• Изменение фиксируется: что исключили, где и на какой срок.
• У правила есть владелец и дата пересмотра.

Пример: после развертывания новых рабочих станций обновления ОС могут дать тысячи событий в час. Если заранее нормализовать имена хостов и время, вы сможете отфильтровать именно обновления, не потеряв реальные попытки входа и запуск подозрительных процессов.

Базовые корреляции, которые дают пользу в MVP

В MVP важны не «все возможные правила», а несколько корреляций, которые ловят типовые инциденты и не засыпают людей уведомлениями. На Wazuh и Elastic лучше начинать с сигналов, которые легко объяснить и быстро проверить вручную.

Корреляции, с которых стоит начать

Хороший стартовый набор покрывает учетные записи, доступ и саботаж логирования:

• изменения в админских группах и правах (добавили пользователя в локальные админы, доменных админов, дали привилегию входа на сервер);
• подбор паролей и «прыжки» по учеткам (много неудачных входов с одного источника, затем успешный вход; серия попыток по разным логинам);
• отключение или поломка логирования (остановка агента, чистка журналов, резкое падение объема событий с важного узла);
• подозрительные процессы и закрепление (запуск из временных папок, создание новой службы, задача в планировщике, новый элемент автозагрузки);
• доступ к критичным серверам (вход в непривычное время, с нового хоста, новой учетной записи или из необычной подсети).

Пример: в небольшой организации бухгалтер заходит на файловый сервер только по будням днем. Ночью появляется успешный вход под его учеткой сразу после 20 неудачных попыток, а затем создается задача в планировщике. Даже если это ложное срабатывание, проверка занимает минуты и дает понятный результат.

Критичность и маршрутизация без спама

Задайте три уровня: низкий (в отчет, без уведомлений), средний (в очередь на разбор), высокий (срочно, с понятным текстом «что произошло и где»). Простое правило: уведомления только по высокому, а средний идет в ежедневный обзор.

Чтобы правила не разрастались, ведите бэклог: цель, владелец (ИБ или ИТ), ожидаемая польза, причины ложных срабатываний. Если за 2-4 недели правило не дало ни одного полезного случая и требует много исключений, его лучше упростить или убрать.

Отчеты и дашборды: что реально нужно разным людям

Отчеты в SIEM нужны не ради красоты. Они помогают быстро отвечать на простые вопросы: что сломалось, где риск, кто должен действовать и как понять, что стало лучше. Для MVP на Wazuh и Elastic обычно хватает нескольких экранов, но каждый должен быть привязан к роли и решению.

Если заранее договориться о формате, один и тот же open source SIEM становится полезным разным группам:

• ИБ: панель по алертам (топ срабатываний за сутки, критичность, по каким хостам больше всего, какие учетные записи чаще фигурируют) и тренды (рост RDP/SSH попыток, появление новых админских действий).
• ИТ: отчет о здоровье сбора данных (какие агенты отвалились, где есть пропуски, задержки доставки, переполнение диска и очередей, ошибки парсинга).
• Руководство: одна страница без деталей (сколько инцидентов за период, сколько закрыто в срок, среднее время реакции, что было самым заметным риском).
• Аудит/комплаенс: покрытие источников (какие системы подключены и с какого числа), подтверждение хранения логов, список значимых инцидентов и действий.

Чтобы отчеты не превращались в спор, заранее зафиксируйте, что именно считается инцидентом. Иначе ИБ будет считать инцидентом любое срабатывание, а ИТ - только падение сервиса.

Как описать «инцидент» так, чтобы он попал в отчет

Опишите правила простыми фразами и привяжите их к полям в событии (критичность, актив, пользователь, результат). Обычно хватает мини-набора:

• условие (что произошло): например, 10 неуспешных входов за 5 минут + успешный вход;
• объект (где): критичный сервер, контроллер домена, бухгалтерская рабочая станция;
• порог (когда «достаточно»): количество, окно времени, повторяемость;
• владелец реакции: ИБ подтверждает и классифицирует, ИТ устраняет причину (или наоборот, если это чисто техсбой);
• критерий закрытия: что должно быть сделано, чтобы инцидент считался завершенным.

Пример: если на сервере внезапно появляется новая учетная запись в группе администраторов, это идет в отчет ИБ как инцидент, а в отчет ИТ как задача на проверку изменений и учетных записей. Главное - чтобы оба отчета ссылались на одно и то же событие.

Пошаговый план внедрения на 30-60 дней

Держите простой принцип: сначала делаем сбор и понятные сигналы, и только потом усложняем. Для MVP на Wazuh и Elastic Stack заранее договоритесь, кто принимает решения по рискам (ИБ), а кто отвечает за доступы, агентов и стабильность инфраструктуры (ИТ).

План работ по неделям

За 30-60 дней реально дойти до работающего минимума, если держать фокус на нескольких системах и измеримых результатах.

• Неделя 1: зафиксируйте 2-3 цели, сделайте инвентаризацию источников логов, выберите 3-5 самых критичных систем (например, контроллер домена, почта, VPN, ключевой сервер приложений, EDR при наличии).
• Недели 2-3: установите Wazuh, поднимите Elastic, подключите первые 3-5 источников. Сразу проверьте время (NTP), объем событий в сутки и где появляется шум.
• Недели 4-6: настройте 5-10 корреляций, добавьте исключения и пороги, чтобы алерты были редкими, но точными. Подготовьте первые простые отчеты для ИБ и для ИТ.
• Недели 7-8: прогоните 2-3 учебных инцидента (например, подбор пароля, подозрительный вход ночью, запуск неизвестного процесса), уточните регламенты реакции и критерии приемки MVP.

Что должно остаться на выходе

MVP считается готовым, когда он воспроизводимо дает пользу и его можно поддерживать без героизма:

• список подключенных источников и ответственных за каждый;
• матрица правил: что ловим, какая логика, какой приоритет, кто реагирует;
• шаблоны отчетов (еженедельный для ИБ, технический для ИТ, краткий для руководителя);
• RACI на поддержку: кто делает изменения, кто согласует, кого уведомляют, кто принимает результат.

Простой тест: если новый сотрудник может понять, откуда берутся алерты и что делать при срабатывании, значит MVP оформлен правильно.

Пример сценария: «небольшая организация, мало людей, много задач»

Организация на 250-400 рабочих мест и 15-20 серверов. В ИТ - 6 человек (админы, поддержка, 1 человек по сетям). В ИБ - один специалист, и еще один подключается «по остаточному времени». Отдельного SOC и дежурств нет.

Цель MVP выбрали предельно практичную: видеть админские действия и ранние признаки компрометации учетных записей. То есть не «всю безопасность», а конкретно: кто получил привилегии, кто менял критичные настройки и где начались подозрительные попытки входа.

Первыми подключили источники с максимальным эффектом при минимальных усилиях: контроллер домена (аутентификация и групповые политики), два важных Windows-сервера (файловый и терминальный), VPN/шлюз (входы извне), антивирус/EDR (детекты). Рабочие станции подключали выборочно: бухгалтерия, кадры, компьютеры админов. Инфраструктуру разместили on-prem, чтобы держать под контролем хранение и цепочку поставок оборудования.

В первый месяц «выстрелили» 6-8 правил. Самые полезные были про подбор пароля (серия неудачных входов с последующим успешным), вход под привилегированной учетной записью в нерабочее время, добавление пользователя в админские группы, отключение журналирования или попытки очистки логов, запуск удаленных инструментов администрирования с нетипичных хостов.

Еще пару правил добавили по ситуации (например, новые локальные админы на серверах и подозрительные входы в VPN). Почти сразу пришлось «успокоить» алерты исключениями: сервисные учетные записи, плановые задания, массовые смены паролей, сканеры уязвимостей. Важно, что исключения делали не «ради тишины», а с явным владельцем: ИТ подтверждает легитимность действия и фиксирует, почему оно должно быть исключено.

Первый отчет для руководства сделали на одной странице: 3-5 цифр и 2-3 коротких примера. Например: сколько было попыток подбора пароля за месяц, сколько успешных входов админов ночью, сколько раз менялись права доступа, и какие два инцидента потребовали реакции (дата, система, итог: «заблокировали учетку», «поменяли пароль», «закрыли доступ из внешней сети»). Такой отчет показывает пользу MVP без перегруза деталями.

Типичные ошибки при запуске open source SIEM

Чаще всего разочарование в open source SIEM связано не с инструментами, а со стартом без ограничений. Когда подключают «все, что есть» в первую неделю, платформа тонет в шуме: тысячи событий без приоритета, а полезные сигналы теряются. Начните с небольшого набора источников и пары понятных сценариев реакции.

Вторая боль - алерты «в воздух». Если у правил нет владельца, уведомления становятся фоном: никто не подтверждает инцидент, не открывает тикет, не делает разбор. Назначьте ответственного за каждую группу правил (ИБ или ИТ) и договоритесь о простом статусе: «принято», «ложное», «нужно улучшить».

Третья ошибка - время. Без синхронизации часов на серверах, рабочих станциях, сетевом оборудовании и самом стеке вы не соберете цепочку событий. Симптом простой: одно и то же действие выглядит как разные эпизоды.

Еще один частый промах - строить корреляции, не проверив, что поля заполняются стабильно. Если «гуляют» имена хостов, пользователи, IP или коды событий, правила будут либо молчать, либо «кричать» без контекста.

И наконец, хранение. Не запланировали объемы - внезапно заканчивается диск, падает индексация, и вы теряете данные именно в момент инцидента. Заранее оцените ретеншн и рост, особенно если разворачиваете все on-prem на выделенных серверах.

Полезно держать в голове пять ограничений на старте:

• не пытайтесь закрыть весь периметр сразу - начните с 3-5 ключевых источников;
• у каждого алерта должен быть владелец и ожидаемое действие;
• синхронизация времени обязательна до первых расследований;
• корреляции настраивайте только после проверки качества полей;
• SIEM не заменяет EDR, обучение сотрудников и процессы управления доступами.

Короткий чеклист перед запуском в эксплуатацию

Перед тем как объявить open source SIEM «боевым», полезно пройти короткий чеклист. Он помогает поймать типичные провалы: непонятные цели, шумные алерты и отсутствие процесса.

5 проверок, что MVP действительно «полезный»

• цели MVP сформулированы в 2-3 фразах и одинаково поняты ИБ и ИТ (что ловим, зачем, кому больно);
• подключены ключевые источники и проверена полнота: события приходят регулярно, без разрывов и с правильным временем;
• настроены 5-10 корреляций с ясной критичностью и понятным описанием;
• есть регламент обработки: кто принимает алерт, что делает первым шагом, и какое время реакции считается нормой;
• отчеты «живые»: отдельный набор для ИБ (инциденты и тренды), для ИТ (сбои, агенты, покрытие), для руководства (1 страница про риски и динамику).

Готовность к эксплуатации

• настроены резервные копии (конфиги, правила, индексы по согласованному сроку) и понятная процедура восстановления;
• есть мониторинг места на дисках и скорости роста данных;
• обновления запланированы: кто обновляет, как тестирует, как откатывается;
• назначены ответственные: ИТ за доступность и хранение, ИБ за правила и разбор инцидентов, без «серой зоны».

Если хотя бы два пункта вызывают сомнения, лучше остановиться на день и поправить, чем потом тушить пожар в проде.

Следующие шаги после MVP: рост и поддержка без перегруза

После MVP главное - расти по плану, а не подключать «все подряд». Если базовые источники уже дают пользу и появились первые рабочие алерты и отчеты, следующий шаг - расширять покрытие так, чтобы команда успевала разбирать срабатывания и улучшать правила.

Как расширять покрытие без хаоса

Удобный ориентир - добавлять по одному крупному блоку за раз и сразу доводить его до качества: понятные поля, фильтры от шума, проверенные корреляции.

Сначала берите источники с высокой ценностью (VPN, почта, EDR/антивирус, прокси или DNS), затем усложняйте правила под ваши процессы (учетки, админ-доступ, критичные сервисы). После этого добавляйте контекст: списки критичных серверов, владельцы систем, расписание работ, чтобы отличать инцидент от плановых изменений. Узкие кейсы и редкие источники оставляйте на потом.

Когда разделять роли

Пока объем небольшой, один человек может совмещать задачи. Роли обычно стоит разделять, когда алертов становится много, а улучшения «застревают»:

• контент (правила, исключения, отчеты) начинает занимать больше 30-40% времени;
• эксплуатация (обновления, агенты, место на диске, бэкапы) требует регулярных работ;
• реагирование стало постоянной функцией, а не редкими проверками.

Чтобы рост не уперся в инфраструктуру, заранее прикиньте ресурсы: хранение (сколько дней логов и какая скорость роста), резервное копирование, что будет при отказе узла. Частая ошибка - оставить все на одном сервере без плана восстановления.

Если нужен переход в промышленный контур, системный интегратор может помочь с обследованием, архитектурой, миграцией и регламентами. В Казахстане иногда важно опираться на локальную инфраструктуру: например, разместить хранение и вычисления на отечественных серверах и рабочих станциях GSE.kz (gse.kz) и заранее договориться о сопровождении, чтобы обновления, мониторинг и поддержка 24/7 не «съедали» команду ИБ.

Пример: небольшая больница добавляет к MVP логи VPN и почты, но вводит правило - новые источники подключаются только вместе с владельцем системы и понятным сценарием реагирования. Это резко снижает число «висящих» алертов и делает рост предсказуемым.