— Cybersécurité
Défensive, autorisée, éthique
J'utilise la connaissance offensive dans un seul but — fortifier et auditer mes propres systèmes.
Méthodologie de test d'intrusion, analyse de vulnérabilités et rétro-ingénierie, appliquées strictement à l'intérieur de limites autorisées. Le travail est défensif : trouver le chemin avant un attaquant réel, et le fermer.
Tout sur cette page est défensif. Les techniques offensives n'existent que pour fortifier et auditer — appliquées contre une infrastructure que je possède, à l'intérieur d'une limite autorisée, éthique et légale.
Je travaille la cybersécurité avec la profondeur d'un spécialiste de la sécurité : méthodologie de test d'intrusion, analyse de vulnérabilités, rétro-ingénierie, sécurité des réseaux et des protocoles, cryptographie appliquée, modélisation des menaces, et durcissement Linux pour des environnements critiques. Le jeu de compétences recoupe ce que sait un attaquant — c'est précisément pourquoi je suis explicite sur la façon dont il est utilisé.
Il est utilisé pour défendre. Je conduis des tests de sécurité autorisés contre mes propres systèmes et l'infrastructure des agents afin de trouver d'abord les faiblesses atteignables et de les fermer avant qu'elles ne puissent être exploitées. Il n'y a ici aucun travail adversarial, aucun test de systèmes que je ne possède pas, et aucun outillage offensif développé ou distribué.
Dit simplement : la méthodologie est la même qu'utiliserait un attaquant, la cible est toujours la mienne, l'autorisation est toujours explicite, et la sortie est toujours une vulnérabilité fermée. Cette limite n'est pas une note de bas de page de ce travail — c'est le travail.
chaque système conçu en couches, pour qu'aucune défaillance unique n'expose l'ensemble
tout test d'intrusion est limité à une infrastructure que je possède et suis autorisé à tester
vulnérabilités trouvées et fermées en auto-audit, en amont de tout adversaire réel
chaque technique appliquée à l'intérieur d'une limite autorisée, éthique et documentée
Quatre compétences qui se recoupent, une intention défensive.
Ce sont les disciplines que je travaille à la profondeur d'un spécialiste. Chacune est présentée telle qu'elle est réellement appliquée — à l'intérieur d'un périmètre autorisé, contre ma propre infrastructure, pour la durcir.
Méthodologie, appliquée à mon propre périmètre
Je mène des tests d'intrusion comme on mène une mission structurée : périmètre, reconnaissance, énumération, exploitation contrôlée d'une découverte, et un rapport écrit qui se termine par un correctif. La différence avec une mission externe est que le périmètre est toujours une infrastructure que je possède et que je me suis autorisé à tester.
Le but n'est jamais de prouver que je peux entrer. C'est de trouver le chemin qu'un attaquant réel emprunterait, de le documenter, et de le fermer avant que quiconque d'autre ne l'emprunte.
- Périmètre, reconnaissance, énumération, exploitation contrôlée, rapport
- Cibles limitées à mes propres systèmes et à l'infrastructure des agents
- Chaque découverte se termine par une vulnérabilité fermée, pas un trophée
Lire un système pour voir où il cède
L'analyse de vulnérabilités est la moitié peu glorieuse du travail : énumérer les versions, configurations, services exposés et relations de confiance, puis raisonner sur quelle combinaison devient une faiblesse réelle et atteignable plutôt que théorique.
Je traite un CVE comme une hypothèse, pas comme un verdict. La question est de savoir s'il est atteignable dans ma configuration réelle, et quel est le rayon d'impact s'il l'est — pas si un scanner l'a signalé.
- Énumération des services, versions et configurations
- Raisonnement sur l'atteignabilité et le rayon d'impact plutôt que sur la sortie brute du scanner
- Découvertes classées par exploitabilité dans le déploiement réel
Comprendre un binaire pour s'en défendre
La rétro-ingénierie, dans un contexte autorisé, est la façon dont je comprends ce qu'un binaire fait réellement — un échantillon de malware dans un bac à sable, un composant fermé dans ma propre pile, un protocole sans spécification publiée. L'analyse statique et dynamique répond à des questions que la documentation ne peut pas.
La sortie est défensive : une signature, une règle de durcissement, la compréhension d'une technique d'attaque qui me permet de la détecter ou de la bloquer. Je ne développe ni ne distribue d'outillage offensif.
- Analyse statique et dynamique en environnements isolés
- Appliquée à la compréhension des malwares et à l'analyse de protocoles
- La sortie est détection et durcissement, jamais outillage offensif
Utiliser correctement les primitives, pas les inventer
La cryptographie appliquée consiste surtout à ne pas commettre les erreurs bien connues : choisir des primitives éprouvées, utiliser le chiffrement authentifié, gérer correctement les clés et les nonces, et résister à la tentation d'inventer son propre schéma. La partie difficile est l'intégration, pas l'algorithme.
Je raisonne aussi sur les modèles de menace face à la cryptographie — ce que voit un attaquant, ce qu'il peut rejouer, ce qu'une clé compromise expose réellement — afin que les garanties correspondent aux affirmations.
- Primitives éprouvées et chiffrement authentifié par défaut
- Gestion disciplinée des clés, nonces et secrets
- Garanties alignées sur un modèle de menace explicite
Aucun contrôle unique ne porte tout le système.
Architecture en couches pour environnements critiques
Je conçois en supposant que chaque couche peut échouer — pour qu'une défaillance n'expose pas tout ce qui se trouve derrière.
La défense en profondeur est l'architecture que j'adopte par défaut pour les environnements critiques. Au lieu d'un unique périmètre fort, le système est construit en couches concentriques — périmètre, hôte, processus, conteneur, données, identité, détection — chacune imposant indépendamment le moindre privilège.
L'hypothèse sous-jacente est que toute couche unique peut être contournée. La question de conception n'est jamais de savoir si un contrôle tiendra toujours, mais ce qu'un attaquant atteint s'il ne tient pas. Le schéma le retrace : une compromission à un anneau rencontre encore le suivant.
- Couches concentriques, chacune imposant le moindre privilège
- Conçues pour qu'un contournement n'expose pas l'ensemble
- La détection enveloppe les couches comme vérification finale
- Par défaut pour les environnements critiques
Les couches — ce que chacune impose
- Périmètre
- Segmentation réseau, pare-feu, minimisation de la surface exposée
- Hôte
- Durcissement Linux — paramètres du noyau, sysctl, services minimisés
- Processus
- Sandboxing systemd, retrait de capacités, isolation par namespaces
- Conteneur
- Frontières d'isolation, moindre privilège, racines en lecture seule
- Données
- Cryptographie appliquée au repos et en transit, gestion des secrets
- Identité
- Moindre privilège, identifiants restreints, pas de secrets à longue durée dans le code
- Détection
- Journalisation, vérifications d'intégrité, auto-audit contre les couches ci-dessus
Décider contre quoi je me défends, avant de décider comment.
Un contrôle choisi sans modèle de menace est une supposition. Avant de durcir quoi que ce soit, je travaille sur qui est l'adversaire, ce qu'il veut, où il peut atteindre, et ce qu'une compromission réussie expose réellement. Ce modèle est ce qui transforme une liste générique en une défense alignée sur une menace réelle.
C'est aussi là que la connaissance offensive gagne sa place défensivement : penser comme l'attaquant est la façon dont je trouve le chemin qu'il vaut la peine de fermer en premier. Le schéma ci-dessous est la forme de ce raisonnement — actif et adversaire d'un côté, surface et rayon d'impact de l'autre, se résolvant en un contrôle concret.
Adversaire, actif, surface, contrôle
Un modèle de menace est une carte allant de qui pourrait attaquer à ce qui ferme le chemin.
Chaque branche du modèle commence par un adversaire et un actif qu'il voudrait, traverse la surface qui les relie, et se termine au contrôle qui rompt le lien. L'écrire rend les hypothèses visibles — et une hypothèse qui cesse silencieusement de tenir est la façon dont la plupart des défenses échouent.
Je garde le modèle vivant plutôt qu'unique : chaque découverte d'un auto-audit y est réinjectée, et chaque contrôle se résout en une couche et un test.
- L'adversaire et l'actif nomment la menace
- La surface d'attaque les relie
- Chaque branche se résout en un contrôle par couches
- Les découvertes sont réinjectées dans le modèle
Qui est l'adversaire
Je commence chaque modèle de menace en nommant celui contre qui je me défends — balayage opportuniste, attaquant ciblé ou erreur interne — car les contrôles diffèrent pour chacun.
Que recherchent-ils
Identifier les actifs qui comptent — identifiants, infrastructure des agents, données — concentre la défense sur ce qu'un attaquant poursuivrait réellement.
Où peuvent-ils atteindre
Cartographier la surface d'attaque réelle, pas la supposée : ce qui est exposé, ce qui est de confiance, et en quoi les relations de confiance s'enchaînent.
Quel est le rayon d'impact
Pour chaque faiblesse atteignable, raisonner sur ce qu'une compromission réussie expose réellement — et l'utiliser pour classer le travail.
Où sont les hypothèses
Écrire les hypothèses dont dépend un contrôle, car une hypothèse qui cesse silencieusement de tenir est la façon dont la plupart des défenses échouent.
Qu'est-ce qui la ferme
Chaque entrée du modèle se résout en un contrôle concret à une couche précise, et un test qui prouve que le contrôle fonctionne.
L'hôte, réduit à ce dont il a réellement besoin.
Noyau · sysctl · systemd · conteneurs · secrets
Le durcissement est une soustraction — chaque service, capacité et privilège dont le système n'a pas besoin est retiré.
Sous Linux, le travail est concret : paramètres conservateurs du noyau, protections réseau et mémoire de sysctl, sandboxing des unités systemd, isolation des conteneurs, et gestion disciplinée des secrets. Chaque couche retire quelque chose qu'un attaquant pourrait sinon utiliser.
systemd en particulier fait beaucoup de travail silencieux — NoNewPrivileges, ProtectSystem, capacités retirées et systèmes de fichiers en namespaces transforment un service ordinaire en un service confiné. Les conteneurs ajoutent une seconde frontière d'isolation avec moindre privilège, images minimales. La pile ci-dessous se lit de bas en haut, du noyau aux secrets.
- Paramètres du noyau et protections sysctl, documentés
- Sandboxing systemd — capacités retirées, système de fichiers confiné
- Isolation des conteneurs avec moindre privilège, images minimales
- Secrets gardés hors du code et des logs, restreints et tournés
Pile de durcissement — contrôle par couche
- Noyau
- Paramètres conservateurs, réduction de la surface d'attaque
- sysctl
- Protections réseau et mémoire réglées et documentées
- Unités systemd
- Directives de sandboxing — NoNewPrivileges, ProtectSystem, jeux de capacités
- Isolation des conteneurs
- Namespaces, moindre privilège, images minimales
- Gestion des secrets
- Secrets hors du code et des logs, restreints et tournés
- Sauvegardes
- Changements réversibles, sauvegardes horodatées avant toute modification
- Validation
- Chaque contrôle vérifié par un test réel, pas supposé
Le durcissement est surtout une soustraction. La façon la plus fiable de défendre un service est de retirer tout ce dont il n'a pas besoin avant qu'un attaquant ne lui trouve un usage.
La méthodologie, menée de bout en bout sur mon propre périmètre.
Je conduis des tests de sécurité autorisés contre ma propre infrastructure à une cadence régulière — la même méthodologie qu'utilise une mission externe, limitée aux systèmes que je possède.
BlackArch Linux est la plateforme que j'exploite à un niveau aisé pour cela. C'est une distribution conçue pour les tests de sécurité, et je l'utilise pour l'auto-audit autorisé et le test d'intrusion contrôlé de mes propres systèmes et de l'infrastructure des agents — jamais contre quoi que ce soit que je ne possède pas ou ne suis pas autorisé à tester.
La séquence est délibérée et bornée : autoriser et délimiter par écrit, puis reconnaissance, énumération, une exploitation contrôlée qui va juste assez loin pour prouver qu'une découverte est atteignable, un rapport écrit, et une remédiation qui est retestée jusqu'à ce que le chemin ait disparu. L'étape d'exploitation est celle qui exige de la discipline — assez loin pour prouver le risque, jamais plus.
Test d'intrusion autorisé — du périmètre au retest
- 01 Autoriser et délimiter Définir exactement lesquels de mes systèmes sont dans le périmètre, et les règles du test, par écrit.
- 02 Reconnaissance Cartographier la surface exposée réelle — services, versions, relations de confiance.
- 03 Énumération Cataloguer les configurations et les faiblesses atteignables face à cette surface.
- 04 Exploitation contrôlée Valider une découverte en isolation, juste assez pour prouver l'atteignabilité, pas plus.
- 05 Rapport Documenter le chemin, l'impact et la remédiation précise.
- 06 Remédier et retester Fermer la vulnérabilité, puis relancer pour confirmer que le chemin a disparu.
BlackArch Linux · périmètre autorisé
Une boîte à outils conçue pour l'offensive, pointée uniquement vers mes propres systèmes.
L'aisance avec une distribution de test de sécurité comme BlackArch compte parce que l'outillage est tranchant ; la responsabilité réside dans la direction où il est pointé. Pour moi, c'est une réponse fixe — ma propre infrastructure, avec l'autorisation établie avant que quoi que ce soit ne s'exécute.
Mener cela à une cadence signifie que les faiblesses apparaissent dans mon propre rapport avant d'apparaître dans celui de quelqu'un d'autre. C'est toute la valeur de le faire : je préfère trouver le chemin moi-même, à mon rythme, plutôt qu'il soit trouvé pour moi.
- BlackArch exploité à un niveau aisé pour les tests autorisés
- Périmètre fixé à mes propres systèmes et à l'infrastructure des agents
- Mené à une cadence régulière, pas une seule fois
- Découvertes fermées avant qu'elles ne puissent être exploitées
Trouver le chemin avant un adversaire réel.
La raison pour laquelle toute cette connaissance offensive existe dans mon travail est la boucle qu'elle alimente : modéliser la menace, tester mes propres systèmes avec cette méthodologie, trouver les faiblesses atteignables, durcir la bonne couche, et vérifier le correctif avant qu'il ne ferme. Puis le résultat retourne au modèle et la boucle recommence.
C'est un cycle continu plutôt qu'un projet avec une fin. Les systèmes changent, les dépendances changent, et un contrôle qui tenait le trimestre dernier peut ne pas tenir aujourd'hui — donc l'audit est récurrent par conception. Le schéma est cette boucle, dessinée comme le cycle qu'elle est.
Modéliser → tester → trouver → durcir → vérifier
Une boucle fermée, menée à une cadence, pour que la défense ne devienne jamais obsolète.
Chaque passage dans la boucle est petit et précis : une menace reconsidérée, un test autorisé, une faiblesse trouvée, une couche durcie, un correctif vérifié. La discipline réside dans le fait de la mener régulièrement plutôt que d'attendre qu'un incident l'impose.
Parce que la boucle se ferme — vérifier réinjecte dans modéliser — rien n'est laissé affirmé. Un contrôle n'est considéré comme terminé qu'une fois qu'un retest prouve que le chemin qu'il était censé fermer a réellement disparu.
- Continu, pas unique
- Chaque passage ferme une faiblesse vérifiée
- La vérification est réinjectée dans le modèle de menace
- Récurrent par conception à mesure que les systèmes changent
Le cycle d'auto-audit
- 01 Modéliser la menace Décider contre qui je me défends et ce qu'ils voudraient de ce système.
- 02 Tester mes propres systèmes Mener des tests autorisés contre ma propre infrastructure avec la méthodologie offensive.
- 03 Trouver avant eux Faire apparaître les faiblesses atteignables avant tout adversaire réel.
- 04 Durcir la couche Appliquer le correctif à la bonne couche de la pile de défense en profondeur.
- 05 Vérifier le correctif Retester pour prouver que la faiblesse est fermée, puis réinjecter dans le modèle.
Sécuriser ce qui circule entre les systèmes.
La sécurité des réseaux et des protocoles et la cryptographie appliquée sont les parties de la défense qui voyagent — protégeant données et confiance lorsqu'elles traversent entre systèmes plutôt qu'à l'intérieur d'un seul.
Côté réseau, le travail est la segmentation, la minimisation de la surface exposée, et le raisonnement sur les faiblesses au niveau protocole — ce qu'un observateur sur le chemin peut voir, rejouer ou injecter. Un protocole n'est aussi digne de confiance que les hypothèses qu'il fait sur le réseau sous-jacent, donc je modélise ce réseau comme hostile par défaut.
Côté cryptographie, la discipline est d'utiliser correctement des primitives éprouvées : chiffrement authentifié, manipulation soigneuse des clés et des nonces, et secrets gardés hors du code et des logs. Je n'invente pas de schémas ; les échecs en cryptographie appliquée viennent presque toujours de l'intégration et de la gestion des clés, pas de l'algorithme. Les deux domaines se résolvent à la même question du modèle de menace — que voit réellement un attaquant, et qu'expose une seule compromission.
Réseau hostile par défaut
Ne rien croire du chemin ; protéger la charge utile et les clés.
Je traite le réseau entre systèmes comme hostile — observable, rejouable, modifiable — et conçois pour que cette hypothèse ne casse rien. La segmentation limite ce qu'un point d'appui atteint ; le chiffrement authentifié protège la charge utile ; la gestion disciplinée des clés limite ce qu'une seule compromission expose.
La sécurité des protocoles est là où ces éléments se rencontrent : la cryptographie ne délivre ses garanties que si le protocole qui l'entoure ne les défait pas. C'est autant un exercice de modélisation de la menace qu'un exercice cryptographique.
- Segmentation réseau et surface exposée minimisée
- Raisonnement au niveau protocole sur observer, rejouer, injecter
- Chiffrement authentifié avec primitives éprouvées
- Gestion des clés, nonces et secrets comme travail de premier plan
La défense comme pratique récurrente, pas une configuration unique.
Modéliser, tester, trouver, durcir, vérifier — le même cycle, mené régulièrement contre ma propre infrastructure pour que la défense suive le rythme des systèmes qu'elle protège.
Lu en séquence, le travail est une pratique récurrente plutôt qu'un état achevé. Il commence par un modèle de menace, mène un auto-audit autorisé contre mes propres systèmes, fait apparaître les faiblesses atteignables, ferme chacune à la bonne couche de la pile de défense en profondeur, et reteste avant que quoi que ce soit ne soit déclaré terminé.
Ce qui traverse tout cela, c'est la limite par laquelle j'ai commencé : méthodologie offensive, autorisée et éthique, pointée uniquement vers une infrastructure que je possède, utilisée dans le seul but de la fortifier avant qu'un adversaire réel n'en ait l'occasion.
- Modéliser La modélisation de la menace d'abord Avant de choisir un contrôle, je décide qui est l'adversaire, ce qu'il veut et où il peut atteindre — pour que la défense corresponde à une menace réelle plutôt qu'à une liste générique.
- Tester Auto-audit autorisé À l'aide de la méthodologie de test d'intrusion et de BlackArch Linux, je mène des tests de sécurité autorisés contre ma propre infrastructure et mes systèmes d'agents à une cadence régulière.
- Trouver Vulnérabilités révélées Les faiblesses atteignables sont trouvées et documentées de la même façon qu'une mission externe les documenterait — chemin, impact, remédiation.
- Durcir Fermées à la bonne couche Chaque découverte est corrigée à la bonne couche de la pile de défense en profondeur : noyau, sysctl, systemd, conteneur, données ou identité.
- Vérifier Retestées, puis réinjectées Le correctif est retesté pour prouver que le chemin a disparu, et le résultat est réinjecté dans le modèle de menace pour le cycle suivant.
Les principes sous la défense.
Les systèmes changent et les contrôles spécifiques changent avec eux ; les principes, non. Voici les règles que j'applique que le travail soit une passe de durcissement, un test d'intrusion autorisé, un modèle de menace ou une intégration cryptographique — la partie qui garde la pratique défensive, autorisée et reproductible.
Autorisé, ou cela n'arrive pas
La technique offensive n'est jamais appliquée qu'à l'intérieur d'une limite autorisée, contre des systèmes que je possède. Il n'y a aucun travail adversarial ici — la méthodologie existe pour fortifier et auditer.
La défense est le but
Le test d'intrusion, l'analyse de vulnérabilités et la rétro-ingénierie sont des moyens pour une seule fin : fermer le chemin avant qu'un attaquant réel ne le trouve.
Des couches, pas un mur
Je suppose que tout contrôle unique peut échouer, donc les systèmes sont construits pour qu'une défaillance n'expose pas l'ensemble. La défense en profondeur est le défaut, pas une option supplémentaire.
Réversible et documenté
Chaque changement est sauvegardé avant d'être effectué et documenté après, pour qu'une étape de durcissement puisse être auditée et annulée aussi proprement qu'elle a été appliquée.
Vérifier, jamais supposer
Un contrôle n'est pas terminé tant qu'un test réel ne prouve pas qu'il tient. Le résultat d'un scanner, un drapeau de configuration et une défense fonctionnelle sont trois choses différentes.
Moindre privilège, partout
Les processus, conteneurs et identifiants obtiennent le minimum dont ils ont besoin. Restreint, à courte durée et révocable l'emporte sur pratique à chaque fois.
La méthodologie est celle d'un attaquant. La cible est toujours la mienne, l'autorisation toujours explicite, et la sortie toujours une vulnérabilité fermée. Cette limite est le travail.
Open to the right work
Si vous avez besoin d'un système qui suppose qu'il sera attaqué et qui est construit pour tenir malgré tout, c'est le travail que je fais.
If you are holding a problem that doesn't fit inside one field, that is the conversation I want.