Cas d’usage cybersécurité
Ces exemples fictifs illustrent des situations possibles et des démarches à envisager. Ils ne constituent pas des références clients.
Des situations pour préparer votre projet
Scénarios fictifs : des objectifs à cadrer, sans résultats clients ni délais garantis.
Examiner un dispositif SOC
Banque fictive avec plusieurs sources d’alertes
Objectif : Revoir les règles de détection et les procédures de qualification. Définir les indicateurs à mesurer avant de proposer des améliorations.
Tester la détection avec une Purple Team
Entreprise fictive disposant d’une équipe de défense
Objectif : Exécuter des scénarios autorisés avec les équipes de défense, observer les alertes produites et identifier les règles à ajuster.
Revoir les accès après une acquisition
Groupe industriel fictif réunissant deux environnements cloud
Objectif : Inventorier les identités et les droits dans Microsoft 365 et Azure. Définir les règles communes et vérifier les accès avant toute migration.
Préparer un premier audit cloud
PME technologique fictive utilisant AWS
Objectif : Examiner les accès, l’exposition des services et les journaux disponibles. Classer les écarts puis définir qui vérifie chaque correction.
Organiser la réponse à un incident M365
Entreprise fictive confrontée à un compte compromis
Objectif : Préserver les éléments utiles à l’analyse, examiner les accès suspects et définir les mesures de confinement et de reprise selon la situation.
Cadrer une migration de messagerie
Entreprise fictive du secteur aéronautique
Objectif : Préparer les règles de sécurité d’Exchange Online et de Microsoft Defender, organiser les tests puis vérifier les accès et les flux après migration.
Exemple fictif · Illustration pédagogique
À quoi ressemble un constat de pentest ?
Portail de démonstration : deux comptes de test représentent deux entreprises distinctes. Le test porte sur la séparation de leurs documents.
Cet exemple explique la forme d’un livrable. Il ne présente ni une mission réalisée, ni un résultat client. Le contenu et le périmètre d’une mission sont définis dans le devis.
- Constat
- Le compte de test A peut consulter un document de démonstration appartenant au compte B. Le serveur vérifie la connexion, mais pas les droits sur le document demandé.
- Preuve fictive
- Dans ce scénario, le document DEMO-B-002 contient uniquement « Document de test B ». Sa consultation par le compte A renvoie ce contenu, alors que seul le compte B devrait y accéder. Aucun compte, document ou système client réel n’est utilisé.
- Risque à qualifier
- Si ce comportement existait en production, il pourrait exposer les documents d’autres clients. La priorité dépendrait notamment de leur sensibilité et du nombre de documents accessibles ; aucune note de gravité universelle ne s’applique.
- Correction et responsable
- Responsable applicatif : vérifier côté serveur les droits de l’utilisateur et son rattachement à l’entreprise pour chaque lecture et téléchargement. Appliquer le même contrôle aux accès par API.
- Critère de validation
- Après correction, le compte A ne reçoit aucun contenu appartenant à B, y compris par téléchargement direct. Le compte B conserve son accès légitime. Ajouter ces deux cas aux tests de non-régression.