Регистрация фактов выявления уязвимостей защиты информации.
Уровень защиты информации 3-Н, 2-Т, 1-Т.
Пояснение
Мера требует регистрации в качестве события защиты информации каждого факта выявления уязвимости в рамках процессов сканирования и анализа защищённости (меры ЦЗИ.1—ЦЗИ.11), а не только формирования итогового отчёта по результатам сканирования.
Главная цель меры — обеспечить полную и достоверную историю выявленных уязвимостей для последующего анализа (в том числе повторного выявления той же уязвимости, признака регресса или несвоевременного устранения), а не полагаться на единственный «плоский» отчёт сканирования, который не позволяет отследить динамику и не защищён от случайной потери или замены более поздним отчётом.
Регистрация обеспечивается настройкой средства анализа защищённости (сканера уязвимостей) на автоматическое формирование события защиты информации при каждом факте выявления уязвимости, с фиксацией её идентификатора (CVE), уровня критичности, затронутого актива и времени обнаружения, и последующей передачей этих событий в SIEM-систему для централизованного хранения и корреляции.
Класс используемых средств — встроенный механизм журналирования средства анализа защищённости (сканера уязвимостей), система централизованного сбора и корреляции событий (SIEM).
Примеры таких средств:
- Иностранные: Tenable Nessus (журнал сканирования), Splunk (централизованный сбор событий) и пр.
- Российские сертифицированные (ФСТЭК): MaxPatrol VM (журнал выявленных уязвимостей), MaxPatrol SIEM, KUMA и др.
- Открытый код: OpenVAS (журнал сканирования), Wazuh (сбор и корреляция событий) и др.
- Конфигурация журналирования событий выявления уязвимостей в средстве анализа защищённости.
- Выгрузка зарегистрированных событий выявления уязвимостей за проверяемый период.
- Итоги интервью с ответственным за управление уязвимостями.
- Регистрируется только итоговый отчёт по завершении сканирования, а не отдельное событие по каждому факту выявления уязвимости;
- События выявления уязвимостей не передаются в SIEM-систему, доступны только в интерфейсе самого сканера с ограниченным сроком хранения;
- При повторном выявлении ранее известной уязвимости отдельное событие не формируется, что не позволяет отследить длительность её существования;
- Уровень критичности уязвимости не фиксируется в событии, что не позволяет приоритизировать реагирование по журналу событий.
Не выявлены.
Не выявлены.
Регистрация установки, обновления и (или) удаления ПО АС, ПО средств и систем защиты информации, системного ПО на серверном и сетевом оборудовании.
Уровень защиты информации 3-Н, 2-Т, 1-Т.
Пояснение
Отдельной регистрации в качестве события защиты информации подлежит каждый факт установки, обновления и (или) удаления ПО автоматизированных систем (АС), средств и систем защиты информации, системного ПО на серверном и сетевом оборудовании — то есть результат операций, выполняемых в рамках меры ЦЗИ.12.
Главная цель меры — обеспечить возможность ретроспективно подтвердить, какое ПО, когда и кем было установлено, обновлено или удалено на конкретном сервере или сетевом устройстве: без такой регистрации расследование инцидента, связанного с несанкционированным изменением состава ПО, невозможно, а факт применения планового обновления невозможно формально подтвердить.
Регистрация обеспечивается настройкой системы патч-менеджмента, платформы централизованного управления серверами и штатных средств журналирования операционных систем на фиксацию событий установки, обновления и удаления пакетов (ПО), с указанием инициатора операции, времени и результата, и последующей передачей таких событий в SIEM-систему.
Класс используемых средств — встроенные журналы операционных систем и систем управления пакетами, системы управления обновлениями (Patch Management), система централизованного сбора и корреляции событий (SIEM).
Примеры таких средств:
- Иностранные: Microsoft SCCM (журнал развёртывания ПО), Splunk и пр.
- Российские сертифицированные (ФСТЭК): MaxPatrol VM, MaxPatrol SIEM, KUMA и др.
- Открытый код: журнал пакетного менеджера (apt/yum history), Wazuh (сбор и корреляция событий) и др.
- Конфигурация журналирования операций установки/обновления/удаления ПО на серверном и сетевом оборудовании.
- Выгрузка зарегистрированных событий за проверяемый период с сопоставлением с плановым графиком обновлений (мера ЦЗИ.12).
- Итоги интервью с ответственным за эксплуатацию серверной инфраструктуры.
- Регистрация событий охватывает серверное оборудование, но не распространяется на сетевое (маршрутизаторы, коммутаторы, межсетевые экраны);
- Инициатор операции (учётная запись, от имени которой выполнено изменение) не фиксируется в событии, что не позволяет установить ответственного;
- События установки/обновления/удаления ПО не передаются в SIEM-систему, доступны только в локальных журналах отдельных серверов с ограниченным сроком хранения;
- Неуспешные (прерванные) операции установки/обновления не регистрируются, фиксируются только успешно завершённые.
Не выявлены.
Не выявлены.
Регистрация установки, обновления и (или) удаления прикладного ПО, ПО АС, ПО средств и систем защиты информации, системного ПО на АРМ пользователей и эксплуатационного персонала.
Уровень защиты информации 3-Н, 2-Т, 1-Т.
Пояснение
Мера аналогична ЦЗИ.28, но распространяется на АРМ пользователей и эксплуатационного персонала: требует регистрации в качестве события защиты информации каждого факта установки, обновления и (или) удаления прикладного ПО, ПО АС, средств и систем защиты информации, системного ПО на рабочих станциях.
Главная цель меры — обеспечить ту же возможность ретроспективного подтверждения состава изменений ПО, что и на серверах, но применительно к существенно более многочисленному и территориально распределённому парку АРМ, где несанкционированная установка ПО пользователем — значимо более вероятный сценарий, чем на серверном оборудовании.
Регистрация обеспечивается настройкой системы патч-менеджмента, платформы централизованного управления АРМ (EPP-платформы) и штатных средств журналирования операционной системы на фиксацию событий установки, обновления и удаления ПО на АРМ, с указанием инициатора операции, времени и результата, и последующей передачей таких событий в SIEM-систему.
Класс используемых средств — встроенные журналы операционных систем, платформы централизованного управления конечными точками (EPP), система централизованного сбора и корреляции событий (SIEM).
Примеры таких средств:
- Иностранные: Microsoft SCCM, Splunk и пр.
- Российские сертифицированные (ФСТЭК): Kaspersky Security Center, MaxPatrol SIEM, KUMA и др.
- Открытый код: Wazuh (сбор и корреляция событий, включая инвентаризацию ПО) и др.
- Конфигурация журналирования операций установки/обновления/удаления ПО на образце АРМ.
- Выгрузка зарегистрированных событий по парку АРМ за проверяемый период.
- Итоги интервью с ответственным за поддержку пользователей.
- Регистрация событий установлена только на части парка АРМ, для АРМ, длительное время не подключающихся к сети, история изменений не собирается вовсе;
- Событие фиксирует факт изменения, но не различает санкционированную (в рамках патч-менеджмента) и несанкционированную (самовольную) установку ПО пользователем;
- Установка ПО в обход централизованной системы управления (например, с правами локального администратора) не регистрируется;
- События не передаются в SIEM-систему, доступны только локально на АРМ и утрачиваются при переустановке или выходе из строя рабочей станции.
Не выявлены.
Не выявлены.
Регистрация запуска программных сервисов.
Уровень защиты информации 3-Н, 2-Н, 1-Т.
Пояснение
Мера требует, чтобы каждый запуск программного сервиса (службы, демона) на серверном оборудовании и АРМ регистрировался как событие защиты информации.
Главная цель меры — не допустить незамеченного запуска постороннего сервиса, используемого для закрепления в системе (persistence): вредоносный код и злоумышленник, получивший контроль над системой, нередко регистрируют собственную службу для автоматического восстановления присутствия после перезагрузки, и без регистрации фактов запуска сервисов такая активность останется без возможности ретроспективного расследования.
Регистрация обеспечивается настройкой штатного журнала операционной системы (журнал служб) на фиксацию событий запуска, остановки и изменения параметров запуска (автозапуск) программных сервисов, с последующей передачей таких событий в SIEM-систему для централизованного анализа и выявления аномальных (ранее не наблюдавшихся) сервисов.
Класс используемых средств — встроенные средства журналирования операционной системы, система централизованного сбора и корреляции событий (SIEM).
Примеры таких средств:
- Иностранные: Splunk (сбор и анализ журналов служб), Microsoft Sysmon (детальное журналирование создания процессов и служб) и пр.
- Российские сертифицированные (ФСТЭК): MaxPatrol SIEM, KUMA и др.
- Открытый код: Wazuh, встроенный журнал systemd/Event Log и др.
- Конфигурация журналирования запуска программных сервисов на образце сервера и АРМ.
- Выгрузка зарегистрированных событий запуска сервисов за проверяемый период.
- Итоги интервью с ответственным за мониторинг ИБ.
- Регистрация запуска сервисов настроена только на серверном оборудовании, но не на АРМ, где риск несанкционированной установки службы выше;
- События запуска сервисов собираются локально, но не передаются в SIEM-систему для централизованного анализа и выявления аномалий;
- Выявление ранее не наблюдавшихся (новых) сервисов не автоматизировано, анализ журнала проводится только по факту уже случившегося инцидента;
- Регистрируется факт запуска, но не факт изменения параметров автозапуска сервиса, что не позволяет выявить закрепление в системе до перезагрузки.
Не выявлены.
Не выявлены.
Регистрация результатов выполнения операций по контролю состава ПО серверного оборудования, АРМ пользователей и эксплуатационного персонала.
Уровень защиты информации 3-Н, 2-Н, 1-Т.
Пояснение
Мера требует, чтобы результаты каждой проверки состава ПО серверного оборудования (мера ЦЗИ.22) фиксировались как событие защиты информации с итогом проверки, а не просто выполнялись без регистрации.
Главная цель меры — обеспечить возможность подтвердить сам факт и результат контроля состава ПО серверов за конкретный период: без регистрации результатов проверок невозможно отличить ситуацию, когда контроль реально выполнялся и не выявил отклонений, от ситуации, когда контроль не выполнялся вовсе, что критично при расследовании инцидента или проверке соответствия.
Регистрация обеспечивается настройкой средства инвентаризации ПО серверного оборудования (мера ЦЗИ.22) на автоматическое формирование события по завершении каждого цикла проверки, с фиксацией результата (соответствие/несоответствие эталонному перечню, перечень выявленных отклонений) и передачей события в SIEM-систему.
Класс используемых средств — встроенный механизм журналирования средства инвентаризации ПО / системы управления конфигурациями, система централизованного сбора и корреляции событий (SIEM).
Примеры таких средств:
- Иностранные: Microsoft SCCM (журнал инвентаризации), Splunk и пр.
- Российские сертифицированные (ФСТЭК): Kaspersky Security Center, Efros Config Inspector, MaxPatrol SIEM и др.
- Открытый код: Wazuh (события syscollector), Ansible (журнал выполнения плейбуков инвентаризации) и др.
- Конфигурация журналирования результатов проверок состава ПО серверного оборудования.
- Выгрузка зарегистрированных результатов проверок за проверяемый период.
- Итоги интервью с ответственным за администрирование серверной инфраструктуры.
- Регистрируется только факт выявленного отклонения, а не каждый цикл проверки, что не позволяет подтвердить регулярность контроля;
- Периодичность формирования события не соответствует установленной регламентом (мера ЦЗИ.22) периодичности самой проверки;
- Событие не содержит перечня выявленных отклонений, только общий признак «соответствие/несоответствие», что затрудняет последующий анализ;
- Результаты проверок не передаются в SIEM-систему, доступны только в локальном журнале средства инвентаризации.
Не выявлены.
Не выявлены.
Регистрация результатов выполнения операций по контролю состава ПО АРМ пользователей и эксплуатационного персонала.
Уровень защиты информации 3-Н, 2-Т, 1-Т.
Пояснение
Мера аналогична ЦЗИ.31, но требует регистрации результатов выполнения операций по контролю состава ПО АРМ пользователей и эксплуатационного персонала (мера ЦЗИ.20) в качестве события защиты информации.
Главная цель меры — обеспечить ту же возможность подтверждения факта и результата контроля, что и для серверного оборудования (мера ЦЗИ.31), применительно к парку АРМ, для которого регулярность и полнота охвата проверками особенно значимы ввиду его многочисленности и территориальной распределённости.
Регистрация обеспечивается настройкой средства инвентаризации ПО АРМ (мера ЦЗИ.20) на автоматическое формирование события по завершении каждого цикла проверки, с фиксацией результата (соответствие/несоответствие эталонному перечню, перечень выявленных отклонений) и передачей события в SIEM-систему.
Класс используемых средств — встроенный механизм журналирования системы инвентаризации ПО (Software Asset Management) / EPP-платформы, система централизованного сбора и корреляции событий (SIEM).
Примеры таких средств:
- Иностранные: Microsoft SCCM, Splunk и пр.
- Российские сертифицированные (ФСТЭК): Kaspersky Security Center, MaxPatrol SIEM, KUMA и др.
- Открытый код: Wazuh (события syscollector) и др.
- Конфигурация журналирования результатов проверок состава ПО АРМ.
- Выгрузка зарегистрированных результатов проверок по парку АРМ за проверяемый период.
- Итоги интервью с ответственным за администрирование АРМ.
- Событие формируется только для АРМ, фактически подключённых к сети в момент проверки, без учёта длительно отсутствующих;
- Регистрируется только факт выявленного отклонения, а не каждый цикл проверки по всему парку АРМ;
- Результаты проверок не сопоставляются с данными меры ЦЗИ.20 о фактическом составе разрешённого ПО за тот же период;
- Результаты проверок не передаются в SIEM-систему, доступны только в локальной консоли средства инвентаризации.
Не выявлены.
Не выявлены.
Регистрация результатов выполнения операций по контролю состава ПО, запускаемого при загрузке операционной системы АРМ пользователей и эксплуатационного персонала.
Уровень защиты информации 3-Н, 2-Т, 1-Т.
Пояснение
Мера является производной от ЦЗИ.23 и требует регистрации результатов каждого выполнения контроля состава программного обеспечения (ПО) именно на этапе инициализации операционной системы (ОС), а не факта запуска отдельных приложений пользователем. В отличие от меры ЦЗИ.32 здесь контролируется и регистрируется состав ПО именно на уровне начальной инициализации ОС и запуска компонентов в ходе её старта, в том числе тех, что завершают работу сразу после окончания загрузки.
Главная цель меры — обеспечить возможность ретроспективно подтвердить факт и результат контроля именно на этапе загрузки при расследовании инцидента, связанного с компрометацией автозагружаемых компонентов, либо при проверке соответствия: без такой регистрации невозможно отличить ситуацию, когда контроль на этапе загрузки реально выполнялся и не выявил отклонений, от ситуации, когда он не выполнялся вовсе.
Регистрация результатов контроля состава ПО, запускаемого при загрузке ОС, должна осуществляться средствами журналирования аппаратно-программного модуля доверенной загрузки (АПМДЗ).
Журналы событий программных средств защиты информации (СЗИ) общего назначения (контроль приложений EDR/EPP-агентов, антивирусов, централизованных консолей управления, например Kaspersky Security Center) фиксируют запуск процессов, инициированный пользователем или системой уже после старта ОС, и не являются регистрацией результатов контроля на этапе загрузки — такие журналы можно использовать только как дополнительное свидетельство к основному, полученному от АПМДЗ/СДЗ, но не как самостоятельное закрытие меры (см. выявленные коллизии).
Класс используемых средств — журнал аппаратно-программного модуля доверенной загрузки (АПМДЗ) / средства доверенной загрузки (СДЗ).
Российские сертифицированные (ФСТЭК/ФСБ): ПАК «Соболь» (Код Безопасности), «Аккорд-АМДЗ» (ОКБ САПР) и др. Зарубежные и открытые аналоги данного класса в РФ не применяются в силу требований ФСТЭК/ФСБ к доверенной загрузке.
- Выгрузка зарегистрированных результатов проверок автозагрузки за проверяемый период.
- Итоги интервью с ответственным за мониторинг ИБ.
- Регистрируются только случаи выявленных отклонений, а не каждый цикл проверки, что не позволяет подтвердить регулярность контроля;
- Отсутствует связь между событием регистрации и конкретной версией эталонного перечня, на соответствие которому проводилась проверка;
- События регистрации результатов контроля автозагрузки не передаются в SIEM-систему, доступны только в локальном журнале АПМДЗ;
- Периодичность формирования события не соответствует фактической периодичности проверок автозагрузки на образцах АРМ.
Не выявлены.
Не выявлены.
Регистрация результатов выполнения операций контроля целостности запускаемых компонентов ПО АС.
Уровень защиты информации 3-Н, 2-Н, 1-Т.
Пояснение
Мера требует, чтобы каждая проверка целостности запускаемых компонентов ПО автоматизированных систем (АС) на АРМ (мера ЦЗИ.24) фиксировалась как событие защиты информации с результатом — не только сама блокировка при выявленном нарушении, но и факт штатной успешной проверки.
Главная цель меры — подтвердить, что контроль целостности реально выполнялся в конкретный период, а не только зафиксировать случаи его срабатывания: доступность полной истории проверок (включая штатные, без нарушений) необходима как для расследования инцидента, связанного с подменой компонента АС, так и для подтверждения непрерывности работы самого механизма контроля.
Регистрация обеспечивается настройкой средства контроля целостности запускаемых файлов (мера ЦЗИ.24) на формирование события при каждой проведённой проверке — как при успешном подтверждении целостности, так и при выявленном нарушении, с последующей передачей событий в SIEM-систему.
Класс используемых средств — встроенный механизм журналирования средства контроля целостности запускаемых файлов (File Integrity Monitoring) в составе EDR/HIPS-платформы, система централизованного сбора и корреляции событий (SIEM).
Примеры таких средств:
- Иностранные: Tripwire for Servers, Splunk и пр.
- Российские сертифицированные (ФСТЭК): Kaspersky Endpoint Security для бизнеса, MaxPatrol SIEM, KUMA и др.
- Открытый код: Wazuh (модуль FIM) и др.
- Конфигурация журналирования результатов проверок целостности запускаемых компонентов ПО АС на образце АРМ.
- Выгрузка зарегистрированных результатов проверок за проверяемый период, включая штатные (без нарушений).
- Итоги интервью с ответственным за администрирование АРМ.
- Регистрируются только случаи выявленного нарушения целостности (блокировки), штатные успешные проверки не фиксируются, что не позволяет подтвердить непрерывность контроля;
- Событие не содержит идентификатор проверенного компонента ПО АС и его контрольную сумму, что затрудняет последующий анализ;
- События проверок целостности не передаются в SIEM-систему, доступны только в локальном журнале средства защиты на АРМ;
- Регистрация результатов настроена не для всех компонентов ПО АС, подлежащих контролю целостности по мере ЦЗИ.24, а только для основного исполняемого файла.
Не выявлены.
Не выявлены.
Регистрация выявления использования технологии мобильного кода.
Уровень защиты информации 3-Н, 2-Т, 1-Т.
Пояснение
Мера требует регистрации в качестве события защиты информации каждого факта выявления использования технологии мобильного кода (мера ЦЗИ.26).
Главная цель меры — обеспечить полную и доступную для последующего анализа историю применения мобильного кода в инфраструктуре: без регистрации таких фактов как отдельных событий защиты информации оценка масштаба и правомерности использования этой технологии сводится к разрозненным наблюдениям, не пригодным для расследования инцидента или периодического анализа тенденций.
Регистрация обеспечивается настройкой средства выявления использования технологии мобильного кода (мера ЦЗИ.26) на автоматическое формирование события при каждом выявленном факте, с фиксацией источника, типа мобильного кода и затронутого актива, и последующей передачей событий в SIEM-систему для централизованного анализа.
Класс используемых средств — встроенный механизм журналирования средства анализа сетевого трафика и содержимого / EDR-платформы, система централизованного сбора и корреляции событий (SIEM).
Примеры таких средств:
- Иностранные: Symantec Content Analysis, Palo Alto Networks (WildFire) и пр.
- Российские сертифицированные (ФСТЭК): Kaspersky Endpoint Security для бизнеса, PT Sandbox, MaxPatrol SIEM и др.
- Открытый код: Sysmon (события создания процессов интерпретаторов), Wazuh и др.
- Конфигурация журналирования фактов выявления использования технологии мобильного кода.
- Выгрузка зарегистрированных событий за проверяемый период.
- Итоги интервью с ответственным за мониторинг ИБ.
- Регистрация событий охватывает не все каналы, по которым выявляется мобильный код (мера ЦЗИ.26), а только часть из них;
- События не содержат сведений о типе мобильного кода и затронутом активе, что не позволяет провести содержательный анализ;
- События не передаются в SIEM-систему, доступны только в локальном журнале средства выявления;
- Повторяющиеся факты использования одного и того же типа мобильного кода не агрегируются, что затрудняет выявление тенденций.
Не выявлены.
Не выявлены.
Регистрация результатов выполнения операций по контролю целостности и
достоверности источников получения при распространении и (или) обновлении
ПО АС, ПО средств и систем защиты информации, системного ПО.
Уровень защиты информации 3-Н, 2-Н, 1-Т.
Пояснение
Каждый результат выполнения операций по контролю целостности и достоверности источников получения при распространении и (или) обновлении ПО автоматизированных систем (АС), средств и систем защиты информации, системного ПО (мера ЦЗИ.19) должен регистрироваться в качестве события защиты информации.
Главная цель меры — обеспечить возможность подтвердить, что контроль подлинности источника и целостности каждого полученного обновления фактически выполнялся, а не только зафиксировать случаи выявленного несоответствия: полная история проверок необходима для расследования инцидента, связанного с компрометацией цепочки поставок ПО, и для подтверждения соответствия установленному регламенту.
Регистрация обеспечивается настройкой средства проверки цифровой подписи и контрольных сумм получаемого ПО (мера ЦЗИ.19) на формирование события при каждой выполненной проверке — как при успешном подтверждении подлинности и целостности источника, так и при выявленном несоответствии, с последующей передачей событий в SIEM-систему.
Класс используемых средств — встроенные механизмы журналирования систем патч-менеджмента и менеджеров пакетов, система централизованного сбора и корреляции событий (SIEM).
Примеры таких средств:
- Иностранные: Microsoft SCCM/WSUS (журнал проверки подписи обновлений), Splunk и пр.
- Российские сертифицированные (ФСТЭК): MaxPatrol VM, MaxPatrol SIEM, KUMA и др.
- Открытый код: журнал GPG-проверки пакетного менеджера (apt/yum), Wazuh и др.
- Конфигурация журналирования результатов проверок подлинности источника и целостности получаемого ПО.
- Выгрузка зарегистрированных результатов проверок за проверяемый период, включая выявленные несоответствия (при наличии).
- Итоги интервью с ответственным за получение и распространение обновлений ПО.
- Регистрируются только случаи выявленного несоответствия подписи или контрольной суммы, а не каждая выполненная проверка;
- Регистрация настроена не для всех категорий ПО, подлежащих контролю по мере ЦЗИ.19, а только для обновлений операционной системы;
- События не содержат сведения об источнике получения ПО, что не позволяет впоследствии подтвердить его доверенность;
- Результаты проверок не передаются в SIEM-систему, доступны только в локальном журнале средства патч-менеджмента.
Не выявлены.
Не выявлены.