Контроль состава разрешенного для использования ПО АРМ пользователей и эксплуатационного персонала.
Уровень защиты информации 3-О, 2-Т, 1-Т.
Пояснение
Мера требует ведения перечня разрешённого к использованию программного обеспечения (ПО) на АРМ пользователей и эксплуатационного персонала и периодического контроля фактического состава установленного ПО на предмет соответствия этому перечню. В отличие от меры ЦЗИ.23 (контроль состава ПО, запускаемого именно на этапе загрузки ОС), здесь контролируется полный состав ПО АРМ на протяжении всей работы системы, а не только момент старта.
Главная цель меры — обеспечить видимость фактического состава ПО на рабочих станциях: без регулярного сопоставления с эталонным перечнем неразрешённое ПО (самовольно установленное пользователем, оставшееся после ранее санкционированной задачи, или внедрённое злоумышленником) может присутствовать на АРМ длительное время незамеченным.
Организационная реализация предполагает:
- Формирование и утверждение перечня разрешённого к использованию на АРМ ПО, дифференцированного по категориям пользователей и решаемым задачам;
- Регламентацию порядка пересмотра перечня при возникновении обоснованной потребности в новом ПО;
- Установление периодичности контроля фактического состава ПО АРМ и порядка действий при выявлении несоответствия эталонному перечню.
Базовую инвентаризацию установленного ПО можно получить штатными средствами (диспетчер пакетов операционной системы, PowerShell/WMI-запросы, скрипты) без отдельного приобретения. Однако штатных средств недостаточно для требуемого мерой автоматического сопоставления фактического состава ПО с эталонным перечнем и оповещения ответственных лиц по всему парку АРМ — для этого технический контроль реализуется:
- Автоматизированной инвентаризацией фактически установленного и запущенного ПО на АРМ;
- Автоматическим сопоставлением результатов инвентаризации с перечнем разрешённого ПО и формированием отчёта об отклонениях;
- Оповещением ответственных лиц при выявлении неразрешённого ПО.
Класс используемых средств — штатный диспетчер пакетов ОС и сценарии инвентаризации (базовый уровень); системы инвентаризации программного обеспечения (Software Asset Management), также реализуемые как модуль EDR/EPP-платформы или платформы централизованного управления АРМ — для автоматического сопоставления и оповещения по всему парку.
Примеры таких средств:
- Иностранные: Microsoft SCCM (инвентаризация ПО), Flexera (Software Asset Management) и пр.
- Российские сертифицированные (ФСТЭК): Kaspersky Security Center (инвентаризация ПО), Secret Net Studio (модуль контроля состава ПО) и др.
- Открытый код: Wazuh (модуль инвентаризации ПО, syscollector) и др.
- Перечень разрешённого к использованию ПО АРМ по категориям пользователей;
- Регламент пересмотра перечня и контроля фактического состава ПО АРМ.
- Конфигурация средства инвентаризации ПО.
- Отчёт сопоставления фактического состава ПО с эталонным перечнем за проверяемый период.
- Итоги интервью с ответственным за администрирование АРМ.
- Перечень разрешённого ПО не актуализирован, не отражает реально используемое в работе ПО, из-за чего фиксируется массовое «несоответствие»;
- Инвентаризация фактического состава ПО проводится не по всему парку АРМ, а выборочно;
- Выявленные отклонения от эталонного перечня не анализируются и не приводят к каким-либо действиям;
- Контроль охватывает только ПО, установленное штатным образом, но не переносимые (portable) версии приложений, не требующие установки.
Не выявлены.
Не выявлены.
Исключение возможности установки и (или) запуска неразрешенного для использования ПО АРМ пользователей и эксплуатационного персонала.
Уровень защиты информации 3-О, 2-Т, 1-Т.
Пояснение
Мера требует не только выявления неразрешённого ПО на АРМ (мера ЦЗИ.20), но и технического исключения самой возможности его установки и (или) запуска — то есть перехода от детективного контроля к превентивному блокированию.
Главная цель меры — не допустить исполнения неразрешённого (в том числе вредоносного) кода на АРМ в принципе: при исключительно детективном контроле (мера ЦЗИ.20) неразрешённое ПО успевает выполниться до момента обнаружения, тогда как превентивная блокировка устраняет саму возможность запуска.
Организационная реализация предполагает:
- Определение режима контроля (whitelisting — разрешено только явно перечисленное ПО, либо blacklisting — запрещено только явно перечисленное) исходя из категории АРМ и критичности решаемых на них задач;
- Регламентацию порядка оперативного согласования запуска нового ПО, требующегося пользователю для решения рабочей задачи, без длительного простоя;
- Определение перечня АРМ, для которых применение технологии контроля запуска ПО невозможно по производственным причинам, с компенсирующими мерами.
Техническая реализация обеспечивается применением технологии контроля запуска приложений (application control / whitelisting), блокирующей установку и (или) запуск ПО, не входящего в перечень разрешённого. Контроль может осуществляться по признакам пути размещения файла, издателя (цифровой подписи) или хеш-суммы конкретной версии — предпочтительным является контроль по цифровой подписи или хешу как более устойчивый к обходу простым переименованием или перемещением файла.
Класс используемых средств — средства контроля запуска приложений (application control), как правило, входящие в состав EDR/EPP-платформы или отдельного решения класса Host Intrusion Prevention System (HIPS).
Примеры таких средств:
- Иностранные: Carbon Black App Control, Microsoft AppLocker (встроенный компонент Windows) и пр.
- Российские сертифицированные (ФСТЭК): Kaspersky Endpoint Security для бизнеса (модуль контроля запуска приложений), Secret Net Studio (замкнутая программная среда) и др.
- Открытый код: встроенный модуль AppArmor/SELinux (Linux) и др.
- Регламент, определяющий режим контроля запуска ПО (whitelisting/blacklisting) и порядок согласования запуска нового ПО;
- Перечень АРМ, исключённых из технического контроля запуска ПО, с указанием компенсирующих мер (при наличии).
- Конфигурация средства контроля запуска приложений на образце АРМ.
- Журнал событий блокировки запуска неразрешённого ПО за проверяемый период.
- Итоги интервью с ответственным за администрирование АРМ.
- Технология контроля запуска приложений применяется не на всех АРМ, а выборочно, без формального обоснования исключений;
- Контроль настроен по пути размещения файла, что позволяет обойти блокировку простым копированием разрешённого файла поверх запрещённого;
- Режим работы фактически переведён в «только уведомление» без реальной блокировки, чтобы избежать обращений пользователей;
- Правила контроля не пересматриваются при изменении перечня разрешённого ПО (мера ЦЗИ.20), из-за чего накапливается рассинхронизация.
Не выявлены.
Не выявлены.
Контроль состава ПО серверного оборудования.
Уровень защиты информации 3-Н, 2-О, 1-Т.
Пояснение
Мера аналогична ЦЗИ.20, но распространяется на серверное оборудование: требует ведения перечня разрешённого к использованию ПО серверов и периодического контроля фактического состава установленного ПО на соответствие этому перечню.
Главная цель меры — ограничить состав ПО серверов исключительно тем, что необходимо для выполнения ими своих функций: избыточное ПО (неиспользуемые службы, средства удалённого администрирования сомнительного происхождения, оставленный инструментарий разработки) на сервере расширяет поверхность атаки в существенно более критичном сегменте инфраструктуры, чем рабочая станция.
Организационная реализация предполагает:
- Формирование и утверждение перечня разрешённого к использованию ПО для каждого класса (роли) серверов исходя из выполняемых функций;
- Регламентацию порядка согласования установки дополнительного ПО на сервер и порядка периодического пересмотра эталонного перечня;
- Установление периодичности контроля фактического состава ПО серверов и порядка действий при выявлении несоответствия.
Технический контроль реализуется автоматизированной инвентаризацией фактически установленного ПО на серверах и его сопоставлением с эталонным перечнем для соответствующего класса (роли) сервера, с оповещением ответственных лиц при выявлении отклонений.
Класс используемых средств — системы инвентаризации программного обеспечения (Software Asset Management), также реализуемые как модуль централизованной платформы управления серверами или средства контроля конфигураций.
Примеры таких средств:
- Иностранные: Microsoft SCCM, Tanium (инвентаризация активов) и пр.
- Российские сертифицированные (ФСТЭК): Kaspersky Security Center, Efros Config Inspector и др.
- Открытый код: Ansible (инвентаризационные плейбуки), Wazuh (syscollector) и др.
- Перечень разрешённого к использованию ПО по классам (ролям) серверов;
- Регламент согласования установки дополнительного ПО и контроля фактического состава ПО серверов.
- Конфигурация средства инвентаризации ПО серверного оборудования.
- Отчёт сопоставления фактического состава ПО серверов с эталонным перечнем за проверяемый период.
- Итоги интервью с ответственным за администрирование серверной инфраструктуры.
- Эталонный перечень разрешённого ПО единый для всех серверов без дифференциации по классам (ролям), что делает контроль формальным;
- Инвентаризация фактического состава ПО серверов проводится нерегулярно или не охватывает весь парк;
- Установка дополнительного ПО на сервер в рамках оперативных задач (например, при расследовании инцидента) не документируется и не удаляется впоследствии;
- Выявленные отклонения от эталонного перечня не приводят к удалению избыточного ПО в разумный срок.
Не выявлены.
Не выявлены.
Контроль состава ПО АРМ пользователей и эксплуатационного персонала, запускаемого при загрузке операционной системы.
Уровень защиты информации 3-Н, 2-Т, 1-Т.
Пояснение
Мера направлена на контроль состава программного обеспечения (ПО), инициализируемого на этапе загрузки операционной системы (ОС): автозапускаемые драйверы, службы, компоненты инициализации — то есть до завершения полной загрузки ОС и начала пользовательской сессии. Это отдельный объект контроля по отношению к мерам ЦЗИ.20/21 (здесь не контроль состава ПО АРМ в целом в любой момент работы системы, а именно перед запуском ОС). Без контроля состава на этапе загрузки вредоносный или неразрешённый компонент, встроенный в автозагрузку, может получить управление раньше, чем инициализируются пользовательские механизмы защиты, и скрыть своё присутствие от последующего контроля, закрепиться в системе с высокими привилегиями, обойти контроль состава ПО, реализуемый мерами ЦЗИ.20/21/32.
Главная цель меры — не допустить получения управления системой вредоносным или неразрешённым компонентом до момента, когда становятся доступны штатные средства защиты уровня ОС: контроль состава ПО на этапе загрузки закрывает разрыв, который не покрывают меры ЦЗИ.20/21/32, ориентированные на состав ПО уже работающей ОС.
Мера требует реализацию контроля состава ПО, запускаемого при загрузке ОС, что достигается средствами доверенной загрузки (СДЗ) — как правило, отдельным аппаратно-программным модулем доверенной загрузки (АПМДЗ). Такие средства инициализируются до полной загрузки ОС и формируют независимую от неё проверку состава компонентов, участвующих в загрузке. Встроенного в большинство современных АРМ механизма UEFI Secure Boot самого по себе недостаточно для закрытия меры: он не является сертифицированным средством доверенной загрузки, не формирует независимого от ОС журнала событий контроля (см. также меру ЦЗИ.33) и не удовлетворяет требованиям ФСТЭК/ФСБ к доверенной загрузке — поэтому необходим именно отдельный сертифицированный аппаратно-программный модуль.
При выборе инструмента реализации необходимо запрашивать у производителя техническую документацию (руководство администратора), явно подтверждающую работу заявленного механизма на этапе, предшествующем полной загрузке ОС, и уточнять, требуется ли для этого отдельный сертифицированный модуль, не входящий в базовую поставку продукта (см. выявленные коллизии).
Класс используемых средств — аппаратно-программные модули доверенной загрузки (АПМДЗ) / средства доверенной загрузки (СДЗ).
Российские сертифицированные (ФСТЭК/ФСБ): ПАК «Соболь» (Код Безопасности), «Аккорд-АМДЗ» (ОКБ САПР) и др. Зарубежные и открытые аналоги данного класса в РФ не применяются в силу требований ФСТЭК/ФСБ к доверенной загрузке.
- Конфигурация СДЗ с перечнем разрешенного к запуску ПО в момент загрузки ОС.
- Выгрузка перечня компонентов автозагрузки с образца АРМ и его сопоставление с эталоном разрешённого ПО.
- Журнал оповещений о выявленных отклонениях от эталонной автозагрузки за проверяемый период.
- Итоги интервью с ответственным за защиту АРМ.
- Контроль охватывает не все механизмы автозапуска (например, задачи планировщика не проверяются, только автозагрузка реестра).
- Эталонный перечень разрешённых компонентов автозагрузки не актуализирован.
- Выявленные отклонения фиксируются, но не эскалируются ответственному за ИБ.
Не выявлены.
Не выявлены.
Контроль целостности запускаемых компонентов ПО АС на АРМ пользователей и эксплуатационного персонала.
Уровень защиты информации 3-Н, 2-Н, 1-Т.
Пояснение
Мера требует, чтобы при каждом запуске компонента прикладного ПО автоматизированной системы (АС) на АРМ пользователя или эксплуатационного персонала проверялось, что запускаемый файл не был изменён с момента последней проверенной (эталонной) версии.
Главная цель меры — исключить возможность подмены легитимного компонента АС вредоносным аналогом (троянизация, DLL hijacking) непосредственно на рабочей станции: без контроля целостности на старте запуск скомпрометированного клиентского модуля АС остаётся незамеченным, а подменённый компонент получает доступ ко всем данным и полномочиям, которыми обладает легитимное ПО АС.
На АРМ устанавливается средство контроля целостности (класс File Integrity Monitoring / Application Control в составе EDR/HIPS), которое при запуске компонента ПО АС сверяет его контрольную сумму или цифровую подпись с эталонным значением, а при несовпадении — блокирует запуск и генерирует событие защиты информации (см. также меру ЦЗИ.34 в части регистрации результатов). Для АРМ на базе Windows частично штатным вариантом (без отдельного приобретения EDR/HIPS) выступают встроенные компоненты AppLocker или Windows Defender Application Control (WDAC), поддерживающие проверку цифровой подписи (хеша) файла перед запуском; однако для полноценного покрытия требования меры — централизованного управления эталонными значениями по всему парку АРМ и передачи событий блокировки в общий контур регистрации (мера ЦЗИ.34) — штатных возможностей, как правило, недостаточно, и используется специализированное средство защиты.
Класс используемых средств — встроенные компоненты контроля запуска приложений операционной системы (AppLocker, WDAC — штатная, частичная возможность); средства контроля целостности запускаемых файлов (File Integrity Monitoring) в составе EDR/HIPS-платформы — для централизованного управления и регистрации по всему парку.
Примеры таких средств:
- Иностранные: Carbon Black App Control, Tripwire for Servers и пр.
- Российские сертифицированные (ФСТЭК): Kaspersky Endpoint Security для бизнеса (модуль контроля целостности/Application Control), Dallas Lock 8.0 (СЗИ от НСД с функцией контроля целостности) и др.
- Открытый код: Wazuh (модуль FIM — File Integrity Monitoring) и др.
- Конфигурация средства контроля целостности запускаемых файлов ПО АС на образце АРМ.
- Эталонный перечень контрольных сумм (цифровых подписей) компонентов ПО АС.
- Журнал событий блокировки запуска компонентов ПО АС с нарушенной целостностью за проверяемый период.
- Итоги интервью с ответственным за администрирование АРМ.
- Контроль целостности настроен не для всех компонентов ПО АС, а только для основного исполняемого файла, без учёта подключаемых библиотек (DLL);
- Эталонные значения контрольных сумм не обновляются согласованно с выпуском новых версий ПО АС, что приводит к массовым ложным блокировкам и последующему отключению контроля;
- При выявлении нарушения целостности запуск блокируется, но событие не передаётся в SIEM-систему для централизованного анализа;
- Контроль целостности реализован только детективно (уведомление), без фактической блокировки запуска изменённого компонента.
Не выявлены.
Не выявлены.
Реализация доверенной загрузки операционных систем АРМ пользователей и эксплуатационного персонала.
Уровень защиты информации 3-Н, 2-Н, 1-Т.
Пояснение
Мера требует, чтобы загрузка операционной системы (ОС) на АРМ пользователей и эксплуатационного персонала проверялась на подлинность и неизменность ещё до старта самой ОС.
Главная цель меры — исключить загрузку АРМ с постороннего носителя (USB, LiveCD) или с модифицированным загрузчиком: буткит или руткит, внедрённый на этом этапе, начинает работу раньше средств защиты уровня ОС и остаётся для них невидимым, получая контроль над системой до того, как штатные механизмы защиты успевают инициализироваться.
На АРМ применяется аппаратно-программный модуль доверенной загрузки (АПМДЗ), проверяющий целостность загрузчика и BIOS/UEFI и блокирующий загрузку с посторонних носителей до входа в доверенную ОС. Встроенного UEFI Secure Boot без выделенного сертифицированного модуля недостаточно для закрытия меры — требуется отдельный аппаратный модуль доверенной загрузки.
Класс используемых средств — аппаратно-программные модули доверенной загрузки (АПМДЗ).
Российские сертифицированные (ФСТЭК/ФСБ): ПАК «Соболь» (Код Безопасности), «Аккорд-АМДЗ» (ОКБ САПР) и др. Зарубежные АПМДЗ в РФ не применяются в силу требований ФСТЭК/ФСБ к доверенной загрузке.
- Конфигурация АПМДЗ и Secure Boot на образце АРМ.
- Акт установки и активации модуля доверенной загрузки по парку АРМ (значим с точки зрения требований ФСБ).
- Итоги интервью с ответственным за защиту АРМ.
- АПМДЗ установлен не на всех АРМ пользователей и эксплуатационного персонала, включая АРМ с повышенными полномочиями;
- Используется только программный UEFI Secure Boot без сертифицированного аппаратного модуля там, где требуется более строгий контроль;
- Пароль (ПИН-код) администратора АПМДЗ не меняется со значения по умолчанию, установленного при внедрении;
- Факт срабатывания блокировки АПМДЗ (попытка загрузки с постороннего носителя) не передаётся для централизованного анализа.
Не выявлены.
Не выявлены.
Контроль (выявление) использования технологии мобильного кода <*>.
Уровень защиты информации 3-Н, 2-Т, 1-Т.
Пояснение
Мера требует контроля (выявления) фактов использования в автоматизированной системе (АС) технологии мобильного кода — программного кода, который передаётся по сети и исполняется на стороне получателя без предварительной установки (сценарии в составе веб-страниц, макросы офисных документов, объекты ActiveX, сценарии PowerShell/командных интерпретаторов, загружаемые Java-апплеты и подобные механизмы).
Главная цель меры — обеспечить видимость применения технологии, которая по своей природе способна исполнять произвольные инструкции без явного действия пользователя по «установке» и потому нередко выпадает из поля зрения традиционного контроля состава ПО (меры ЦЗИ.20/22): без выявления фактов использования мобильного кода организация не может оценить связанный с этим риск и целенаправленно ограничить его применение только оправданными случаями.
Технический контроль реализуется:
- Анализом сетевого и почтового трафика на предмет передачи объектов, содержащих технологию мобильного кода (сценарии, макросы, ActiveX-объекты, вложения с активным содержимым);
- Контролем на стороне АРМ и серверов фактов запуска интерпретаторов сценариев (командных оболочек, PowerShell, WSH) и активации макросов офисных документов;
- Регистрацией и централизованным анализом выявленных фактов использования мобильного кода для последующей оценки их правомерности (см. также меру ЦЗИ.35 в части регистрации).
Класс используемых средств — средства анализа сетевого трафика и содержимого (Content Filtering / Sandbox), функциональность выявления сценариев в составе EDR/EPP-платформы.
Примеры таких средств:
- Иностранные: Symantec Content Analysis (песочница), Palo Alto Networks (WildFire, анализ содержимого) и пр.
- Российские сертифицированные (ФСТЭК): Kaspersky Endpoint Security для бизнеса (контроль макросов и сценариев), PT Sandbox и др.
- Открытый код: встроенное журналирование PowerShell (Script Block Logging), Sysmon (события создания процессов интерпретаторов) и др.
- Конфигурация средства выявления использования технологии мобильного кода.
- Журнал (отчёт) выявленных фактов использования мобильного кода за проверяемый период.
- Итоги интервью с ответственным за мониторинг ИБ.
- Контроль охватывает только один канал (например, только почтовые вложения), тогда как мобильный код может поступать и через веб-трафик, съёмные носители или уже присутствовать во внутренних документах;
- Выявленные факты использования мобильного кода не анализируются на предмет правомерности, а лишь накапливаются в журнале без дальнейших действий;
- Контроль настроен только для распространённых форматов (макросы Office), но не охватывает менее очевидные механизмы (сценарии PowerShell, встроенный JavaScript в PDF);
- Пороговые значения (правила выявления) не пересматриваются при появлении новых техник использования мобильного кода злоумышленниками.
Не выявлены.
Не выявлены.