owasp/pytmUn framework Pythonic pour la modélisation des menaces
La modélisation traditionnelle des menaces arrive trop souvent en retard, ou parfois pas du tout. De plus, la création manuelle de flux de données et de rapports peut prendre énormément de temps. L'objectif de pytm est de déplacer la modélisation des menaces vers la gauche, rendant la modélisation des menaces plus automatisée et axée sur les développeurs.
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 :
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 diagramme auxquels il fait 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 aussi un exemple de `Makefile` qui regroupe tout cela en cibles faciles à partager pour plusieurs modèles. Si vous avez [GNU make](https://www.gnu.org/software/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 devriez 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 :```
export USE_DOCKER=true make image
make
### Pour commencer - Variante Devbox
Pour simplifier l'utilisation de `pytm`, les dépendances hôtes peuvent être complètement isolées à l'aide de [`Devbox`](https://github.com/jetify-com/devbox). C'est généralement une alternative plus légère et plus pratique que l'approche par conteneur OCI.
- Installez Devbox sur Linux/MacOS : `curl -fsSL https://get.jetify.com/devbox | bash`
- Installez Devbox sur [Windows/WSL](https://www.jetify.com/docs/devbox/installing-devbox/index#installing-wsl2)
- Mettez à 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 à l'aide de la commande which python. La sortie doit être le chemin suivant : `.devbox/nix/profile/default/bin/python`
- Testez en exécutant la commande suivante, qui doit générer un DFD sous forme de fichier PNG nommé `sample.png` : `./tm.py --dfd | dot -Tpng -o sample.png`
- Quittez l'environnement shell Devbox : `exit`
## Utilisation
Tous les arguments disponibles :```text
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/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 du 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 cette vérification 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, SetOfProcesses, Dataflow, Boundary, Lambda, LLM et Agent.