Регистрация нарушений и сбоев в формировании и сборе данных о событиях защиты информации.
Уровень защиты информации 3-Н, 2-Т, 1-Т.
Пояснение
Любые нарушения и сбои в самом процессе формирования и сбора данных регистрации должны фиксироваться как отдельные события защиты информации, дополняя контроль формирования (мера МАС.10) фактической историей таких сбоев для последующего анализа.
Главная цель меры — выявлять повторяющиеся сбои сбора событий с конкретного источника как возможный след злоумышленника, намеренно вызывающего отказ агента сбора журналов на скомпрометированном узле: единичный сбой, как правило, является технической случайностью, тогда как системность сбоев по конкретному источнику — значимый индикатор для расследования.
Техническая реализация обеспечивается настройкой системы централизованного сбора событий (SIEM) на автоматическое формирование отдельного события при выявлении нарушения или сбоя в процессе формирования и сбора данных регистрации (отказ агента сбора, ошибка парсинга/нормализации, разрыв канала передачи) с фиксацией источника, времени и характера сбоя, и последующим анализом истории сбоев на предмет системности по конкретному источнику.
Класс используемых средств — встроенный механизм журналирования системы централизованного сбора событий (SIEM), функция контроля состояния источников и агентов сбора (health check).
Примеры таких средств:
- Иностранные: Splunk (внутренние логи Forwarder/Indexer), IBM QRadar и пр.
- Российские сертифицированные (ФСТЭК): MaxPatrol SIEM/KUMA (журнал состояния источников и агентов сбора) и др.
- Открытый код: Wazuh (журнал состояния агентов), Elastic Stack Monitoring и др.
- Конфигурация журналирования нарушений и сбоев в формировании и сборе данных регистрации.
- Выгрузка зарегистрированных нарушений и сбоев за проверяемый период с анализом системности по источникам.
- Итоги интервью с ответственным за администрирование SIEM-системы.
- Регистрируются только полные отказы агента сбора, частичные сбои (ошибки нормализации отдельных событий) не фиксируются как отдельная категория;
- Анализ системности повторяющихся сбоев по конкретному источнику на предмет признаков компрометации не проводится, каждый сбой рассматривается изолированно;
- Оповещение о сбое сбора данных регистрации не имеет установленного регламентом срока реагирования;
- Сбои, вызванные плановыми регламентными работами на источнике, не отделяются от внеплановых сбоев, что затрудняет выявление действительно значимых случаев.
Не выявлены.
Не выявлены.
Регистрация доступа к хранимым данным о событиях защиты информации.
Уровень защиты информации 3-Т, 2-Т, 1-Т.
Пояснение
Каждое обращение к хранимым данным регистрации событий защиты информации должно фиксироваться отдельным событием — кто, когда и к каким именно данным обращался.
Главная цель меры — обеспечить возможность расследования случаев, когда администратор или злоумышленник, получивший доступ к хранилищу событий, просматривает или экспортирует чувствительные данные регистрации: само хранилище содержит сведения обо всей активности инфраструктуры, и доступ к нему без отдельного контроля способен использоваться для разведки перед атакой или для сокрытия следов уже совершённых действий.
Техническая реализация обеспечивается настройкой системы централизованного сбора событий (SIEM) на аудит собственных операций доступа к хранимым данным регистрации (поисковые запросы, экспорт данных, административные действия) с фиксацией учётной записи, времени и объёма затронутых данных, и передачей таких событий в отдельный, изолированный от общего потока журнал.
Класс используемых средств — встроенный механизм аудита действий пользователей SIEM-системы (audit trail).
Примеры таких средств:
- Иностранные: Splunk (внутренний индекс _audit), IBM QRadar (журнал аудита) и пр.
- Российские сертифицированные (ФСТЭК): встроенный аудит действий пользователей MaxPatrol SIEM/KUMA и др.
- Открытый код: Elasticsearch/Kibana (журнал аудита X-Pack Security) и др.
- Конфигурация аудита доступа к хранимым данным регистрации в SIEM-системе.
- Выгрузка зарегистрированных фактов доступа к хранимым данным регистрации за проверяемый период.
- Итоги интервью с ответственным за администрирование SIEM-системы.
- Аудит доступа к хранимым данным регистрации охватывает только административные действия (изменение конфигурации), но не сами поисковые запросы и просмотр данных аналитиками;
- Журнал аудита доступа к данным регистрации хранится в общем индексе вместе с прочими событиями, а не изолированно, что не защищает его от модификации тем же администратором;
- Экспорт (выгрузка) данных регистрации за пределы SIEM-системы не фиксируется как отдельное событие повышенной значимости;
- Аудит доступа не распространяется на данные регистрации, перенесённые в архивное хранилище (меры МАС.15/16).
Не выявлены.
Не выявлены.
Регистрация операций, связанных с изменением правил нормализации (приведения к единому формату), фильтрации, агрегации и классификации данных регистрации о событиях защиты информации.
Уровень защиты информации 3-Н, 2-Т, 1-Т.
Пояснение
Изменения правил нормализации, фильтрации, агрегации и классификации данных регистрации (мера МАС.17) должны фиксироваться отдельным событием защиты информации — кто, когда и что именно изменил в логике обработки событий.
Главная цель меры — исключить возможность скрытого искажения логики обработки данных регистрации: изменение правила фильтрации или нормализации способно избирательно «ослепить» систему мониторинга в отношении определённого типа событий (например, исключить из анализа события конкретной учётной записи), и без регистрации самого факта такого изменения подобное искажение может долго оставаться незамеченным.
Техническая реализация обеспечивается настройкой системы централизованного сбора событий (SIEM) на аудит изменений собственной конфигурации в части правил нормализации, фильтрации, агрегации и классификации данных регистрации, с фиксацией учётной записи, времени изменения и содержания внесённой правки (сравнение версии правила до и после изменения), и передачей таких событий в изолированный журнал аудита конфигурации.
Класс используемых средств — встроенный механизм аудита изменения конфигурации SIEM-системы (audit trail, контроль версий правил).
Примеры таких средств:
- Иностранные: Splunk (журнал изменений конфигурации, версионирование), IBM QRadar и пр.
- Российские сертифицированные (ФСТЭК): встроенный аудит изменения правил обработки MaxPatrol SIEM/KUMA и др.
- Открытый код: контроль версий правил через git-репозиторий конфигурации (например, для Logstash/Sigma-правил) и др.
- Конфигурация аудита изменения правил нормализации, фильтрации, агрегации и классификации данных регистрации в SIEM-системе.
- Выгрузка зарегистрированных изменений правил обработки данных регистрации за проверяемый период с сопоставлением регламенту внесения изменений.
- Итоги интервью с ответственным за администрирование SIEM-системы.
- Аудит изменений правил обработки данных регистрации не выявляет изменения, внесённые в обход штатного интерфейса управления (например, прямым редактированием конфигурационного файла);
- Зарегистрированные изменения правил не сопоставляются с регламентом внесения изменений (мерой управления изменениями), любое изменение считается допустимым без проверки согласования;
- Содержание внесённой правки (что именно изменилось в правиле) не фиксируется, регистрируется только факт изменения без деталей;
- Журнал аудита изменения конфигурации не изолирован от общего потока данных регистрации и потенциально доступен для модификации тем же кругом лиц, чьи действия он призван контролировать.
Не выявлены.
Не выявлены.