Бизнес31 июля
Алексей ЛукацкийАлексей ЛукацкийАлексей ЛукацкийАлексей ЛукацкийПо итогам 2023 года был зафиксирован новый рекорд — почти 29 000 зарегистрированных уязвимостей, имеющих свой номер в базе CVE. Это практически на 4000 уязвимостей больше, чем в прошлом году, и число это с каждым годом лишь увеличивается. При этом считается, что на одну зарегистрированную в базе CVE уязвимость приходится не менее трех незарегистрированных — это делает процесс управления уязвимостями крайне сложным для компаний.
Согласно отчету Edgescan, среднее время устранения критически опасных уязвимостей в 2022 году составляло 65 дней (Infosec Institute указывает 60–150 дней), а время начала их эксплуатации, по данным американской CISA, составляет в среднем 15 дней после обнаружения. По данным аналитиков Rapid7, в 2022 году киберпреступники разрабатывали эксплойты быстрее, чем когда-либо: 56% уязвимостей начинали эксплуатироваться в течение семи дней после публичного раскрытия; этот показатель на 12% больше, чем в 2021 году, и на 87% больше, чем в 2020-м. По данным же Palo Alto Networks, в 2022 году злоумышленники начинали сканирование на наличие уязвимостей в течение первых 15 минут после публикации информации в базе CVE. Получается, что устранение уязвимостей осуществляется гораздо позже, чем эти уязвимости начинают использовать атакующие.
Одна из причин промедления — отсутствие выстроенного процесса . Когда их всего несколько десятков или даже сотен в год, можно попробовать устранить их все по мере выявления. Но такой подход дает сбой, когда у вас двадцать пять тысяч уязвимостей. По данным Positive Technologies, в 2022–2023 годах 24% компаний не учитывали значимость актива, на котором обнаружена уязвимость. Большинство компаний не принимали во внимание уровень опасности уязвимости (76%), ее трендовость и наличие публичного эксплойта (59%). Это повышает риск пропустить наиболее опасную для инфраструктуры уязвимость. Что же делать?
В этой статье я рассмотрю различные подходы к приоритизации уязвимостей. Сразу надо сказать, что я не буду рекомендовать какой-либо один, единственно верный метод приоритизации — хотя бы потому, что его нет. У каждого из описанных вариантов — свои преимущества и свои недостатки, своя область применения. Некоторые из них зависят от используемого вами решения по анализу защищенности. Поэтому выбор за вами.
Все методы, рассмотренные в этой статье, разбиты на 3 группы: зарубежные, российские и проприетарные / закрытые.
Common Vulnerability Scoring System (CVSS) — это стандартизированная система оценки опасности уязвимостей, разработанная в 2005 году NIAC (National Infrastructure Advisory Council) и переданная для развития в апреле того же года. Она используется для предоставления единообразной и понятной оценки опасности уязвимостей, что помогает организациям приоритизировать свои усилия по их исправлению.
Согласно CVSS, каждая уязвимость должна оцениваться по трем критериям:
CVSS — самая популярная, а поэтому и самая критикуемая система приоритизации уязвимостей. Она бесплатна и поддерживается многими частными компаниями и государственными организациями. ФСТЭК или НКЦКИ тоже поддерживают этот стандарт, базирующийся на заполнении опросников, считающихся достаточно субъективными. Нередко для одной и той же уязвимости значения CVSS, заданные исследователем уязвимого ПО, его производителем и национальным регулятором, не совпадают.
Более того, сегодня существует несколько версий стандарта CVSS (v2, v3 и совсем недавно принятая v4), которые несовместимы между собой. В базах ФСТЭК и NVD сосуществуют вместе уязвимости с оценками, указанными по разным версиям CVSS. В результате система, которая должна была упорядочить уязвимости, порождает хаос.
CVSS 4.0 — это обновленная версия стандарта для оценки опасности уязвимостей. Она предлагает, по задумке авторов, более точные и гибкие по сравнению с предыдущими версиями механизмы для оценки рисков, связанных с уязвимостями. Среди заявленных преимуществ CVSS 4.0:
Но все эти нововведения, к сожалению, не сделали стандарт CVSS более практичным, скорее наоборот. Исторически сложилось так, что пользователи заходят на портал CVE или в NVD и БДУ, только чтобы посмотреть базовые метрики, а точнее конечное значение от 0 до 10, на базе которого и принимается решение об опасности той или иной «дыры» в ПО. Основная ценность CVSS — в том, что базовые метрики рассчитываются экспертами NIST (или производителями) и предоставляются открыто и бесплатно. Временные метрики (temporal — в ранних версиях, threat — в четвертой версии) обычно никто и никогда не публикует, что и приводит к тому, что их почти и не используют. Что уж говорить о контекстуальных метриках окружения (environmental), которые надо вычислять самостоятельно, чего никто никогда не хотел делать.
С выходом CVSS 4.0 пользователи будут также по-прежнему приходить на NVD (неизвестно, будет ли БДУ поддерживать эту версию) за базовым значением опасности (даже несмотря на то, что с начала 2022 года число тех, кто опирается на NVD, сократилось) и не будут вычислять дополнительные метрики, специфичные для каждой организации. Отчасти станет даже хуже, так как из-за разных версий теперь будет несколько значений базовой метрики для одной и той же уязвимости. Не знаю, как пользователи будут с этим справляться. Кто-то будет брать самое последнее доступное значение (например, по CVSS 4.0), кто-то — максимальное значение из всех представленных, а кто-то — и вовсе среднее арифметическое. И это не говоря уже о несовместимости стандартов CVSS между собой. В какой-то момент мы столкнемся с ситуацией, когда в той же NVD для старых уязвимостей будут указаны метрики только по CVSS 2.0, 3.0, 3.1, а для новых уязвимостей — по CVSS 3.1 и 4.0 (а потом и вовсе только 4.0, если к тому моменту не придумают CVSS 5.0, что вполне реально).
Недостатки CVSS 4.0 (да и 3-й версии) тоже уже очевидны:
CVSS 4.0 представляет собой очередной шаг вперед в области оценки уязвимостей, предлагая более точные и контекстуальные оценки. Однако увеличение сложности и рост требований к знаниям оценивающих может стать вызовом для организаций, особенно в начальный период перехода на новую версию. Положа руку на сердце, признаемся, что мы, скорее всего, и дальше будем использовать только базовые метрики в CVSS.
Но самый непростой вопрос, который сейчас не имеет ответа, — будет ли CVSS и дальше поддерживаться ФСТЭК в условиях геополитической напряженности? С одной стороны, это просто стандартизированная формула расчета опасности уязвимости и она не может нести в себе никакой угрозы. С другой — мы помним, что та же ФСТЭК так и не признала MITRE ATT&CK и множество других стандартов, разработанных в США. А если из БДУ будут удалены ссылки на CVSS, то что будет предложено взамен?
Exploit Prediction Scoring System (EPSS) — это система, разработанная для предсказания вероятности того, что конкретная уязвимость будет проэксплуатирована в реальных условиях. EPSS создана для дополнения существующих методов оценки уязвимостей, таких как CVSS, путем предоставления дополнительной информации о вероятности эксплуатации уязвимости в следующие 30 дней. Первая версия EPSS была выпущена в январе 2021 года и в данный момент , так же как и CVSS, которую можно .
Что отличает EPSS от той же CVSS? Машинное обучение и аналитика данных! EPSS использует методы машинного обучения и анализ больших данных для предсказания вероятности эксплуатации уязвимостей; при этом система обучается на основе исторических данных об эксплойтах, распространенности уязвимости, конфигурациях систем, активности в интернете и др. В отличие от CVSS, которая просто показывает опасность той или иной «дыры», EPSS предоставляет оценку вероятности того, что эта уязвимость будет проэксплуатирована злоумышленниками в течение определенного времени. Недавно вышла третья версия EPSS, которая, как пишут, стала на 82% круче. Эта версия анализирует уже 1164 параметра (атрибута) по каждой уязвимости, поэтому разобраться, как работает система, едва ли возможно (если вдруг у вас была такая мысль). Но система бесплатная: ее можно использовать почти без ограничений и без привязки к решениям тех или иных вендоров.
К основным преимуществам EPSS я бы отнес ее обновляемость и снижение количества ложных срабатываний. EPSS регулярно обновляется на основе новых данных и информации о реальных атаках, что позволяет поддерживать актуальность сделанных оценок и отличает ее от CVSS, у которой базовая метрика почти никогда не меняется. Также с помощью EPSS можно избежать избыточного фокуса на уязвимостях с высокой оценкой по CVSS, но низкой вероятностью эксплуатации (и наоборот), что позволяет более эффективно распределять ресурсы на исправление наиболее опасных уязвимостей.
Но у EPSS есть и недостатки, среди которых я бы выделил пять:
В 2019 году Институт Карнеги — Меллона (SEI) вместе с агентством CISA разработали систему SSVC (Stakeholder-Specific Vulnerability Categorization), которая помогает специалистам по ИБ определять приоритетность устранения уязвимости на основе воздействия, которое ее эксплуатация может оказать на конкретную организацию. В 2020 году CISA вместе с SEI , включив в нее свое дерево принятия решений, которое и является визитной карточкой SSVC.
Идея SSVC достаточно проста: система задает ряд вопросов по каждой уязвимости и в зависимости от полученных ответов советует предпринять одно из четырех действий:
К любому из этих четырех вариантов можно прийти, следуя дереву принятия решений, в развилках которого (CISA называет их точками принятия решения) нужно повернуть в определенную сторону. Таких точек всего четыре, что при наличии у каждой развилки двух или трех ответвлений, дает всего 36 возможных сценариев развития событий. Точки принятия решения следующие:
На что ориентироваться при выборе ответов в дереве принятия решений, CISA не говорят, а значит, речь идет о классической экспертной оценке, что при большом числе уязвимостей очень плохо масштабируется. Без автоматизации и исходных данных для принятия решения эта методика, скорее всего, не станет востребованной, хотя CISA и пишет, что она себя неплохо зарекомендовала в деятельности самого агентства. В подходе ФСТЭК видим ту же проблему: есть дерево принятия решения, но отсутствуют данные, на базе которых эти решения надо принимать.
Понимая сложность использования на практике почти любой из существующих методик приоритизации уязвимостей, в том числе и своей собственной, CISA запустило , то есть каталог уязвимостей, используемых «в дикой природе». Его можно использовать и как один из входных параметров для выбранной методологии приоритизации уязвимостей, и как самостоятельный источник данных о слабых местах в ПО, которые надо устранять в первую очередь, пока ими не воспользовались злоумышленники.
Помимо подхода с указанием трендовых уязвимостей от PT или активно эксплуатируемых уязвимостей от CISA KEV, в интернете можно найти и другие агрегаторы данных об уязвимостях:
При использовании этих сервисов важно помнить, что «трендовые» уязвимости не универсальны и не могут быть одинаковыми в любой части света, так как зависят не только от используемого в том или ином регионе программного обеспечения, но и от активности злоумышленников, действиях которых обычно имеют ярко выраженную географическую привязку.
Тем, кому по каким-либо причинам не подходит дерево принятий решений от CISA, институт Карнеги — Меллона, являющийся соавтором системы SSVC, предложил , которая отличается от первой версии новыми точками принятия решений:
При таком росте числа точек принятия решения растет и число возможных ответвлений, что усложняет сам процесс, но делает его более гибким. При этом в описании SSVC 2.0 больше внимания уделено деталям и примерам. Например, авторы объясняют, почему они пошли именно по выбранному пути с деревьями принятия решений и отказались и от машинного обучения, и от байесовских подходов, и от регрессионного анализа, а также почему CVSS 3.0 не очень хорошо подходит для приоритизации уязвимостей. Кроме того, они подсказывают, как отвечать на задаваемые в дереве вопросы и где брать данные для ответа. Но без автоматизации этот способ приоритизации пока малоприменим на практике.
— это инструмент, который приоритизирует уязвимости, беря за основу CVSS и EPSS от FIRST. Все уязвимости, для которых посчитаны базовые и временные метрики, распределяются по четырем блокам, которые делятся в зависимости от оценок по CVSS и по EPSS (с контрольными значениями 6 и 0,2 соответственно). В итоге у нас получается четыре вида уязвимостей, к которым при наличии сведений об уязвимости в CISA KEV добавляется пятый:
Заменив значение 6 на 7 для CVSS, мы получим подход, схожий с тем, что рекомендует НКЦКИ.
— это метод предсказания уровня опасности уязвимости на основе CVSS, разработанный в проекте Vulners и использующий методы машинного обучения, а конкретно — , которой на вход подаются значения базовой метрики CVSS объектов-предков, связи между объектами в базе данных Vulners (а там более 3 миллионов бюллетеней и статей по ИБ из более чем 200 источников данных), тип объекта, текстовые описания объекта и прочее (список атрибутов, на которых учится ML-модель, в AI Score не раскрывается).
Например, для уязвимостей в OpenSSL (CVE-2022-3602 и CVE-2022-3786) оценка по CVSS v3 была высокой, в то время как система AI Score показала низкий уровень опасности, что и подтвердилось позже в реальной жизни. Для уязвимости CVE-2023-20867 в VMware ESXi ситуация была противоположной: CVSS v3 показывала низкий рейтинг, а расчет AI Score дал высокие значения, что позже было подтверждено рядом атак APT-группировок.
была разработана компанией Zoom и представляет собой 100-балльную систему оценки, которая рассчитывается на основании 13 метрик, объединенных в три группы:
Две метрики находятся вне указанных трех групп:
Авторы , которые уже успели назвать свою систему революционной, , что их детище оценивает уязвимости не с точки зрения атакующего, как достаточно субъективная CVSS, а с точки зрения специалистов по ИБ: анализирует не потенциальный ущерб, который может нанести уязвимость, а действительные возможности эксплуатации. При этом VISS, которую уже успели опробовать на багбаунти-платформе HackerOne в 2023 году, может использоваться вместе с CVSS, дополняя ее.
Система SSPP (Stakeholder-Specific Patching Prioritization) и предлагает фокусироваться на процессе управления патчами в организации, для чего нужно в том числе приоритизировать все устанавливаемое или обновляемое ПО по четырем бинарным критериям, которые оформлены в виде дерева принятия решений:
В зависимости от итогового значения, авторы системы SSPP предлагают удалить неиспользуемое ПО, настроить автоматическую установку патчей или не предпринимать никаких действий.
До недавнего времени ФСТЭК просто требовала устранения уязвимостей, для которых по аналогии с американской NVD или китайской CNNVD был предложен свой банк данных (БДУ); все уязвимости в нем ранжировались согласно стандартам CVSS 3.0 и 3.1. Позже регулятор выпустил уровня критичности уязвимостей программных, программно-аппаратных средств, которая представляет собой фундаментальный труд, описывающий многоступенчатый процесс определения релевантности, актуальности и опасности уязвимости для конкретной организации.
По сути, пользуясь терминологией CVSS, ФСТЭК обязывает оценивать временные и контекстуальные (temporal и environmental) метрики, что представляет, не побоюсь этого слова, колоссальную сложность для абсолютного большинства организаций. В 2024 году среднее число уязвимостей, ежедневно классифицируемых в CVE, составляет 115. Учитывая то, что, помимо уязвимостей, имеющих классификацию CVE, у нас есть «дыры», в базу CVE не попадающие, но числящиеся в БДУ или CNNVD, общее число уязвимостей, которые должны ежедневно загружаться в банк данных, согласно методике ФСТЭК составляет около 350–400. Проведя для каждой из них (что невозможно без автоматизации) определенные вычисления, мы и оценим опасность недостатков ПО, а далее должны будем устранить их в срочном режиме, планово или предусмотреть компенсирующие меры.
Однако есть подозрение, что в текущем варианте методика не учитывает динамичность уязвимостей, которые сегодня могут не иметь эксплойта, а завтра — да, сегодня не быть актуальными из-за отсутствия уязвимого ПО, а завтра — снова да и т. д. Согласно методике, принятое по уязвимости решение уже не меняется. Если мы признали уязвимость не критически опасной, то она будет отнесена к планово устраняемым уязвимостям, и, если завтра она вдруг станет критически опасной, методика не предусматривает процедуры пересмотра ранее принятых решений. В этом плане подход ФСТЭК чем-то напоминает EPSS за одним серьезным отличием: EPSS — это не просто теоретическая методика, это еще и система, которая базируется на большом объеме данных. И если сегодня EPSS считает маловероятным, что уязвимость будет проэксплуатирована в ближайший месяц, то завтра — по мере получения новых данных и автоматического пересчета рейтинга уязвимости — ситуация может поменяться. У ФСТЭК этот динамический пересчет не предусмотрен, а если бы он и был, то должен был бы реализовываться на стороне каждого из заказчиков — а это неподъемная задача.
Требуется постоянно обновлять информацию о состоянии инфраструктуры, чтобы динамически корректировать статусы трех десятков тысяч уязвимостей, обнаруживаемых ежегодно: менять срочность исправления, определять наличие патча или компенсирующей меры, менять релевантность, актуальность и т. п. Как это сделать для тысяч и сотен тысяч узлов в организации — не очень понятно.
Чтобы эта методика заработала в полной мере, регулятору потребуется создание для БДУ схожей с EPSS структуры, которую нужно будет поддерживать в актуальном состоянии, круглосуточно мониторя данные по эксплойтам, использованию уязвимостей «в дикой природе» (хотя методика не учитывает этот показатель сейчас), частоте их обсуждения в даркнете и т. п. Способна ли ФСТЭК реализовать такое с нужными качеством и в нужные сроки?
Национальный координационный центр по компьютерным инцидентам (НКЦКИ) в апреле 2022 года предложил специалистам по IT и ИБ . Он учитывает тип уязвимостей, их рейтинг в CVSS, расположение и страну производителя ПО, характеристику активов, а также влияние на бизнес-процессы компании.
Нельзя называть предлагаемый НКЦКИ алгоритм системой приоритизации уязвимостей, но, так как он позволяет регулировать процесс обновления программного обеспечения (что является конечной целью после приоритизации слабых мест в нем), я посчитал возможным упомянуть его в обзоре.
Схожая с CISA KEV методология разработана и , которая предложила понятие «трендовая уязвимость». Речь идет об уязвимости, которая представляет наибольшую опасность для организации или активно эксплуатируется злоумышленниками, либо об уязвимости нулевого дня, для которой есть подтвержденные механизмы эксплуатации. Иными словами, эксперты Positive Technologies взяли на себя работу по определению слабых мест, эксплуатируемых «в дикой природе», опираясь на информацию:
Отличительная особенность подхода PT — не просто выявление трендовых уязвимостей и их публикация на своем сайте, но и включение соответствующей экспертизы в продукты по управлению уязвимостями в течение 12 часов с момента обнаружения соответствующего слабого места. Уязвимости обычно начинают эксплуатироваться в течение суток после их обнаружения — у пользователей продукции Positive Technologies есть еще 12 часов на устранение слабых мест, если они выявляются в инфраструктуре.
Александр Леонов , названный им ОСОКА (общая система оценки критичности автоматизируемая), в котором приоритизация базируется на трех группах метрик, схожих по идеологии с CVSS:
Не знаю, найдет ли отражение этот подход в каком-либо средстве автоматизации. Возможно, , которое разработал сам Александр.
Страховая компания Coalition летом 2023 года анонсировала свою собственную систему оценки и приоритизации уязвимостей — , которая, так же как и EPSS, позволяет определять вероятность эксплуатации уязвимости. В основе модели ESS лежат собственные внутренние данные Coalition, а также искусственный интеллект и крупные языковые модели. Модель сканирует описания недавно опубликованных в базе CVE уязвимостей и, чтобы предсказать вероятность их эксплуатации, сравнивает их с опубликованными ранее, генерируя две оценки:
Оценка ESS становится доступна в день объявления об уязвимости, в отличие от CVSS. Она динамична, обновляется по мере поступления дополнительной информации и сопровождается историей изменений. Это отход от традиционных способов оценки, результаты которых часто остаются статичными после выпуска (легкий укор в сторону CVSS).
Что «под капотом» у системы — не очень понятно, но, судя по отрывочным сведениям, прорывающимся в публичное интернет-пространство, Coalition заключила партнерские соглашения с GreyNoise и The Metasploit Project, которые и поставляют в ESS данные о том, насколько та или иная уязвимость обсуждается в даркнете, используется в реальных атаках, имеет соответствующий эксплойт и т. п. Кроме того, страховая компания Coalition фокусируется именно на киберрисках, и в их заявлениях и результатах сюрвейинга (оценки страхового случая) появляются данные, которых больше нигде нет.
Но если честно, то один из авторов системы, на вопрос «Чем вы отличаетесь от EPSS?» прямо ответил: «Мы сделали ESS потому, что можем!», а потом добавил, что ESS нужна для клиентов страховой компании, которым нужно обладать данными для расчета стоимости страховки, оценки текущего уровня своей защищенности, выстраивания планов улучшения состояния ИБ и т. п. Иными словами, ESS работает только в связке со страховыми продуктами Coalition, иных преимуществ по сравнению с EPSS у нее нет (обе системы находятся в открытом доступе). Недостатки у нее те же.
Vulnerability Priority Rating (VPR) — это система оценки уязвимостей, разработанная компанией Tenable и предназначенная… здесь бы надо было написать про помощь организациям в приоритизации исправления уязвимостей, но в реальности это просто еще одна закрытая, непубличная система, привязанная к решениям конкретного вендора.
VPR опирается на данные об уязвимостях и угрозах, которые собирает Tenable, и позволяет оценивать уязвимости, учитывая их опасность и вероятность эксплуатации, доступность эксплойта и активность в даркнете, использование «в дикой природе» и другие контекстные данные. Но источники этих данных скрыты от пользователя, который вынужден, как и в случае с другими динамическими системами приоритизации, доверять оценкам выбранной системы. Tenable заявляет о семи ключевых элементах, на базе которых вычисляется VPR:
VPR интегрирована в продукты Tenable, что упрощает процесс оценки и приоритизации уязвимостей для пользователей этих платформ. Отдельно от них применять VPR будет затруднительно, так как, в отличие от EPSS или ESS, ежедневно пересчитываемый рейтинг VPR не публикуется в интернете и доступен только клиентам Tenable.
— это система оценки и приоритизации активов, требующих внимания специалистов по ИТ и ИБ, разработанная компанией Qualys. Вычисления TruRisk зависят от того, о каких устройствах — управляемых (внутренних) или неуправляемых (внешних) — идет речь, и базируется на ряде параметров:
В остальном идея TruRisk во многом схожа с ранее упомянутой системой VPR от Tenable с той лишь разницей, что все преимущества TruRisk доступны только пользователям этого вендора. Исходные данные TruRisk и сам рейтинг неотчуждаемы: применимы только внутри продукта.
MVSF (Mason Vulnerability Scoring Framework) — это методология и инструмент приоритизации уязвимостей при разработке ПО, разработанная совместно с исследовательским центром Пало-Альто (городом, а не компанией), который позже объединился с SRI. В отличие от всех предыдущих методик и фреймворков, позволяющих приоритизировать уязвимости по базе CVE, MVSF предлагает способ ранжирования по базе CWE (Common Weakness Enumeration). Опираясь на данные CWE, NVD, публичные правила IDS Snort и Suricata (по мнению авторов, наличие в публичных репозиториях правил для IDS делает эксплуатацию уязвимостей менее вероятной, так как повышается шанс обнаружения действий хакеров), исследователи университета Джорджа Мейсона предложили ежемесячно обновляемый (а не ежегодно, как CWE Top 25 или OWASP Top 10) список наиболее популярных ошибок при создании программ. Если вы не разработчик ПО, этот инструмент малополезен, к тому же ограничен.
Компания PRIOn выпустила , обогащенную большим объемом дополнительных сведений:
На основе собранной информации PRIOn приоритизирует уязвимости и может передавать эти данные во внешние системы по API.
На самом деле этот список можно было бы еще продолжать и продолжать, так как сегодня почти каждый крупный вендор в области ИТ или ИБ считает своим долгом разработать собственную систему приоритизации уязвимостей. А еще есть стартапы, активно продвигающие тему VPT (vulnerability prioritisation technology), которую они готовы внедрить в любой процесс любого заказчика: от Vulnera, VPT от Outpost24, , , от Ridge Security…
На мой взгляд, выбор у корпоративных пользователей небогат. Либо они целиком и полностью доверяют своим вендорам решений класса vulnerability management, которые берут на себя задачу приоритизации уязвимостей, по сути добавляя к базовым метрикам CVSS временные (temporal) показатели. Либо заказчики должны сами выстраивать этот процесс, самостоятельно выискивая временные показатели в интернете и рассчитывая контекстуальные метрики (environmental) под свою инфраструктуру. Правда, и в этом случае без автоматизации не обойтись.
Можно попробовать разработать и собственную методику приоритизации уязвимостей, как это, например, было сделано в системе VULCON, в которой на основе ранее упомянутых исходных данных были сформированы две метрики, использованные в одном из SOCов:
Однако для этого все равно нужно где-то брать исходные данные. Большинство компаний берут за основу стандарт CVSS, но только в его базовой части. Затем к нему добавляется информация о временных метриках, взятая из тех же EPSS, Coalition ESS, AI Score, CVE Shield, CISA KEV и т. п. Главное — не забывать, что все эти системы не панацея и они не могут ответить вам на вопросы:
Последний вопрос особенно актуален для российских пользователей, которые не только активно начинают использовать локально разработанное ПО, но и живут в условиях, когда информация об уязвимостях в принципе не попадает в базу CVE, оставаясь либо неопубликованной, либо аккумулированной только в БДУ ФСТЭК. А EPSS, AI Score, PRIOn, CVE Shield и т. п. не имеют доступа к БДУ и, соответственно, не могут предоставить расширенные данные по уязвимостям в российском ПО, которых становится все больше и больше.
Вендоры, активно упоминающие в своих материалах риск-ориентированный скоринг, инсайды из хакерского сообщества, непрерывный мониторинг даркнета и социальных сетей, выстроенный процесс threat intelligence, возглавляемый бывшими сотрудниками спецслужб, контекстуализацию, и, конечно же, “AI Driven & Empowered” действуют по той же схеме. Но вместо того чтобы делиться информацией о временных метриках с широкой общественностью или проектами типа NVD и CVE , компании придумывают собственные, часто проприетарные системы приоритизации, выгодно подсвечивающие их продукты или услуги, демонстрирующие их экспертизу и позволяющие продавать свои решения. В основе же почти у всех лежат одни и те же принципы: информация о наличии эксплойта, использование уязвимости в реальных атаках, активность обсуждения в СМИ и соцсетях и т. п. Ко всему этому подключается машинное обучение, и на выходе мы получаем «уникальную и революционную систему приоритизации уязвимостей».
Кто-то идет по более простому пути и разрабатывает свои собственные критерии принятия решений (НКЦКИ, SSPP, CISA), которые и позволяют без сложных средств автоматизации (ха-ха, щаз) выстроить процесс приоритизации. Например, процесс может выглядеть следующим образом: сначала мы устраняем все критически опасные уязвимости, потом уязвимости с эксплойтами, потом только удаленно эксплуатируемые уязвимости, потом те, которые найдены на критически важных активах (можно варианты менять местами или комбинировать).
Однако даже в этом случае где-то нужно брать исходные данные, позволяющие ответить на вопросы об активности использования уязвимостей «в дикой природе». Ровно по этой причине Zoom и разработала собственную систему VISS, которая вообще никак не связана с анализом информации с точки зрения атакующего. К слову сказать, , только 52% респондентов используют CVSS, 45% приоритизируют уязвимости по влиянию уязвимого сервиса или ПО на бизнес, 36% опираются на метрики вендора, а 26% и вовсе разрабатывают какую-то свою систему приоритизации.