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

Threat Modelling & Supply-Chain (Part 2: Threats & Threat Actors)

Следующим этапом определим пользователей наших процессов. Эти же пользователи будут нашими потенциальными нарушителями (threat actors). Рассматривая атаки на цепочки поставок это могут быть внутренние нарушители (разработчики, администраторы CI и CD систем, администраторы кластера, сопровождение ОС и так далее) и внешние (пользователь, который может повилять на общедоступные репозитории).Также на этом этапе мы понимаем, где еще могут использоваться наши защищаемые активы (секреты и код на рабочих станциях).

Далее переходим к главному и самому сложному - раскидывание угроз. Сложность заключается в том, чтобы определить для себя исчерпывающий перечень угроз. В лучшем случаем вам может помочь банк угроз (например MITRE), в худшем случае придется опираться на собственный опыт и известные кейсы.

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

На этом этапе мы можем получить уже множество интересных открытий. Например, оказывается, что разработчик имеет возможность изменять пайплайн развертывания подменяя источник артефактов, внедряя backdoor или малварь. На этом же этапе мы можем определить у себя возможность реализации Dependency Confusion при скачивании зависимости разработчиком из Artifactory и многое другое.

В следующих постах мы поговорим про приоритизацию угроз и формирование требований ИБ по результатам модели угроз. Если вы уже хотите попрактиковаться, то можете почитать пример моделирования угроз для облачного приложения в AWS с использованием STRIDE. Хорошим материалом является также Threat Modeling Training от компании Segment, где есть простые и понятные слайды по всем этапам моделирования угроз.

#threatmodeling #dev #ops #talks

bilibili/LastOrder-Dota2
Dota2 AI bot
Language: Python
Stars: 85 Issues: 0 Forks: 5
https://github.com/bilibili/LastOrder-Dota2

Искуственный интеллект™ (модель машинного обучения) переводит просьбы на английском языке в питон-код для обработки и представления данных.

Срочно нужен такой же для перевода с русского на 1С.

https://github.com/deepklarity/jupyter-text2code

https://github.com/MaksimDzhangirov/complete-gRPC/blob/main/SSL_TLS_lecture_rus.md
Подробное описание SSL/TLS и его криптографической системы

Exo - инструмент для логирования и работы с процессами в системе.

https://github.com/deref/exo
https://github.com/deref/exo/blob/main/doc/guide.md

#Exo

Обновил реализацию Web Ring для Telegram.
Из основного: переделал систему управления кольцом. Теперь все управление лежит на плечах Ring Master - для этого в бота были добавлены удобные кнопочки управления.
Также, исправил какие-то баги и что-то улучшил.

линк на Github проекта
линк текст про Web Ring

StackFinder: A VSCode extension to help you find and use Stack Overflow answers

/r/datascience
https://redd.it/p0e2zb

Telegram Remote Administration Tool

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

Ссылка на проект: https://github.com/Antcating/telegram-remote-bot

П.с. Да, я опять ищу переводчика на русский язык.

MITM-cheatsheet

https://github.com/Sab0tag3d/MITM-cheatsheet

🖇 Фаззинг + IDOR = Права администратора

Классический способ поэтапной эксплуатации уязвимостей контроля доступа в API и получение прав администратора.

#web #idor #api #fuzz

Читать статью