Обзор публикации NIST SP 800-40 "Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology"

Руслан Рахметов, 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'ов, сведений о влиянии установки вендорский обновлений на ИТ-актив в целом.