Контроль размещения и своевременного обновления на серверном и сетевом оборудовании ПО средств и систем защиты информации, прикладного ПО, ПО АС, системного ПО и сигнатурных баз средств защиты информации, в том числе с целью устранения выявленных уязвимостей защиты информации.
Уровень защиты информации 3-О, 2-О, 1-Т.
Пояснение
Мера требует контролировать, что программное обеспечение (средств защиты информации, прикладное, ПО АС, системное) и сигнатурные базы средств защиты информации на серверном и сетевом оборудовании фактически развёрнуты в соответствии с эталонным составом и своевременно обновляются, в том числе для устранения выявленных в рамках мер ЦЗИ.1—ЦЗИ.10 уязвимостей.
Главная цель меры — не допустить разрыва между выявлением уязвимости (мерами ЦЗИ.1—ЦЗИ.10) и её фактическим устранением: обнаружение уязвимости само по себе не защищает организацию, если процесс размещения и применения обновлений не отлажен, не контролируется централизованно и не подтверждается фактическим результатом на всём парке серверного и сетевого оборудования.
Организационная реализация предполагает:
- Разработку и утверждение регламента управления обновлениями (patch management), определяющего источники обновлений, порядок тестирования (см. также меру ЦЗИ.14), сроки установки в зависимости от критичности и ответственных лиц;
- Ведение эталонного перечня версий ПО и сигнатурных баз, подлежащих поддержанию в актуальном состоянии на серверном и сетевом оборудовании;
- Периодический контроль фактического соответствия установленных версий эталонному перечню с оформлением результатов актом.
Мера широкая и закрывается несколькими дополняющими друг друга техническими подходами:
- Патч-менеджмент — автоматизированная инвентаризация версий ПО на серверном и сетевом оборудовании, сопоставление с базами уязвимостей, применение обновлений по расписанию с контролем результата;
- Централизованное управление серверами (платформа класса endpoint/server management) — единая консоль развёртывания и контроля обновлений ПО и сигнатурных баз СЗИ на всём парке серверов;
- Контроль целостности и соответствия конфигураций — фиксация эталонных версий ПО серверного и сетевого оборудования, автоматическое выявление отклонений (устаревшая версия, несанкционированный откат обновления);
- Регистрация и сверка через SIEM-систему — события установки и обновления ПО собираются в SIEM и сверяются с плановым графиком обновлений.
Встроенных средств отдельных операционных систем (например, WSUS, apt/yum) не всегда достаточно — рекомендуется обеспечить централизованный охват и подтверждение результата по всей инфраструктуре, чего разрозненные штатные средства обеспечить не могут.
Класс используемых средств — системы управления обновлениями и уязвимостями (Patch/Vulnerability Management), платформы централизованного управления серверами, средства контроля целостности конфигураций.
Примеры таких средств:
- Иностранные: Ivanti Patch Management, Microsoft SCCM, Tripwire Enterprise и пр.
- Российские сертифицированные (ФСТЭК): MaxPatrol VM, Kaspersky Security Center (модуль управления обновлениями), «Efros Config Inspector» и др.
- Открытый код: Ansible (плейбуки инвентаризации и обновления пакетов), Wazuh (регистрация и сверка событий) и др.
- Регламент управления обновлениями (patch management);
- Эталонный перечень версий ПО и сигнатурных баз, подлежащих поддержанию в актуальном состоянии;
- Акты периодического контроля соответствия установленных версий эталонному перечню.
- Конфигурация системы патч-менеджмента.
- Выгрузка инвентаризации версий ПО и истории обновлений серверного/сетевого оборудования.
- Итоги интервью с ответственным за эксплуатацию серверной инфраструктуры.
- Акты устранения уязвимостей.
- Регламент управления обновлениями не охватывает все категории ПО (например, забыли про сигнатурные базы или сетевое оборудование);
- Обновления устанавливаются нерегулярно, без контроля фактического охвата всего парка серверного и сетевого оборудования;
- Централизованный контроль версий и сигнатурных баз отсутствует, полагаются только на разрозненные штатные средства отдельных систем;
- Фактическое устранение уязвимости после установки обновления не подтверждается повторной проверкой.
Не выявлены.
Не выявлены.
Контроль размещения и своевременного обновления на АРМ пользователей и эксплуатационного персонала ПО средств и систем защиты информации, прикладного ПО, ПО АС и системного ПО, в том числе с целью устранения выявленных уязвимостей защиты информации.
Уровень защиты информации 3-О, 2-О, 1-Т.
Пояснение
Мера аналогична ЦЗИ.12, но распространяется на автоматизированные рабочие места (АРМ) пользователей и эксплуатационного персонала: их программное обеспечение (средства защиты информации, прикладное, ПО АС, системное) должно контролироваться на предмет размещения в соответствии с эталонным составом и своевременно обновляться, в том числе для устранения выявленных уязвимостей.
Главная цель меры — обеспечить актуальность и защищённость ПО именно на рабочих станциях, парк которых, как правило, существенно многочисленнее серверного оборудования, а обновление зависит не только от централизованных процессов, но и от фактического подключения конкретного АРМ к сети в момент распространения обновления.
Организационная реализация предполагает:
- Распространение регламента управления обновлениями (мера ЦЗИ.12) на парк АРМ пользователей и эксплуатационного персонала с учётом его специфики (территориальной распределённости, непостоянного подключения к сети);
- Установление предельного срока, в течение которого АРМ, не получившее критичное обновление, подлежит принудительному изолированию от сети до устранения отставания;
- Периодический контроль фактического охвата парка АРМ актуальными обновлениями с оформлением результатов актом.
Штатным (не требующим отдельного приобретения) базовым каналом распространения обновлений служат встроенные механизмы самой операционной системы — служба WSUS (роль Windows Server) для домена Windows или unattended-upgrades/apt-mirror для Linux, — способные централизованно распространять обновления по расписанию без выделенного средства защиты информации. Однако штатных средств недостаточно для явно требуемого мерой контроля фактического охвата парка АРМ, автоматического выявления отставших устройств и их принудительной изоляции — для этого мера широкая и закрывается несколькими дополняющими друг друга техническими подходами:
- Патч-менеджмент АРМ — централизованное развёртывание обновлений на пользовательские рабочие станции по расписанию, с контролем фактического охвата парка;
- Централизованное управление конечными точками (EPP-платформа или платформа управления АРМ) — единая консоль обновления ПО как один из модулей общей платформы защиты рабочих станций;
- Контроль целостности и состава ПО АРМ — фиксация эталонного набора версий ПО на образе АРМ и выявление отклонений (устаревшая версия, самовольный откат);
- Регистрация и сверка через SIEM-систему — события установки и обновления ПО на АРМ (см. также меру ЦЗИ.29) собираются в SIEM и сверяются с плановым графиком.
Класс используемых средств — штатная служба обновлений ОС (WSUS, apt) для базового распространения обновлений; системы управления обновлениями и уязвимостями (Patch/Vulnerability Management) и платформы централизованного управления конечными точками (EPP) — для контроля охвата парка, отчётности и выявления отклонений.
Примеры таких средств:
- Иностранные: Ivanti Patch Management, Microsoft SCCM и пр.
- Российские сертифицированные (ФСТЭК): MaxPatrol VM, Kaspersky Security Center (модуль управления обновлениями) и др.
- Открытый код: Ansible (плейбуки инвентаризации и обновления пакетов) и др.
- Регламент управления обновлениями, распространённый на парк АРМ, с учётом его специфики;
- Свидетельства принудительной изоляции от сети АРМ, не получивших критичные обновления в установленный срок (при наличии таких случаев).
- Конфигурация централизованной системы управления обновлениями.
- Отчёт о статусе последних обновлений по парку АРМ за проверяемый период.
- Итоги интервью с ответственным за поддержку пользователей.
- Акты устранения уязвимостей.
- Значительная часть парка АРМ не подключается к сети регулярно, из-за чего обновления на них не устанавливаются длительное время;
- Централизованный контроль фактического охвата парка АРМ актуальными обновлениями не ведётся;
- Критичные обновления АРМ устанавливаются с той же приоритетностью, что и некритичные;
- Отклонения от эталонного состава ПО на образе АРМ (самовольный откат обновлений пользователем) не выявляются.
Не выявлены.
Не выявлены.
Контроль работоспособности (тестирование) и правильности функционирования АС после выполнения обновлений ПО, предусмотренного мерами ЦЗИ.12 и ЦЗИ.13 настоящей таблицы, выполняемого в сегментах разработки и тестирования.
Уровень защиты информации 3-О, 2-О, 1-О.
Пояснение
Мера требует, чтобы обновления, устанавливаемые в рамках мер ЦЗИ.12 и ЦЗИ.13, предварительно проверялись в отдельном сегменте разработки и тестирования (мера СМЭ.6) на предмет работоспособности и корректности функционирования автоматизированной системы (АС), прежде чем применяться в продуктивной среде.
Главная цель меры — не допустить ситуации, когда установка обновления нарушает функциональность или защитные механизмы АС: без предварительной проверки в тестовом сегменте «слепое» применение обновлений в продуктивной среде способно привести к простою критичных систем, что зачастую наносит больший ущерб, чем сама уязвимость, которую обновление устраняет.
Мера реализуется исключительно организационными методами и предполагает:
- Регламентацию обязательного этапа тестирования обновлений в сегменте разработки и тестирования перед их применением в продуктивной среде — во внутреннем нормативном документе (положении об обеспечении защиты информации на стадиях жизненного цикла автоматизированных систем);
- Формирование набора тест-кейсов, покрывающих ключевые функции АС, для проверки её работоспособности после установки обновления;
- Документальную фиксацию результатов тестирования и формальное согласование выкатки обновления в продуктивную среду ответственным лицом.
На практике мера, как правило, реализуется базовыми средствами (staging-окружением, ручным тестированием по чек-листу) без выделенного средства защиты информации; для повышения зрелости процесса рекомендуется формализованный CI/CD-пайплайн с автоматизированными тестами.
- Внутренний нормативный документ, устанавливающий обязательность тестирования обновлений перед применением в продуктивной среде;
- Набор тест-кейсов для проверки работоспособности АС после установки обновления;
- Протоколы (акты) тестирования обновлений с результатами и согласованием выкатки в продуктивную среду.
- Тестирование обновлений в сегменте разработки и тестирования проводится не для всех обновлений, а выборочно;
- Тест-кейсы не охватывают ключевые функции АС, ограничиваются поверхностной проверкой запуска;
- Согласование выкатки обновления в продуктивную среду носит формальный характер, без анализа результатов тестирования;
- Результаты тестирования не фиксируются документально, что не позволяет подтвердить факт его проведения.
Не выявлены.
Не выявлены.
Контроль отсутствия и обеспечение оперативного устранения известных (описанных) уязвимостей защиты информации после выполнения обновлений ПО, предусмотренного мерой ЦЗИ.12 настоящей таблицы.
Уровень защиты информации 3-О, 2-Т, 1-Т.
Пояснение
Мера требует, чтобы после установки обновлений ПО на серверном и сетевом оборудовании (мера ЦЗИ.12) проводилась повторная проверка на отсутствие известных уязвимостей — как для подтверждения того, что устраняемая обновлением уязвимость действительно закрыта, так и для выявления новых уязвимостей, которые могло привнести само обновление.
Главная цель меры — не полагаться на предположение, что установка обновления автоматически означает устранение уязвимости: некорректно применённое обновление, конфликт версий или ошибка в самом обновлении способны оставить уязвимость открытой или создать новую, и только повторная проверка подтверждает фактический результат.
Организационная реализация предполагает:
- Установление обязательного этапа повторной проверки (регрессионного сканирования) в регламенте управления обновлениями (мера ЦЗИ.12) как неотъемлемой части процесса устранения уязвимости, а не отдельной по желанию процедуры;
- Определение критериев, при которых устранение уязвимости считается подтверждённым (отсутствие уязвимости по результатам не менее одного повторного сканирования).
Технически контроль дополняется:
- Проведением повторного (регрессионного) сканирования на уязвимости серверного и сетевого оборудования непосредственно после установки обновлений;
- Сопоставлением результатов повторного сканирования с перечнем уязвимостей, выявленных до обновления, для подтверждения их устранения;
- Дополнительным сканированием на предмет новых уязвимостей, которые могло привнести само обновление (например, из-за изменения конфигурации по умолчанию).
Класс используемых средств — средства анализа защищённости (сканеры уязвимостей).
Примеры таких средств:
- Иностранные: Tenable Nessus, Qualys VMDR и пр.
- Российские сертифицированные (ФСТЭК): MaxPatrol VM, «Сканер-ВС» и др.
- Открытый код: OpenVAS и др.
- Регламент управления обновлениями с указанием обязательного этапа повторной проверки после обновления;
- Критерии подтверждения фактического устранения уязвимости.
- Отчёты повторного (регрессионного) сканирования после установки обновлений за проверяемый период;
- Сопоставление перечня уязвимостей до и после обновления, подтверждающее их устранение;
- Итоги интервью с администраторами серверного и сетевого оборудования.
- Повторное сканирование после установки обновлений проводится не всегда, а выборочно;
- Устранение уязвимости считается подтверждённым по факту установки обновления, без фактической повторной проверки;
- Новые уязвимости, привнесённые самим обновлением, не выявляются, так как сканирование ориентировано только на ранее известный перечень;
- Результаты повторного сканирования не сопоставляются с исходным перечнем уязвимостей.
Не выявлены.
Не выявлены.
Обеспечение возможности восстановления эталонных копий ПО АС, ПО средств и систем защиты информации, системного ПО в случаях нештатных ситуаций.
Уровень защиты информации 3-О, 2-О, 1-О.
Пояснение
Мера требует создания и хранения эталонных (заведомо корректных, актуальных) копий программного обеспечения автоматизированных систем (АС), средств и систем защиты информации и системного ПО, а также обеспечения технической возможности восстановления из этих копий в случае нештатной ситуации — сбоя, отказа оборудования, повреждения данных, компрометации системы.
Главная цель меры — минимизировать время простоя и объём потерь при нештатной ситуации: наличие заведомо корректной эталонной копии позволяет оперативно восстановить работоспособность системы, не полагаясь на реконструкцию ПО «с нуля» или на потенциально скомпрометированные текущие версии.
Мера реализуется исключительно организационными методами и предполагает:
- Определение перечня ПО (АС, СЗИ, системного), для которого создание и хранение эталонных копий является обязательным, исходя из критичности систем;
- Установление порядка и периодичности создания эталонных копий, а также требований к месту и условиям их хранения (изолированно от систем-источников, с защитой от несанкционированного доступа);
- Регламентацию порядка тестового восстановления из эталонных копий на периодической основе для подтверждения их фактической пригодности;
- Определение ответственных за создание, хранение и восстановление эталонных копий.
- Регламент (порядок) создания, хранения и восстановления эталонных копий ПО;
- Перечень ПО, для которого созданы эталонные копии, с указанием актуальности (даты последнего обновления копии);
- Акты (протоколы) тестового восстановления из эталонных копий.
- Эталонные копии созданы не для всего критичного ПО, определённого в перечне;
- Эталонные копии хранятся вместе с системами-источниками, без изоляции, что не защищает их от того же инцидента, что и оригинал;
- Тестовое восстановление из эталонных копий не проводится, фактическая пригодность копий не подтверждается;
- Эталонные копии не обновляются при выходе новых версий ПО, восстановление привело бы к устаревшей и уязвимой версии.
Не выявлены.
Не выявлены.
Наличие, учет и контроль целостности эталонных копий ПО АС, ПО средств
и систем защиты информации, системного ПО.
Уровень защиты информации 3-Н, 2-Н, 1-Т.
Пояснение
Мера требует ведения учёта эталонных копий ПО автоматизированных систем (АС), средств и систем защиты информации, системного ПО, созданных в рамках меры ЦЗИ.16, а также контроля их целостности — то есть подтверждения того, что хранимая копия не была изменена (случайно повреждена или преднамеренно скомпрометирована) с момента её создания.
Главная цель меры — исключить ситуацию, когда организация полагается на эталонную копию для восстановления после нештатной ситуации, а фактически копия непригодна: изменена, повреждена или подменена, и это обнаруживается только в момент восстановления, когда времени на альтернативные действия уже нет.
Контроль целостности эталонных копий обеспечивается:
- Вычислением контрольных сумм (хеш-значений) эталонных копий ПО в момент их создания и фиксацией эталонных значений отдельно от самих копий;
- Периодическим автоматическим пересчётом контрольных сумм хранимых копий и их сопоставлением с зафиксированными эталонными значениями;
- Автоматическим оповещением ответственных лиц при выявлении несоответствия — как признака повреждения или несанкционированного изменения копии;
- Ведением учёта (реестра) эталонных копий с указанием версии, даты создания и результатов последней проверки целостности.
Класс используемых средств — средства контроля целостности файлов (file integrity monitoring), в том числе входящие в состав системы резервного копирования или системы контроля конфигураций.
Примеры таких средств:
- Иностранные: Tripwire Enterprise, Veeam Backup & Replication (встроенная проверка целостности резервных копий) и пр.
- Российские сертифицированные (ФСТЭК): Efros Config Inspector, «Кибер Бэкап» (встроенная проверка целостности) и др.
- Открытый код: AIDE, OSSEC (модуль контроля целостности файлов) и др.
- Реестр (учёт) эталонных копий ПО с указанием версий и дат создания.
- Конфигурация средства контроля целостности эталонных копий.
- Журнал (отчёт) результатов периодической проверки целостности эталонных копий за проверяемый период.
- Итоги интервью с ответственным за хранение эталонных копий.
- Контрольные суммы эталонных копий фиксируются в момент создания, но их периодический пересчёт и сверка в дальнейшем не проводятся;
- Эталонные значения контрольных сумм хранятся вместе с самими копиями, без изоляции, что не защищает от согласованной подмены и копии, и эталона;
- Учёт (реестр) эталонных копий ведётся не по всему перечню ПО, для которого копии должны создаваться согласно мере ЦЗИ.16;
- Оповещение об обнаруженном несоответствии контрольной суммы не настроено, нарушение целостности выявляется только при попытке восстановления.
Не выявлены.
Не выявлены.
Наличие, учет и контроль целостности эталонных значений параметров настроек ПО АС, системного ПО, ПО средств и систем защиты информации, возможность восстановления указанных настроек в случаях нештатных ситуаций.
Уровень защиты информации 3-О, 2-О, 1-Т.
Пояснение
Эталонные значения параметров настроек (конфигураций) ПО автоматизированных систем (АС), системного ПО, средств и систем защиты информации подлежат учёту и контролю целостности (соответствия фактических настроек эталонным), а сама возможность восстановления эталонных настроек в случае нештатной ситуации должна быть технически обеспечена.
Главная цель меры — обеспечить, что защитные и функциональные свойства системы определяются не только установленной версией ПО (меры ЦЗИ.16/ЦЗИ.17), но и его настройками: несанкционированное или ошибочное изменение конфигурации способно снизить защищённость системы так же существенно, как отсутствие обновления, а без эталона и контроля отклонений такое изменение останется незамеченным.
Организационная реализация предполагает:
- Определение перечня ПО (АС, системного, СЗИ), для которого фиксация эталонных значений параметров настройки является обязательной, исходя из критичности систем;
- Регламентацию порядка фиксации, пересмотра и хранения эталонных значений настроек, включая ответственных лиц и порядок согласования изменений эталона;
- Регламентацию порядка восстановления эталонных настроек в случае нештатной ситуации (сбоя, несанкционированного изменения) с указанием допустимых сроков восстановления.
Технический контроль реализуется применением системы класса Configuration Management, которая автоматически хранит эталонные конфигурации, выявляет отклонения (drift detection) от них и позволяет откатить настройки к эталону. Хранения конфигураций «как код» (например, набором Ansible-плейбуков или экспортом групповых политик) без выделенного средства защиты для этого недостаточно — необходим именно автоматический контроль дрейфа настроек и оповещение об отклонениях.
Класс используемых средств — системы управления конфигурациями (Configuration Management) с функцией контроля дрейфа настроек (drift detection).
Примеры таких средств:
- Иностранные: Tripwire Enterprise, Ansible + AWX (drift detection) и пр.
- Российские сертифицированные (ФСТЭК): Efros Config Inspector и др.
- Открытый код: Ansible совместно с git (конфигурация как код с историей изменений) и др.
- Перечень ПО, для которого зафиксированы эталонные значения параметров настройки;
- Регламент фиксации, пересмотра и восстановления эталонных настроек;
- Акты (протоколы) восстановления эталонных настроек при нештатных ситуациях (при наличии таких случаев).
- Конфигурация системы контроля конфигураций.
- Отчёт о выявленных отклонениях от эталона за проверяемый период.
- Итоги интервью с ответственным за администрирование АС/СЗИ.
- Эталонные значения настроек зафиксированы не для всего ПО, определённого в перечне, в частности упускается системное ПО и сетевое оборудование;
- Автоматический контроль дрейфа настроек не применяется, конфигурации хранятся «как код», но фактическое отклонение выявляется только вручную и нерегулярно;
- Возможность восстановления эталонных настроек не проверялась тестово, фактическая работоспособность процедуры отката не подтверждена;
- Изменения эталонных значений настроек вносятся без согласования и документальной фиксации причины изменения.
Не выявлены.
Не выявлены.
Контроль целостности и достоверности источников получения при распространении и (или) обновлении ПО АС, ПО средств и систем защиты информации, системного ПО.
Уровень защиты информации 3-О, 2-О, 1-Т.
Пояснение
Мера требует контроля целостности и достоверности источников получения ПО автоматизированных систем (АС), средств и систем защиты информации, системного ПО при его распространении и (или) обновлении — то есть подтверждения того, что дистрибутив или обновление получены именно от легитимного производителя (разработчика) и не были подменены или модифицированы на этапе доставки.
Главная цель меры — противодействовать угрозам цепочки поставок (supply chain): без контроля достоверности источника и целостности получаемого ПО организация рискует установить компонент, скомпрометированный ещё до попадания в её инфраструктуру, — такая подмена не выявляется мерами ЦЗИ.12—ЦЗИ.18, ориентированными на уже установленное ПО.
Организационная реализация предполагает:
- Регламентацию перечня доверенных источников получения ПО (официальные сайты и репозитории производителей, авторизованные дистрибьюторы) для каждой категории используемого ПО;
- Запрет на получение ПО из непроверенных источников (сторонние файлообменники, неофициальные зеркала) во внутреннем нормативном документе;
- Регламентацию обязательной проверки целостности и подлинности получаемого ПО перед его применением, включая порядок действий при выявлении несоответствия.
Технически контроль реализуется:
- Проверкой цифровой подписи дистрибутивов и обновлений производителя перед их применением;
- Сверкой контрольных сумм (хеш-значений) полученного ПО со значениями, опубликованными производителем по доверенному каналу;
- Использованием доверенных (официальных) репозиториев и зеркал с контролем целостности на уровне менеджера пакетов;
- Регистрацией и сверкой через SIEM-систему фактов получения и применения обновлений из внешних источников.
Класс используемых средств — встроенные механизмы проверки цифровой подписи и контрольных сумм пакетов (менеджеры пакетов, средства патч-менеджмента), дополняемые средствами централизованного контроля доверенных источников.
Примеры таких средств:
- Иностранные: встроенная проверка подписи пакетов Microsoft SCCM/WSUS, Ivanti Patch Management и пр.
- Российские сертифицированные (ФСТЭК): MaxPatrol VM (контроль источников обновлений в рамках патч-менеджмента) и др.
- Открытый код: встроенная проверка GPG-подписи пакетов в apt/yum/dnf, sigstore/cosign (проверка подписи контейнерных образов) и др.
- Перечень доверенных источников получения ПО по категориям;
- Внутренний нормативный документ, запрещающий получение ПО из непроверенных источников;
- Регламент проверки целостности и подлинности получаемого ПО.
- Конфигурация средства проверки цифровой подписи и контрольных сумм получаемого ПО.
- Журнал (отчёт) о результатах проверки подлинности и целостности обновлений за проверяемый период, включая выявленные несоответствия (при наличии).
- Итоги интервью с ответственным за получение и распространение обновлений ПО.
- Проверка цифровой подписи и контрольных сумм получаемого ПО настроена не для всех категорий ПО, а выборочно (например, только для ОС, но не для прикладного ПО и СЗИ);
- Перечень доверенных источников не формализован, фактический источник получения ПО определяется на усмотрение конкретного администратора;
- При выявлении несоответствия контрольной суммы или подписи полученное ПО всё равно применяется без разбирательства причины;
- Обновления сторонних (не входящих в состав ОС) компонентов получаются из непроверенных репозиториев, не входящих в утверждённый перечень.
Не выявлены.
Не выявлены.