pytm : un framework Pythonique pour la modélisation des menaces

Introduction

La modélisation traditionnelle des menaces arrive trop souvent trop tard, voire parfois pas du tout. De plus, la création manuelle de flux de données et de rapports peut être extrêmement chronophage. L'objectif de pytm est de décaler la modélisation des menaces vers la gauche, en la rendant plus automatisée et centrée sur le développeur.

Fonctionnalités

En fonction de vos entrées et de la définition de la conception architecturale, pytm peut générer automatiquement les éléments suivants :

• Diagramme de flux de données (DFD)
• Diagramme de séquence
• Menaces pertinentes pour votre système

Prérequis

• Linux/MacOS
• Python 3.11+
• Paquet Graphviz
• Java (OpenJDK 10 ou 11)
• plantuml.jar

Pour commencer

Le fichier tm.py est un exemple de modèle. Vous pouvez l'exécuter pour générer le rapport et les fichiers d'images de diagrammes qu'il référence :

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

Il existe également un exemple de Makefile qui regroupe tout cela en cibles facilement partageables pour plusieurs modèles. Si vous avez GNU make installé (disponible par défaut sur les distributions Linux mais pas sur OSX), exécutez simplement :

make MODEL=the_name_of_your_model_minus_.py

Vous devez soit avoir plantuml.jar dans le même répertoire que votre modèle, soit définir PLANTUML_PATH.

Pour éviter d'installer toutes les dépendances, comme pandoc ou Java, le script peut être exécuté dans un conteneur :

# do this only once
export USE_DOCKER=true
make image

# call this after every change in your model
make

Premiers pas - Variante Devbox

Pour simplifier l'utilisation de pytm, les dépendances hôtes peuvent être complètement isolées en utilisant Devbox. C'est généralement une alternative plus légère et plus pratique à l'approche par conteneur OCI.

• Installer Devbox sur Linux/MacOS : curl -fsSL https://get.jetify.com/devbox | bash
• Installer Devbox sur Windows/WSL
• Mettre à jour vers la dernière version de devbox : devbox version update
• Définissez votre jeton d'accès GitHub dans le fichier ~/.config/nix/nix.conf : access-tokens = github.com=YOUR_TOKEN_HERE
• Créez un nouvel environnement shell isolé qui inclut tous les outils et paquets spécifiés dans le fichier devbox.json du projet : devbox shell
• Affichez le chemin complet de l'exécutable Python qui sera utilisé lorsque vous tapez simplement python dans votre terminal en utilisant la commande which python. La sortie devrait être le chemin suivant : .devbox/nix/profile/default/bin/python
• Testez en exécutant la commande suivante, qui devrait générer un DFD sous forme de fichier PNG appelé sample.png : ./tm.py --dfd | dot -Tpng -o sample.png
• Quittez l'environnement shell Devbox : exit

Premiers pas - Variante IA

« Mais je croyais qu'on en avait fini avec ce truc d'« écrire du code » ! » - celle-ci est pour ceux d'entre nous qui passent trop de temps à parler aux assistants IA : consultez https://github.com/izar/tm_skills pour découvrir quelques façons d'ajouter OWASP pytm à votre assistant de codage (vous aurez toujours besoin d'une installation fonctionnelle de pytm !).

Utilisation

Tous les arguments disponibles :

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

L'argument stale_days tente de déterminer l'écart en jours entre le script de modèle (que vous écrivez) et le code qui implémente le système modélisé. Idéalement, ils devraient être assez proches dans la plupart des cas d'un système activement développé. Vous pouvez exécuter ceci périodiquement pour mesurer le pouls de votre projet et la « fraîcheur » de votre modèle de menace.

Les éléments actuellement disponibles sont : TM, Element, Server, ExternalEntity, Datastore, Actor, Process, Dataflow, Boundary, Lambda, LLM et Agent.

Les propriétés disponibles d'un élément peuvent être listées en utilisant --describe suivi du nom d'un élément :