Обзор публикации NIST SP 800-167 "Guide to Application Whitelisting"

Руслан Рахметов, Security Vision

При выстраивании эффективных процессов управления информационной безопасностью одной из главных задач является т.н. «харденинг», т.е. защищенная настройка операционных систем и приложений с задействованием встроенных функций безопасности. Такой подход оправдан, например, при невозможности приобретения наложенных средств защиты информации при наличии бюджетных, законодательных и прочих ограничений, а также при нежелательности применения дополнительного ПО в критичных системах. Например, при защите значимых объектов КИИ согласно Приказу ФСТЭК №239 приоритет следует отдавать штатному защитному функционалу. При выстраивании системы технических защитных мер штатными средствами для минимизации киберрисков одним из важных и действенных методов является создание разрешительных списков (англ. allow list / white list). При полноценном применении данной концепции создается защищенная программная среда, функционирующая по принципу «запрещено все, что явно не разрешено» (англ. Default Deny, «запрет по умолчанию»). Данный принцип позволяет отсечь существенное количество потенциальных угроз, оставляя атакующим достаточно узкую поверхность атаки и вынуждая их прибегать к продвинутым методам атак (например, с использованием системных утилит "Living-off-the-Land Binaries" или с помощью покупки/кражи цифрового сертификата для подписи кода), что в свою очередь повышает стоимость атаки и, следовательно, снижает привлекательность цели для злоумышленников. Ниже мы рассмотрим документ NIST SP 800-167 "Guide to Application Whitelisting" («Руководство по составлению белого списка приложений»), который содержит предложения по созданию разрешительных списков исполняемых файлов, библиотек, файлов конфигураций путем применения встроенных в ОС технологий и использования разнообразных критериев оценки (цифровая подпись, хэш, расположение файла).

Итак, публикация NIST SP 800-167 дает определение следующим понятиям:

1. Whitelist (белый/разрешительный список) - перечень отдельных сущностей (например, хосты, IP-адреса, email-адреса, имена процессов и приложений), которые могут присутствовать или быть активными в системе в соответствии с заранее определенными правилами;

2. Blacklist (черный/запретительный список) - перечень сущностей, которые были ранее определены как связанные с вредоносной активностью, и их активность на системе должна быть исключена;

3. Graylist (серый/несогласованный список) - перечень сущностей, достоверность которых пока не была оценена, и для этого требуется дополнительная информация или ресурсы.

Разрешительный список приложений ("application whitelist") - это перечень приложений и их компонент (библиотеки, модули, конфигурационные файлы), которые могут присутствовать или быть активными в системе в соответствии с заранее определенными правилами ("baseline"). Данные ограничения реализуются программами контроля приложений (application control programs) или технологиями создания разрешительных списков (application whitelisting technologies).

Технология разрешительных списков призвана защищать от вредоносного ПО, в том числе от образцов, пока неизвестных антивирусным лабораториям. При этом, в отличие от тех же антивирусов, они действуют более строго, разрешая запуск только заранее определенного ПО и блокируя всё остальное. Эта технология также призвана защитить инфраструктуру компании от несанкционированной установки пользователями программного обеспечения, которое может содержать критичные уязвимости, не поддерживаться вендором и нести юридические риски для компании в случае отсутствия лицензии - указанные риски, известные как «Теневое ИТ» ("Shadow IT"), могут принести много головной боли крупным компаниям с разветвленной структурой. При этом следует учесть, что поддержка технологии разрешительных списков в распределенных гетерогенных инфраструктурах также потребует дополнительных накладных расходов на администрирование и оперативную актуализацию разрешений по заявкам пользователей.

В публикации NIST SP 800-167 приведены следующие типы разрешительных списков приложений:

1. Атрибуты файлов и каталогов:

1.1. Путь к файлу. Распространенный, но не самый надежный вариант, поскольку вредоносное ПО с правом записи в каталоги из «разрешительного списка» сможет быть запущено. При этом применение данного атрибута может быть оправдано при использовании строгих правил контроля доступа к каталогам (ACL, access control lists).

1.2. Имя файла. Также достаточно ненадежный вариант, использовать который рекомендуется только в сочетании с другими атрибутами, такими как путь к файлу или его цифровая подпись.

1.3. Размер файла. Также ненадежный вариант, который может быть использован лишь в сочетании с другими атрибутами.

1.4. Цифровая подпись или издатель. Использование цифровых сертификатов для подписи кода (code signing certificates) позволяют подписать хэш-сумму от определенного исполняемого файла или библиотеки с помощью закрытого ключа издателя - компании-разработчика или организации, которая санкционировала исполнение данного файла на своих устройствах. Разрешительный список по имени издателя может избавить от дополнительных трудозатрат на проверку и подпись каждого файла в отдельности, но позволит пользователям запускать любое ПО, созданное данным издателем, включая устаревшее или не рекомендованное к использованию в компании. Единственным минусом данного типа атрибутов, помимо трудозатрат на администрирование списка издателей, является тот факт, что и по сей день не все разработчики ПО подписывают своё ПО цифровыми подписями - отчасти это связано с необходимостью приобретения сертификатов у коммерческих центров сертификации.

1.5. Значение хэш-суммы. Достаточно надежный способ атрибутирования, при этом следует учесть трудозатраты на регулярное обновление списка хэшей при выходе обновлений ПО и на удаление из "белого списка" хэшей старых версий ПО, содержащих уязвимости.

2. Ресурсы приложений. Технологии контроля приложений по разрешительным спискам, как правило, позволяют также контролировать и различные дополнительные атрибуты, помимо непосредственно исполняемых файлов - это могут быть библиотеки, скрипты, макросы, расширения (плагины), файлы конфигураций, значения ключей реестра приложения. Гранулярность мониторинга и блокирования зависят от конкретной технологии контроля приложений.

3. Создание и поддержка разрешительных списков. Создание разрешительного списка можно выполнить на основании данных вендора (предоставленного им списка характеристик/хэшей файлов) или рассчитав хэши на устройстве в известном хорошем состоянии (не подключенном к ЛВС, сразу же после установки ОС и дистрибутива ПО из доверенного источника). Оба метода могут приводить к дополнительным накладным расходам на администрирование и к ложноположительным срабатываниям при обновлении ПО и несвоевременном включении атрибутов файлов новой версии в разрешительный список.

В качестве решения некоторые технологии предлагают опции включения в разрешительный список всех файлов, которые были обновлены каким-либо доверенным сервисом (например, клиентом Microsoft SCCM), а также варианты использования репутационного анализа, при котором неизвестный новый файл не блокируется по умолчанию, а его атрибуты (издатель, сервис-установщик) сверяются с данными систем репутационного анализа для получения вердикта (доброкачественный/вредоносный).

Режимы работы технологий для создания разрешительных списков приложений, в соответствии с документом NIST SP 800-167, могу быть следующими:

1. Режим аудита: запуск всех приложений без ограничений и сбор информации об их атрибутах для дальнейшего анализа;

2. Режим блокирования:

2.1. Запуск только разрешенных приложений с блокированием иного ПО;

2.2. Запрос пользователя (администратора) при попытке запуска приложения не из «белого» / «черного» списка;

2.3. Блокирование приложений только из списка запрещенных и разрешение всех иных приложений.

Кроме непосредственного разрешения или запрещения определенных программ, технологии контроля приложений могут предоставлять следующие возможности:

1. Инвентаризация ПО: контроль версий, издателей, соблюдения лицензионных требований и внутренних нормативных документов по использованию ПО;

2. Мониторинг целостности файлов: мониторинг целостности файлов или предотвращение несанкционированного изменения файлов;

3. Реагирование на киберинциденты: сбор данных о файлах на скомпрометированном хосте, выявление аналогичных подозрительных файлов на других устройствах в сети компании;

4. Дополнительные опции, включающие в себя контроль загруженных в память приложений, репутационный анализ неизвестных файлов, проверка файлов из «серого» списка через онлайн-сканеры вредоносного ПО (например, VirusTotal).

При внедрении решения для контроля приложений авторы документа NIST SP 800-167 рекомендуют придерживаться следующих этапов:

1. Выявление текущих и возможных будущих потребностей и функционала решения для контроля приложений, описание требований к безопасности и производительности, разработка соответствующих внутренних нормативных документов;

2. Разработка архитектуры решения, включая управление разрешительными и запретительными списками, выбор алгоритмов хэширования и цифровой подписи для файлов, а также алгоритмов шифрования канала связи между клиентом и сервером управления, на котором хранятся политики и «белые»/ «черные» списки;

3. Тестирование прототипа выбранного решения в тестовой среде на выбранных устройствах, включая проверку технологии разрешения и запрещения приложений, управления настройками решения, логирования, производительности, безопасности самого решения (контроль отсутствия уязвимостей и т.д.);

4. Развертывание решения последовательно на различных группах устройств с выявлением и устранением проблем;

5. Дальнейшее управление решением, включающее в себя обновление «белого»/«черного» списков приложений, развертывание решения на различных платформах и типах устройств, обновление политик в соответствии с изменяющимися организационными требованиями, обновление самого решения, периодическое тестирование защитного функционала и проверка решения на наличие уязвимостей.