Skip to content

Оценка уязвимостей#

Vuln_Assessment

Типы уязвимостей#

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

Простая техническая уязвимость#

Уязвимости, которые массового встречаются в 💩-коде и собранных на нем продуктах. Самый распространённые - это, например, оставленные пароли и ключи в коде, IP в клиентской части и т.д.

По сути, это все те уязвимости, которые можно отдать разработчику с минимальным участием со своей стороны, т.к. сканеры и анализаторы уже имеют: "Описание" (Description), "Влияние"(Impact) и "Рекомендации к устранению" (Redemption / Mitigation).

Redemption vs Mitigation

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

Комплексная техническая уязвимость#

Несколько простых (даже с критичностью Low или Info) могут сформировать связку, которая позволяет говорить, что в системе присутствует уязвимость более высокого уровня критичности.

Такие уязвимости обычно не находят автоматизированные средства сканирования и для определения такого вектора необходим взгляд специалиста. Именно по этому проводят Анализ защищенности и на основе полученных результатов смотрят возможные вектора атаки.

Анализ защищенности/ Пентест / Аудит

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

Уязвимость бизнес-логики#

Данная уязвимость обычно является следствием отсутствия проведения оценки рисков на этапе аналитики или проектирования. Чаще всего это вытекает из ситуации, что "Бизнес" хочет добиться функционала, которого нет у других, не задумываясь о подводных камнях, которые могут перекрыть стоимость всего проекта.

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

Архитектурная уязвимость#

Info

Данные класс уязвимостей обычно не выделяют в отдельную категорию.

Для себя я отношу к данному типу уязвимости, которые допускаются на этапе разработки и/или аналитике. Например, отсутствие бэкапов клиентских данных или реплик инстансов (hi microservices!), т.к. это может привести к нарушению доступности (Accessability) или отсутствие балансировщика и/или примитивной защиты от DDOS.

Оценка#

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

SDL / SDLC

Software Development Lifecycle. Это самый популярный термин безопасной разработки. Однако, во многих статьях и форумах используется SDLC, где «C» - Cycle. Лично я считаю это не верным.

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

Для себя я выделил 2 общие оценки: - Техническая оценка; - Бизнес оценка.

Техническая оценка#

Проводится с помощью CVSS калькулятора. На момент написание статьи версия 3.1. Я считаю, что все "технические уязвимости" можно оценить с помощью CVSS, однако, в некоторых случаях из-за разного "контекста" возможны несколько оценочных векторов для одной обнаруженной проблемы.

Кстати, ФСТЭК также предлагает оценку угроз с помощью CVSS. Пруф.

Бизнес оценка#

Данная оценка была составлена нашей командой из АБЦТ на основе OWASP Risk Rating Methodology (Business Impact Factors). На тот момент (2019 год) она считалась оптимальным решением и, в принципе, актуальна до сих пор.

Общая оценка#

Общая оценка считается как среднеарифметическая из двух ранее описанных.

По итогу мы получаем описанную с разных углов проблему безопасности, чтобы продавать1 разработке и владельцам продуктов (Product Owner). В нашем случае, мы формировали вектора по каждому калькулятору и прикладывали их в поле Риски у задач в Jira.

Например, так: 

* Medium = 4.725
* CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N = 3.7
* BIS-IMP:1.0/FD:M/RD:LG/NC:H/PV:H = 5.75

Вот скромные наработки для этих оценок.

Комментарии и дискуссии.

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

Back to top