Threat Modelling & Supply-Chain (Part 1: Assets)

Безопасность разработки стала весьма широким доменом в плане охватываемых проблемных зон и инструментов. За последние полгода в одну из решаемых задач попала митигация рисков, связанных с атаками на цепочку поставок (supply-chain attack). Для тех, кто следит за новостями, сразу вспоминаются атаки на SolarWinds (хотя в реальности примеров подобных атак значительно больше). Тем не менее, как связать примеры подобных атак с собственной инфраструктурой и цепочкой поставок не всегда очевидно (чем активно пользуются производители решений SCA).

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

Активами могут стать код, зависимости и итоговый артефакт, то есть те компоненты, которые участвуют в цепочке поставок. Также в качестве активов нередко рассматривают сами системы, которые участвуют в процессе сборки артефактов и их развертывания (CI и CD системы).

Раскидывая все процессы разработки на схеме (мне нравится обычный draw.io с плагином dfd) мы имеем архитектуру нашего сборочного конвейера совместно с этапом раскатки. Детализация схемы зависит от вашего погружения вместе с DevOps командами. Модель угроз можно декомпозировать вплоть до всех компонентов Kubernetes. Чтобы точно убедиться, что мы ничего не пропустили, мы можем расписать процессы отдельно:

CI Master:
- Вызов сборки
- Конфигурация сборки
- Получение секретов git из встроенного хранилища секретов
- ....

К каждому процессу подписываются защищаемыми нами активы:

A01: секреты git
A02: код бизнес-приложения
A03: итоговый артефакт
A04: зависимость
...

Совместно с определением процессов и активов рекомендуется определить так называемые доверенные зоны (trusted zones). Они помогают определить логические границы, за которых ответственны те или иные администраторы систем, а также поверхности атаки злоумышленника в случае, если он окажется внутри инфраструктуры.

#threatmodeling #dev #ops #talks

Security Wine (бывший - DevSecOps Wine)

Threat Modelling & Supply-Chain (Part 1: Assets)

Безопасность разработки стала весьма широким доменом в плане охватываемых проблемных зон и инструментов. За последние полгода в одну из решаемых задач попала митигация рисков, связанных с атаками на цепочку поставок (supply-chain attack). Для тех, кто следит за новостями, сразу вспоминаются атаки на SolarWinds (хотя в реальности примеров подобных атак значительно больше). Тем не менее, как связать примеры подобных атак с собственной инфраструктурой и цепочкой поставок не всегда очевидно (чем активно пользуются производители решений SCA).

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

Активами могут стать код, зависимости и итоговый артефакт, то есть те компоненты, которые участвуют в цепочке поставок. Также в качестве активов нередко рассматривают сами системы, которые участвуют в процессе сборки артефактов и их развертывания (CI и CD системы).

Раскидывая все процессы разработки на схеме (мне нравится обычный draw.io с плагином dfd) мы имеем архитектуру нашего сборочного конвейера совместно с этапом раскатки. Детализация схемы зависит от вашего погружения вместе с DevOps командами. Модель угроз можно декомпозировать вплоть до всех компонентов Kubernetes. Чтобы точно убедиться, что мы ничего не пропустили, мы можем расписать процессы отдельно:

CI Master:
- Вызов сборки
- Конфигурация сборки
- Получение секретов git из встроенного хранилища секретов
- ....

К каждому процессу подписываются защищаемыми нами активы:

A01: секреты git
A02: код бизнес-приложения
A03: итоговый артефакт
A04: зависимость
...

Совместно с определением процессов и активов рекомендуется определить так называемые доверенные зоны (trusted zones). Они помогают определить логические границы, за которых ответственны те или иные администраторы систем, а также поверхности атаки злоумышленника в случае, если он окажется внутри инфраструктуры.

#threatmodeling #dev #ops #talks

hottg.com/sec_devops/510

3.3K viewsDenis Yakimov, edited  Aug 4, 2021 at 07:58