Ce que nous testons

Huit pratiques, de l’application que vos clients voient au réseau derrière, au cloud dessous, aux équipes autour et aux modèles au-dessus. Chacune se termine par un rapport que vous pouvez remettre à ceux qui corrigent. Les listes ci-dessous sont un point de départ, pas une limite : le périmètre de chaque mission se définit avec vous.

Test d’applications web

Toujours là où se trouvent la plupart des portes d’entrée.

Un test manuel de l’application en tant qu’utilisateur connecté, puis en tant qu’utilisateur qui ne devrait pas pouvoir faire ce qu’il fait. Les scanners trouvent les problèmes connus ; les failles de logique qui comptent se trouvent en lisant l’application comme ses concepteurs ne l’ont pas fait.

Ce que nous examinons

Authentification, session et gestion des comptes
Contrôle d’accès entre rôles, comptes et objets
Logique métier, workflows et états
Injection, désérialisation, gestion des fichiers
Composants front-end et tiers

Ce que vous recevez

Une preuve d’exploitation partout où il est sûr d’en produire une
Un résumé exécutif et le détail technique complet
Des correctifs avec le chemin de code précis quand c’est possible
Un retest une fois corrigé

Référentiels utilisés OWASP Web Security Testing Guide, OWASP ASVS, OWASP Top 10

Test d’API

Là où vos services se parlent, et parlent aux inconnus.

Les API portent désormais la logique métier, et elles sont testées moins souvent que les écrans placés devant elles. Nous les testons comme un client auquel on ne peut pas faire confiance : mauvais rôles, jetons rejoués, objets qui appartiennent à quelqu’un d’autre, limites jamais appliquées.

Ce que nous examinons

Authentification et gestion de session
Autorisation sur chaque objet et chaque verbe
Limites de débit, mass assignment, injection
Introspection GraphQL, batching, requêtes imbriquées
API internes et partenaires derrière l’API publique

Ce que vous recevez

Des constats avec une requête fonctionnelle pour chacun
Une sévérité fondée sur l’impact réel, pas sur un score de scanner
Des correctifs rédigés pour l’équipe qui possède l’API
Un retest une fois corrigé

Référentiels utilisés OWASP API Security Top 10, OWASP ASVS

Test d’applications mobiles

Les deux plateformes, en statique et à l’exécution.

Une application mobile est un client qui tourne sur du matériel que vous ne contrôlez pas. Nous la démontons, l’observons pendant qu’elle tourne, et testons le backend avec lequel elle parle avec une confiance qu’un client ne devrait jamais avoir.

Ce que nous examinons

Stockage local, keychain et keystore
Certificate pinning et sécurité du transport
Deep links, intents et communication inter-applications
Rétro-ingénierie et résistance à la modification
L’API backend, testée comme un client auquel on ne peut pas faire confiance

Ce que vous recevez

Des constats pour l’application et pour le backend, séparément
Une correspondance OWASP MASVS quand elle sert votre conformité
Des correctifs pour les deux plateformes
Un retest une fois corrigé

Référentiels utilisés OWASP MASVS et MASTG

Test d’intrusion réseau

Tout ce qu’il y a entre les murs, et les murs.

Deux questions, une mission. De l’extérieur : que voit un attaquant sur Internet, et jusqu’où cela le mène-t-il ? De l’intérieur : avec un portable sur le réseau ou un compte utilisateur standard, combien de temps avant qu’il contrôle tout le domaine ? Les deux réponses s’obtiennent à la main.

Ce que nous examinons

Périmètre externe : services exposés, VPN, messagerie, accès distant
Interne : Active Directory, Kerberos, relais, protocoles hérités
Segmentation entre réseaux bureautique, serveurs et production
Hygiène des identifiants : réutilisation, valeurs par défaut, comptes de service
Élévation jusqu’à l’administration du domaine et aux systèmes les plus sensibles

Ce que vous recevez

Le chemin d’attaque du premier accès aux systèmes qui comptent le plus, tracé
Des constats avec l’hôte, le service et la requête exacts
Des correctifs classés selon la part du chemin qu’ils coupent
Un retest une fois corrigé

Référentiels utilisés PTES, MITRE ATT&CK pour le chemin interne, CIS Benchmarks pour les correctifs

Test d’intrusion cloud

L’ordinateur de quelqu’un d’autre, avec vos clés dedans.

La plupart des compromissions cloud sont des compromissions d’identité. Nous partons de là où part un attaquant, une clé fuitée, un utilisateur hameçonné, un espace de stockage laissé public, et nous suivons les permissions pour voir jusqu’où elles mènent.

Ce que nous examinons

Entra ID, rôles IAM et les chemins entre eux
Politiques trop permissives et élévation de privilèges
Stockage, fonctions, files et bases de données exposés
Pipelines de build, secrets et identités de déploiement
Exposition réseau entre environnements

Ce que vous recevez

Des chemins d’attaque tracés de bout en bout, avec les permissions qui les ont rendus possibles
Des correctifs classés selon la part du chemin qu’ils coupent
Des recommandations de configuration pour votre équipe plateforme
Un retest une fois corrigé

Référentiels utilisés CIS Benchmarks Azure, AWS et Google Cloud, matrice MITRE ATT&CK Cloud

Red Team

L’équipe qui attaque.

Une Red Team répond à une autre question qu’un test d’intrusion : non pas ce qui ne va pas, mais si quelqu’un s’en apercevrait. Nous prenons un objectif, des règles et une fenêtre, et nous progressons vers cet objectif comme le ferait un véritable attaquant, discrètement, avec les tactiques, techniques et procédures (TTP) observées dans les intrusions actuelles.

Ce que nous examinons

Des objectifs convenus avec un petit groupe de confiance
Entrer par hameçonnage, par des services exposés, ou partir de l’intérieur comme si un attaquant avait déjà accès
Des outils et une infrastructure d’attaque construits pour la mission
Se déplacer entre les systèmes, obtenir des privilèges plus élevés, rester
Détection et réponse, observées du côté de l’attaquant

Ce que vous recevez

La chronologie de l’opération, étape par étape
Chaque TTP utilisée, cartographiée sur MITRE ATT&CK
Ce qui a été détecté, ce qui ne l’a pas été, et pourquoi
Un débrief avec vos défenseurs, puis un plan

Référentiels utilisés MITRE ATT&CK

Purple Team

Rouge plus bleu.

Une Purple Team est une Red Team qui travaille à découvert, avec vos défenseurs. Nous exécutons de vraies TTP d’attaquants contre votre environnement pendant que vos défenseurs surveillent leurs alertes et leurs journaux, et nous nous arrêtons après chacune pour répondre à la seule question qui compte : l’avez-vous vue, et auriez-vous agi ?

Ce que nous examinons

Des tactiques, techniques et procédures (TTP) choisies dans MITRE ATT&CK selon les attaquants que vous êtes le plus susceptible de rencontrer
Entrer, exécuter du code, rester, voler des identifiants, se déplacer entre les systèmes
Couverture de détection et qualité des alertes pour chaque TTP
Des procédures de réponse testées en conditions réelles

Ce que vous recevez

Une carte de couverture : détecté, journalisé, manqué
Des améliorations de détection convenues avec votre équipe pendant l’exercice
Une liste priorisée de ce qu’il faut construire ensuite
Un débrief pour la direction et pour l’équipe sécurité

Référentiels utilisés MITRE ATT&CK, avec les détections cartographiées par TTP

Test d’IA et de LLM

Un modèle de langage à qui l’on a confié des outils, une mémoire et bien trop de confiance.

Les systèmes construits sur des modèles de langage ne cassent pas comme les applications web. Le modèle est un composant qui suit les instructions de quiconque parvient à lui faire lire du texte, et il est généralement branché à des outils, des documents et d’autres systèmes. Nous testons toute la chaîne comme un attaquant l’utiliserait, avec l’OWASP Top 10 for LLM Applications et MITRE ATLAS comme carte et votre architecture comme territoire.

Ce que nous examinons

Chatbots destinés aux clients et assistants internes : ce qu’ils révèlent, et ce qu’on peut leur faire faire
Injection de prompt directe et indirecte, y compris via les documents, e-mails et contenus web que le modèle lit
Outils, fonctions et serveurs MCP : ce que le modèle a le droit d’appeler, avec quelle identité, et ce que le serveur vérifie avant d’agir
Recherche documentaire et mémoire : la séparation entre comptes et organisations dans les données que le modèle atteint, et ce qui fuit à travers
Autonomie excessive : ce qu’un agent peut faire sans surveillance, et ce qui l’arrête
Contournement des garde-fous et des filtres de contenu
La surface web et API classique autour du modèle

Ce que vous recevez

Des chaînes d’attaque reproductibles, pas des prompts isolés
Un impact évalué sur ce que le système peut réellement faire
Des mesures au niveau de l’architecture, pas seulement du prompt
Un format Purple Team avec votre équipe IA, en option

Référentiels utilisés OWASP Top 10 for LLM Applications, menaces OWASP Agentic AI, MITRE ATLAS, NIST AI RMF

Cadrer l’une de ces missions

Vous ne savez pas laquelle il vous faut ? C’est à cela que sert le premier appel.

Réserver un appel de cadrage