Ce projet part d’une idée simple : une attaque ne réussit pas seulement parce qu’un message est convaincant. Elle réussit quand une demande arrive à traverser une suite de contrôles jusqu’à produire un effet réel.
- Sollicitationmail, SMS, appel, réunion
- Actionsaisir, approuver, exécuter
- Capacitésession, droit, paiement
- Effetaccès, fuite ou fraude
Ce que je cherche à comprendre
Je ne veux pas classer les personnes entre celles qui seraient vigilantes et celles qui ne le seraient pas. Je préfère regarder ce que le système exige après une erreur humaine normale.
Une défense devient intéressante lorsqu’elle demande une preuve que l’attaquant ne peut pas obtenir par la seule persuasion. Mais cette preuve doit correspondre à l’action réelle : authentifier une personne ne prouve pas forcément qu’elle autorise le bon appareil, le bon paiement ou le bon interlocuteur.
Une série plutôt qu’un long texte
Chaque module isole un mécanisme. Les incidents servent à comparer des chemins, pas à distribuer des bons et des mauvais points. Les schémas montrent où la chaîne continue et où elle s’arrête.
D’où vient le projet
Le point de départ est mon mémoire ENG251 sur les techniques d’ingénierie sociale et leurs défenses. Ici, je garde les idées et les sources, mais je retire la forme universitaire : moins de texte continu, davantage de chemins, de comparaisons et de questions concrètes.
Ce dossier reste évolutif. Les prochains modules pourront traiter la récupération de compte, les paiements validés hors bande, ClickFix ou encore la place réelle de la sensibilisation.