Пункт 1.4 Приказа ОАЦ №66: как определить способ и периодичность мониторинга событий ИБ

Смысл требования

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

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

Формулировка требования

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

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

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

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

Что проверяет аудитор или ОАЦ

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

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

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

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

Организационный вариант.

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

Организационно-технический вариант.

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

Комбинированный вариант для зрелой среды.

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

Что целесообразно закрепить в ЛПА и ОРД

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

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

При отсутствии этих элементов ЛПА обычно получается декларативным и не создаёт доказуемого порядка исполнения требования.

Периодичность мониторинга: практический подход

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

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

Возможность технической поддержки процесса

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

• Windows Event Viewer / Windows Event Collector. Подходит для Windows-среды, когда мониторинг выполняется по установленному регламенту штатными средствами.
• Syslog / rsyslog / syslog-ng. Уместны для Linux, сетевого оборудования, межсетевых экранов и части СЗИ как основа централизованного просмотра.
• Graylog. Полезен как инструмент поиска, фильтрации и формирования оповещений в малых и средних ИС.
• Wazuh. Подходит там, где мониторинг должен сочетаться с агентским сбором, контролем целостности и более выраженной security-логикой.
• ELK / OpenSearch Stack. Уместны для больших объёмов событий и сложной смешанной инфраструктуры.
• SIEM-платформы. Рациональны в крупных ИС, когда мониторинг тесно связан с корреляцией, приоритизацией и реагированием.

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

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

• в ЛПА указано только общее требование “осуществлять мониторинг”, но не определены способ, периодичность и ответственные лица;
• мониторинг фактически осуществляется эпизодически, только после сбоев или инцидентов;
• не различаются критичные и некритичные события, вследствие чего установлен либо избыточный, либо заведомо слабый режим контроля;
• используется техническая платформа, однако порядок обработки уведомлений и результатов анализа не урегулирован;
• не ведётся фиксация результатов мониторинга, поэтому на проверке невозможно подтвердить сам факт его выполнения;
• ЛПА не согласованы с перечнем событий по пункту 1.1 и моделью хранения по пунктам 1.2–1.3.

Для пункта 1.4 определяющим является не выбор SIEM, коллектора журналов или иного инструмента, а наличие утверждённого владельцем ИС порядка мониторинга событий ИБ. Именно локальные акты и организационно-распорядительные документы должны определять, какие события просматриваются и анализируются, кем, как часто и в каком порядке оформляются результаты.

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