Приоритизация уязвимостей без дорогих платформ на Budibase

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

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

При устранении уязвимостей существуют несколько проблем:

1. Большое количество уязвимостей разного риска на разных активах.

2. Отсутствие единого способа понять, что приоритетно, так как опираться только на риск по CVSS не всегда является правильным решением и пентесты это доказывают.

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

Теория и метрики приоритета

После сканирования на уязвимости необходимо проанализировать результат и задать приоритет устранения уязвимостей. На самом деле если обновления проводятся постоянно, то большинство уязвимостей будет устранено без особых усилий.

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

Для оценки я сделал интерфейс в Budibase который позволяет оценить приоритетные уязвимости в количественном масштабе и выгрузить для коллег список в .csv формате.

Приведу основные метрики по которым создавал фильтры:

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

• Значимость актива — насколько актив значим, если к нему получат доступ.

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

• Трендовость уязвимости — означает эксплуатируется ли данная уязвимость активно в данный момент. Если имеется информация с оценкой от вендора сканера уязвимостей или оценка от threat intelligence, то можно задать такой параметр.

• Вектор эксплуатации — это метрики CVSS(локально/удаленно).

• Наличие эксплойта — имеется готовый эксплойт под уязвимость.

• Критичность уязвимости — оценка того насколько уязвимость критична согласно базовым метрикам CVSS.

• Наличие исправления — наличие обновлений от вендора, устраняющих уязвимость.

Реализация фильтров приоритезации в Budibase

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

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

В запросе SQL они фиксируются между двумя скобками {{ var }} в нужном месте. Таким образом получается полноценный SQL запрос.

Сам SQL-запрос создаётся во вкладке Data, внутри раздела подключения к СУБД.

Там же задаются bindings для SQL-запроса и значения по умолчанию — на случай, если фильтр пуст или ничего не выбрано. Эти условия также должна учитывать логика самого SQL-запроса.

Примеры SQL запросов с приоритизацией для построения дашбордов

Приведу несколько примеров SQL-запросов для построения дашбордов с учётом фильтров приоритизации.

Дашборд 1 — Топ 10 уязвимых активов

SELECT COUNT(hostname) AS total, hostname FROM mat_allassets WHERE osname ILIKE '%windows 20%' AND status = 'new' AND VulnerabilityIssueTime < CURRENT_DATE - {{days}}::interval AND (   CASE  WHEN {{ sev }}::text IS NULL THEN TRUE  ELSE severity = {{ sev }}::text  END ) AND (   CASE  WHEN {{expltbl}}::bool IS NULL THEN TRUE  ELSE metrics ILIKE 'Exploitable: {{expltbl}}%'::text  END ) AND (   CASE  WHEN {{netvector}}::bool IS NULL THEN TRUE  ELSE metrics ILIKE '%HasNetworkAttackVector: {{netvector}}%'::text  END ) AND (   CASE  WHEN {{remedy}}::bool IS NULL THEN TRUE  ELSE metrics ILIKE '%HasFix: {{remedy}}%'::text  END ) AND (   CASE  WHEN {{vulntrend}}::bool IS NULL THEN TRUE  ELSE VulnerIsTrend = '{{vulntrend}}'::text  END ) AND (   CASE  WHEN {{hostimport}}::text IS NULL THEN TRUE  ELSE HostImportance = '{{hostimport}}'::text  END ) GROUP BY hostname ORDER BY total DESC LIMIT 10;

Дашборд 2 — Топ 10 уязвимых сервисов

SELECT COUNT(hostname) AS total, VulnerableEntity || ' ' || VulnerableEntityVersion AS VulnerableObject FROM mat_allassets WHERE osname ILIKE '%windows 20%' AND VulnerableEntity IS NOT NULL AND status = 'new' AND VulnerabilityIssueTime < CURRENT_DATE - {{days}}::interval AND (   CASE  WHEN {{ sev }}::text IS NULL THEN TRUE  ELSE severity = {{ sev }}::text  END )  AND (   CASE  WHEN {{expltbl}}::bool IS NULL THEN TRUE  ELSE metrics ILIKE 'Exploitable: {{expltbl}}%'::text  END ) AND (   CASE  WHEN {{expltbl}}::bool IS NULL THEN TRUE  ELSE metrics ILIKE 'Exploitable: {{expltbl}}%'::text  END ) AND (   CASE  WHEN {{netvector}}::bool IS NULL THEN TRUE  ELSE metrics ILIKE '%HasNetworkAttackVector: {{netvector}}%'::text  END ) AND (   CASE  WHEN {{remedy}}::bool IS NULL THEN TRUE  ELSE metrics ILIKE '%HasFix: {{remedy}}%'::text  END ) AND (   CASE  WHEN {{vulntrend}}::bool IS NULL THEN TRUE  ELSE VulnerIsTrend = '{{vulntrend}}'::text  END ) AND (   CASE  WHEN {{hostimport}}::text IS NULL THEN TRUE  ELSE HostImportance = '{{hostimport}}'::text  END ) GROUP BY VulnerableObject ORDER BY total DESC LIMIT 10;

Дашборд 3 — Топ 10 активных CVE

SELECT COUNT(DISTINCT hostname) AS total, cve FROM mat_allassets WHERE osname ILIKE '%windows 20%' AND status = 'new' AND cve IS NOT NULL AND VulnerabilityIssueTime < CURRENT_DATE - {{ days }}::interval AND (   CASE  WHEN {{ sev }}::text IS NULL THEN TRUE  ELSE severity = {{ sev }}::text  END ) AND (   CASE  WHEN {{expltbl}}::bool IS NULL THEN TRUE  ELSE metrics ILIKE 'Exploitable: {{expltbl}}%'::text  END ) AND (   CASE  WHEN {{netvector}}::bool IS NULL THEN TRUE  ELSE metrics ILIKE '%HasNetworkAttackVector: {{netvector}}%'::text  END ) AND (   CASE  WHEN {{remedy}}::bool IS NULL THEN TRUE  ELSE metrics ILIKE '%HasFix: {{remedy}}%'::text  END ) AND (   CASE  WHEN {{vulntrend}}::bool IS NULL THEN TRUE  ELSE VulnerIsTrend = '{{vulntrend}}'::text  END ) AND (   CASE  WHEN {{hostimport}}::text IS NULL THEN TRUE  ELSE HostImportance = '{{hostimport}}'::text  END ) GROUP BY cve ORDER BY total DESC LIMIT 10;

Что в итоге получилось

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

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

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

Будет интересно узнать, используете ли вы приоритизацию уязвимостей в своей работе? Как отслеживаете проблемные активы?