Как построить процесс управления уязвимостями в корпоративной сети

Современная кибербезопасность — это не столько сосредоточение дорогих суперсовременных продуктов, сколько люди и процессы, и только затем уже технологии — в этом смысле подходы к кибербезопасности принципиально не изменились за последние годы. Защита информации по-прежнему строится на ряде базовых процессов, которые изменяются и дополняются для соответствия актуальным вызовам и современному ландшафту киберугроз.

Один из таких процессов — это управление уязвимостями, который не только тесно связан с рядом других ИБ-процессов, но и далеко не всегда эффективно реализуется даже с учетом наличия различных современных технологий. В данной статье мы пройдем по основным этапам процесса Vulnerability Management и обсудим ряд рекомендаций, которые можно предложить для обхода типичных сложностей и подводных камней.

Для выстраивания процесса управления уязвимостями можно воспользоваться рядом готовых фреймворков и рекомендаций:

• Методические документы ФСТЭК России: «Руководство по организации процесса управления уязвимостями в органе (организации)» и «Методика оценки уровня критичности уязвимостей программных, программно-аппаратных средств».
• Специальная публикация NIST SP 800-40 Rev. 4 «Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology».
• Рекомендации агентства CISA «Cyber Resource Review — Volume 4 — Vulnerability Management».
• Советы по управлению уязвимостями и способ оценки уровня зрелости процесса VM от SANS Institute.

В указанных документах прослеживается применение процессного подхода для управления уязвимостями в соответствии с классическим PDCA-циклом Деминга (Планирование — Выполнение — Оценка — Корректировка/улучшение). Рассмотрим далее основные шаги и дадим некоторые советы в рамках данного цикла.

Планирование

Подготовке документационного сопровождения процесса управления уязвимостями следует уделить особое внимание, поскольку в данный процесс вовлекаются сотрудники различных подразделений, а выполнение срочных действий — например, обновление информационных систем — будет сложно обосновать без соответствующих полномочий. Регламент управления уязвимостями должен быть встроен в документационное обеспечение всей СУИБ в рамках высокоуровневой политики ИБ компании. В документе не только должны быть описаны все шаги, выполняемые в рамках управления уязвимостями, но и приведена RACI-матрица с указанием зон ответственности и ролей, которые отвечают за то или иное действие. Например, выполнять поиск и учет уязвимостей может сотрудник департамента ИБ, принимать решение о принятии определенной уязвимости может риск-менеджер вместе с владельцем бизнес-процесса, а устанавливать обновления безопасности будут, скорее всего, ИТ-администраторы.

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

Для управления уязвимостями важно и наличие информации о пользователе и бизнес-владельце актива, об ответственном за актив со стороны ИТ, а также об уровне критичности актива, выполняемой им функции и зависимых от него бизнес-процессах. Приоритет обработки уязвимостей на конкретном активе должен быть напрямую связан с уровнем его важности для компании, его доступностью из Интернет или из внутренних сетевых сегментов, с требованиямми к защите обрабатываемой на нём информации. Например, доступный из интернет корпоративный почтовый сервер должен быть пропатчен незамедлительно после обнаружения на нём эксплуатируемой удаленно уязвимости, а обновление внутреннего некритичного сервера может быть выполнено в запланированные окна обслуживания. Не следует также забывать, что сетевые устройства, системы телефонии, СКУД, видеонаблюдения, IoT-устройства часто «выпадают» из скоупа сканирования и после компрометации становятся платформой для закрепления злоумышленников, дальнейшего горизонтального перемещения и развития атаки.

Необходимо учитывать и то, что в соответствии с ГОСТ Р 56546-2015 уязвимости — это не только дефекты безопасности, возникшие при разработке программных продуктов, но и небезопасные конфигурации, а также недостатки организационных мер. По этой причине область управления уязвимостями можно расширить, рассматривая технический, физический и организационный уровни:

• Уязвимость технического уровня — это недостаток создания, конфигурирования, эксплуатации информационного актива или слабость технических мер защиты. Например, это привычные «дыры» в ОС, микропрограммах, прикладном и системном софте серверов, конечных точек, мобильных и сетевых устройств, инфраструктурных и периферийных устройств (СХД, телефония, МФУ, различные ПАКи и т.д.). Кроме того, к техническим уязвимостям относятся и уязвимости конфигураций — оценка безопасности текущих настроек может показать, например, что установленные дефолтные пароли не были изменены, служебные учетные записи не отключены, а настройки встроенного межсетевого экрана позволяют подключиться неаутентифицированному пользователю извне. Уязвимости конфигураций могут быть выявлены путем сравнения параметров текущих настроек с конфигурациями, рекомендуемыми организациями и вендорами, например, NIST National Checklist Program, CIS Benchmarks List, Security Technical Implementation Guides, рекомендации по безопасной установке и эксплуатации Astra Linux, Microsoft Security Compliance Toolkit, Cisco Harden IOS Devices, Red Hat Security Hardening и т.д.

• Уязвимость физического уровня — это недостаток создания, конфигурирования, эксплуатации физического актива или слабость физических мер защиты. Например, это отсутствие, некорректная настройка или неправильное использование СКУД (систем контроля и управления доступом), систем кондиционирования, вентиляции, пожаротушения, энергоснабжения, систем видеонаблюдения, дверей, окон, шкафов, шлагбаумов, турникетов, а также ошибки в организации работы сотрудников службы безопасности (охранников, дежурных). К физическим уязвимостям можно также отнести недостатки в реализации политики «чистых рабочих столов» и правил работы с бумажными документами, включая гарантированное уничтожение распечаток презентаций и надписей на досках и флипчартах в переговорных комнатах. Не стоит забывать и про уязвимости резервных копий данных: LTO-кассеты должны быть зашифрованы, пронумерованы и учтены, а их обработка и перемещение в места долгосрочного хранения должны регулироваться правилами Chain of custody.

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

С учетом разнородности потенциальных уязвимостей важно создать единую систему централизованного хранения данных об уязвимостях: для физических и организационных уязвимостей подойдут либо специализированные платформы BPM, ERP, HR, либо GRC/SGRC-система, в которой можно агрегировать данные по всем уязвимостям из различных источников и выстроить процесс управления ими. Для технических уязвимостей подойдет платформа управления уязвимостями (система Vulnerability Management), преимуществами которой будут интеграция с различными сканерами уязвимостей и обогащение данных по уязвимостям из аналитических интернет-сервисов. Одним из способов оптимизации процесса будет ретро-сканирование, которое позволяет сопоставлять данные о версиях обнаруженного ранее ПО и описания новых уязвимостей — когда появляется информация, что в определенном софте такой-то версии обнаружена уязвимость, можно быстро найти уязвимые хосты на основе информации из ранее проведенных сканирований. Кроме того, важно сохранять всю историю изменений уязвимостей для того, чтобы можно было понять, какие именно уязвимости были на определенных устройствах, физических активах или в бизнес-процессах на конкретную дату — такая детализация поможет в расследовании киберинцидентов, а также позволит отслеживать динамику управления уязвимостями, формировать отчетность и непрерывно совершенствовать сам процесс VM.

Выполнение

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

• Принятие (accept) — осознанное, взвешенное и согласованное принятие риска эксплуатации определенной уязвимости, осуществленное с учетом имеющихся мер защиты для предотвращения эксплуатации уязвимости, после проведения оценки опасности уязвимости и целесообразности реализации других мер.
• Снижение (mitigate) — уменьшение риска либо за счет устранения уязвимости (установка обновлений безопасности, обновление софта), либо за счет реализации дополнительных защитных или компенсирующих мер (внедрение правил межсетевого экранирования, использование WAF, IPS, отключение уязвимых компонентов и т.д.). В качестве меры снижения риска можно рассматривать и применение временных workaround до момента выхода патча, однако реализованные временные решения должны быть учтены в корпоративном реестре уязвимостей и оперативно заменены вендорской «заплаткой» после её выпуска.
• Передача (transfer) — уменьшение риска за счет разделения ответственности за последствия вероятной эксплуатации уязвимости (использование киберстрахования, переход на облачные сервисы). Отметим, однако, что согласно ст.928 ГК РФ не допускается страховать противоправные интересы — таким образом, штрафы за последствия эксплуатации уязвимостей должны быть выплачены самими нарушителями, вне зависимости от наличия киберстраховки.
• Избежание (avoid) — устранение возможности эксплуатации уязвимости за счет удаления уязвимого софта, вывода уязвимых активов из эксплуатации, отключения избыточного функционала.

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

Обогащение включает в себя агрегацию данных об уязвимости из официальных реестров (включая CVE, NVD, БДУ ФСТЭК России) и получение дополнительной аналитической информации о характеристиках и возможности эксплуатации уязвимости (например, с ресурсов AttackerKB, Exploit-db, VulDB, Snyk Vulnerability Database и т.д.). Приоритизация может включать в себя оценку опасности уязвимости по системе CVSS (предпочтение стоит отдавать новой версии CVSS v4, в которой появились дополнительные метрики), оценку уровня критичности уязвимостей по методике ФСТЭК России, оценку вероятности эксплуатации уязвимости по моделям EPSS и SSVC. Следует также учитывать и популярность определенных уязвимостей среди атакующих — для этого можно использовать перечни самых распространенных уязвимостей от ФСТЭК России (наиболее опасные уязвимости) и от CISA (Known Exploited Vulnerabilities Catalog). При этом не всякая уязвимость даже с высоким CVSS-рейтингом может быть проэксплуатирована в реальной атаке и в текущей конфигурации корпоративной инфраструктуры — для уточнения перечня действительно актуальных уязвимостей следует проверять возможность эксплуатации конкретной уязвимости в контролируемой манере с помощью функционала Pentest-проверок в VM-системе.

Сформированная диаграмма принятия решений должна давать однозначный ответ на вопрос, какие действия следует выполнить с определенной уязвимостью и в какие сроки. Например, в соответствии с упомянутой методикой оценки уровня критичности уязвимостей ФСТЭК России, в отношении критичных уязвимостей меры должны быть приняты в течение 24 часов после их обнаружения, однако легко эксплуатируемые опасные уязвимости начинают использоваться атакующими буквально в течение считанных минут после опубликования кода эксплойта. Поэтому важно автоматизировать этапы выявления уязвимостей, выбора метода обработки и постановки задач (тикетов) исполнителям, а в идеальном случае — принимать решения, тестировать и устанавливать критические обновления безопасности в автоматическом режиме (функционал автопатчинга). При этом для низкоприоритетных уязвимостей, срок обработки которых может составлять несколько дней или даже недель, можно использовать стандартные ИТ-процедуры патч-менеджмента с постепенной установкой обновлений на группы устройств.

Оценка

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

Кроме того, важно вести и контроль установленных обновлений — в частности, проверять, что установленные обновления не были удалены либо вручную (пользователем или атакующим), либо автоматически, например, при восстановлении системы из бэкапа. Нередки случаи того, что обновления ломают тот или иной функционал, поэтому важно не только проверять их перед установкой, но и вести мониторинг поведения обновленного актива. Более того, учитывая распространенность атак на цепочки поставок и риски внедрения вредоносного функционала в обновления из официальных источников, следует внимательно анализировать отклонения в поведении недавно пропатченных устройств — в этом помогут системы выявления аномалий класса UEBA (User and Entity Behavior Analytics). Следует также учитывать, что в текущей ситуации, когда доступ российских компаний к официальным обновлениям от зарубежных производителей существенно затруднен, важно применять процедуры тестирования и контроля подлинности и безопасности получаемых патчей — для этого можно руководствоваться методическим документом ФСТЭК России «Методика тестирования обновлений безопасности программных, программно-аппаратных средств».

Корректировка/улучшение

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

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

В случае, если компания занимается внутренней разработкой ПО, важно переходить к практикам SSDLC, DevSecOps и CI/CD/CS-пайплайнам, в которых учтено управление уязвимостями, а также использовать анализаторы кода (SAST, DAST, IAST, BAST) и решения для тестирования безопасности API (API Security Testing). Формирование спецификаций SBOM, применение инструментов анализа состава ПО (SCA, Software Composition Analysis) и анализа компонентов с открытым исходным кодом (OSA, Open Source Analysis) поможет в работе с рисками атак на цепочки поставок. Кроме того, важно использовать справочные сведения о наиболее опасных ошибках при разработке ПО (например, от MITRE и от OWASP), а также руководствоваться подходами Secure by Design (использование ИБ-практик при разработке продуктов), Secure by Default (использование безопасных конфигураций по умолчанию), Secure by Demand (критерии, по которым заказчики могут оценить надежность вендора, включая использование им практик SSDLC, предоставление спецификации SBOM на разрабатываемый софт, его политику раскрытия информации об уязвимостях, наличие roadmap по повышению безопасности разработки).

Компаниям важно переходить к проактивому выявлению уязвимостей — лучше найти «дыры» до того, как это сделают атакующие. Запуск программы Bug Bounty позволит привлечь к оценке безопасности различных независимых экспертов, а проведение пентестов и оценок Red Team поможет выявить уязвимости информационной инфраструктуры, процессов, персонала (например, за счет фишинговых имитаций), применяемых мер защиты, включая физические (например, за счет контролируемых попыток проникновения в здание).

Скорость поиска уязвимостей и разработки эксплойтов увеличивается за счет технологий ИИ, поэтому крайне важно не отставать от атакующих и применять средства автоматизации для выявления и устранения уязвимостей, включая автопатчинг, автоматическое применение предварительно согласованных безопасных конфигураций, принудительное восстановление безопасных настроек. Системы машинного обучения и искусственного интеллекта уже сейчас помогают выявлять аномалии и неизвестные ранее угрозы, однако всё более частое применение 0-Day эксплойтов может привести к компрометации инфраструктуры даже при безупречно выстроенном процессе управления уязвимостями. Именно поэтому важно быть готовым к управлению инцидентами ИБ, иметь готовые сценарии реагирования на кибератаки, использовать соответствующие средства автоматизации для ускорения реагирования и снижения ущерба.

Мы в компании Security Vision разрабатываем и продукт для управления уязвимостями Security Vision NG VM, и платформу для автоматизации всех процессов ИБ Security Vision SGRC, и решение для автоматизации управления киберинцидентами Security Vision SOAR. В частности, Security Vision NG VM обеспечивает обнаружение активов и интеллектуальное сканирование уязвимостей с помощью собственного движка, контроль и управление конфигурациями устройств, автоматическое устранение уязвимостей (автопатчинг) в соответствии с риск-ориентированной моделью, а также поддерживает различные режимы сканирования, включая ретро-скан, сканирование веб-приложений и пентест с контролируемой проверкой эксплойтов.

Автор: Руслан Рахметов, Security Vision.