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

Мы поговорили с Лизой, аналитиком по информационной безопасности, о том, как она работает с этими требованиями и что помогает избежать разночтений с заказчиком.
Почему регистрация событий ИБ — это всегда вызов
Событие ИБ — состояние системы, указывающее на важное с точки зрения безопасности действие, например, нарушение политики ИБ или сбой.
Звучит просто, но в реальности возникает множество проблем:
требования часто сформулированы абстрактно — «иные действия пользователей», «события, связанные с безопасностью»;
невыполнение требований ИБ может заблокировать весь проект;
нет универсальной базы — нормативные документы дают общее направление, а у каждого заказчика есть свои внутренние требования и особенности.
Откуда берутся требования
Во внедрении я сталкиваюсь сразу с несколькими источниками:
требования по защите персональных данных — например, приказ ФСТЭК № 21;
документы регуляторов с описанием инцидентов и состава событий;
отдельные требования финансовых организаций;
внутренние документы заказчика, к которым не всегда есть доступ;
особые режимы — государственные информационные системы, требования, которые важно учитывать еще на этапе пресейла.
Недавно в нормативке появились практические ориентиры. ФСТЭК выпустил рекомендации по базовой настройке регистрации событий безопасности — с примерами настройки логирования в ОС.
Как я структурирую требования по событиям ИБ
Чтобы работать с этим массивом, я условно делю требования на четыре группы.
Общие требования
Сроки хранения архивов журналов, источники событий, уровни системы: от ПО до сетевого оборудования.
Общий перечень событий
Самый опасный пункт — «иные действия пользователей». Моя тактика: фиксировать конкретный список событий, показывать демо и добиваться согласования, чтобы исключить разночтения.
Состав полей события безопасности
Важно понимать не только что регистрируется, но и какие атрибуты попадают в лог. Я всегда ставлю себя на место специалиста SOC: хватит ли этих данных, чтобы расследовать инцидент?
Мониторинг и передача в SIEM-систему
Даже здесь возникают сложности — неподдерживаемые протоколы, требования к формату полей и событий, особенности интеграции. Формулировки должны быть максимально точными.
Что я вынесла из практики
Требования в ТЗ — это только часть картины, всегда нужно копать глубже.
Требования меняются по ходу проекта и это нормально.
Все договоренности важно фиксировать письменно.
Нужно учитывать не только нормативные документы, но и локальные требования заказчика.
Про SIEM-интеграцию стоит думать сразу, чтобы не пришлось переделывать позже.
Важно заранее договориться, кто и сколько хранит логи.
→ Подробнее своим опытом Лиза поделилась в статье.












