82 lines
5.3 KiB
Markdown
82 lines
5.3 KiB
Markdown
|
|
# Prompt
|
|
|
|
Mimic est une application WebUI de type BAS (Breach and Attack Simulation), se basant sur la matrice MITRE ATT&CK. Cette application doit permettre de réaliser des tests en purple Team en fin de mission Read Team. Elle doit être simple et conviviale à utiliser. Elle remplace l'utilisation d'un fichier excel plat que l'on partage entre la redteam et les analystes SOC en fin de mission red team.
|
|
|
|
# Details
|
|
## Simulation
|
|
Une simulation est composée des champs suivants :
|
|
* Partie RedTeam :
|
|
- Nom du test
|
|
- Type d'attaque MITRE correspondant (peut être une liste de référence)
|
|
- Description
|
|
- Commandes exécutés (liste)
|
|
- Pré-requis (champs texte)
|
|
- Date et heure d'exécution
|
|
- Résultat d'exécution
|
|
* Partie Analyste SOC :
|
|
- Source des logs
|
|
- Logs obtenues
|
|
- Commentaires
|
|
- Numéro incident correspondant
|
|
|
|
## Fonctionnement
|
|
La redteam peut modifier l'ensemble des champs d'une simulation, tandis que l'analyste SOC ne peut remplir que sa partie.
|
|
Un workflow de simulation doit être mis en place : Pending, In progress, Review required, Done.
|
|
Le workflow se mettra à jour de la manière suivante :
|
|
- Création de la simulation : pending
|
|
- La redteam saisit des informations dans la simulation : in progress
|
|
- La redteam décide par une action manuelle de passer la simulation en status "review required" ce qui offre à la possibilité au SOC de remplir les informations nécessaire.
|
|
- Le SOC (ou la redteam) décide par une action manuelle de passe la simulation en status "Done".
|
|
|
|
Un engagement correspond à une mission redteam. Il est possible d'ajouter plusieurs test dans un engagement.
|
|
|
|
Prévoir un module d'authentification : dans un premier temps local à la bdd.
|
|
|
|
Dans un premier temps, il s'agit juste de notifier manuellement de l'exécution et les résultats des tests.
|
|
Dans un second temps, après que la V1 soit terminée, nous ajouterons une couche permettant de se connecter à un C2 (mythic ou maison) afin d'exécuter des simulation au travers du C2.
|
|
|
|
## Stacks techniques
|
|
* **FrontEnd** : WebUI
|
|
- Stacks standard : ReactJS, Vite, TailWind etc...
|
|
- Evite l'utilisation de remote librairie un maximum, télécharge toujours les ressources en local si possible.
|
|
- Design récent et UI respectant le fichier `DESIGN.md`
|
|
* **Backend** : Flask Python, Base de données SQLLite
|
|
* **Livrable** : Container compatible Docker/Podman et Makefile pour gérer les différents états des containers - `start`, `stop`, `restart`, `update`, `build`, etc.
|
|
|
|
## Points importants
|
|
* Ne prend pas d'initiative. Si tu doutes d'une fonctionnalité, pose les questions afin de pouvoir coder la fonctionnalité.
|
|
* **Focus sur la méthode KISS** : Keep It Simple and Stupid. Limite toi à des fonctionnalités simples sans entreprendre du coding couteux avec des fonctionnalités non demandées.
|
|
|
|
## Workflows
|
|
* Découpage en sprint
|
|
* Chaque sprint doit apporter une nouvelle fonctionnalité à tester sur l'UI
|
|
* A chaque sprint : Code + Test (Test unitaire python + Test pywright front) + Reviews (spec + code). Une fois le review OK, PR que je valide après test.
|
|
* A chaque fin de sprint, avant mes tests, le team lead doit me faire un récapitulatif synthétique de ce qui a été fait et ce qui doit être testé (et comment le tester).
|
|
|
|
# Team
|
|
|
|
Pour ce projet, j'ai besoin d'une équipe d'agent réparti de la manière suivante :
|
|
1. Team leader : **modèle Opus**
|
|
- Lit les spec et réparti les tâches entre les différents agents
|
|
- En charge de la livraison de son sprint et de la création des PR
|
|
- Met à jour le README.md quand nécessaire
|
|
- Met à jour le fichier SPEC.md quand de nouvelles fonctionnalités ou des précisions sont apportées à certains points
|
|
- Réfléchit à l'aspect architecturale de l'application
|
|
2. Développeur : **modèle Sonnet**
|
|
- Code l'application Frontend et Backend
|
|
- Livre un code simple à comprendre sans essayer de prévoir l'avenir (se limiter au scope)
|
|
- Ne prend pas de décision ou d'hypothèse. Si des questions subsitent, il les remonte au team lead qui décidera de la position à prendre en fonction des contraintes énnoncés par le développeur.
|
|
- Livre un code propre, avec les tests appropriés
|
|
3. Spec reviewer : **modèle Sonnet**
|
|
- Avant chaque début de sprint, lit les plans du team leader et valide les tâches à donner au développeur
|
|
- Si le plan s'éloigne des spec énoncés, le dire au team leader afin qu'il mette à jour son plan pour répondre aux besoins énoncés
|
|
4. Code reviewer : **modèle Opus**
|
|
- A la fin de chaque sprint, avant de réaliser la PR, cet agent relit le code généré par le développeur sur le sprint courant (pas tout le code, juste celui du scope).
|
|
- Utilise un maximum les LSP quand c'est possible
|
|
- Vérifie si des optimisations ou des factorisations de code sont possibles suite aux nouvelles implémentations du développeur.
|
|
- Dans le cas ou des erreurs ou des optimisations ou des factorisations sont possible, les remontés directement au développeur afin qu'il traite les erreurs et en informer le team lead.
|
|
- Quand le code review est OK, le remonter au team lead afin qu'il génère la PR.
|
|
5. Devil advocate : **modèle Opus**
|
|
- Dans le cas de questions structurantes sur le projet, faire intervenir cet agent en tant que tierce personne n'ayant pas connaissance de tout le projet mais permettant d'avoir un regarde neuf sur ces questions.
|
|
|