Понимание оценки CVSS: Вводят ли вас в заблуждение оценки уязвимостей?

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

С 2016 года количество новых уязвимостей, о которых сообщается каждый год, увеличилось почти в три раза. По состоянию на апрель 2022 года прогнозы о количестве новых уязвимостей продолжают сбываться.

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

Уязвимости последних лет

Все критические уязвимости не являются эквивалентом log4j или spring4shell с точки зрения широкого распространения программного пакета, возможности эксплуатации или воздействия.

Идеальное состояние для любой программы кибербезопасности — это возможность быстро выявлять уязвимости, которые действительно влияют на организацию и могут быть использованы. Выгорание ИТ-команд и команд безопасности в погоне за всеми уязвимостями несостоятельно.

В этой статье мы хотим объяснить:

  • Что такое уязвимость?
  • В чем смысл оценки CVSS?
  • Какие переменные влияют на оценку CVSS?
  • Является ли CVSS лучшим способом определения приоритетов в рамках управления уязвимостями?
  • Существуют ли альтернативы CVSS для расстановки приоритетов на основе рисков?

Что означает уязвимость?

MITRE определяет уязвимость как:

«Слабость в вычислительной логике (например, код) в программных и аппаратных компонентах, которая при использовании приводит к негативному воздействию на конфиденциальность, целостность или доступность».

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

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

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

Чтобы углубиться в управление уязвимостями, мы объясним, что представляет собой процесс, когда появляется уязвимость.

Жизненный цикл уязвимости

Происхождение уязвимости никем не определено.

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

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

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

Что в таком случае лучше всего сделать? Усовершенствовать процесс, чтобы быть готовым как можно скорее к раскрытию 0-day и обнаруживать ее с этого момента, предоставляя соответствующие исправления и во многих случаях проверяя, что эта уязвимость не использовалась в прошлом (когда она действительно была 0-day).

Когда уязвимость зарегистрирована, у нас есть идентификатор, который ее идентифицирует. Это поможет нам идентифицировать уязвимость и проверить, подвергаемся ли мы воздействию или нет. Но где она зарегистрирована?

Одним из самых распространенных сайтов, но не единственным, является Common Vulnerabilities and Exposures (CVE). Корпорация MITRE — это организация, которая выявляет, определяет и каталогизирует публично раскрытые уязвимости кибербезопасности и публично делится этой информацией о CVE-идентификаторах. Информация об уязвимостях также передается в организацию NIST, где может быть добавлена дополнительная информация для предоставления более подробных сведений или рекомендаций по безопасности. Эта информация хранится в Национальной базе данных уязвимостей NIST (NVD) и упорядочена по CVE-идентификаторам.

Другие государства имеют свои собственные системы для каталогизации и хранения уязвимостей, например, Китайская национальная база данных уязвимостей (CNNVD) или Японские заметки об уязвимостях (JVN). Но в этой статье мы сосредоточимся на NVD.

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

Как рассчитывается оценка уязвимости

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

Метрики, используемые в CVSS v3.1, последней версии, оценивают различные элементы, которые зависят от процесса эксплуатации и воздействия, в результате чего выводится окончательный балл серьезности. Первое, что мы можем найти в документации, это то, что CVSS измеряет серьезность, а не риск.

CVSS, как оценка, это «объективная» оценка, когда вы задаете некоторые атрибуты уязвимости без контекста, и по формуле получается оценка, которая также сопоставляется с «серьезностью». Ниже мы видим реальный пример CVSS уязвимости Spring4Shell, который оценивает серьезность в 9.8 CRITICAL.

Базовый балл рассчитывается с помощью восьми переменных:

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

  • Сложность атаки (AC): Есть два варианта — низкая или высокая. В версии 3.1 он был обновлен и зависит от требований к системе, чтобы быть уязвимой, где может возникнуть спор, если конфигурация принимается как вероятная или маловероятная. В случае высокой сложности, она определяется как успешная атака, которая зависит от условий, находящихся вне контроля атакующего, но требует от него измеримых усилий по подготовке или выполнению атаки на уязвимый компонент. Например, атакующему необходимо использовать атаки грубой силы, чтобы победить состояние гонки, а не «серебряную пулю» вроде log4j с помощью одной команды.

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

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

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

  • CIA (Конфиденциальность, целостность и доступность): Триада CIA, авторитетная модель безопасности, которая является основой для разработки систем и политик безопасности. Здесь находится реальное воздействие уязвимости. Другая часть — это процесс эксплуатации. С помощью RCE злоумышленник получает полный контроль над машиной жертвы, и если привилегии достаточны, он поражает все три стороны с высокой степенью тяжести.

Конечный формат CVE-2022-22965 представляет собой вектор с этой информацией: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

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

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

Поставщики, такие как RedHat или Debian в качестве поставщика базового дистрибутива, также оценивают серьезность уязвимости в конкретном контексте (т.е. пакет внутри дистрибутива). Клиенты могут доверять оценке поставщика больше, чем общим оценкам, присваиваемым MITRE или NIST, поскольку они обычно более точны.

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

Из расчета баллов CVSS следует несколько производных, которые могут быть полезны при оценке безопасности системы. Вот некоторые из них:

  • Common Misuse Scoring System (CMSS): Это набор показателей серьезности уязвимостей программного обеспечения, связанных с неправомерным использованием. Уязвимости нецелевого использования позволяют злоумышленникам использовать функциональность, которая должна была принести пользу, в злонамеренных целях. Эта оценка может помочь компаниям предоставить данные для использования в количественных оценках общего уровня безопасности системы.

  • Common Configuration Scoring System (CCSS): CCSS основана на CVSS и CMSS. Наиболее заметным отличием является тип эксплуатации: активная или пассивная. Активная эксплуатация подразумевает выполнение злоумышленником действий, направленных на использование неправильной конфигурации, в то время как пассивная эксплуатация подразумевает неправильную конфигурацию, которая препятствует выполнению авторизованных действий, например, конфигурационный параметр, который препятствует созданию записей журнала аудита для событий безопасности.

  • Общая система оценки слабых мест (CWSS): Концептуально CVSS и CWSS очень похожи. CWSS может применяться на ранних стадиях обнаружения новой уязвимости. Кроме того, она может служить для восполнения недостатка некоторой информации в отчете об уязвимости. Поскольку консервативный подход предполагает завышение баллов, глубокое понимание затронутой технологии позволяет получить часть этой недоступной информации. Когда сообщается о новой уязвимости, можно сообщить о ней вместе с эксплуатационной неделей, CWE-ID / CWSS таким же образом, как и в CVSS.

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

Использование альтернатив CVSS Score для приоритизации рисков безопасности

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

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

Скоринговая система прогнозирования эксплойтов

Какова реальная вероятность того, что уязвимость будет использована злоумышленником? Эту вероятность объясняет система оценки прогнозирования эксплуатации (EPSS). Модель EPSS выдает оценку вероятности, и чем выше оценка, тем больше вероятность того, что уязвимость будет использована.

Эта оценка ведется той же организацией, что и CVSS, — MITRE, что гарантирует ее согласованность с вышеупомянутыми таксономиями уязвимостей и системами классификации. Если мы посмотрим на уязвимости с самым высоким рейтингом за последние 30 дней, мы лучше поймем потенциальное реальное воздействие уязвимостей. В качестве примера можно привести CVE-2022-0441, относящийся к плагину MasterStudy LMS WordPress.

Для расчета процентной доли EPSS использует часть оценки CVSS, а также применяет аналитические данные об угрозах, чтобы понять, насколько легко использовать уязвимость. Например, эксплойт может позволить использовать другие уязвимости для усиления воздействия. В рамках сложной цепочки атак злоумышленник может достичь RCE, используя одну уязвимость, а затем использовать другие уязвимости для повышения привилегий, что приведет к более значительному воздействию. Оценка может также учитывать доступность инструментов эксплуатации или репозиториев, таких как Metasploit или Exploit-db, которые не требуют знаний о шагах эксплуатации.

Категоризация уязвимостей для конкретных заинтересованных сторон

Категоризация уязвимостей с учетом заинтересованных сторон (Stakeholder-specific Vulnerability Categorization, SSVC) — это в основном концептуальный инструмент для управления уязвимостями. SSVC стремится избежать универсальных решений в пользу модульной системы принятия решений с четко определенными и проверенными частями, которые менеджеры по управлению уязвимостями могут выбирать и использовать в соответствии со своим контекстом.

Целью SSVC является ориентация на риск, большая прозрачность процесса расчета и возможность масштабирования количественной оценки риска уязвимости за счет автоматизации.

Балльная оценка поставщика

Рейтинг приоритетности уязвимостей (Vulnerability Priority Rating, VPR) поддерживается компанией Tenable и также использует серьезность и возможность эксплуатации, аналогично EPSS.

Рейтинг приоритетности уязвимостей (VPR) является динамическим дополнением к данным, предоставляемым оценкой CVSS уязвимости, поскольку Tenable обновляет VPR, чтобы отразить текущий ландшафт угроз, например, когда код эксплойта уязвимости становится доступным или повышается уровень зрелости. Диапазон значений VPR составляет от 0,1 до 10,0, при этом более высокое значение означает более высокую вероятность эксплуатации.

Другие поставщики, такие как Snyk, создали свой собственный показатель (Snyk Priority Score) для определения приоритетов, используя CVSS и другие факторы, упомянутые выше, такие как зрелость эксплойта, процесс устранения или упоминания в сообществе. Они также оценивают уязвимости в рамках собственных исследований угроз, которые могут не иметь CVE-идентификаторов, но предоставляют ценность при определении приоритетов.

Вертикально-специфические подходы

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

Актуальная для обрабатывающей промышленности система оценки промышленных уязвимостей (Industrial Vulnerability Scoring System, IVSS) включает в свои расчеты такие факторы, как, в частности, физическая безопасность. Эта оценка специально разработана для уязвимостей в промышленных системах управления, которые влияют на критическую инфраструктуру, где ущерб может повлиять на целые города и жизни граждан.

Следующий шаг? Включение информации об уязвимостях и стимулирование мер по их устранению

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

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

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

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

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

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

Одним из самых известных фидов является Vulndb, который использует National Vulnerability Database (NVD) в качестве надежной базы данных уязвимостей, а также владеет зарегистрированными уязвимостями и сотрудничает с компаниями по безопасности, чтобы быть максимально актуальным.

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

Значительное препятствие, которое необходимо преодолеть в отношении исправления, заключается в возможности быстрого исправления каждого отдельного актива или зависимости, которые подвержены воздействию или потенциально могут эксплуатироваться, и эти процессы также должны быть способны масштабироваться. Нетривиально исправлять старые версии, которые могут повлиять на новые функции или низкую производительность; делать это массово или иметь другие последствия. Проблема усугубляется при наличии переходных зависимостей. То есть, ваш код или система, скорее всего, полагаются на множество других кодов или систем, и цепочки зависимостей на практике становятся довольно вложенными. Иногда даже возникает необходимость исправления старых версий, которые все еще распространяются. Это то, что в RedHat называется бэкпортированием.

Бэкпортирование

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

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

Уроки, связанные с оценкой cvss

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

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

Ручные процессы не могут масштабироваться до бесконечности, и у вас никогда не будет достаточно сотрудников для удовлетворения всех ваших потребностей в области безопасности. Безопасность должна быть бесперебойной и автоматизированной. Организации должны планировать соответствующим образом, чтобы опередить волну критических уязвимостей, таких как log4j и spring4shell.

Оцените статью
devanswers.ru
Добавить комментарий