🥶 Анализ рисков ИБ: зачем нам риски?

Итак, начнем,

Данный процесс - Анализ Рисков, описывает практику Shift Left (раннего вовлечения) на этапах проектирования (далее тоже посмотрим как это работает?), проработки технического решения и внесения изменений в архитектуру уже на стадии эксплуатации.

Анализ Рисков служит источником требований для команды в рамках Lean-Agile подхода при разработке продукта или проекта. Этот подход особенно полезен и актуален при оценке влияния features на бизнес-логику.

Он позволяет:

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

• Своевременно выявлять и покрывать проблемы с прямым, побочным уроном бизнесу, а также недопустимыми событиями

• Прорабатывать меры снижения рисков

• Определить минимально достаточный объем вводных и конечных данных

Один из самых частых вопросов на проектах:

«Как объяснить бизнесу, что наш AppSec нужен, а не просто тормозит релизы?»

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

Именно поэтому нужен анализ рисков ИБ - язык, который одинаково понимают и разработчики, и бизнес, и мы как инженеры.

Базовые шаги:

1. Идентифицировать - где может прилететь: feature, изменение спецификации инфраструктуры, изменение процессов, новые люди.

2. Классифицировать - описать (vulnerability description), по источнику возникновения (threat description), влиянию (scenario impact description).

В случае необходимости сгруппировать, определить вектор реализации, на сколько уязвимость вменяема для продукта, а дальше проработать PRE- (обязательные условия до поставки в продукционную среду - именно критикалы, блокаторы), POST-меры (что может быть устранено впоследствии)3. Оценить - вероятность (от 0 до 1) × ущерб × устранение × влияние = уровень риска. Здесь помогают предикторные метрики (например, % закрытых findings до релиза) и классические отстающие (legging) метрики (первичное и базовое приблежение)

4. Сопоставить с бизнес-функциями которые являются как изменения технического решения, либо аффектящие компоненты, функции, API endpoints, etc

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

Что это даёт:

1. Разговор с бизнесом на понятных терминах («потери», «TTM», «стоп фактор»)

2. Приоритезацию (не чиним всё подряд, а то, что реально бьёт по деньгам/ срокам)

3. Прозрачность: команда понимает, почему фикс именно этих задач важен

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

Рабочий подход: карта рисков типа Critical, Medium уровня с оценкой и мерами их снижения.

Концептуальный пример: devops необходимо осуществлять мониторинг критичного сервиса, для этого им надо понимать, что и когда может упасть, что бы отследить вовремя инцидент отказа в обслуживании. Следовательно появляется вполне классная мысль: "давайте мы будем отправлять нотификации себе в общий чатик типа телеги?". Идея очень мощная и классная, но например для сектора fintech могут быть вызванные обоснованные риски, такие как.. (смотри картинку поста). Надо продумать какие меры снизят риски ИБ, это может быть линк на внутренний прокси с 2fa, чистка логов в канале, модерирование ботом, использование шифрование канала (WSO2? Мы его рассмотрим), DAM, обезличивание/ маскирование чувствительных данных, подготовка заранее определенных шаблонов и тд. Этот подход либо снижает риски, либо дают понимание бизнесу для реальной ответственности.

Вывод: именно поэтому важно оценивать правильность использования тех или иных feature и давать им оценку влияния от влекущих рисков ИБ.

#riskanalys #pmi #compliance #pmcases #techsolution