wazuh_devsecops

1.

Wazuh как
DevSecOps-платформа
Безопасность инфраструктуры без дорогих лицензий:
что умеет, как устроено и как это ложится на наши процессы
По мотивам доклада Юрия Медведева «Wazuh как DevSecOps-платформа» (DevOops 2022) · факты обновлены под ветку 4.x

2.

С чего всё начинается
Построение безопасности внутри компании обычно упирается в три варианта
Позвать интегратора
Купить платформу
Оставить как есть
Быстро, но дорого и не наше. Экспертиза
уходит вместе с подрядчиком, каждое
изменение — новый счёт и новый срок.
Коммерческие SIEM берут деньги за объём:
EPS, гигабайты, число хостов. Растёт
инфраструктура — растёт счёт.
«У нас же есть логи» — но они лежат по
хостам, никто не коррелирует, никто не
смотрит. Инцидент находят постфактум.
→ дорого и зависимо
→ растущий чек
→ слепые зоны
Четвёртый вариант: open source платформа + наши руки
Wazuh закрывает большую часть задач SIEM/XDR бесплатно и без потолка по объёму. Платим не деньгами, а временем инженера на
настройку — зато экспертиза и данные остаются внутри команды.
2

3.

Что такое Wazuh за одну минуту
Открытая платформа: обнаружение угроз, мониторинг, реагирование и соответствие требованиям
Prevention
Detection & Response
Security Analytics
Threat Intelligence
Предотвращение
Детект и реакция
Аналитика
Обогащение
Харднинг по стандартам, контроль
конфигураций, инвентарь софта и
поиск уязвимых версий до того, как
их найдут другие.
Правила корреляции по потоку
событий и автоматические
контрмеры: заблокировать, убить,
откатить.
Сбор, агрегация и анализ данных
безопасности со всего парка в
одном месте с полнотекстовым
поиском.
Сверка индикаторов с внешними
базами и маппинг на MITRE
ATT&CK: не «алерт», а «техника
атаки».
Главное для нас: это не «ещё один сборщик логов». Агент на хосте одновременно смотрит за файлами, конфигурацией, уязвимостями и
процессами — и умеет выполнять команды в ответ. Один агент вместо четырёх разных инструментов.
3

4.

Часть 1. Что умеет платформа
Девять возможностей из доклада. По каждой: что делает · зачем нам · живой пример
1
Аналитика безопасности
4
Контроль целостности файлов
7
Реагирование на инциденты
2
Обнаружение вторжений (IDS)
5
Поиск уязвимостей
8
Соответствие стандартам
3
Анализ логов
6
Аудит конфигураций
9
Облака и контейнеры
4

5.

Аналитика безопасности
1/9
Сбор, агрегация и анализ данных со всего парка — фундамент, на котором стоит всё остальное
Что делает
Собирает — события со всех агентов в единый поток: логи, изменения файлов, результаты сканов,
инвентарь.
Приводит к общему виду — декодеры раскладывают разнородные строки в одинаковые поля —
sshd, nginx, Windows и облако становятся сравнимы.
Коррелирует — правила видят не одиночное событие, а последовательность: 8 неудачных логинов
за 2 минуты — это уже брутфорс, а не 8 записей.
Хранит и ищет — всё складывается в индекс с полнотекстовым поиском: любой срез по хосту, IP,
пользователю за секунды.
Зачем это нам
Один поиск вместо ssh на десять машин при разборе
инцидента
Долгий срок хранения: можно вернуться к событиям
месячной давности
Общая картина парка вместо разрозненных логов
Как это выглядит
rule.level >= 10
and agent.name: web-*
and data.srcip: 10.0.0.5
Если запомнить одно
Ценность не в том, что логи собраны, а в том, что они приведены к общему
виду и связаны правилами между собой.
→ все критичные события с этого IP
по всем веб-серверам за период
5

6.

Обнаружение вторжений
2/9
Агент ищет на хосте то, что злоумышленник обычно прячет
Что делает
Руткиты и малварь — проверка по сигнатурам известных руткитов: подменённые бинари,
характерные файлы и каталоги.
Скрытые процессы — сравнивает то, что показывает система, с тем, что видно напрямую через
системные вызовы — расхождение и есть маскировка.
Скрытые файлы — то же для файловой системы: файл не виден обычным способом, но существует
на диске.
Незарегистрированные порты — кто-то слушает сеть, но в списке служб его нет — классический
признак бэкдора.
Аномалии системных вызовов — подозрительное поведение на уровне ядра и прав: неожиданный
setuid, странные права на критичных файлах.
Зачем это нам
Это то, чего не покажут метрики и обычные логи
Работает на каждом хосте сам, без отдельного сканера
Дешёвая страховка: модуль уже стоит вместе с агентом
Живой сценарий
На стенде кто-то оставил майнер с маскировкой процесса.
Метрики покажут только «CPU 100%» — и всё.
Если запомнить одно
Wazuh даст алерт «hidden process detected» с PID и путём —
сразу понятно, что это не наша нагрузка.
Это не антивирус: модуль ищет не сигнатуры вирусов, а признаки того, что
кто-то на хосте прячется.
6

7.

Анализ логов
3/9
Агент читает логи ОС и приложений, сервер разбирает их правилами
Что делает
Читает откуда угодно — файлы, journald, Windows EventChannel, вывод команд, JSON-логи
приложений и Docker.
Понимает формат — сотни готовых декодеров: sshd, sudo, nginx, БД, файрволы. JSON раскладывается
сам, без написания regex.
Ищет проблемы правилами — ошибки приложений, кривые конфигурации, попытки атак,
нарушения политик — тысячи правил из коробки.
Учится вашим логам — для самописного сервиса пишется свой декодер и правила — обычно это
работа на час.
Зачем это нам
Логи приложений и логи безопасности живут в одном
месте
Алерт про «5xx лавиной с одного IP» — это тоже правило
Wazuh
Не нужен отдельный экспортер под каждый сервис
Правило корреляции
<rule id="100100" level="10"
frequency="8" timeframe="120">
<if_matched_sid>31101</if_matched_sid>
Если запомнить одно
<same_source_ip />
Правило под наш сервис — это 5–7 строк XML. А если писать логи в JSON,
поля разберутся сами, без единой строки regex.
<description>Волна 5xx
с одного IP</description>
</rule>
7

8.

Контроль целостности файлов
4/9
Отслеживание изменений файловой системы в реальном времени
Что делает
Следит за содержимым — хранит хэш-подписи файлов и сравнивает при каждой проверке —
изменение видно даже при сохранённой дате.
Следит за атрибутами — права, владелец, размер, время изменения — отдельно от содержимого.
Три режима — плановый скан (раз в 12 часов), realtime (мгновенно, через inotify), whodata (плюс имя
пользователя и процесса).
Показывает разницу — для текстовых файлов хранит diff: видно не только «изменён», но и что
именно поменялось.
Зачем это нам
Ответ на «кто поменял конфиг на проде в три часа ночи»
Сверка с change management: незапланированное
изменение видно сразу
Требование почти любого регламента по ИБ
Что в событии
syscheck.path: /etc/nginx/nginx.conf
syscheck.event: modified
md5_before → md5_after
Если запомнить одно
audit.user.name: deploy
Мгновенный режим включаем точечно на критичные каталоги. Вешать его
на логи нельзя — зашумит и съест ресурсы.
audit.process.name: /usr/bin/vim
8

9.

Поиск уязвимостей
5/9
Сверка установленного софта с базами CVE — без сетевого сканирования
Что делает
Знает, что установлено — агент собирает инвентарь пакетов с версиями и отправляет на сервер.
Сверяет с базой — сервер сопоставляет «пакет + версия» с фидами уязвимостей (NVD и базы
вендоров), которые обновляются автоматически.
Показывает срез — по каждому хосту — список CVE с уровнем критичности; по каждой CVE — список
затронутых хостов.
Закрывает сам — обновили пакет — запись уходит при следующем пересчёте. Отдельно чистить
ничего не надо.
Зачем это нам
Нет нагрузки на хосты: сканер по сети не нужен
«Где ещё стоит уязвимая версия?» — ответ за секунды по
всему парку
Готовый бэклог на патчинг с приоритетами
Реальный кейс
Выходит громкая CVE в популярной библиотеке.
Обычно: обзвон команд и ручная инвентаризация на день.
Если запомнить одно
С Wazuh: фильтр по имени пакета → точный список хостов и
версий за минуту.
Мы не сканируем сеть в поисках дыр — мы точно знаем, что установлено, и
сверяем это с базой известных уязвимостей.
9

10.

Аудит конфигураций
6/9
Регулярная проверка настроек систем на соответствие стандартам харднинга
Что делает
Проверяет по чек-листу — готовые политики CIS Benchmark под каждую ОС: парольные политики,
права на файлы, настройки sshd, ядра, docker.
Даёт оценку — по каждому хосту процент пройденных проверок — измеримая метрика состояния
харднинга.
Объясняет и учит чинить — у каждой проваленной проверки есть описание, обоснование и готовые
команды исправления.
Принимает свои правила — к стандартным политикам добавляются свои — под внутренние
требования компании.
Зачем это нам
Дрейф конфигураций виден до того, как станет
инцидентом
Score можно поставить целью спринта и измерять
прогресс
Готовый ответ аудитору «как вы контролируете
харднинг»
Как выглядит проверка
Failed: SSH разрешает вход root по паролю
Rationale: даёт прямой путь для перебора
Если запомнить одно
Remediation: PermitRootLogin no в sshd_config + перезапуск
службы
Сто процентов — не цель. Часть проверок мы осознанно отклоняем и
фиксируем как принятый риск, остальное чиним.
10

11.

Реагирование на инциденты
7/9
Готовые контрмеры, которые применяются автоматически по срабатыванию правила
Что делает
Блокирует — готовые сценарии: заблокировать IP на файрволе, отключить учётную запись,
завершить процесс, перезапустить службу.
Откатывает сам — у действия есть таймаут: заблокировали на 10 минут и автоматически
разблокировали — без ручного разбана.
Эскалирует рецидивистов — повторный нарушитель получает всё более длинную блокировку: 5 →
10 → 60 минут.
Выполняет что угодно — свой сценарий — это обычный скрипт: снять ноду из балансировки, создать
тикет, дёрнуть внутренний API.
Ищет следы компрометации — проверка индикаторов (IOC): хэши файлов и адреса сверяются с
внешними базами — VirusTotal, MISP.
Зачем это нам
Реакция за секунды там, где дежурный доедет за полчаса
Рутинные ответы на атаки перестают требовать человека
Порог входа низкий: сначала включаем только
уведомления
Осторожно на проде
Автоблокировка на шумном правиле однажды забанит своего
же.
Если запомнить одно
Из коробки система только предупреждает. Всё, что делает что-то само,
включаем мы — точечно и после проверки на ложные срабатывания.
Практика: две недели только алерты → разбор ложных →
включаем блокировку на точные правила, с таймаутом и
белым списком.
11

12.

Соответствие стандартам
8/9
Каждое правило размечено тегами требований — отчёты собираются сами
Что делает
Поддерживает основные стандарты — PCI DSS, GDPR, NIST 800-53, HIPAA, TSC (SOC 2), GPG13 — по
каждому свой раздел и дашборд.
Связывает события с требованиями — один инцидент автоматически попадает во все применимые
стандарты — раскладывать вручную не нужно.
Выгружает отчёт — PDF по выбранному периоду и фильтрам одной кнопкой; можно ограничить
нужным контуром.
Расширяется — внутренний стандарт компании размечается своими тегами — и получает такой же
дашборд и отчёт.
Зачем это нам
Подготовка к аудиту — выгрузка, а не месяц ручной
работы
Понятный язык для разговора с ИБ и аудиторами
Работает даже если формального аудита нет: полезный
чек-лист
Нюанс
Своё правило без тега стандарта в отчёт не попадёт.
Закрыли контроль кастомным правилом — сразу добавьте тег,
иначе аудитор его просто не увидит.
Если запомнить одно
Отчёт собирается из тегов правил. Закрыли требование своим правилом —
сразу проставьте тег, иначе в отчёте его не будет.
12

13.

Облака и контейнеры
9/9
Отдельные модули собирают события там, где агента поставить некуда
Что делает
Облачные API — модули (wodles) ходят в API провайдера и забирают журналы: AWS CloudTrail и
GuardDuty, Azure, Google Cloud, Microsoft 365, GitHub.
Yandex Cloud — интеграция с Audit Trails: журналы выгружаются в Object Storage, оттуда их читает
отдельный модуль (в докладе — авторская разработка, сейчас есть в примерах Yandex Cloud).
Docker — слушает события демона: запуск и остановка контейнеров, exec внутрь, изменения
образов, сетей и томов.
Kubernetes — агенты ставятся DaemonSet'ом, отдельно собираются audit-логи API-сервера — видно,
кто и что делал в кластере.
Общий конвейер — облачные события проходят через те же декодеры и правила, что и события с
хостов — один язык и одни дашборды.
Зачем это нам
Действия в облачной консоли видны наравне с
действиями на серверах
kubectl exec в прод-под становится событием, а не
тайной
Не нужен отдельный инструмент под каждое облако
Что ловим
Создан ключ доступа с широкими правами
Открыт доступ к бакету наружу
Если запомнить одно
Облачные события проходят тот же путь, что и логи серверов: одни
декодеры, одни правила, один дашборд.
Удалена группа безопасности
Вход в консоль из незнакомой страны
13

14.

Часть 2. Как это устроено
Компоненты, модули агента, связь и путь события — без этого не понять, что чинить, когда сломается
1
Три компонента: агент, сервер, хранилище с интерфейсом
2
Где ставится агент и какие ОС поддерживаются
3
Модули агента: кто именно и что собирает
4
Связь агент ↔ сервер: порты, шифрование, буфер
5
Путь события от строки лога до дашборда
14

15.

Три компонента
Агент собирает → сервер думает → хранилище и интерфейс показывают
Wazuh Agent
Wazuh Server
Indexer + Dashboard
на каждом хосте
мозг системы
память и лицо
Ставится на серверы, ВМ, рабочие
станции, облачные инстансы
Разбирает события декодерами и
проверяет правилами
Хранит алерты и события, ищет по ним за
секунды
Собирает логи, следит за файлами,
сканирует конфигурации
Рождает алерты и запускает контрмеры
Управляет агентами и раздаёт им
конфигурацию
Веб-интерфейс: дашборды, поиск,
управление, отчёты
Держит тысячи агентов, масштабируется в
кластер
В докладе 2022 это был Elastic Stack
(Elasticsearch + Kibana)
Сейчас — собственные форки OpenSearch
в составе Wazuh
Ничего не решает сам — отправляет
данные серверу
Занимает около 30 МБ памяти
Что изменилось после доклада: начиная с версии 4.3 Wazuh поставляется со своими Wazuh Indexer и Wazuh Dashboard (форки OpenSearch)
вместо Elastic Stack. Интеграция с Elastic осталась опцией, но по умолчанию ставится всё своё — лицензионных вопросов нет.
15

16.

Куда ставится агент
Один инструмент на весь зоопарк — включая то, что обычно выпадает из мониторинга
Linux
Windows
macOS
Solaris
AIX
HP-UX
FreeBSD
Сетевое оборудование без агента
Облачные сервисы без агента
Контейнеры и кластеры
Свитчи, роутеры, файрволы шлют syslog на
сервер напрямую. Конфигурации сетевых
устройств можно проверять по SSH — агент на
них не нужен.
Управляемые базы, объектные хранилища, сама
облачная консоль — события забираются через
API провайдера отдельными модулями.
Агент видит процессы и порты контейнеров с
хоста, плюс отдельный модуль слушает события
Docker. В Kubernetes — DaemonSet и audit-логи
API-сервера.
Практический вывод: белых пятен почти не остаётся — legacy-серверы, сетевое железо и облако попадают в одну картину вместе с современными
хостами.
16

17.

Из чего состоит агент
Модульная архитектура: каждый модуль включается и настраивается отдельно
Log Collector
Command Execution
Читает логи ОС и приложений: файлы, journald, Windows-события,
JSON и Docker-формат.
Запускает команды по расписанию и отдаёт вывод как событие:
свободное место, состояние дисков, сроки сертификатов.
File Integrity Monitoring
Security Configuration Assessment
Следит за файлами: хранит подписи и состояние, ловит изменения
атрибутов в реальном времени.
Проверяет настройки системы и сравнивает их со стандартами CIS,
считает оценку харднинга.
Syscollector
Active Response
Инвентарь: пакеты, процессы, открытые порты, сетевые интерфейсы,
железо. Основа для поиска уязвимостей.
Выполняет команды реагирования, которые прислал сервер, и ведёт
журнал того, что было выполнено.
Настройка централизованная: конфигурация задаётся для группы агентов на сервере и сама доезжает до всех хостов группы. Локально на хосте
править ничего не нужно.
17

18.

Как агент общается с сервером
Одно постоянное соединение, всё шифруется, потери событий защищены буфером
Регистрация — порт 1515
события · TCP 1514
Агент
Сервер
на хосте
менеджер
При установке агент сам получает ключ и
появляется в списке.
конфиг · команды
Всё шифруется
Канал агент → сервер закрыт шифрованием и сжат, ключ у каждого
агента свой. Соединение инициирует агент — входящих портов на
хосте не появляется.
Постоянный пульс
Агент регулярно отмечается на сервере. Замолчал дольше порога — в
интерфейсе он «отключён», и на это можно повесить уведомление.
Буфер от потерь
Конфиг едет сверху
Оборвалась сеть — события копятся локально и досылаются после
восстановления. Есть защита от переполнения очереди при всплеске.
По тому же каналу сервер раздаёт настройки группам агентов,
перезапускает их и обновляет версию — без похода по хостам.
Для сетевиков коротко: с хостов наружу нужен только порт 1514 до менеджера (и 1515 в момент регистрации). Всё остальное — исходящие соединения.
18

19.

Путь события: от строки лога до дашборда
1
2
3
4
5
На хосте появилось
событие: строка лога,
изменение файла,
результат скана
Агент отправил его
на сервер
по защищённому
каналу
Сервер разобрал
декодером на поля
и проверил
правилами
Правило сработало →
родился алерт;
отправщик положил
его в хранилище
Интерфейс читает
хранилище: дашборды,
поиск, отчёты,
уведомления
Важно понимать
Где искать поломку
В хранилище по умолчанию попадают только алерты — то есть
события, на которые сработало правило. Остальной поток
отбрасывается. Хранить всё подряд можно, но это отдельная
настройка и заметно больше диска.
Нет событий с хоста — смотрим агент и сеть. Событий нет ни от
кого — смотрим сервер. Алерты есть в файле, но не видны в
интерфейсе — виноват отправщик или хранилище.
19

20.

Данные не заперты внутри
Wazuh отдаёт события туда, где команда уже работает
Дежурному в мессенджер
Таск-трекеры
Grafana
Slack, Telegram, PagerDuty и любой webhook.
Фильтр по важности: дежурного будим только
критичным, остальное копится в интерфейсе.
Jira и ServiceNow: алерт превращается в задачу с
описанием и хостом. Уязвимости и провалы
аудита ложатся в бэклог автоматически.
Хранилище подключается как источник данных:
панели с событиями безопасности встают
рядом с привычными метриками сервисов.
Внешние базы угроз
Свои скрипты и API
Другие системы сбора
VirusTotal, MISP и подобные: хэши новых
файлов и адреса проверяются автоматически,
совпадение поднимает важность алерта.
Есть REST API для управления и прямой доступ к
хранилищу запросами — от простого curl в
кроне до полноценной интеграции.
Поток алертов можно переслать в syslog, Splunk,
Elastic или корпоративное хранилище — Wazuh
не требует жить только в своём интерфейсе.
Это ключевой довод против «ещё одна вкладка, куда никто не ходит»: сигналы приходят в наши текущие инструменты сами.
20

21.

Почему это «DevSecOps-платформа», а не просто SIEM
Инструмент живёт в нашем цикле разработки и эксплуатации, а не в отдельном кабинете безопасника
Сборка
Инвентарь пакетов и поиск
уязвимых версий работает и на
образах, из которых мы собираем
окружение. Проблема видна до
выката, а не после.
Развёртывание
Агент кладётся в базовый образ и в
плейбуки. Новая машина или под
появляются в мониторинге сами,
без ручной заявки.
Работа
Реакция
На проде: изменения файлов,
дрейф конфигураций, новые
уязвимости, подозрительные
действия в облаке и кластере.
Автоматические контрмеры плюс
задача в трекере и сигнал
дежурному. Инцидент попадает в
наш обычный процесс.
Правила — это код
Общий инструмент, а не чужой
Правила и настройки — обычные текстовые файлы. Они лежат в
git, проходят ревью и раскатываются через CI, как любой наш
конфиг. Есть встроенный отладчик: подаём строку лога и видим,
что система о ней подумала.
Разработчику — почему упал сервис и что менялось в
конфиге. Эксплуатации — состояние парка и инвентарь.
Безопасности — инциденты и отчётность. Данные одни,
взгляды разные.
21

22.

Пример расширения: события Yandex Cloud
Готового модуля в поставке нет — и это нормально: платформа достраивается под свою среду
Audit Trails
пишет журнал
действий в облаке
Журнал выгружается
в Object Storage
(S3-совместимое)
Модуль Wazuh
забирает файлы
из бакета
Свои правила
разбирают события
и дают алерты
Что это даёт
Главный вывод для нас
Действия в облачной консоли попадают в общий поток: создание
ключей и прав, изменение сетевых правил, удаление ресурсов, вход
из необычного места. Разбирается теми же правилами и видно на тех
же дашбордах, что и события с серверов.
Нет модуля под нужный сервис — он пишется. Решение из
доклада сейчас лежит в публичных примерах Yandex Cloud
вместе с разворачиванием инфраструктуры. Тот же подход
применим к любому нашему внутреннему сервису.
Репозиторий: github.com/yandex-cloud-examples/yc-export-auditlogs-to-wazuh — разворачивание Wazuh в Yandex Cloud и интеграция с Audit Trails
22

23.

Что изменилось со времени доклада
Докладу несколько лет — часть деталей устарела, суть осталась
Тема
Было в докладе (2022)
Сейчас
Хранилище и интерфейс
Elastic Stack: Elasticsearch и Kibana отдельными продуктами
Свои Wazuh Indexer и Wazuh Dashboard в поставке; Elastic — опция
Поиск уязвимостей
Периодические сканы и отдельная база на сервере
Пересчёт по событию: изменился инвентарь или фид — обновилась
картина
Интерфейс
Модули общим списком
Разделы: Endpoint security, Threat intelligence, Security operations,
Server management
Yandex Cloud
Авторская разработка, показанная в демо
Лежит в публичных примерах Yandex Cloud вместе с деплоем
Версия
Ветка 4.3
Ветка 4.14 (2026), релизы каждые один-два месяца
Что не изменилось: архитектура из трёх компонентов, модульный агент, движок декодеров и правил, набор возможностей и сам
подход. Всё, о чём говорит доклад по сути, актуально — расходятся только названия компонентов хранилища и расположение
пунктов меню.
23

24.

Часть 3. Демо
Смотрим живой стенд — всё, о чём говорили, на реальных данных
1
Главный экран: сколько машин на связи, где всплеск алертов
5
Уязвимости: список CVE по хосту и обратный срез по CVE
2
Список агентов и инвентарь одного хоста: пакеты, процессы, порты
6
Аудит конфигураций: проваленная проверка и готовый рецепт
фикса
3
Поиск по событиям: раскручиваем инцидент от алерта к цепочке
7
Отладчик правил: подаём строку лога и видим вердикт системы
4
Меняем файл на хосте — смотрим событие с деталями «кто и что»
8
Отчёт по стандарту в PDF одной кнопкой
Если демо сорвётся: все эти экраны есть в записи доклада — ссылку пришлю вместе со слайдами.
24

25.

Честно: во что мы вложимся и где подводные камни
Чтобы через месяц не было сюрпризов
Первые недели шумно
Из коробки много срабатываний под нашу
специфику. Нужен тюнинг: глушим известный
шум, иначе команда перестанет читать алерты.
Это разовая работа на несколько дней.
Настройка не мгновенная
Поднять стенд — вечер. Довести до состояния
«сигналы полезны и им доверяют» — недели.
Экономим на лицензиях, тратим время
инженера.
Хранилище ест диск
Объём растёт с числом хостов и глубиной
хранения. Планируем ретеншен заранее: сколько
дней держим и что удаляем автоматически.
Не всё видно
Ловим то, что оставляет след в логах, файлах и
конфигурациях. Сетевые атаки без следов на
хостах — задача других инструментов.
Нужен хозяин
У инструмента должен быть владелец, иначе он
тихо умрёт. Это не полная ставка, но регулярное
внимание: правила, обновления, разбор алертов.
Не замена EDR
Контроль файлов, поиск руткитов и проверка
индикаторов закрывают многое, но
полноценного поведенческого анализа уровня
коммерческого EDR здесь нет.
Ни один из пунктов не является блокером — но лучше сказать о них сейчас, чем услышать в виде претензии через месяц.
25

26.

Итоги и предложение
Wazuh закрывает сразу несколько задач — логи, целостность файлов, уязвимости, аудит конфигураций и реагирование — одним
агентом и без платы за объём.
Это инструмент нашего цикла, а не отдельного кабинета: правила лежат в git, сигналы приходят в трекер и мессенджер, данные
доступны в Grafana.
Плата — время инженера на тюнинг и владельца у инструмента. Взамен экспертиза и данные остаются внутри команды.
Что предлагаю сделать
1
Поднять стенд одной машиной
и поставить агентов
на 5–10 некритичных хостов
2
Две недели наблюдаем
без автоматических действий,
разбираем шум
3
Показываем команде
реальные данные и решаем,
разворачиваем ли дальше
Вопросы? · Доклад: Юрий Медведев, «Wazuh как DevSecOps-платформа», DevOops 2022 · documentation.wazuh.com
26