Политика журналирования: какие события обязаны писать системы
Зафиксируйте политику журналирования: какие события критичные системы и средства защиты информации (СЗИ) обязаны писать, куда их складывать и сколько хранить. Как довести journald до сервера — другой текст: сбор логов. Сколько дней реально лежит на диске: logrotate и journald. Дошло ли до Wazuh: доставка событий.
Статья опирается на логику направления «Мониторинг кибербезопасности» из методики зрелости Группы Сбер (источник); это методика для крупных компаний, мы используем её как ориентир и пересказываем своими словами. CIS Control 8 требует собирать, смотреть и хранить журналы событий, которые помогут обнаружить инцидент: cisecurity.org/controls. Процесс управления журналами — NIST SP 800-92: SP 800-92. Это не российский закон и не замена 152-ФЗ по срокам персональных данных в логах.
Минимум событий
| Класс | Что писать | Откуда |
|---|---|---|
| Вход | Успех и отказ, привилегированный вход, sudo / Run as | Серверы, jump-хост, контроллер домена, VPN |
| Доступ к данным | Выгрузка базы, смена прав, отказ в доступе администратора | Критичные приложения по CIA |
| Изменение конфигурации | Смена firewall, sudoers, пользователей, DNS | Экраны, auditd, гипервизор |
| Средства защиты | Отключение агента, срыв обновления сигнатур, блокировка | EDR, почтовый фильтр, WAF |
| Копии | Успех, сбой, проверка restore | Система резервного копирования |
Одна страница: таблица выше плюс «куда» (центральный сборщик, не только диск узла) и «сколько» (срок из статьи про ротацию, не новый выдуманный). Не требуйте «все пакеты с ноутбука»: это не политика, а обещание, которое никто не выполнит. Станции пользователей — входы, запуск средств защиты, подключение к VPN.
В логах не должно быть паролей и тел карт. Если приложение пишет тело запроса — это находка политики, не «подробный аудит». Для информационных систем персональных данных (ИСПДн) объём журнала ещё задаёт модель угроз, не эта страница: журналы ИСПДн.
Риск: политика есть, а на хосте по-прежнему только «агент зелёный». Тогда сначала доставка, потом галочка в политике.
Как внедрить без тома на 40 страниц
- Возьмите системы с высокой критичностью, не весь реестр сразу.
- Против каждой строки таблицы поставьте: есть / нет / исключение до даты.
- Исключение «диск маленький» не вечное: либо место, либо внешний сборщик.
- Раз в квартал сверка трёх хостов: событие из таблицы находится на сборщике.
Правила выявления в Wazuh опираются на эти события; без политики вы настраиваете детектор в пустоту: правила Wazuh.
Диагностика
| Симптом | Причина и что делать |
|---|---|
| Политика = «логировать всё» | Не будут. Вернитесь к таблице классов |
| Срок 7 дней на узле | Нет централи. Сборщик + ротация |
| Персональные данные в access.log приложения | Сузьте формат. Это нарушение минимума данных, не зрелость |
| Нет отказов входа | Пишут только success. Включите failure — иначе перебор невидим |
Где это в модели зрелости
Материал относится к направлению «Мониторинг кибербезопасности» (хаб: мониторинг, карта: карта зрелости). Сбор и ротация — трубы. Политика говорит, какая вода должна в них течь. Без неё покрытие хостов считает агентов, а не события входа.
Как проверить
- Есть одностраничная таблица классов событий, систем и сроков.
- По трём критичным системам каждая обязательная строка либо пишется, либо исключена с датой.
- Пароли и карты в выборке логов за неделю не встречаются.
- Документ не заменяет rsyslog, logrotate и пробу Wazuh.
- Отказ входа на jump-хосте находится на сборщике, не только success.
Источники
- CIS Control 8: cisecurity.org/controls.
- NIST SP 800-92: csrc.nist.gov.
