SOT

SOT

SOAR
Security Orchestration, Automation and Response

Автоматизация реагирования на инциденты информационной безопасности при помощи динамических плейбуков с применением СЗИ, выстраиванием цепочки атаки и объектно-ориентированным подходом

NG SOAR
Next Generation SOAR

Автоматизация реагирования на инциденты ИБ со встроенной базовой корреляцией, сбором сырых событий непосредственно с СЗИ, динамическими плейбуками, выстраиванием цепочки атаки и объектно-ориентированным подходом

AM
Asset Management

Описание ИТ-ландшафта, обнаружение новых объектов в сети, категорирование активов, инвентаризации и управления жизненным циклом оборудования и ПО на АРМ и серверах организаций

VM
Vulnerability Management

Выстраивание процесса обнаружения и устранения технических уязвимостей, сбор информации с имеющихся сканеров защищённости, платформ управления обновлениями, экспертных внешних сервисов и других решений

ГосСОПКА
Государственная Система Обнаружения Предупреждения и Ликвидации Последствий Компьютерных Атак

Двустороннее взаимодействие с Национальным координационным центром по компьютерным инцидентам (НКЦКИ), а именно передача информации об инцидентах и получение оперативных уведомлений/бюллетеней от регулятора

FinCERT
Financial Computer Emergency Response Team

Двустороннее взаимодействие с Центральным Банком (ЦБ РФ, ЦБ РБ и др.), а именно передача информации об инцидентах и получение оперативных уведомлений/бюллетеней от регулятора

Напишите нам на sales@securityvision.ru или закажите демонстрацию

GRC

GRC

КИИ
Критическая Информационная Инфраструктура

Аудит и исполнение требований ФЗ-187 «О безопасности критической информационной инфраструктуры Российской Федерации» и других нормативных документов

RM
Risks Management

Формирование реестра рисков, угроз, мер защиты и других параметров контроля, оценка по выбранной методике, формирование перечня дополнительных мер для изменения уровня риска, контроль исполнения, периодическая переоценка

ORM
Operational Risks Management

Учёт и фиксация событий операционных рисков (СОР), мониторинг ключевых индикаторов рисков (КИР) и проведение самооценки /контроля согласно положению №716-П ЦБ РФ

CM
Compliance Management

Аудит соответствия и комплаенса различным методологиям и стандартам (проектный)

BCP
Business Continuity Plan

Автоматизация процесса обеспечения непрерывности и восстановления деятельности (ОНиВД) после наступления чрезвычайных ситуаций

Напишите нам на sales@securityvision.ru или закажите демонстрацию

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

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

  |  Слушать на Google Podcasts  |   Слушать на Mave  |   Слушать на Яндекс Музыке  |    


Руслан Рахметов, 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. Дальнейшее управление решением, включающее в себя обновление «белого»/«черного» списков приложений, развертывание решения на различных платформах и типах устройств, обновление политик в соответствии с изменяющимися организационными требованиями, обновление самого решения, периодическое тестирование защитного функционала и проверка решения на наличие уязвимостей.

Подкасты ИБ NIST Стандарты ИБ

Рекомендуем

Нормативные документы по ИБ. Часть 6. Обзор российского и международного законодательства в области защиты персональных данных
Нормативные документы по ИБ. Часть 6. Обзор российского и международного законодательства в области защиты персональных данных
Измерение эффективности процессов кибербезопасности. Метрики ИБ. Часть 2
Измерение эффективности процессов кибербезопасности. Метрики ИБ. Часть 2
Обзор публикации NIST SP 800-167 "Guide to Application Whitelisting"
Обзор публикации NIST SP 800-167 "Guide to Application Whitelisting"
Нормативные документы по ИБ. Часть 13. Обзор российского законодательства в области ИБ финансовых организаций – продолжение
Нормативные документы по ИБ. Часть 13. Обзор российского законодательства в области ИБ финансовых организаций – продолжение
Зачем и как создавать сети передачи данных
Зачем и как создавать сети передачи данных
Управление рисками информационной безопасности. Часть  6. Стандарт ISO/IEC 27005:2018
Управление рисками информационной безопасности. Часть 6. Стандарт ISO/IEC 27005:2018
Практическая защита персональных данных. Где компания обрабатывает ПДн?
Практическая защита персональных данных. Где компания обрабатывает ПДн?
Измерение эффективности процессов кибербезопасности. Метрики ИБ. Часть 3
Измерение эффективности процессов кибербезопасности. Метрики ИБ. Часть 3
Практическая защита персональных данных. Как компания должна обрабатывать и защищать персональные данные? Часть 1
Практическая защита персональных данных. Как компания должна обрабатывать и защищать персональные данные? Часть 1
DDoS-атаки: что это такое и способы защиты от них
DDoS-атаки: что это такое и способы защиты от них
Обзор публикации NIST SP 800-88 "Guidelines for Media Sanitization"
Обзор публикации NIST SP 800-88 "Guidelines for Media Sanitization"
Менеджмент инцидентов информационной безопасности. Стандарт ГОСТ Р ИСО/МЭК ТО 18044-2007
Менеджмент инцидентов информационной безопасности. Стандарт ГОСТ Р ИСО/МЭК ТО 18044-2007

Рекомендуем

Нормативные документы по ИБ. Часть 6. Обзор российского и международного законодательства в области защиты персональных данных
Нормативные документы по ИБ. Часть 6. Обзор российского и международного законодательства в области защиты персональных данных
Измерение эффективности процессов кибербезопасности. Метрики ИБ. Часть 2
Измерение эффективности процессов кибербезопасности. Метрики ИБ. Часть 2
Обзор публикации NIST SP 800-167 "Guide to Application Whitelisting"
Обзор публикации NIST SP 800-167 "Guide to Application Whitelisting"
Нормативные документы по ИБ. Часть 13. Обзор российского законодательства в области ИБ финансовых организаций – продолжение
Нормативные документы по ИБ. Часть 13. Обзор российского законодательства в области ИБ финансовых организаций – продолжение
Зачем и как создавать сети передачи данных
Зачем и как создавать сети передачи данных
Управление рисками информационной безопасности. Часть 6. Стандарт ISO/IEC 27005:2018
Управление рисками информационной безопасности. Часть  6. Стандарт ISO/IEC 27005:2018
Практическая защита персональных данных. Где компания обрабатывает ПДн?
Практическая защита персональных данных. Где компания обрабатывает ПДн?
Измерение эффективности процессов кибербезопасности. Метрики ИБ. Часть 3
Измерение эффективности процессов кибербезопасности. Метрики ИБ. Часть 3
Практическая защита персональных данных. Как компания должна обрабатывать и защищать персональные данные? Часть 1
Практическая защита персональных данных. Как компания должна обрабатывать и защищать персональные данные? Часть 1
DDoS-атаки: что это такое и способы защиты от них
DDoS-атаки: что это такое и способы защиты от них
Обзор публикации NIST SP 800-88 "Guidelines for Media Sanitization"
Обзор публикации NIST SP 800-88 "Guidelines for Media Sanitization"
Менеджмент инцидентов информационной безопасности. Стандарт ГОСТ Р ИСО/МЭК ТО 18044-2007
Менеджмент инцидентов информационной безопасности. Стандарт ГОСТ Р ИСО/МЭК ТО 18044-2007

Похожие статьи

Статический анализ исходного кода
Статический анализ исходного кода
Модель угроз ФСТЭК
Модель угроз ФСТЭК
Основы риск- и бизнес-ориентированной информационной безопасности. Часть 1. Основные понятия и парадигма
Основы риск- и бизнес-ориентированной информационной безопасности. Часть 1. Основные понятия и парадигма
Каналы утечки информации. Часть 1
Каналы утечки информации. Часть 1
Импортозамещение
Импортозамещение
Фреймворк COBIT 2019
Фреймворк COBIT 2019
Обзор публикации NIST SP 800-40 "Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology"
Обзор публикации NIST SP 800-40 "Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology"
Обзор средств информационной безопасности: защита конечных точек
Обзор средств информационной безопасности: защита конечных точек
Обзор публикации NIST SP 800-124 Rev. 2 (Draft) "Guidelines for Managing the Security of Mobile Devices in the Enterprise"
Обзор публикации NIST SP 800-124 Rev. 2 (Draft) "Guidelines for Managing the Security of Mobile Devices in the Enterprise"

Похожие статьи

Статический анализ исходного кода
Статический анализ исходного кода
Модель угроз ФСТЭК
Модель угроз ФСТЭК
Основы риск- и бизнес-ориентированной информационной безопасности. Часть 1. Основные понятия и парадигма
Основы риск- и бизнес-ориентированной информационной безопасности. Часть 1. Основные понятия и парадигма
Каналы утечки информации. Часть 1
Каналы утечки информации. Часть 1
Импортозамещение
Импортозамещение
Фреймворк COBIT 2019
Фреймворк COBIT 2019
Обзор публикации NIST SP 800-40 "Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology"
Обзор публикации NIST SP 800-40 "Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology"
Обзор средств информационной безопасности: защита конечных точек
Обзор средств информационной безопасности: защита конечных точек
Обзор публикации NIST SP 800-124 Rev. 2 (Draft) "Guidelines for Managing the Security of Mobile Devices in the Enterprise"
Обзор публикации NIST SP 800-124 Rev. 2 (Draft) "Guidelines for Managing the Security of Mobile Devices in the Enterprise"