Регистрация событий ИБ без боли: опыт аналитика Naumen Contact Center

Лиза — аналитик по информационной безопасности в Naumen Contact Center. В своей работе она сталкивается с требованиями, которые часто сформулированы расплывчато и без конкретики. Но именно от них зависит успешное внедрение проекта.

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

Почему регистрация событий ИБ — это вызов

• Расплывчатые формулировки. В требованиях часто встречаются общие описания: «иные действия пользователей», «события, связанные с безопасностью». Это касается не только функциональных, но и нефункциональных требований.
  
• Высокие риски. Невыполнение требований ИБ блокирует весь проект. Если что‑то не соответствует, заказчик просто не примет работу.
  
• Нет универсальной базы. Нормативные документы не дают однозначной и полной картины. У заказчика обычно есть свои внутренние требования, которые приходится отдельно уточнять и прорабатывать, да и функционал самого программного продукта существенно разнится на каждой конкретной инсталляции.
  

Откуда берутся требования

Работая во внедрении, я сталкиваюсь с разными источниками требований:

• Персональные данные. Почти в каждой системе они так или иначе обрабатываются. Приказ ФСТЭК № 21 перечисляет меры безопасности для защиты персональных данных, в том числе раздел о регистрации событий безопасности.
  

• Документы регуляторов. Там перечислены требования к инцидентам безопасности, формированию и составу событий. Все расписано подробно, но на практике часто эти положения трудно применять буквально.
  

• Финансовые организации. При работе с банками приходится учитывать отдельные документы, связанные с защитой их информационных систем. 
• Внутренние документы. Локальные требования организации как правило, предназначены только для внутреннего использования, к ним не всегда есть доступ: в требованиях мы видим, например, ссылку «согласно пункту 5.3», а что именно внутри — выясняем отдельно и просим предоставить хотя бы часть.
• Особые режимы. Для объектов КИИ и государственных информационных систем действуют отдельные требования. Их приходится учитывать уже на этапе пресейла, чтобы потом не «вскрылись» неожиданные обязательства. 

Вывод один: нормативных документов много, информации тоже, но конкретики почти нет. Все нужно самостоятельно «раскапывать» и фиксировать договоренности вручную.

Как я делю требования по событиям ИБ

Общие требования

Сюда относится срок хранения архивов журналов и перечень источников событий.

• Для финансовых операций — хранение 5 лет.
  
• Для иных событий ИБ — хранение 3 года.

События собираются со всех уровней системы: не только из нашего ПО, но и с серверов, вспомогательного ПО, СУБД, сетевого оборудования и так далее.

Общий перечень событий

Базовые списки в нормативке включают: 

• аутентификация и авторизация, в том числе неуспешная;

• действия пользователей;

• действия, связанные с управлением правами доступа;

• изменение аутентификационных данных;

• управление учетными записями;

• запуск программных процессов;

• установка и удаление ПО;

• вывод информации на печать;

• очистка журнала ИБ. 

Самая опасная формулировка — «иные действия пользователей». Это значит, что заказчик вправе ожидать что угодно.

Моя тактика: фиксирую перечень событий, показываю демо возможностей системы и добиваюсь согласования, чтобы исключить разночтения.

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

«Создание, модификация и удаление привилегий (все параметры, на базе которых осуществляется определение полномочий пользователя в информационном ресурсе — например, ролей, групп, меню доступа и так далее)».

Требование предметное и проверяемое.

Состав полей событий безопасности

Каждое событие должно содержать набор атрибутов: идентификатор события, дату и время, результат выполнения действия, логин и ip‑адрес пользователя, идентификаторы объекта или ресурс доступа. И снова встречается размытая формулировка «другие данные, позволяющие однозначно и полно идентифицировать событие». 

Здесь помогает поставить себя на место специалиста SOC: если прилетит инцидент, что именно должно быть в логе, чтобы понять, что пошло не так, и расследовать инцидент дальше?

«Регистрируемые события должны содержать следующие атрибуты: ip/dns субъекта доступа; время; id/login/имя субъекта доступа; id/имя объекта доступа; вход/выход субъекта/неуспешные попытки входа; результат воздействия (access/deny/read/write/update/upgrade/ delete)».

В одном пункте перемешаны состав полей и сами события.

«Для каждого регистрируемого события должны указываться: его тип; идентификационные данные пользователя, инициировавшего регистрируемое событие; успешность или не успешность осуществляемых действий; дата и время события; другие данные, достаточные для однозначной интерпретации события».

Мониторинг (просмотр, анализ) результатов регистрации событий безопасности и их передача в SIEM-систему

Формально это классическая проработка интеграции, но и здесь хватает проблем:

• неподдерживаемые протоколы и способы передачи: например, события лежат в базе данных, а SIEM‑система не имеет коннекторов для работы с ней;

• особые требования к формату полей и событий;

• другие особые требования.

«Подсистема ведения журнала должна иметь возможность направления событий в систему сбора событий безопасности (например, по протоколу syslog)».

Слово «например» оставляет слишком много вопросов.

«Должен поддерживаться экспорт журналов аудита в syslog. (Журналы общесистемного ПО (ОС, СУБД и др.) могут предоставляться в исходном виде в соответствии с документацией на соответствующее ПО)».

Какие способы реализации в ППО для построения удачной системы сбора событий ИБ существуют

Кейc: регистрация и передача событий ИБ на крупном проекте

В одном из больших внедрений мы столкнулись со следующими вызовами:

• сложная архитектура — до 10 подсистем, несколько видов СУБД, общесистемное ПО, контейнеризация, аппаратные устройства;
  
• нет единого формата данных и состава событий;
• нет готового инструмента для сбора и анализа;
• нет четких требований к составу событий;
• хранение событий безопасности — 3 года.

Что мы сделали:

• разработали децентрализованную схему — на каждом сервере настроили сбор событий для отказоустойчивости;

• на каждом сервере через syslog настроили отправку логов на сервер ИБ, откуда они поступали в SIEM;

• хранение логов реализовывалось средствами заказчика, поэтому дополнительно закладывать место на своих серверах не потребовалось;

• использовали лог‑парсер для приведения логов к единому формату.

Результат:

• единый общий состав событий для всех источников;

• возможность кастомизировать отдельные события при помощи парсера;

• единый атрибутивный состав;

• единая схема отправки через syslog;

• децентрализация;

• проработка на всех уровнях всех типов источников.

Что я вынесла из практики

• Требования в ТЗ — это только часть картины. Всегда нужно копать глубже.

• Требования меняются по ходу проекта и это нормально.

• Важно фиксировать все договоренности письменно — ограничивать и четко определять с заказчиком скоуп работ. 

• Ориентироваться не только на общие нормативные документы, но и на локальные, запрашивать их у заказчика.

• Сразу думать о SIEM‑интеграции, чтобы не пришлось переделывать позже.

• Нужно заранее договариваться, кто хранит логи и сколько.