
Python-фреймворк для моделирования угроз
Традиционное моделирование угроз слишком часто происходит слишком поздно, а иногда и вовсе не происходит. Кроме того, создание ручных потоков данных и отчётов может быть чрезвычайно трудоёмким. Цель pytm — сместить моделирование угроз влево, сделав его более автоматизированным и ориентированным на разработчика.
На основе ваших входных данных и определения архитектурного дизайна pytm может автоматически генерировать следующие элементы:
tm.py — это пример модели. Вы можете запустить его, чтобы сгенерировать отчёт и файлы изображений диаграмм, на которые он ссылается:
mkdir -p tm
./tm.py --report docs/basic_template.md | pandoc -f markdown -t html > tm/report.html
./tm.py --dfd | dot -Tpng -o tm/dfd.png
./tm.py --seq | java -Djava.awt.headless=true -jar $PLANTUML_PATH -tpng -pipe > tm/seq.png
Также есть пример Makefile, который объединяет всё это в цели, которые можно легко использовать совместно для нескольких моделей. Если у вас установлен GNU make (доступен по умолчанию в дистрибутивах Linux, но не в OSX), просто запустите:
make MODEL=the_name_of_your_model_minus_.py
У вас должен быть plantuml.jar в том же каталоге, что и ваша модель, либо задайте PLANTUML_PATH.
Чтобы избежать установки всех зависимостей, таких как pandoc или Java, скрипт можно запустить внутри контейнера:
# do this only once
export USE_DOCKER=true
make image
# call this after every change in your model
make
Чтобы упростить использование pytm, зависимости хоста можно полностью изолировать
с помощью Devbox. Обычно это
менее затратная и более удобная альтернатива подходу с OCI-контейнерами.
curl -fsSL https://get.jetify.com/devbox | bashdevbox version update~/.config/nix/nix.conf: access-tokens = github.com=YOUR_TOKEN_HEREdevbox.json проекта: devbox shellpython в терминале, с помощью команды which python. Вывод должен быть следующим путём: .devbox/nix/profile/default/bin/pythonsample.png: ./tm.py --dfd | dot -Tpng -o sample.pngexit«А я думал, мы уже покончили с этим "написанием кода"!» — этот вариант для тех из нас, кто слишком много болтает с ИИ-ассистентами: загляните на https://github.com/izar/tm_skills, чтобы узнать о способах добавить OWASP pytm в вашего помощника по программированию (вам всё ещё понадобится рабочая установка pytm!).
Все доступные аргументы:
usage: tm.py [-h] [--debug] [--dfd] [--report REPORT] [--exclude EXCLUDE]
[--seq] [--list] [--colormap] [--describe DESCRIBE]
[--list-elements] [--json JSON] [--levels LEVELS [LEVELS ...]]
[--stale_days STALE_DAYS]
options:
-h, --help show this help message and exit
--debug print debug messages
--dfd output DFD
--report REPORT output report using the named template file (sample
template file is under docs/basic_template.md)
--exclude EXCLUDE specify threat IDs to be ignored
--seq output sequential diagram
--list list all available threats
--colormap color the risk in the diagram
--describe DESCRIBE describe the properties available for a given element
--list-elements list all elements which can be part of a threat model
--json JSON output a JSON file
--levels LEVELS [LEVELS ...]
Select levels to be drawn in the threat model (int
separated by comma).
--stale_days STALE_DAYS
checks if the delta between the TM script and the code
described by it is bigger than the specified value in
days
Аргумент stale_days пытается определить, насколько в днях скрипт модели (который вы пишете) отстоит от кода, реализующего моделируемую систему. В идеале они должны быть довольно близки в большинстве случаев активно разрабатываемой системы. Вы можете запускать это периодически, чтобы измерять пульс вашего проекта и «свежесть» вашей модели угроз.
В настоящее время доступны следующие элементы: TM, Element, Server, ExternalEntity, Datastore, Actor, Process, Dataflow, Boundary, Lambda, LLM и Agent.
Доступные свойства элемента можно перечислить, используя --describe, за которым следует имя элемента: