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
Risk Management

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

ORM
Operational Risk Management

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

CM
Compliance Management

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

BCP
Business Continuity Plan

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

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

Обзор публикации 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"
31.01.2022

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


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


Как мы писали в одной из ранних публикаций, уязвимость - это некий недостаток создания/конфигурирования/использования программно-технического средства или информационной системы, который может негативно повлиять на обеспечение кибербезопасности ИТ-актива, при этом атакующие используют (эксплуатируют) уязвимости в самом активе или в его защите для осуществления вредоносных действий. Список уязвимостей непрерывно пополняется, так, например, в реестре CVE (Common Vulnerabilities and Exposures) организации MITRE на конец января 2022 года задокументировано почти 170 тысяч уязвимостей, среди которых встречаются по-настоящему разрушительные, эксплуатация которых может привести к захвату всей ИТ-инфраструктуры.


Основным способом защиты от эксплуатации известных уязвимостей является выстраивание процесса патч-менеджмента, который описан в рассматриваемом сегодня документе NIST SP 800-40 Rev. 4 (Draft) "Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology" («Руководство по планированию корпоративного управления обновлениями безопасности: Профилактическое обслуживание для ИТ»).


Итак, в драфте 4-ой ревизии документа NIST SP 800-40 дается определение процессу установки обновлений (патчингу) как действию по применению изменений к установленному ПО (приложениям, операционным системам, микропрограммам), которые исправляют проблемы с безопасностью/функционалом или привносят новые функциональные возможности. Корпоративное управление обновлениями определяется как процесс идентификации, приоритизации, получения, установки и проверки корректности установки обновлений безопасности, апдейтов или апгрейдов в рамках всей организации. В рамках документа NIST SP 800-40 рассматриваются такие информационные активы, как IT/OT-системы, IoT-устройства, мобильные устройства, а также облачные, виртуализированные и контейнеризированные инфраструктуры. В целях повышения и операционной эффективности процесса управления обновлениями ИТ и ИБ-руководителям совместно с руководством компании и владельцами бизнес-систем следует разработать корпоративную стратегию проактивного патч-менеджмента, контролируемо устраняющего потенциальную проблему (эксплуатация уязвимости), несмотря на устоявшиеся предубеждения (подход «работает - не трогай») и риски простоя бизнес-процессов (для установки обновления, перезагрузки ОС после установки обновления или в случае, если обновление нарушило функционал решения). При этом в документе признается факт того, что не все обновления действительно устраняют уязвимости или расширяют необходимый защитный функционал (достаточно вспомнить выпуск некорректных обновлений для Windows, нарушающих базовый функционал ОС, с последующим экстренным выпуском «патча для патча»), а также упоминаются случаи, когда обновление может само содержать новые уязвимости, допущенные случайно или заложенные намеренно (например, в рамках проведения атаки "supply chain", т.е. атаки на цепочку поставок).


С точки зрения риск-менеджмента, обработка связанных с уязвимостями киберрисков может быть реализована следующими способами:


1. Принятие: осознанное понимание наличия незакрытых уязвимостей, использование наложенных средств защиты, ожидаемый ущерб от эксплуатации уязвимости достаточно низок для непринятия дополнительных мер ИБ.


2. Минимизация: снижение киберриска путем устранения уязвимости (например, установка обновления безопасности ПО, отключение уязвимого компонента, обновление ПО до актуальной версии без уязвимостей) и/или применение дополнительных мер защиты для снижения вероятности эксплуатации уязвимости (например, применение «виртуального патчинга» на Web Application Firewall или в IPS-системе, сетевое ограничение доступа от/к уязвимому активу для сокращения поверхности потенциальной атаки). При этом следует учесть ограничения: уязвимость и эксплойт для неё появились раньше, чем вышел патч (например, в атаках “0-day” или при отсутствии должной реакции вендора); производитель больше не поддерживает устаревшее ПО/решение или истек срок лицензии на получение обновлений; бизнес-процессы не допускают простоя из-за установки обновления, требуется протестировать работу бизнес-приложений после установки ПО или обучить сотрудников работе с обновленной версией; установка патчей откладывается из-за наличия более высокоприоритетных обновлений; производитель выпускает обновление ПО/решения с задержкой, обусловленной расширенным тестированием или испытаниями; необходимость использования только сертифицированного ПО/решения, обновление для которого пока не прошло необходимые процедуры, установленные законодательством.


3. Передача: использование услуг киберстрахования или решений класса SaaS (Software-as-a-Service, программное обеспечение как услуга).


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


Жизненный цикл управления уязвимостями программного обеспечения в соответствии с NIST SP 800-40 состоит из следующих этапов:


1. Управление активами и получение сведений о новых уязвимостях: требуется понимание того, какие ИТ-активы и с какими целями используются, с точностью до версии и билда конкретного приложения/утилиты/пакета/библиотеки, а также следует непрерывно получать и обрабатывать информацию об уязвимостях в этих программных компонентах.


2. Планирование реагирования на киберриск эксплуатации уязвимости: выбор одного или нескольких способов обработки киберриска эксплуатации уязвимости (принятие, минимизация, передача, избегание).


3. Реагирование на киберриск эксплуатации уязвимости:


3.1. Подготовка к установке обновлений: приоритизация патча (в зависимости от уровня критичности уязвимости, которую он закрывает), планирование установки патча (в рамках корпоративной процедуры change management, т.е. управления внесением изменений), получение патча (скачивание, доставка на носителе, разработка своими силами), проверка патча (контроль целостности и отсутствия внесенных несанкционированных изменений), тестирование (для выявления проблем при/после установки патча до широкомасштабного развертывания).


3.2. Установка патча: доставка патча (автоматически через системы доставки обновлений/ПО, вручную, по расписанию, силами вендора в случае облачных решений); проверка патча (целостность, неизменность содержимого); установка патча (автоматически или вручную, с привлечением пользователя или без, с необходимостью использования административных полномочий или без, в результате установки обновления другого продукта); изменение конфигурации и состояния ПО (например, перезагрузка устройства, перезапуск ПО, рестарт сервиса, ручная активация новых опций безопасности в ПО); решение возникших проблем (например, изменение патчем настроек безопасности или появление новых опций, а также неработоспособность бизнес-приложений с последующим откатом изменений или восстановлением из бэкапов).


3.3. Проверка установленного обновления: оценка успешности установки; проверка устранения связанной уязвимости.


3.4. Мониторинг установленных обновлений: контроль того, что обновление не было отменено/деинсталлировано пользователем или злоумышленником; контроль того, что старая уязвимая версия ПО не была восстановлена из бэкапа автоматически; анализ поведения обновленного ПО/решения для выявления признаков реализации атаки на цепочку поставок.


В документе NIST SP 800-40 также содержатся практические рекомендации по разработке корпоративного плана управления уязвимостями:


1. Снижение количества инсталляций потенциально уязвимого ПО.


Снижение количества инсталляций потенциально уязвимого ПО и, как следствие, минимизация необходимости установки обновлений может заключаться в следующем:


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


1.2. Использование ПО/решений, которые с меньшей вероятностью будут содержать уязвимости.


1.3. Взаимодействие с опытными вендорами, которые с меньшей вероятностью допустят появление уязвимостей в своих продуктах.


1.4. Использование, по возможности, предоставляемых сервисов вместо традиционного ПО.


1.5. Использование стека технологий или платформ, которые с меньшей вероятностью будут содержать уязвимости (например, использование контейнеров вместо традиционных ОС).


2. Инвентаризация ИТ-активов.


Инвентаризацию ИТ-активов рекомендуется выполнять с применением средств автоматизации для выявления новых ИТ-активов и получения актуальной информации по ним. При этом результаты инвентаризации ИТ-активов должны содержать данные о технических и бизнес-характеристиках активов для предоставления контекста использования того или иного ПО. Данные по ИТ-активу могут содержать:

  • тип платформы (IT/OT/IoT/облако/контейнер/виртуальная машина);

  • администрирующее лицо (IT-администратор, вендор, конечный бизнес-пользователь);

  • механизм управления актива (гипервизор, менеджер контейнеров, endpoint-система управления);

  • данные о сетевой связности актива (доступ в интернет, использующиеся порты и протоколы);

  • применяемые СЗИ;

  • основной пользователь актива или взаимосвязанные сервисы (с указанием привилегий);

  • роль и критичность актива для компании (выполняемая бизнес-задача);

  • нормативные требования к устранению уязвимости на этом активе;

  • ограничения при установке обновлений (например, установить патч может только вендор);

  • бизнес-требования к доступности актива (например, перезагрузка возможна раз в квартал в заранее согласованный временной интервал).


3. Определение сценариев реагирования на киберриск эксплуатации уязвимости.


Сценарии реагирования на киберриск эксплуатации уязвимости могут включать в себя:


3.1. Плановое обновление: установка обновлений в соответствии с планом обновлений, при отсутствии данных об эксплуатации уязвимостей атакующими.


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


3.3. Экстренный «обходной путь» (англ. workaround): выполнение срочных действий (изменение настроек ОС, правки реестра, перенастройка конфигурации ПО) для минимизации риска эксплуатации уязвимости до момента доступности патча или до возможности провести процедуру его установки.


3.4. Необновляемые ИТ-активы: ограничение сетевого доступа/функционала актива, обновления для которого невозможно установить (ввиду критичных требований по непрерывной работе актива, устаревания ПО/решения, отсутствия технической поддержки от вендора).


4. Объединение активов в группы обслуживания.


Следует объединить ИТ-активы в группы обслуживания в соответствии с инвентаризационными данными и определенными сценариями реагирования на киберриск эксплуатации уязвимости. Группа обслуживания - это набор активов со сходными инвентаризационными характеристиками, имеющих одинаковые потребности в обслуживании (ограничения при установке патчей и применении workaround'ов) при реализации каждого из сценариев реагирования на киберриск эксплуатации уязвимости.


5. Разработка планов обслуживания для каждой группы обслуживания.


5.1. План обслуживания для сценария «Плановое обновление»: следует определить небольшую группу активов, на которую будет установлено обновления в первую очередь, для тестирования и получения обратной связи, с выборкой пользователей и сервисов из различных бизнес-подразделений; после успешного теста можно применить обновление на оставшиеся активы. При этом в больших инфраструктурах тестовых групп может быть несколько, например, с распределением в пропорции 5%/20%/75%. При этом затягивать процесс установки плановых обновлений тоже не следует: можно установить дедлайн по установке, после которого обновление будет принудительно применено к устройству, либо временно блокировать сетевой доступ необновленному устройству.


5.2. План обслуживания для сценария «Экстренное обновление»: в случае необходимости применить экстренное обновление следует также выделить группу тестовых активов, в максимально сжатые сроки установить и протестировать на них обновление, а затем распространить его уже на все активы.


5.3. План обслуживания для сценария «Экстренный workaround»: следует заранее продумать способ применения экстренного workaround, например, централизованно отключая уязвимые компоненты, изолируя активы, автоматически изменяя настройки ОС, внося правки реестра, переконфигурируя ПО. При этом следует продумать процедуру отката внесенных экстренных изменений после выхода официального патча для его успешного применения.


5.4. План обслуживания для сценария «Необновляемые ИТ-активы»: следует продумать способы защиты необновляемых активов, такие как применение сетевой микросегментации, включения в виртуальные VLAN с ограниченным сетевым доступом, ограничение функционала, максимальный hardening. Следует также непрерывно анализировать применяемые меры для оценки их эффективности, а также проводить cost/benefit-анализ для соотнесения затрат на защиту необновляемых активов и их бизнес-пользы.


6. Выбор метрик эффективности процесса управления обновлениями.


Документ NIST SP 800-40 предлагает использовать инвентаризационные данные (включая информацию о критичности ИТ-активов) и данные систем оценки опасности уязвимостей (например, CVSS) для разработки метрик, отражающих важность каждой уязвимости и патча для инфраструктуры организации. В качестве примера составления метрики можно использовать взаимосвязь критичности актива (3 градации) и опасности уязвимости (4 градации).


7. Оценка технической поддержки ПО/решений при закупках.


При закупках ПО/решений следует оценивать уровень технической поддержки вендора при помощи опросника, который включает в себя вопросы о планах по выпуску обновлений для ПО/решения, регулярности предоставления патчей, периоде планируемого предоставления обновлений безопасности, способе обработки данных об обнаруженных уязвимостях, предоставлении экстренных патчей/workaround'ов, сведений о влиянии установки вендорский обновлений на ИТ-актив в целом.

Управление ИБ Киберриски (Cyber Risk, CRS) Управление уязвимостями Угрозы ИБ Практика ИБ Подкасты ИБ NIST Стандарты ИБ MITRE

Рекомендуем

SOC (Security Operation Center): что это такое и зачем используется? Центры мониторинга информационной безопасности
SOC (Security Operation Center): что это такое и зачем используется? Центры мониторинга информационной безопасности
КИИ - что это? Безопасность объектов критической информационной инфраструктуры
КИИ - что это? Безопасность объектов критической информационной инфраструктуры
Кейлоггер для кибербезопасности и оптимизации
Кейлоггер для кибербезопасности и оптимизации
Информационная  безопасность (ИБ) - что это такое. Виды защиты информации.
Информационная безопасность (ИБ) - что это такое. Виды защиты информации.
Что такое IRP, где используется и как внедряется
Что такое IRP, где используется и как внедряется
SIEM системы (Security Information and Event Management) - что это и зачем нужно?
SIEM системы (Security Information and Event Management) - что это и зачем нужно?
Управление рисками информационной безопасности. Часть 1. Основные понятия и методология оценки рисков
Управление рисками информационной безопасности. Часть 1. Основные понятия и методология оценки рисков
Управление рисками информационной безопасности (конспект лекции)
Управление рисками информационной безопасности (конспект лекции)
Федеральный закон № 161-ФЗ «О национальной платежной системе»
Федеральный закон № 161-ФЗ «О национальной платежной системе»
Категорирование объектов критической информационной инфраструктуры в рамках 187-ФЗ. Постановление Правительства РФ № 127
Категорирование объектов критической информационной инфраструктуры в рамках 187-ФЗ. Постановление Правительства РФ № 127
Практика ИБ. Централизованный сбор логов с Windows-устройств
Практика ИБ. Централизованный сбор логов с Windows-устройств
Управление инцидентами ИБ (конспект лекции)
Управление инцидентами ИБ (конспект лекции)

Рекомендуем

SOC (Security Operation Center): что это такое и зачем используется? Центры мониторинга информационной безопасности
SOC (Security Operation Center): что это такое и зачем используется? Центры мониторинга информационной безопасности
КИИ - что это? Безопасность объектов критической информационной инфраструктуры
КИИ - что это? Безопасность объектов критической информационной инфраструктуры
Кейлоггер для кибербезопасности и оптимизации
Кейлоггер для кибербезопасности и оптимизации
Информационная безопасность (ИБ) - что это такое. Виды защиты информации.
Информационная  безопасность (ИБ) - что это такое. Виды защиты информации.
Что такое IRP, где используется и как внедряется
Что такое IRP, где используется и как внедряется
SIEM системы (Security Information and Event Management) - что это и зачем нужно?
SIEM системы (Security Information and Event Management) - что это и зачем нужно?
Управление рисками информационной безопасности. Часть 1. Основные понятия и методология оценки рисков
Управление рисками информационной безопасности. Часть 1. Основные понятия и методология оценки рисков
Управление рисками информационной безопасности (конспект лекции)
Управление рисками информационной безопасности (конспект лекции)
Федеральный закон № 161-ФЗ «О национальной платежной системе»
Федеральный закон № 161-ФЗ «О национальной платежной системе»
Категорирование объектов критической информационной инфраструктуры в рамках 187-ФЗ. Постановление Правительства РФ № 127
Категорирование объектов критической информационной инфраструктуры в рамках 187-ФЗ. Постановление Правительства РФ № 127
Практика ИБ. Централизованный сбор логов с Windows-устройств
Практика ИБ. Централизованный сбор логов с Windows-устройств
Управление инцидентами ИБ (конспект лекции)
Управление инцидентами ИБ (конспект лекции)

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

Польза от Pentest для постинцидента
Польза от Pentest для постинцидента
Логины, пароли и другие способы аутентификации: описание, особенности, угрозы
Логины, пароли и другие способы аутентификации: описание, особенности, угрозы
IDE для разработки средств защиты в формате no-code
IDE для разработки средств защиты в формате no-code
Взломы в информационной безопасности - что это, как они происходят и как от них защититься
Взломы в информационной безопасности - что это, как они происходят и как от них защититься
SSDL: ML для проверки кода и поведения opensource-решений
SSDL: ML для проверки кода и поведения opensource-решений
Атаки на веб-системы по методологии OWASP Top 10
Атаки на веб-системы по методологии OWASP Top 10
SSDL: Знай своего opensource-поставщика в лицо и не только
SSDL: Знай своего opensource-поставщика в лицо и не только
Технология SOAR и ее место в SOC
Технология SOAR и ее место в SOC
Живее всех живых: непрерывность бизнеса
Живее всех живых: непрерывность бизнеса

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

Польза от Pentest для постинцидента
Польза от Pentest для постинцидента
Логины, пароли и другие способы аутентификации: описание, особенности, угрозы
Логины, пароли и другие способы аутентификации: описание, особенности, угрозы
IDE для разработки средств защиты в формате no-code
IDE для разработки средств защиты в формате no-code
Взломы в информационной безопасности - что это, как они происходят и как от них защититься
Взломы в информационной безопасности - что это, как они происходят и как от них защититься
SSDL: ML для проверки кода и поведения opensource-решений
SSDL: ML для проверки кода и поведения opensource-решений
Атаки на веб-системы по методологии OWASP Top 10
Атаки на веб-системы по методологии OWASP Top 10
SSDL: Знай своего opensource-поставщика в лицо и не только
SSDL: Знай своего opensource-поставщика в лицо и не только
Технология SOAR и ее место в SOC
Технология SOAR и ее место в SOC
Живее всех живых: непрерывность бизнеса
Живее всех живых: непрерывность бизнеса