Представьте: понедельник, утро. Критический сервис лежит, база данных пуста, а бэкапы зашифрованы. Отчаянный бросок к консоли и попытки понять. Но в системном журнале — тишина. Или, наоборот, миллионы записей, среди которых невозможно найти следы взлома. Результат: огромный ущерб, виновные не найдены, дыра в защите остается открытой.

Плохих новостей же может быть много. Аудитор просит показать историю входов администратора за прошлый квартал… но ротация логов настроена на 30 дней — сертификат не получен, сделки сорваны, штрафы выписаны. Обиженный сотрудник перед увольнением слил ключи шифрования и почистил за собой следы. Примеры можно продолжать долго.

Там, где управление событиями настроено «для галочки», все эти сценарии повторяются из раза в раз. Что-то сломалось, а кто сломал — неизвестно. И любые права доступа превращаются в фикцию.

Привет, Хабр! Меня зовут Марк, я методолог по ИБ в Selectel. В статье рассказываю, какие события жизненно необходимо отслеживать и как требования регуляторов помогают навести порядок в хаосе системных журналов.

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

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

Источники требований

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

К обязательным требованиям в России относятся, например, приказы ФСТЭК:

  • № 17 — для государственных информационных систем,

  • № 21 — для персональных данных.

В этих документах процесс закреплен в группе мер РСБ — «регистрация событий безопасности».

Среди рекомендательных, но широко используемых стандартов можно отметить международный ISO/IEC 27001:2022. Несмотря на то что он фокусируется на высокоуровневом менеджменте, в пункте А.8.15 прямо указывается на необходимость ведения логов.

Наиболее строгие и детальные требования предъявляются в финансовом секторе, в том числе при обработке данных платежных карт:

  • российский ГОСТ Р 57580.1-2017 — интегрирует правила регистрации событий в каждый процесс защиты информации;

  • международный стандарт индустрии платежных карт PCI DSS 4.0.1 — не только диктует требования по управлению событиями безопасности, но и предоставляет подробные инструкции с наглядными примерами практической реализации.

Анализ этих и других документов позволяет сформулировать универсальные требова��ия к тому, какие именно события необходимо фиксировать, в каком формате вести запись и как безопасно использовать полученные данные.

Security Center

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

Исследовать →

Требования к событиям безопасности

Типы событий

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

  • взаимодействие субъектов с объектами — любые контакты пользователей и сервисов с компонентами системы и данными на всех этапах;

  • сбои и аномалии — любые нетипичные изменения конфигурации или нарушения в работе компонентов, особенно тех, что отвечают за функции защиты.

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

Действия с аккаунтами, паролями, ключами и токенами, в том числе: 

  • создание,

  • чтение, 

  • изменение,

  • блокировка и разблокировка,

  • удаление.

Действия с полномочиями, ролями и разрешениями для работы с файлами, системой в целом и отдельными функциям, в том числе сетевыми соединениями: 

  • создание и выдача, включая добавление в группы;

  • изменение;

  • удаление и отзыв, удаление из групп.

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

  • создание;

  • чтение;

  • запись (в том числе обновление программного обеспечения, которое предполагает изменение исполняемых и конфигурационных файлов);

  • запуск;

  • остановка;

  • удаление;

  • резервное копирование и восстановление;

  • подключение и отключение съемных носителей информации, а также их использование.

Действия, выполняемые с повышенными привилегиями — в дополнение к описанными выше действиям:

  • повышение привилегий,

  • вводимые в терминале команды со всеми параметрами.

Вход в систему — попытки аутентификации сервисов и всех пользователей, даже служебных, — как успешные, так и неудачные, — а также жизненный цикл сессий: 

  • создание и открытие;

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

Запуск, остановка (штатная или аварийная), а также изменение режимов работы программных модулей, механизмов защиты и специализированных средств безопасности, в том числе переключение или смену ролей узлов отказоустойчивого кластера.

Действия, выполняемые средствами безопасности — активность антивирусов, межсетевых экранов, сканеров, инструментов контроля целостности и аналогичных средств: 

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

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

  • обнаружение и блокирование угроз — сетевых атак, вредоносного кода, нарушения целостности и подобных событий.

Некоторые безопасные системные действия могут генерировать огромный поток событий, «зашумляя» логи. Особенно это касается операций чтения. По этой причине рекомендуется настраивать точечные, максимально конкретные исключения.Например, нет смысла фиксировать, как сама подсистема регистрации пишет или читает собственные лог-файлы — обычно такое поведение отключено по умолчанию. Также излишне отслеживать каждое чтение файла модулем контроля целостности.

Кроме того, стоит заранее определить перечень критичных объектов, от которых зависит безопасность системы и обрабатываемых в ней данных. Механизмы аудита нужно настроить так, чтобы детально регистрировать действия именно с этими активами, тогда как события, связанные с другими, менее ценными, объектами, можно записывать в минимальном объеме или игнорировать вовсе.

Состав события

Каждая запись в журнале событий должна содержать набор обязательных атрибутов:

  • дату и время — точную хронологическую метку события с точностью до секунд;

  • источник — имя компонента системы, который зарегистрировал событие;

  • субъект доступа — идентификатор пользователя или процесса, сетевой адрес источника и другие инициаторы активности;

  • объект доступа — имя файла или виртуальной машины, конкретный элемент в базе данных, сетевой адрес назначения и подобные целевые ресурсы;

  • действие — чтение, запись, блокировка, изменение контрольной суммы и прочие операции;

  • результат — успех или ошибка.

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

Особое требование касается работы с аутентификационными данными: паролями, ключами шифрования и токенами. Поскольку эта информация строго конфиденциальна, фиксируется исключительно факт выполнения операции — например, смены пароля. В качестве объекта указывается только его идентификатор — имя переменной, содержащей токен, или файла закрытого ключа. Записывать в лог сами секретные данные категорически запрещено!

Сроки хранения

Сроки хранения логов разделяют на два уровня: оперативный («горячий») и архивный («холодный»).

Оперативный доступ необходим для быстрого поиска и анализа недавних событий. Архивное хранение используется для долгосрочного накопления данных. Доступ здесь значительно медленнее, часто нужна предварительная выгрузка или распаковка массивов.

Конкретная глубина архива зависит от нормативных требований, однако мы рекомендуем ориентироваться на следующие оптимальные значения:

  • не менее трех месяцев — для оперативного доступа,

  • от трех до пяти лет — для архивного хранения.

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

  • Приказы ФСТЭК России № 17 и № 21: сроки хранения оператор устанавливает самостоятельно с учетом того, что они должны обеспечивать возможность обнаружения, идентификации и анализа инцидентов, возникших в системе;

  • ГОСТ Р 57580.1 предписывает хранить события безопасности в течение 5 лет (для систем 1‑го уровня защиты информации) или 3 лет (для систем 2‑го и 3‑го уровня защиты информации);

  • PCI DSS требует хранения событий безопасности в течение 1 г��да с возможностью оперативного доступа к просмотру событий за ближайшие 3 месяца.

Требования к процессу сбора и анализа событий безопасности

«Сырые» логи позволяют отвечать на простые, точечные вопросы. Например, мы можем узнать, кто и когда авторизовался в веб-панели, чтобы загрузить документ.

Однако с масштабированием инфраструктуры и ростом общего количества информационных систем — объем данных и скорость их поступления растут лавинообразно. В таких условиях ручной поиск становится трудоемким, а зачастую и вовсе бессмысленным занятием. Чтобы взять этот поток под контроль, используются системы класса SIEM (Security Information and Event Management) для сбора, обработки и хранения событий безопасности.

Эти системы решают три ключевые задачи:

  • Нормализация и первичная обработка — приведение событий, полученных от разных источников, к единому формату. Большие объемы записей обрабатываются по заданным правилам. К примеру, это может быть агрегация: события группируются по типу или источнику, а администратор получает оповещения, если показатели превышают заданные пороговые значения.

  • Корреляция — этап углубленного анализа, когда SIEM ищет взаимосвязи между разрозненными элементами, выстраивает их в хронологические цепочки. Таким образом удается выявить скрытые паттерны, характерные для целенаправленных кибератак.

  • Долговременное хранение — система обеспечивает централизованное отказоустойчивое хранение записей и управляет доступом к данным.

Чтобы SIEM-система работала эффективно, одной лишь регистрации событий недостаточно. Необходимо реализовать две дополнительные, критически важные меры:

  • Синхронизация времени — все источники событий должны быть согласованы с единым эталоном времени. Алгоритмы агрегации и корреляции во многом опираются именно на временны́е отметки — чем они точнее и чем меньше расхождение часов между узлами, тем выше вероятность достоверно обнаружить атаку и восстановить цепочку событий.

  • Быстрая и гарантированная доставка логов в централизованное хранилище — защищает данные от уничтожения. Проникая в инфраструктуру, злоумышленник первым делом пытается «замести следы», удаляя локальные журналы на скомпрометированном узле. Если события уже переданы в централизованную систему, скрыть активность намного сложнее. Кроме того, механизмы гарантированной доставки предотвращают потерю данных при технических сбоях — например, во время кратковременной сетевой недоступности источников или всей SIEM‑системы.

Для полноценного анализа событий, связанных с использованием ресурсов Selectel, мы рекомендуем подключить наш сервис — аудит логов. Он в автоматическом режиме передает в SIEM‑систему клиентов всю информацию о действиях администраторов — будь то операции в панели управления или запросы к API.

Полное руководство по интеграции описано в документации.

Выводы

Управление событиями информационной безопасности — часть базового минимума для каждой защищаемой инфраструктуры. Именно этот процесс позволяет в любой момент получить ответы на главные вопросы:

  • что происходит в системе прямо сейчас;

  • что послужило первопричиной этих событий.

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

Описанные в статье принципы мы собрали в универсальный чек-лист, который пригодится при планировании и внедрении процессов защиты.

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