Add some verification step
continuous-integration/drone/push Build is passing Details

This commit is contained in:
nemunaire 2022-06-12 16:19:43 +02:00
parent 193823eda7
commit 75f84ff1a7
3 changed files with 75 additions and 0 deletions

View File

@ -0,0 +1,9 @@
---
date: 2022-06-12T13:46:52+02:00
title: Vérifications à faire
weight: 20
---
Avant de passer votre soutenance, lorsque vous avez terminé une étape, prennez le temps de vérifier les points suivants. C'est ces points qui seront vérifiés par les assistants pour valider votre étape :
{{% children %}}

View File

@ -0,0 +1,36 @@
---
date: 2022-06-12T13:48:35+02:00
title: Scénario général
weight: 10
---
## Sur la page d'accueil
- 1 image sympa ;
- 1 titre sympa : pas de langage familier, ça peut être un jeu de mot, le nom de l'entreprise, ... soyez créatif ;
- 1 à 2 phrase d'accroche bien conçues : c'est-à-dire qui présentent bien, sans s'étendre, mais faut vraiment que ce soit court, environ 6 lignes, 9-10 c'est trop.
## Sur la page du scénario
### Contexte du scénario `overview.md`
Il faut 3 à 4 paragraphes (**pas moins !**) qui présente le contexte, et le présente bien, avec du beau storytelling et sans faute d'orthographe : quel est le secteur de votre entreprise, quelles sont ses activités habituelles, comment s'est passé la découverte de l'incident de sécurité, quelles premières mesures ont été prises (s'il y en a eu), quels sont nos interlocuteurs sur place, où se trouve-t-on, ...
Il faut aussi **au moins 1** schéma (**obligatoire**) qui ne dévoile aucune information pour la suite, mais qui présente convenablement le contexte : cela peut être un schéma d'architecture du réseau (dans lequel on voit les différents équipements ainsi que les séparations, ...)
Pour le texte, il faut essayer autant que possible que ce soit compréhensible par un décideur, d'où le storytelling qui compte davantage que les détails techniques précis. Attention de ne pas donner d'informations qui dévoilent les flags.
Le schéma attendu correspond à un schéma que l'équipe IT donnerait aux auditeurs lorsqu'ils arrivent sur place : il peut y avoir des éléments manquant (on ne sait jamais si le schéma est bien à jour !), profitez-en pour omettre sciemment les détails que vous souhaitez cacher s'ils donnent trop d'indication sur le reste des étapes.
### Présentation des étapes `X-Titre/overview.md`
1 à 2 phrases par étape qui décrit bien l'étape : toujours sans donner d'informations capitales, mais il faut que cela résume bien ce qui sera fait dedans.
Au delà de ces deux phrases (c'est la première ligne du fichier `overview.md` qui est extrait), on peut détailler un peu plus ce qui est attendu, pour que ce soit compréhensible par un décideur.
La suite de ce texte est accessible aux participants lorsqu'ils cliquent sur une étape pour laquelle il n'ont pas encore l'accès. On le retrouve aussi sur le tableau de bord visible du public. C'est pour cela qu'il faut faire un effort pour être le plus pédagogue possible. Le texte est affiche seul, sans le reste du contexte, donc n'hésitez pas à réexpliquer succinctement le contexte.
Pas plus de 2 à 3 paragraphes, la première ligne doit mettre dans l'action et donner envie de lire la suite.

View File

@ -0,0 +1,30 @@
---
date: 2022-06-12T14:15:15+02:00
title: Étape
weight: 15
---
## Le contexte
Il faut veiller à ce que l'étape soit largement décrite dans le moindre détail.
Minimum 3 paragraphes pour poser le contexte (ne pas hésiter à faire des redits par rapport à `overview.txt` ou aux `statement.txt` précédents, car les participants peuvent passer d'un scénario à l'autre) et expliquer ce qui est attendu.
Ici, le storytelling n'est pas important (c'est toujours mieux s'il y a), les informations données sont purement techniques, à destination des participants. À la lecteure du `statement.txt` ils doivent savoir exactement quelles informations rechercher.
# Les flags
## Les intitulés des flags
Vérifiez l'orthographe !
Vérifiez la présence **OBLIGATOIRE** d'un placeholder qui montre le format attendu du flag :
- `x.x.x.x` ou `127.0.0.1` ou `0.0.0.0`, ... pour une IP,
- `0123456789abcdef0123456789abcdef` pour un hash,
- `john.doe` pour un login,
- `secret_password` si c'est un mot de passe,
- ...
Assurez-vous que le label soit une description du champ « Mot de passe de l'administrateur » ou « Hash du fichier compromis », et PAS ~~« Quel est le hash du fichier compromis »~~ <-- c'est pour ça que `repochecker` vous embête pour pas mettre de `?`, on ne formule pas une question, on décrit le contenu attendu dans le champ.