PME - CyberBBQ part 4 - La place du red teaming durant un incident - Parce que... c'est l'épisode 0x337! — PolySécure Podcast

PME - CyberBBQ part 4 - La place du red teaming durant un incident - Parce que... c'est l'épisode 0x337!

PolySécure Podcast · 26/08/2026 04:00 · 16 min
Informatique

Contenu de l'épisode

Parce que… c’est l’épisode 0x337! Shameless plug Description

Cette description a été faite à l’aide de GLM 5.3 Flash, à partir de la transcription qui a été effectuée par ElevenLabs Scribev2. Aucune vérification humaine n’a été faite. Si vous découvrez des erreurs ou des inexactitudes, vous pouvez m’en faire part afin que je procède aux modifications appropriées.

Mise en contexte de l’épisode

Cet épisode poursuit la fiction des épisodes précédents de « Cyber avec vous ». La PME victime d’un incident de cybersécurité a éteint le feu et veut bâtir une structure plus robuste pour l’avenir. Plusieurs pistes ont déjà été explorées et la gouvernance est réservée pour la fin. L’entreprise, qui a eu très peur, dispose même d’un budget étonnamment confortable et veut valider que ses systèmes fonctionnent vraiment. L’épisode réunit Thomas Veynachter, Dominique Derrier, Cédric, Steve Lavoie, Mickael Nadeau et Martin Dubé, ce dernier agissant à titre d’expert en tests d’intrusion et autoproclamé spécialiste du poulet shawarma. Il explique comment le red team peut éprouver la solidité de l’ensemble.

Faut-il faire un pen test pendant un incident

La première question posée à Martin est délicate. Faut-il réaliser un test d’intrusion en plein incident ? Sa réponse est non, sauf si l’organisation ignore encore son point d’entrée mais détient des indices clairs d’un compromis. En général, un pen test se situe plutôt avant ou après un incident. Après l’incident, l’application web compromise mérite un examen attentif, car les causes restent tristement banales, notamment des logiciels non mis à jour, de mauvaises configurations ou un fichier de sauvegarde oublié à la racine du site, un classique encore très courant, tout comme le backup de la base de données laissé accessible.

Les fondamentaux qui fonctionnent encore

Martin insiste sur le pare-feu, un contrôle toujours efficace en 2026. Pour un site web, il suffit souvent d’ouvrir les ports 80 et 443 et de fermer le port 22, sans parler de la base de données. Un participant ajoute les règles de pare-feu en sortie, souvent oubliées. Les gens pensent au trafic entrant mais négligent le trafic sortant. Si un serveur n’a pas besoin d’aller surfer sur Netflix, il n’a aucune raison d’avoir une règle de sortie permissive. Martin note aussi que des reverse shells ne fonctionnent pas en présence de règles d’egress.

Le casse-tête de la visibilité en PME

L’animateur partage son expérience d’implantation du filtrage en sortie dans des PME. Quand on creuse les besoins réels, on découvre des employés qui utilisent WeTransfer, d’autres applications et même quelqu’un qui fait du BitTorrent. Le processus révèle vite l’absence d’inventaire, les gens faisant n’importe quoi comme administrateurs de leur poste. Imposer de la structure dans un petit milieu génère beaucoup de friction. Un participant renchérit en soulignant que plusieurs clients se ramassent chez le premier hébergeur bon marché en pensant que la sécurité viendra automatiquement avec le service.

Segmentation réseau et simulation assume breach

Martin aborde ensuite la segmentation réseau. L’attaquant a-t-il réussi à pivoter de l’application web vers le réseau interne ? Dans une PME sans DMZ ni règles de pare-feu, le scénario est plausible. Un test sur l’application web reste pertinent pour comprendre sa surface d’attaque. Un test interne peut aussi être utile en simulant un scénario d’assume breach, en partant du principe qu’un serveur est compromis, puis on vérifie si un atta

Plus d'informations