Привет! Меня зовут Лиза — я аналитик по информационной безопасности в направлении внедрения Naumen Contact Center. В Naumen я работаю около трех лет.
Лиза Степанова
Аналитик по информационной безопасности в направлении внедрения NCC
Когда пришла в команду, аналитиков по ИБ не было: задачи закрывали другие специалисты, а процесс только начинал выстраиваться. Пришлось учиться на практике, как анализировать требования, договариваться с заказчиками, внедрять решения. Сейчас в команде нас уже двое, мы постепенно растем и развиваемся вместе с другими участниками проектов — системными аналитиками, инженерами, архитекторами.
Одна из важных задач, с которой мне постоянно приходится сталкиваться — проработка решений по регистрации событий информационной безопасности и интеграция с SIEM‑системами заказчика. В этой статье мой личный опыт с примерами реальных кейсов и нормативных документов, с которыми сталкиваюсь.
Почему регистрация событий ИБ — это вызов
Событие ИБ — состояние системы, указывающее на важное с точки зрения безопасности действие, например, нарушение политики ИБ или сбой.
Звучит просто, но в реальности возникает множество проблем:
Расплывчатые формулировки. В требованиях часто встречаются общие описания: «иные действия пользователей», «события, связанные с безопасностью». Это касается не только функциональных, но и нефункциональных требований.
Высокие риски. Невыполнение требований ИБ блокирует весь проект. Если что‑то не соответствует, заказчик просто не примет работу.
Нет универсальной базы. Нормативные документы не дают однозначной и полной картины. У заказчика обычно есть свои внутренние требования, которые приходится отдельно уточнять и прорабатывать, да и функционал самого программного продукта существенно разнится на каждой конкретной инсталляции.
Откуда берутся требования
Работая во внедрении, я сталкиваюсь с разными источниками требований:
Персональные данные. Почти в каждой системе они так или иначе обрабатываются. Приказ ФСТЭК № 21 перечисляет меры безопасности для защиты персональных данных, в том числе раздел о регистрации событий безопасности.
Документы регуляторов. Там перечислены требования к инцидентам безопасности, формированию и составу событий. Все расписано подробно, но на практике часто эти положения трудно применять буквально.
Финансовые организации. При работе с банками приходится учитывать отдельные документы, связанные с защитой их информационных систем.
Внутренние документы. Локальные требования организации как правило, предназначены только для внутреннего использования, к ним не всегда есть доступ: в требованиях мы видим, например, ссылку «согласно пункту 5.3», а что именно внутри — выясняем отдельно и просим предоставить хотя бы часть.
Особые режимы. Для объектов КИИ и государственных информационных систем действуют отдельные требования. Их приходится учитывать уже на этапе пресейла, чтобы потом не «вскрылись» неожиданные обязательства.
Вывод один: нормативных документов много, информации тоже, но конкретики почти нет. Все нужно самостоятельно «раскапывать» и фиксировать договоренности вручную.
Как я делю требования по событиям ИБ
Чтобы эффективно работать с массивом документов, я условно делю требования на четыре группы.
1. Общие требования
Сюда относится срок хранения архивов журналов и перечень источников событий.
Для финансовых операций — хранение 5 лет.
Для иных событий ИБ — хранение 3 года.
События собираются со всех уровней системы: не только из нашего ПО, но и с серверов, вспомогательного ПО, СУБД, сетевого оборудования и так далее.
2. Общий перечень событий
Базовые списки в нормативке включают:
аутентификация и авторизация, в том числе неуспешная;
действия пользователей;
действия, связанные с управлением правами доступа;
изменение аутентификационных данных;
управление учетными записями;
запуск программных процессов;
установка и удаление ПО;
вывод информации на печать;
очистка журнала ИБ.
Самая опасная формулировка — «иные действия пользователей». Это значит, что заказчик вправе ожидать что угодно.
Моя тактика: фиксирую перечень событий, показываю демо возможностей системы и добиваюсь согласования, чтобы исключить разночтения.
❌ Плохая формулировка
«Регистрация событий защиты информации, связанных с действиями и контроль действий эксплуатационного персонала, обладающего привилегированными правами логического доступа и правами по управлению логическим доступом».
Непонятно, какие действия, какой состав, для каких пользователей.
✅ Хорошая формулировка
«Создание, модификация и удаление привилегий (все параметры, на базе которых осуществляется определение полномочий пользователя в информационном ресурсе — например, ролей, групп, меню доступа и так далее)».
Требование предметное и проверяемое.
3. Состав полей событий безопасности
Каждое событие должно содержать набор атрибутов: идентификатор события, дату и время, результат выполнения действия, логин и ip‑адрес пользователя, идентификаторы объекта или ресурс доступа. И снова встречается размытая формулировка «другие данные, позволяющие однозначно и полно идентифицировать событие».
Здесь помогает поставить себя на место специалиста SOC: если прилетит инцидент, что именно должно быть в логе, чтобы понять, что пошло не так, и расследовать инцидент дальше?
❌ Плохая формулировка
«Регистрируемые события должны содержать следующие атрибуты: ip/dns субъекта доступа; время; id/login/имя субъекта доступа; id/имя объекта доступа; вход/выход субъекта/неуспешные попытки входа; результат воздействия (access/deny/read/write/update/upgrade/ delete)».
В одном пункте перемешаны состав полей и сами события.
✅ Хорошая формулировка
«Для каждого регистрируемого события должны указываться: его тип; идентификационные данные пользователя, инициировавшего регистрируемое событие; успешность или не успешность осуществляемых действий; дата и время события; другие данные, достаточные для однозначной интерпретации события».
4. Мониторинг (просмотр, анализ) результатов регистрации событий безопасности и их передача в SIEM-систему
Формально это классическая проработка интеграции, но и здесь хватает проблем:
неподдерживаемые протоколы и способы передачи: например, события лежат в базе данных, а SIEM‑система не имеет коннекторов для работы с ней;
особые требования к формату полей и событий;
другие особые требования.
❌ Плохая формулировка
«Подсистема ведения журнала должна иметь возможность направления событий в систему сбора событий безопасности (например, по протоколу syslog)».
Слово «например» оставляет слишком много вопросов.
✅ Хорошая формулировка
«Должен поддерживаться экспорт журналов аудита в syslog. (Журналы общесистемного ПО (ОС, СУБД и др.) могут предоставляться в исходном виде в соответствии с документацией на соответствующее ПО)».
Какие способы реализации в ППО для построения удачной системы сбора событий ИБ существуют
На уровне продукта встречаются разные способы: просмотр в интерфейсе, отправка через syslog, хранение (БД, файловое хранилище или вовсе «не хранить у себя»), передача (syslog/БД/API/брокеры сообщений/коллекторы/ агенты и др.).
Кейc: регистрация и передача событий ИБ на крупном проекте
В одном из больших внедрений мы столкнулись со следующими вызовами:
сложная архитектура — до 10 подсистем, несколько видов СУБД, общесистемное ПО, контейнеризация, аппаратные устройства;
нет единого формата данных и состава событий;
нет готового инструмента для сбора и анализа;
нет четких требований к составу событий;
хранение событий безопасности — 3 года.
Что мы сделали:
разработали децентрализованную схему — на каждом сервере настроили сбор событий для отказоустойчивости;
на каждом сервере через syslog настроили отправку логов на сервер ИБ, откуда они поступали в SIEM;
хранение логов реализовывалось средствами заказчика, поэтому дополнительно закладывать место на своих серверах не потребовалось;
использовали лог‑парсер для приведения логов к единому формату.
Результат:
единый общий состав событий для всех источников;
возможность кастомизировать отдельные события при помощи парсера;
единый атрибутивный состав;
единая схема отправки через syslog;
децентрализация;
проработка на всех уровнях всех типов источников.
Что я вынесла из практики
Требования в ТЗ — это только часть картины. Всегда нужно копать глубже.
Требования меняются по ходу проекта и это нормально.
Важно фиксировать все договоренности письменно — ограничивать и четко определять с заказчиком скоуп работ.
Ориентироваться не только на общие нормативные документы, но и на локальные, запрашивать их у заказчика.
Сразу думать о SIEM‑интеграции, чтобы не пришлось переделывать позже.
Нужно заранее договариваться, кто хранит логи и сколько.