|

Реализация требования 1.1 Приказа ОАЦ №66: определение состава событий информационной безопасности, подлежащих регистрации

ОтVK

Краткое описание требования

Смысл пункта 1.1 не в том, чтобы “включить побольше логов”. Требование про другое: владелец ИС должен заранее определить, какие именно события информационной безопасности для его системы считаются значимыми и подлежат регистрации. Если этого нет, журналирование превращается либо в шум, где теряются важные события, либо в декоративную меру, когда критичные действия вообще не фиксируются.

На практике это базовое требование для всей дальнейшей проверки. Если состав регистрируемых событий не определён осмысленно, дальше невозможно нормально выстроить ни контроль действий пользователей и администраторов, ни расследование инцидентов, ни доказательную базу для аттестации. Само требование входит в раздел «Аудит безопасности» перечня требований к СЗИ, включаемых в ТЗ.

Оригинальная формулировка требования

Приложение 3 к Положению о порядке технической и криптографической защиты информации в ИС, раздел «1 Аудит безопасности», пункт 1.1: «определение состава сведений о событиях информационной безопасности, подлежащих регистрации».

Обязательность требования

По таблице приложения 3 требование 1.1 отмечено как рекомендуемое для классов 4-ин, 4-спец, 4-бг, 4-юл и как обязательное для классов 4-дсп, 3-ин, 3-спец, 3-бг, 3-юл, 3-дсп. Обозначение «+/–» в приложении 3 означает рекомендуемый характер требования, обозначение «+» — обязательный.

На практике даже там, где требование указано как рекомендуемое, игнорировать его неразумно. Если в ИС нет заранее определённого перечня событий ИБ для регистрации, потом очень трудно доказать, что владелец реально контролирует систему, а не просто хранит логи “на всякий случай”. Это уже практический вывод из самого требования и из логики аттестации.

Что именно проверяет проверяющий

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

  • есть ли в ТЗ, ЛПА, регламенте эксплуатации или ином ОРД закреплённый перечень событий ИБ, подлежащих регистрации;
  • связан ли этот перечень с реальной архитектурой ИС, удалённым доступом, администрированием, прикладными системами, сетевыми узлами и СЗИ;
  • есть ли фактические источники регистрации этих событий: ОС, СУБД, межсетевые экраны, VPN, приложения, средства защиты, телекоммуникационное оборудование;
  • не упущены ли критичные события: входы, неуспешные попытки входа, выдача и изменение прав, действия администраторов, изменения конфигурации, отключение защиты, удалённые подключения;
  • можно ли по зарегистрированным событиям восстановить картину инцидента или хотя бы подтвердить факт его возникновения и развития.

Отдельно важно, что в методических рекомендациях ОАЦ прямо указано: перечень типов и записей событий ИБ определён в приложении к положению, утверждённому приказом ОАЦ № 130 от 25 июля 2023 г., и этот перечень дан для операционных систем, СУБД, телекоммуникационного оборудования, прикладного программного обеспечения и средств защиты информации. То есть проверяющий вполне обоснованно будет смотреть, учёл ли владелец ИС хотя бы эти базовые источники.

Варианты реализации

Организационный подход.

Владелец ИС закрепляет в ТЗ, регламенте эксплуатации, регламенте журналирования или отдельном приложении к ЛПА перечень событий, которые должны регистрироваться. Это минимально допустимый вариант для небольших систем, если потом можно показать, в каких именно журналах эти события реально появляются.

Технический подход.

Перечень событий раскладывается по источникам: отдельно для ОС, СУБД, телекоммуникационного оборудования, прикладного ПО, средств защиты, межсетевых экранов и удалённого доступа. Это сильнее организационного варианта, потому что сразу связывает требование с фактическими журналами и уменьшает риск, что событие описано только на бумаге, но нигде не фиксируется. Методические рекомендации ОАЦ отдельно приводят такой перечень источников и примеры обязательных записей для них со ссылкой на приказ ОАЦ № 130. :contentReference[oaicite:5]{index=5}

Комбинированный подход.

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

Типовой минимальный список событий для обычной ИС

Ниже — не “единственно правильный список”, а типовой минимальный практический перечень для обычной ИС, собранный из логики пункта 1.1, рекомендаций ОАЦ и перечня типов событий, на который рекомендации ссылаются через приказ ОАЦ № 130. Это минимальная база, от которой обычно разумно отталкиваться. Для реальной системы этот список почти всегда приходится расширять под архитектуру и прикладной контур.

На уровне операционных систем:

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

На уровне СУБД:

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

На уровне телекоммуникационного оборудования и межсетевых экранов:

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

На уровне прикладного ПО:

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

На уровне средств защиты информации:

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

Для обычной ИС этого минимума обычно достаточно как стартовой базы. Но если у тебя есть удалённый доступ, VPN, прикладные шлюзы, веб-приложения, отдельные административные контуры, резервное копирование, централизованное журналирование или специфичные прикладные операции, список нужно расширять под них отдельно. Это уже практический вывод из архитектуры, а не из одной строки приказа.

Типичные ошибки при реализации

  • в статье требований есть только общая фраза про журналирование, но нет утверждённого перечня событий;
  • в документе описан широкий список событий, но технически часть из них нигде не фиксируется;
  • регистрируются только пользовательские входы, а действия администраторов, изменения прав и настройки СЗИ выпадают;
  • не учитываются события из СУБД, межсетевых экранов, прикладных систем и средств защиты;
  • в журналы тащат всё подряд без отбора, в результате важные события теряются в шуме;
  • события регистрируются, но порядок их хранения, просмотра и использования в расследовании не определён.

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

Для распределённой ИС, среды с удалённым доступом, несколькими сегментами, привилегированным администрированием и несколькими источниками журналов нужно сразу строить более зрелую модель: единый организационный перечень плюс раскладка по техническим источникам и правилам хранения. Главная мысль здесь простая: пункт 1.1 — это не про “вести логи вообще”, а про осмысленное решение владельца ИС, какие события для его системы реально критичны и должны регистрироваться. В рекомендациях ОАЦ это решение уже дополнительно привязано к перечню типов и записей событий из приказа ОАЦ № 130, и игнорировать эту опору в практике уже не стоит.

Похожие записи