В предыдущей статье я рассказывал, как я интегрировал EPSS (Exploit Prediction Scoring System) с системой приоритизации уязвимостей, чтобы уйти от ограничений классической CVSS-модели.
Из практики CVSS не подсказывает, будет ли уязвимость реально эксплуатироваться. Это приводит к перегрузке команд, неэффективному использованию ресурсов и пропуску уязвимостей, которые получат высокий уровень критичность в дальнейшем.

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

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

Одна из главных проблем в управлении уязвимостями — огромный объём задач при ограниченных ресурсах. Не все уязвимости одинаково опасны, и не каждая требует срочного устранения. Даже уязвимость с высоким уровнем риска может не представлять реальной угрозы, если вероятность разработки эксплойта для неё крайне мала. Именно здесь на помощь приходит EPSS (Exploit Prediction Scoring System) — метрика, которая становится ключевым фильтром при расстановке приоритетов.

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

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

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

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

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

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

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

На приктике заказчик не всегда проверяет, а какие на самом деле данные в логах выгружаются.

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

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