SIEM

Почему одному серверу редко нужен полноценный SIEM

SIEM расшифровывается как Security Information and Event Management (управление информацией и событиями безопасности).

Платформы SIEM созданы для корреляции событий сразу на многих системах, и именно в этом их ценность. Один небольшой VPS, генерирующий скромный объём логов, обычно получает больше пользы от простого, целенаправленного мониторинга логов, чем от полноценного развёртывания SIEM.

Когда он становится ценным

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

Где SIEM занимает место в мониторинге сервера, объясняется здесь: руководство по мониторингу сервера и анализу логов.

Что может сделать небольшой сервер вместо SIEM

Глоссарий NIST со ссылкой на SP 800-92 описывает ПО SIEM как обеспечивающее централизованное ведение журналов для разных типов логов. Суть этой идеи доступна и на одном VPS: храните логи, которые переживут инцидент, и держите копию там, куда злоумышленник не дотянется. Тот, у кого есть root на скомпрометированном хосте, может править и удалять локальные логи, поэтому именно копия вне сервера делает след заслуживающим доверия.

Во-первых, сделайте журнал systemd постоянным. Согласно документации journald.conf, Storage=auto хранит логи на диске только если существует каталог /var/log/journal; иначе они лежат в памяти и пропадают при перезагрузке. Значение по умолчанию задаётся при сборке systemd, поэтому может различаться между версиями и дистрибутивами. Параметр Storage=persistent в /etc/systemd/journald.conf снимает неоднозначность. После этого журнал можно опрашивать напрямую:

journalctl -u ssh --since yesterday -p warning

Юнит называется ssh в Debian и Ubuntu и sshd в семействе RHEL. Во-вторых, пересылайте копию на другую машину. В rsyslog это делает действие omfwd:

action(type="omfwd" target="logs.example.com" port="514" protocol="tcp")

Принимающий хост должен принимать логи только от ваших серверов. В рекомендациях CISA для клиентов управляемых провайдеров предлагается хранить самые важные логи не менее шести месяцев, и это разумный ориентир для планирования объёма. Что искать, когда логи уже собраны, объясняет руководство по мониторингу.

Когда SIEM начинает окупаться

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

Закладывайте в бюджет не только установку, но и эксплуатацию: хранилище для срока хранения, время на написание и настройку правил обнаружения, чтобы они перестали давать шум, и обновление агентов. Существуют открытые решения. Документация Wazuh описывает его как бесплатную платформу с открытым исходным кодом, объединяющую возможности XDR и SIEM и состоящую из индексатора, сервера, панели и единого универсального агента. Любой вариант сначала оцените на тестовом сервере, прежде чем направлять на него рабочую среду.

SIEM дополняет, а не заменяет узкоспециализированные инструменты: fail2ban по-прежнему блокирует перебор, а мониторинг целостности файлов по-прежнему следит за файлами. На странице продукта Server Warden в архитектуре указан экспорт в SIEM, и сказано, что локальный вывод JSON и CEF и основы приёма данных существуют, а живая удалённая доставка зависит от конечных точек и учётных данных клиента, поэтому перед планированием интеграции проверьте актуальный статус там.

Связанные термины: Мониторинг целостности файлов, Реагирование на инциденты, Intrusion prevention, fail2ban, journalctl (просмотр журнала systemd), rsyslog (системный журнал syslog), auditd (аудит Linux).