Централизованный сбор данных регистрации о событиях защиты информации, формируемых объектами информатизации, определенных мерами МАС.1 - МАС.7 таблицы 33.
Уровень защиты информации 3-Н, 2-Т, 1-Т.
Пояснение
Данные регистрации со всех источников, определённых мерами МАС.1—МАС.7 (СЗИ, сетевое оборудование, сервисы, ОС/СУБД, АС, контроллеры доменов, средства контроля доступа), должны собираться в единую централизованную систему, а не оставаться разрозненно на каждом источнике.
Главная цель меры — обеспечить возможность сопоставления событий из разных источников в единой точке сбора при расследовании инцидента, затрагивающего несколько систем: без централизации локальные журналы разных источников недоступны для сквозного анализа и, как правило, имеют существенно более короткий срок хранения на самом источнике, чем требуется для полноценного расследования.
Техническая реализация обеспечивается развёртыванием системы централизованного сбора событий (SIEM), к которой подключаются все источники, определённые мерами МАС.1—МАС.7, с настройкой транспорта передачи событий (агенты сбора, syslog, API) для каждого типа источника и контролем фактического подключения каждого из них (см. также меру МАС.10 в части контроля формирования событий). Базовый транспорт передачи событий от большинства источников может строиться на штатных механизмах — syslog (сетевое оборудование, сетевые сервисы, серверы на базе Linux) и Windows Event Forwarding (для операционных систем Windows) — без отдельного приобретения. Однако штатных механизмов передачи недостаточно для выполнения самой цели меры: они не обеспечивают ни единой точки хранения и корреляции событий от всех типов источников одновременно, ни гарантированной доставки (мера МАС.12), ни нормализации разнородных форматов (мера МАС.17) — для этого используется система централизованного сбора и корреляции событий (SIEM).
Класс используемых средств — штатные механизмы пересылки событий (syslog, Windows Event Forwarding) для базового транспорта; система централизованного сбора и корреляции событий (SIEM) — для единой точки хранения, гарантированной доставки и нормализации.
Примеры таких средств:
- Иностранные: Splunk, IBM QRadar и пр.
- Российские сертифицированные (ФСТЭК): MaxPatrol SIEM, KUMA и др.
- Открытый код: Wazuh, ELK Stack (Elasticsearch, Logstash, Kibana) и др.
- Конфигурация SIEM-системы с перечнем подключённых источников, соответствующим мерам МАС.1—МАС.7.
- Схема транспорта передачи событий по типам источников.
- Итоги интервью с ответственным за администрирование SIEM-системы.
- Централизованный сбор охватывает не все источники, определённые мерами МАС.1—МАС.7, отдельные категории источников передают события только в локальный журнал;
- Транспорт передачи событий не защищён (незашифрованный syslog по UDP), что создаёт риск потери или подмены событий в пути;
- Подключение нового источника инфраструктуры к централизованному сбору не является обязательным этапом процесса ввода его в эксплуатацию;
- Централизованная система сбора имеет единую точку отказа без резервирования, что при её недоступности прекращает сбор событий со всех источников одновременно.
Не выявлены.
Не выявлены.
Генерация временных меток для данных регистрации о событиях защиты информации и синхронизации системного времени объектов информатизации, используемых для формирования, сбора и анализа данных регистрации.
Уровень защиты информации 3-Т, 2-Т, 1-Т.
Пояснение
Мера требует генерации временных меток для данных регистрации о событиях защиты информации и синхронизации системного времени всех объектов информатизации, используемых для формирования, сбора и анализа данных регистрации, с единым источником точного времени.
Главная цель меры — обеспечить возможность достоверно восстановить хронологическую последовательность событий, зафиксированных разными источниками: без единой синхронизации времени временные метки событий от разных систем несопоставимы между собой, что делает невозможным построение единой временной шкалы инцидента, растянутого по нескольким компонентам инфраструктуры.
Техническая реализация обеспечивается развёртыванием службы синхронизации времени (протокол NTP) с использованием доверенного (в том числе аппаратного, например ГЛОНАСС/GPS-приёмника) источника точного времени, к которому подключаются все объекты информатизации, формирующие данные регистрации, с периодическим контролем расхождения системного времени каждого источника с эталонным.
Класс используемых средств — серверы точного времени (NTP-серверы), в том числе с аппаратным источником синхронизации (ГЛОНАСС/GPS).
Примеры таких средств:
- Иностранные: встроенные NTP-клиенты операционных систем, синхронизация с публичными пулами NTP (ограниченно применимо для контура повышенных требований к доверенности источника) и пр.
- Российские сертифицированные: сертифицированные серверы точного времени с приёмником ГЛОНАСС отечественного производства и др.
- Открытый код: chrony/ntpd (клиент и сервер NTP) и др.
- Конфигурация службы синхронизации времени и перечень источников точного времени.
- Отчёт о расхождении системного времени объектов информатизации с эталонным источником за проверяемый период.
- Итоги интервью с ответственным за администрирование инфраструктуры.
- Синхронизация времени настроена не для всех объектов информатизации, формирующих данные регистрации, отдельные изолированные сегменты синхронизируются с локальным, а не единым источником;
- Источник точного времени, с которым синхронизируются объекты внутреннего контура, сам не проверяется на доверенность (публичный интернет-сервер без резервирования);
- Контроль фактического расхождения времени между объектами информатизации не автоматизирован, отклонение выявляется только по факту затруднений при расследовании инцидента;
- Допустимое расхождение системного времени не регламентировано, что не позволяет объективно оценить, укладывается ли фактическое отклонение в приемлемые пределы.
Не выявлены.
Не выявлены.
Контроль формирования данных регистрации о событиях защиты информации объектов информатизации, определенных мерами МАС.1 - МАС.7 таблицы 33.
Уровень защиты информации 3-О, 2-Т, 1-Т.
Пояснение
Недостаточно один раз настроить регистрацию событий на источниках (меры МАС.1—МАС.7) — нужно постоянно проверять, что она продолжает фактически формироваться, а не прекратилась из-за сбоя, отключения аудита или изменения конфигурации.
Главная цель меры — обнаружить случаи отключения аудита администратором или злоумышленником на конкретном источнике (сервисе, ОС, сетевом устройстве): без отдельного контроля формирования событий отсутствие данных регистрации от источника неотличимо от штатной ситуации, когда на источнике попросту не происходило значимых событий.
Регламентация периодической ручной или полуавтоматической сверки: ответственный за ИБ по установленному графику проверяет, что каждый источник из перечня МАС.1—МАС.7 продолжает формировать события, и документально фиксирует результат выполненной проверки.
Автоматический технический контроль обеспечивается настройкой системы централизованного сбора (SIEM) на отслеживание потока событий от каждого зарегистрированного источника и формирование оповещения при отсутствии событий дольше установленного интервала (dead source detection / health check).
Класс используемых средств — система централизованного сбора и корреляции событий (SIEM) с функцией контроля состояния источников (health check).
Примеры таких средств:
- Иностранные: Splunk (health check источников), Elastic Security и пр.
- Российские сертифицированные (ФСТЭК): MaxPatrol SIEM (контроль состояния источников событий), KUMA и др.
- Открытый код: Wazuh и др.
- Документ регламентирующий проверки формирования событий по графику.
- Артефакты реализованного контроля (акты, служебные записки, закрытие тикеты и пр.).
- Итоги интервью с администратором системы мониторинга.
- Конфигурация правил контроля/алертинга по отсутствию событий от источника;
- Выгрузка зафиксированных случаев прекращения поступления событий от источников за проверяемый период.
- Контроль настроен только для части источников из перечня МАС.1–МАС.7.
- Алерты об отсутствии событий генерируются, но не имеют регламентированной реакции ответственного.
- Сверка проводится нерегулярно и не документируется.
Не выявлены.
Не выявлены.
Реализация защиты данных регистрации о событиях защиты информации от раскрытия и модификации, двухсторонней аутентификации при передаче данных регистрации с использованием сети Интернет.
Уровень защиты информации 3-Н, 2-Т, 1-Т.
Пояснение
При передаче данных регистрации через сеть Интернет (например, между филиалом и центральной SIEM) должна обеспечиваться защита от раскрытия и модификации, а также двухсторонняя аутентификация сторон канала — аналогично требованию ЗВС.2, но применительно именно к потоку событий защиты информации.
Главная цель меры — исключить перехват или подмену событий защиты информации в пути следования, ещё до их попадания в центральное хранилище: без взаимной аутентификации сторон посторонний узел способен выдать себя за легитимный источник и внедрить поддельные события либо заблокировать (перехватить) передачу настоящих, тем самым маскируя следы атаки до того, как они станут доступны для анализа.
Техническая реализация обеспечивается применением криптографического протокола защищённой передачи данных (TLS с взаимной аутентификацией сторон по сертификатам, либо VPN-туннель) для канала передачи данных регистрации через сеть Интернет, с контролем целостности передаваемых событий и отказом в приёме данных от узла, не прошедшего взаимную аутентификацию.
Класс используемых средств — средства криптографической защиты канала передачи данных (TLS/VPN) с функцией взаимной (двухсторонней) аутентификации сторон.
Примеры таких средств:
- Иностранные: встроенная поддержка mTLS в транспортных агентах SIEM (Splunk Forwarder over TLS) и пр.
Российские сертифицированные (ФСБ): КриптоПро CSP/TLS, «Континент» (VPN-модуль) и др.
Примеры таких средств:
- Открытый код: OpenVPN/WireGuard (VPN-туннель) в сочетании с mTLS транспортных агентов сбора событий (Wazuh, rsyslog over TLS).
- Конфигурация криптографической защиты и взаимной аутентификации канала передачи данных регистрации через сеть Интернет.
- Схема канала передачи данных регистрации между удалённым источником и центральной SIEM-системой.
- Итоги интервью с ответственным за администрирование канала передачи данных регистрации.
- Взаимная аутентификация сторон канала не реализована, применяется только односторонняя аутентификация сервера (стандартный TLS без mTLS);
- Защита канала передачи распространяется не на все удалённые источники, часть филиалов передаёт события по незащищённому каналу;
- Сертификаты (ключи), используемые для взаимной аутентификации, не имеют установленного регламентом срока действия и порядка замены;
- Целостность передаваемых данных регистрации не контролируется отдельно от факта успешного установления защищённого соединения.
Не выявлены.
Не выявлены.
Обеспечение гарантированной доставки данных регистрации о событиях защиты информации при их централизованном сборе.
Уровень защиты информации 3-Н, 2-Т, 1-Т.
Пояснение
При централизованном сборе данных регистрации должна обеспечиваться гарантированная доставка, чтобы события не терялись при сбоях канала связи или перегрузке системы сбора, а буферизовались и досылались повторно.
Главная цель меры — избежать безвозвратной утраты событий защиты информации, сформированных в момент кратковременного разрыва канала между источником и центральной системой: без механизма гарантированной доставки именно тот интервал, когда канал связи временно недоступен, зачастую совпадает с активной фазой атаки, в течение которой злоумышленник намеренно нарушает связность инфраструктуры.
Техническая реализация обеспечивается применением на источниках событий (агентах сбора) локальной буферизации данных регистрации на время недоступности канала связи или перегрузки центральной системы сбора, с автоматической повторной отправкой накопленных событий после восстановления связности и подтверждением их фактического приёма центральной системой (доставка с подтверждением, at-least-once delivery).
Класс используемых средств — агенты (форвардеры) сбора событий с функцией локальной буферизации и гарантированной доставки, промежуточные брокеры сообщений.
Примеры таких средств:
- Иностранные: Splunk Universal Forwarder (буферизация и повторная отправка), Kafka (промежуточный брокер) и пр.
- Российские сертифицированные (ФСТЭК): агенты сбора MaxPatrol SIEM/KUMA с функцией буферизации и др.
- Открытый код: Wazuh agent (буферизация на источнике), Filebeat + Kafka и др.
- Конфигурация агентов (форвардеров) сбора событий в части буферизации и гарантированной доставки.
- Результат тестового моделирования разрыва канала связи с подтверждением последующей доставки накопленных событий.
- Итоги интервью с ответственным за администрирование системы централизованного сбора.
- Объём локального буфера на источнике недостаточен для покрытия типичной продолжительности разрыва канала связи, что приводит к частичной потере событий при длительных сбоях;
- Подтверждение фактического приёма события центральной системой не контролируется, форвардер считает событие доставленным сразу после отправки;
- Гарантированная доставка настроена не для всех источников, критичные с точки зрения объёма событий источники (например, DLP-система) исключены из механизма буферизации;
- Факты срабатывания буферизации (временной недоступности канала) не регистрируются как отдельное событие (см. также меру МАС.21).
Не выявлены.
Не выявлены.
Резервирование необходимого объема памяти для хранения данных регистрации о событиях защиты информации.
Уровень защиты информации 3-Т, 2-Т, 1-Т.
Пояснение
Должен быть зарезервирован объём памяти под хранение данных регистрации (которые финансовая организация выбрала к регистрации), достаточный для хранения событий в течение установленного срока без риска переполнения хранилища.
Главная цель меры — предотвратить преждевременную (до истечения установленного срока хранения) перезапись старых событий вследствие переполнения хранилища: без заблаговременного расчёта и резервирования необходимого объёма памяти данные, необходимые для расследования инцидента, могут оказаться безвозвратно утрачены задолго до истечения формально установленного срока их хранения (меры МАС.15/16).
Техническая реализация обеспечивается расчётом необходимого объёма хранилища данных регистрации исходя из фактической интенсивности потока событий от всех подключённых источников (мера МАС.8) и установленного срока хранения, с заблаговременным резервированием этого объёма и настройкой автоматического оповещения при приближении фактической заполненности хранилища к пороговому значению, требующему расширения.
Класс используемых средств — система хранения данных (СХД), масштабируемая подсистема хранения событий в составе SIEM-платформы.
Примеры таких средств:
- Иностранные: масштабируемые индексные кластеры Splunk, IBM QRadar и пр.
- Российские сертифицированные (ФСТЭК): подсистема хранения MaxPatrol SIEM/KUMA и др.
- Открытый код: масштабируемый кластер Elasticsearch (в составе ELK Stack) и др.
- Расчёт необходимого объёма хранилища данных регистрации исходя из интенсивности потока событий и установленного срока хранения.
- Конфигурация системы хранения с указанием фактически зарезервированного объёма и настроенных пороговых оповещений о заполненности.
- Отчёт о фактической динамике заполнения хранилища данных регистрации за проверяемый период.
- Расчёт необходимого объёма хранилища выполнен без учёта роста интенсивности потока событий при подключении новых источников;
- Пороговое оповещение о приближении к заполненности хранилища не настроено, переполнение выявляется только по факту начавшейся перезаписи данных;
- Резервирование объёма выполнено формально (по факту закупки оборудования), без периодического пересчёта фактической достаточности;
- При достижении предела хранилища происходит автоматическая перезапись данных без предварительной архивации в более дешёвое (холодное) хранилище с более длительным сроком.
Не выявлены.
Не выявлены.
Реализация защиты данных регистрации о событиях защиты информации от НСД при их хранении, обеспечение целостности и доступности хранимых данных регистрации.
Уровень защиты информации 3-Т, 2-Т, 1-Т.
Пояснение
Хранимые данные регистрации о событиях защиты информации должны быть защищены от несанкционированного доступа, а их целостность и доступность — обеспечены (хеширование, резервное копирование, разграничение доступа).
Главная цель меры — не допустить, чтобы злоумышленник, получивший доступ к хранилищу журналов (в том числе администратор с расширенными правами), мог изменять или удалять записи о собственных действиях, тем самым скрывая следы атаки; наличие резервного копирования дополнительно защищает от безвозвратной потери всей истории событий при сбое самого хранилища.
Техническая реализация обеспечивается разграничением доступа к хранилищу данных регистрации по принципу минимально необходимых полномочий (с исключением возможности удаления или модификации записей даже для администраторов SIEM-системы в штатном режиме работы), применением средств контроля целостности хранимых данных (хеш-цепочки записей, WORM-хранилище — write once, read many) и регулярным резервным копированием.
Класс используемых средств — система централизованного сбора и корреляции событий (SIEM) с функцией разграничения доступа и контроля целостности хранимых данных, средства резервного копирования.
Примеры таких средств:
- Иностранные: Splunk (ролевая модель доступа, индексная целостность), Veeam Backup & Replication и пр.
- Российские сертифицированные (ФСТЭК): MaxPatrol SIEM/KUMA (разграничение доступа к архиву событий), «Кибер Бэкап» и др.
- Открытый код: Elasticsearch (ролевая модель X-Pack Security), immutable-хранилище на базе объектного хранилища с политикой WORM.
- Конфигурация разграничения доступа к хранилищу данных регистрации с указанием полномочий отдельных ролей.
- Конфигурация средства контроля целостности хранимых данных регистрации.
- Отчёт о выполненном резервном копировании данных регистрации за проверяемый период и результат тестового восстановления.
- Учётные записи администраторов SIEM-системы фактически обладают полномочиями на удаление и модификацию хранимых записей в штатном режиме работы;
- Контроль целостности хранимых данных регистрации не реализован, изменение отдельной записи в хранилище технически не выявляется;
- Резервное копирование данных регистрации выполняется, но тестовое восстановление из резервной копии не проводится, фактическая пригодность копий не подтверждена;
- Резервные копии данных регистрации хранятся в той же зоне доступа, что и основное хранилище, без изоляции от единой точки компрометации.
Не выявлены.
Не выявлены.
Обеспечение возможности доступа к данным регистрации о событиях защиты информации в течение трех лет.
Уровень защиты информации 3-Т, 2-Т, 1-Н.
Пояснение
Мера требует обеспечения возможности доступа к данным регистрации о событиях защиты информации в течение трёх лет с момента их формирования.
Главная цель меры — установить минимальный срок доступности данных регистрации, достаточный для расследования инцидентов, факт которых был обнаружен со значительной задержкой относительно момента их совершения: многие целенаправленные атаки и мошеннические схемы выявляются далеко не сразу, и без установленного минимального срока доступности исходные данные регистрации к моменту обнаружения могут быть уже безвозвратно утрачены.
Техническая реализация обеспечивается организацией многоуровневого хранения данных регистрации: оперативное (быстрый поиск) хранение на индексном хранилище SIEM-системы на протяжении ближайшего периода и последующая архивация в более дешёвое (холодное) хранилище с сохранением возможности поиска и восстановления данных на протяжении не менее трёх лет с момента их формирования.
Класс используемых средств — система хранения данных (СХД) с многоуровневой архитектурой (оперативное/архивное хранилище) в составе или в сочетании с SIEM-платформой.
Примеры таких средств:
- Иностранные: Splunk (SmartStore, архивные индексы), объектное хранилище класса Amazon S3 Glacier (для архивного уровня) и пр.
- Российские сертифицированные (ФСТЭК): архивная подсистема MaxPatrol SIEM/KUMA, отечественные объектные хранилища для архивного уровня.
- Открытый код: Elasticsearch (архивные индексы с холодным/замороженным уровнем хранения, ILM) и др.
- Конфигурация многоуровневого хранения данных регистрации с указанием фактического срока хранения на архивном уровне.
- Результат тестового поиска и восстановления данных регистрации за период, приближающийся к трёхлетнему сроку.
- Итоги интервью с ответственным за администрирование системы хранения данных регистрации.
- Фактический срок хранения данных регистрации на архивном уровне меньше установленного мерой трёхлетнего минимума из-за ограниченного объёма архивного хранилища;
- Доступ к данным регистрации, перенесённым в архивное хранилище, требует ручного восстановления администратором и не может быть выполнен оперативно при расследовании;
- Требование о трёхлетнем сроке доступности распространяется не на все источники данных регистрации, определённые мерами МАС.1—МАС.7;
- Целостность архивных данных регистрации за длительный период не контролируется отдельно от контроля целостности оперативного хранилища (мера МАС.14).
Не выявлены.
Не выявлены.
Обеспечение возможности доступа к данным регистрации о событиях защиты
информации в течение пяти лет.
Уровень защиты информации 3-Н, 2-Н, 1-Т.
Пояснение
Мера аналогична МАС.15, но устанавливает повышенный, пятилетний минимальный срок обеспечения доступа к данным регистрации о событиях защиты информации — для уровня защиты, требующего более длительной ретроспективной доступности.
Главная цель меры — обеспечить тот же результат доступности данных регистрации для расследования инцидентов с длительным периодом обнаружения, что и мера МАС.15, но применительно к объектам защиты повышенной критичности, для которых регуляторные и договорные требования предполагают более продолжительный период ретроспективного анализа.
Техническая реализация аналогична мере МАС.15 и обеспечивается той же многоуровневой архитектурой хранения данных регистрации, рассчитанной на увеличенный, не менее пятилетний срок доступности данных на архивном уровне хранения.
Класс используемых средств — система хранения данных (СХД) с многоуровневой архитектурой (оперативное/архивное хранилище) в составе или в сочетании с SIEM-платформой.
Примеры таких средств:
- Иностранные: Splunk (SmartStore, архивные индексы), объектное хранилище класса Amazon S3 Glacier Deep Archive и пр.
- Российские сертифицированные (ФСТЭК): архивная подсистема MaxPatrol SIEM/KUMA, отечественные объектные хранилища для архивного уровня.
- Открытый код: Elasticsearch (замороженный уровень хранения, ILM с длительным сроком) и др.
- Конфигурация многоуровневого хранения данных регистрации с указанием фактического пятилетнего срока хранения на архивном уровне.
- Расчёт необходимого объёма архивного хранилища исходя из пятилетнего срока и интенсивности потока событий.
- Результат тестового поиска и восстановления данных регистрации за период, приближающийся к пятилетнему сроку.
- Пятилетний срок хранения применяется не для всех объектов защиты, требующих данного уровня, часть систем архивирует данные регистрации по сокращённому (трёхлетнему) сроку меры МАС.15;
- Объём архивного хранилища не рассчитан на фактическую нагрузку при увеличенном до пяти лет сроке хранения, что создаёт риск переполнения задолго до истечения срока;
- Носители архивного хранилища (например, ленточные накопители) не проходят периодическую проверку читаемости на протяжении длительного срока хранения;
- Доступ к данным пятилетней давности требует привлечения стороннего подрядчика (поставщика архивного решения), что не позволяет уложиться в разумные сроки при реальном расследовании.
Не выявлены.
Не выявлены.