Сколько стоят уязвимости: методология экспресс-оценки рисков для цифровых продуктов

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

Любой цифровой продукт несёт не только потенциальную прибыль, но и риски: операционные, юридические, информационной безопасности. Злоумышленники могут нарушить работу приложения, украсть данные или сделать сервис недоступным. Чтобы этого избежать, просчитывать уязвимости и принимать меры нужно заранее. Но найти баланс между безопасностью и разработкой бывает непросто.

Меня зовут Вячеслав Касимов, я лидер информационной безопасности Точка Банк. В статье расскажу, как мы создали количественную модель оценки рисков информационной безопасности, которая помогла уйти от субъективности и сделать процесс прозрачным для бизнеса.

Как проходит оценка рисков

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

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

При этом важно не допустить двух крайностей:

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

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

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

Почему мы решили идти в количественную оценку риска

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

• Оставить всё как есть: такой подход работал и мог существовать ещё довольно долго, особенно при отсутствии серьёзных инцидентов. Но главная проблема оставалась нерешенной -— меры безопасности по-прежнему зависели от аналитика и были субъективны.
• Прокачивать софт-скилы: можно было развивать переговорные навыки и выстраивать более эффективный диалог с продуктовыми командами. Однако иногда договориться не получается, потому что ИБ и бизнес говорят на разных языках.
• Создать количественную модель оценки рисков: она позволяет обсуждать безопасность не на уровне ощущений, а через понятные и измеримые параметры. Мы выбрали именно этот вариант.

Основная идея заключалась в том, чтобы встроить ИБ-риски в финансовую модель продукта. У любой новой инициативы есть: прогнозируемая выручка, затраты, срок окупаемости. Если выразить риск в денежной форме, его можно обсуждать в той же системе координат, что и бизнес-метрики.

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

И наоборот: если для снижения риска стоимостью 15 миллионов предлагается внедрить меры стоимостью 27 миллионов, то возникает резонный повод пересмотреть подход к защите. Это помогает избежать обеих крайностей -— и недооценки угроз, и чрезмерного усложнения архитектуры.

Как устроена методология экспресс-оценки

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

После этого система автоматически рассчитывает две величины:

• Абсолютный риск — что произойдёт, если не делать вообще ничего.
• Остаточный риск — то, что останется после внедрения конкретных мер для обеспечения безопасности.

Общий риск информационной безопасности для прорабатываемой активности считается так:

Ri — отдельные сценарии, которые могут привести к инцидентам.» >Ri — отдельные сценарии, которые могут привести к инцидентам.

Подсчёт отдельного риска осуществляется по классической формуле:

pi — оценка вероятности возникновения инцидента приводящего к потерям, Ci — потенциальная величина потерь, mj — вероятность, что меры будут эффективны и предотвратят инцидент.» >pi — оценка вероятности возникновения инцидента приводящего к потерям, Ci — потенциальная величина потерь, mj — вероятность, что меры будут эффективны и предотвратят инцидент.

Основная сложность в том, чтобы правильно оценить сами множители. Pi формируется либо на основе статистики, либо выбирается экспертом из середин промежутков [0;0,25), [0,25;0,5), [0,5;0,75),[0,75;1]. Ci оценивается в зависимости от объективных данных: штрафов, средних остатков по счетам, прибыли сервиса.

Эффективность мер — наиболее субъективная сущность, но для валидации вводятся дополнительные эксперты для достижения консента.

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

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

С точки зрения общего воркфлоу почти ничего не изменилось. Новая модель встроилась в существующий процесс как дополнительный инструмент принятия решений. Теперь процесс выглядит так:

• Продуктовая команда описывает инициативу и передаёт информацию экспертам по ИБ и продакт секьюрити.
• Специалисты анализируют архитектуру, оценивают потенциальные угрозы и параллельно заполняют риск-модель.
• На основе расчёта формируется набор мер, которые должны снизить риск до приемлемого уровня.
• После этого команда инфобеза возвращается к продуктовой команде с аргументацией: какой риск существует и как он изменится после внедрения мер.
• Проверяем итоговую реализацию. Если что-то недоделано, задача добавляется в бэклог и контролируется в рамках той же процедуры ДОДов.

На данный момент через новую модель прошли 22 пилотных проекта, в том числе: предоставление доступа новым сотрудникам до подписания документов, интеграция с внешним партнёром по анализу кредитного портфеля, продвижение кредитных продуктов в одном из маркетплейсов, внешний сервис для обучения сотрудников и многие другие.

После внедрения количественного анализа, скорость работы заметно выросла. Если раньше 15-20% задач задерживались, то теперь просрочки стали единичными, большинство инициатив укладывается в ожидаемые сроки.

Что в итоге

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

Однако, даже в текущем виде модель помогает выстроить более прозрачный диалог с продуктовой командой. Благодаря ей мы получили:

• Объективные критерии оценки риска: безопасность перестала восприниматься как набор субъективных требований или «мнение инфобеза». Теперь обсуждение строится вокруг измеримых параметров, поэтому разговаривать о рисках стало проще.
• Формализацию процесса: новый инструмент помогает не упустить важные детали, стандартизирует применяемые меры ИБ и даёт возможность при необходимости вернуться к предыдущим оценкам.
• Возможность оценивать собственную эффективность: разница между абсолютным и остаточным риском стала важной метрикой для бизнеса. Она показывает, какой объём потенциальных потерь удалось предотвратить благодаря участию ИБ-команды. На сегодняшний день сумма исходных рисков для рассмотренных проектов составляет 3,97 млрд. рублей, а остаточных — всего 0,038 млрд. рублей.

В будущем планируем развивать модель дальше: переделаем Excel-таблицу в полноценный внутренний сервис и подключим дополнительную экспертизу со стороны продуктовых команд, чтобы сделать оценку ещё более объективной.

А как проходит оценка рисков у вас в команде? Делитесь в комментариях!