Все об уязвимостях и как ими управлять. Интервью с Александром Леоновым (Positive Technologies)

В последние несколько лет количество успешных кибератак на компании во всём мире растёт. По результатам исследования Positive Technologies, эксплуатация уязвимостей остается одним из лидирующих методов атак на организации: во II квартале 2024 года он использовался в 35% успешных кибератак. Поэтому организациям важно понимать, как не дать злоумышленникам пробраться в инфраструктуру компании через уязвимости. Редакция CISOCLUB подготовила интервью с Александром Леоновым, ведущим экспертом лаборатории PT Expert Security Center компании Positive Technologies и автором телеграм-канала «Управление Уязвимостями и прочее» о том, что такое уязвимости, как определяются самые опасные из них — трендовые — и почему важно ими управлять.

1. Что такое процесс управления уязвимостями?

Управление уязвимостями — это процесс детектирования и устранения уязвимостей в организации. Он позволяет усложнить злоумышленникам проведение атак на инфраструктуру организации, чтобы они не могли реализовать недопустимые события^[1].

Уязвимости могут быть известными, описанными в базах уязвимостей, таких как NVD и БДУ ФСТЭК России, а могут быть неизвестными.

Известные уязвимости в инфраструктуре обнаруживают, ориентируясь на информацию о том, какая версия ПО или аппаратного средства содержит ту или иную уязвимость, или через попытку эксплуатации уязвимости. Для этого используются инфраструктурные сканеры уязвимостей (например, Nessus, Сканер-ВС, RedCheck, MaxPatrol 8) или более функциональные системы управления уязвимостями (например, Qualys, Tenable VM, MaxPatrol VM). Работой с такими уязвимостями, как правило, занимается отдел инфраструктурной безопасности организации.

Неизвестные уязвимости детектируются путём ручного или автоматизированного анализа приложений. Для этого используются решениякласса dynamic application security testing (DAST), static application security testing (SAST), interactive application security testing (IAST). Кроме того, такие уязвимости могут быть обнаружены в ходе пентестов или багбаунти. Работой с такими уязвимостями, как правило, занимается отдел безопасности приложений организации.

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

2. Какие ключевые этапы выделяют в процессе управления уязвимостями?

Обычно процесс управления уязвимостями визуализируют в виде какой-то последовательности этапов, похожих на PDCA-цикл (plan–do–check–act):

• инвентаризация инфраструктуры и детектирование уязвимостей;
• оценка уязвимостей;
• устранение уязвимостей;
• контроль устранения уязвимостей;
• улучшение процесса.

Мне такая визуализация не очень нравится. Создается иллюзия, что есть какие-то шаги, которые выполняются последовательно. Это может иметь место в рамках каких-то ежегодных аудитов, но непрерывный процесс так уже не работает. Поэтому речь, скорее, идёт о поддержании непрерывных автоматизированных процессов (подпроцессов?):

• оценки используемых средств детектирования уязвимостей
• инвентаризации активов и детектирования уязвимостей;
• оценки (и переоценки) уязвимостей;
• заведения задач на исправление и контроля их выполнения.

3. В чём состоят сложности при выявлении уязвимостей в современных IT-инфраструктурах?

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

4. Как понять, какие активы в организации требуется покрывать процессом управления уязвимостями?

Для этого нужно иметь развитый процесс управления активами (asset management). Это один из самых важных этапов управления уязвимостями, своеобразная нулевая точка в управлении уязвимостями и построении результативной кибербезопасности. Иронично, что самая важная часть vulnerability management не имеет прямого отношения к уязвимостям.

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

К существующей в организации системе инвентаризации должно быть критическое отношение. Специалисты по управлению уязвимостями должны постоянно задаваться вопросом, действительно ли нет неучтенных в системе asset management активов.

Ниже несколько вопросов, над которыми стоит задуматься в вопросе инвентаризации активов:

• Все ли филиалы учтены в системе, в том числе дочерние и купленные компании?
• Все ли компьютеры, в том числе удаленных специалистов и на различных операционных системах, учтены?
• Все ли серверы, в том числе на других внешних хостингах, ERP-системы, Kubernetes вы знаете?
• Все ли сетевые устройства учтены?
• Учитываете ли вы телефонию, камеры, экраны в переговорных комнатах в офисах, системы бронирования переговорных?

Когда есть информация, что активы учтены в системе asset management, можно идти дальше и задаваться следующими вопросами:

• Кто ответственный за актив? Кто должен обновлять этот актив? С какой периодичностью это делается? Что будет, если обновление по факту не производится?
• Что это за актив? Насколько он критичен?
• Можем ли мы сканировать этот актив на уязвимости на уровне операционной системы? Если нельзя, то что можно с этим сделать?

Затем можно заниматься инвентаризацией на уровне софтов и думать: есть ли у нас средства для детектирования уязвимостей для этих софтов и что делать, если нет?

5. В чём состоят сложности непосредственного детектирования уязвимостей в инфраструктуре организации?

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

Представим ситуацию: сканер ошибочно не продетектировал уязвимость, и в итоге через неё взломали организацию. VM-специалист может обратиться с претензией к VM-вендору, но вендор только выпустит обновленный детект, а это никак не исправит последствий от атаки злоумышленников.

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

6. Как оценивать полноту и достаточность способов детектирования уязвимостей?

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

Как оценивать? Для каждого типового актива в первую очередь следует понять, поддерживается ли он средством детектирования в принципе. Если нет, то необходимо думать, что делать: менять инфраструктуру, стимулировать VM-вендора, покупать другое средство детектирования или делать его самостоятельно.

Если актив поддерживается средством детектирования, можно задавать следующий вопрос: как именно происходит обнаружение? Рассмотрим ситуацию, когда есть Linux-узел и сканер уязвимостей, который детектирует уязвимости только в пакетах, установленных из официального репозитория. И тут следует задать следующий вопрос: достаточно ли этого и нет ли в инфраструктуре софта, установленного по-другому (из исходников, из сторонних пакетов, в виде Snap, Flatpak, AppImage, в виде Docker-контейнера)?

Если достаточно, то всё в порядке. Если нет — можно подумать, как расширить способы детектирования (использовать пентест или веб-режим, анализ контейнеров и т. п.). Если не помогает — считаем, что средство детектирования поддерживает актив не в полной мере.

Безусловно, недостаточно одной констатации VM-вендором факта, что тот или иной способ детектирования уязвимостей реализован в полной мере. Нужно идти ещё глубже.

Опять возьмем базовый пример — детектирование уязвимостей на Linux-узле в пакетах из официального репозитория. На первый взгляд, выглядит просто: сравниваются фактические и уязвимые версии пакетов. Информация об уязвимых версиях пакетов собирается из бюллетеней безопасности или даже готового OVAL-контента Linux-вендора.

В реальности ошибиться можно в нескольких местах, например:

• функции сравнения версий пакетов (часто не учитывается эпоха);
• источнике безопасных версий пакетов (когда в бюллетенях указаны source-пакеты, а от них нужно перейти к версиям бинарных пакетов).

Особенно наглядно видно, когда один узел проверяется несколькими сканерами и находятся расхождения в отчетах.

7. Как сравнивать уязвимости и как понимать, какие из них более опасны и требуют приоритетного исправления?

Существует множество методик для оценки и сравнения уязвимостей. Большой обзор недавно опубликовал на портале «Резбез» Алексей Лукацкий. Сам я также занимаюсь приоритизацией уязвимостей с помощью своей опенсорсной утилиты Vulristics. Ей можно подать на вход набор CVE уязвимостей и получить оценки для них. Наибольший вес при оценке имеют признаки наличия публичного эксплойта — особого кода, который использует уязвимости в ПО, — признаки эксплуатации в реальных атаках и тип уязвимости.

Мы в Positive Technologies ввели специальный термин для обозначения уязвимостей, которые следует устранять в первую очередь, — «трендовые уязвимости». Чтобы выявить одну трендовую уязвимость, наши эксперты анализируют множество источников. Учитывается медийный резонанс, общедоступная информация об уязвимости, наличие эксплойта, сложность эксплуатации и прочее. Информация о таких уязвимостях попадает в нашу систему управления уязвимостями в течение 12 часов.

8. Значит ли это, что достаточно исправлять только самые опасные эксплуатируемые уязвимости, а на остальные можно закрыть глаза?

Вовсе нет, не значит. Я убежден, что устранять нужно все уязвимости, однако приоритет отдавать трендовым. Вендору виднее: раз вышло обновление безопасности, значит, необходимо его поставить. Это может быть сделано не сразу, но нельзя пренебрегать обновлениями только потому, что уязвимость выглядит безобидной. Каждая продетектированная уязвимость должна находиться в процессе устранения (приоритетного или планового). Во всяком случае, нужно к этому стремиться.

К сожалению, мир уязвимостей так устроен, что о большинстве из них мы не знаем практически ничего, кроме небольшого абзаца текста. Кот Шрёдингера в коробке одновременно и жив, и мёртв. А у нас уязвимость одновременно и критически опасная, эксплуатабельная, и нет — пока не появятся детали: write-up, эксплойт, подтверждения эксплуатации вживую. К сожалению, к этому моменту может быть уже слишком поздно и часть организаций пострадает от атак злоумышленников.

9. То есть нужно стремиться к тому, чтобы в организации было ноль уязвимостей? Но разве это достижимо?

По моему мнению, следует стремиться к нулю в вопросе устранения уязвимостей. Но нужно уточнить: каких именно уязвимостей?

Речь о том, что каждая продетектированная уязвимость должна находиться в процессе исправления. Должно быть понимание, кто, как и в какие сроки её исправляет. А уязвимостей, на которые специалисты по ИБ не обратили внимания (вообще не продетектировали или продетектировали, но посчитали не требующими исправления и т. п.), быть не должно.

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

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

10. Кто и как должен определять SLA по устранению уязвимостей?

Здесь сошлюсь на хорошую статью про управление уязвимостями в финансовых организациях. SLA на выполнение задач по устранению уязвимостей (плановому и приоритетному) согласовывают совместно ИБ и ИТ (или ИБ и бизнес).

При этом учитываются:

• важность активов;
• требования к доступности активов и к версионности;
• технологические окна.

Если какие-то активы невозможно обновлять даже в окна, следует рассмотреть возможность дублирования систем или обновления по частям.

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

11. Как оценивать эффективность процесса управления уязвимостями?

Как и способов приоритизации уязвимостей, способов оценки эффективности процесса управления уязвимостями существует много. Как мне кажется, среди них нет единственно правильного. Если уязвимости в инфраструктуре своевременно исправляются, аудиторы вас нахваливают, а пентестеры грустят, значит, всё нормально. Но некоторые свои соображения я формулирую под названием БОСПУУ (Базовая Оценка Состояния Процесса Управления Уязвимостями (рис. 1)). Я придерживаюсь того, что важно не зацикливаться на каких-то конкретных кейсах выявления и исправления уязвимостей, а смотреть, есть ли за этим нормальный функционирующий процесс с точки зрения:

• адекватности используемых решений для детектирования уязвимостей;
• анализа уязвимостей и заведения задач на устранение уязвимостей;
• охвата инфраструктуры, работы с активами и ответственными за устранение уязвимостей;
• отслеживания выполнения SLA по задачам на устранение уязвимостей для скоупов активов.

Иными словами, есть поток продетектированных уязвимостей со всех известных активов. Он обрабатывается, задачи на устранение уязвимостей заводятся, выполнение задач отслеживается.

Если же, допустим, 10% активов не покрыты детектами или же эти активы не оценены — неизвестно, есть ли среди них целевые или ключевые системы, — то это значит, что нормального VM-процесса у вас нет.

Можно, конечно, не ставить себе целью покрывать инфраструктуру на 100%. Спрятаться за метрику-светофорчик: 90% есть — красим в зелёненький. Но это самообман и обман руководства организации. В случае инцидента светофорчик вас не спасёт.

К сожалению, риски специалиста по ИБ могут заключаться не только в том, что его уволят. В случае успешной атаки на организацию он вполне может оказаться крайним с самыми печальными последствиями. Поэтому одна из важнейших задач решения класса vulnerability management заключается в том, чтобы защищать самого VM-специалиста (и его руководителей вплоть до CISO). Решение должно предоставлять надёжные доказательства, что специалист добросовестно выполнял свою часть работы:

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

Цель в том, чтобы в момент внешнего аудита или расследования инцидента в руках VM-специалиста не было «горячей картошки» — необработанных критически опасных уязвимостей. Это значит, что необходимо постоянно оценивать количество «картошки» в руках и автоматически минимизировать его или предлагать шаги для этого.

12. Какие источники наиболее эффективны для отслеживания уязвимостей в России?

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

Однако имеет смысл дополнительно отслеживать трендовые уязвимости, которые активно эксплуатируются в атаках или могут эксплуатироваться в ближайшем будущем. Обычно таких уязвимостей бывает не больше 10 в месяц. Мы отображаем их отдельно в MaxPatrol VM, а также рассказываем о них в ежемесячных дайджестах, постах на Хабре и видеороликах. Более оперативно информация о них выходит в моём телеграм-канале «Управление Уязвимостями и прочее».

Кроме того, следует читать новости, связанные с уязвимостями. Если про уязвимость начинают писать в СМИ, то она часто действительно критически опасная. Хорошим примером такого агрегатора новостей, связанных с уязвимостями, является раздел «Уязвимости» на CISOCLUB.

---

^[1] Недопустимое событие — событие в результате кибератаки, делающее невозможным достижение операционных и (или) стратегических целей организации или приводящее к значительному нарушению ее основной деятельности. Каждая компания определяет для себя собственные недопустимые события. Это могут быть простой ключевых сервисов, кража денег или критически важных данных, крупные аварии и т. д.