Aller au contenu
HackingByte
EN Demander un échange de cadrage

Un test d’intrusion devrait clore un débat, pas produire l’export d’un scanner.

Des tests manuels menés par des seniors qui montrent comment un attaquant atteint réellement ce qui compte — et ce que cela vous coûterait — et non une liste de CVE dédoublonnée.

Demander un échange de cadrage Voir notre méthode
  • Praticiens seniors uniquement.
  • Aucun outil vendu.
  • Reporting fondé sur des preuves.

La plupart des organisations n’achètent pas un test d’intrusion par curiosité. Elles l’achètent parce que l’équipe sécurité d’un client bloque un contrat, qu’un auditeur a signalé l’exigence de tests annuels, qu’un assureur pose des questions précises, ou qu’un conseil d’administration attend une réponse indépendante que l’équipe interne est trop impliquée pour donner. Les tests d’intrusion de HackingByte existent précisément pour ces moments : des tests manuels menés par des seniors qui montrent comment un attaquant compétent atteindrait réellement ce qui compte dans votre environnement — et ce que cela vous coûterait s’il y parvenait.

Nous ne livrons pas l’export dédoublonné d’un scanner avec un logo en couverture. Chaque mission produit des preuves reproductibles, une sévérité notée au regard de l’impact métier plutôt que du seul score CVSS, et un plan de remédiation sur lequel votre équipe peut agir. Un test d’intrusion utile ne se limite pas à une liste de vulnérabilités : il sert à clore un débat par la preuve, pas à en ouvrir un nouveau sur la réalité d’un constat.

Ce que nous testons.

  • Test d’intrusion externe.

    Nous attaquons votre surface exposée sur Internet comme le ferait un adversaire externe — applications web, API exposées, infrastructure, périphéries cloud, périmètres de messagerie et DNS, et les intégrations tierces qui y sont rattachées. Le travail commence par de l’OSINT et de la découverte d’actifs, car les actifs que vous avez oubliés sont généralement ceux qui comptent, puis passe à l’exploitation et à la construction de chemins d’attaque chaînés dans le cadre des règles d’engagement convenues. Vous obtenez une réponse défendable à la question que pose réellement chaque revue de sécurité client et chaque renouvellement d’assurance : qu’obtiendrait aujourd’hui un attaquant externe compétent contre nous ? Base méthodologique : PTES et MITRE ATT&CK Enterprise, appuyés par le NIST SP 800-115.

  • Test d’intrusion interne.

    Une mission en hypothèse de compromission : nous partons d’un point d’appui à l’intérieur du réseau — fourni par VPN, par un rebond sur site ou par un équipement expédié — et mesurons jusqu’où un attaquant progresse avant d’être arrêté. L’objectif est généralement l’administration du domaine, un magasin de données privilégié ou une charge de travail critique pour l’activité. Nous énumérons et exploitons l’Active Directory, extrayons et réutilisons des identifiants, élevons les privilèges, testons la segmentation et cartographions le chemin réel vers vos actifs les plus sensibles. Le livrable est une vision chiffrée du rayon d’impact interne et de l’exposition aux rançongiciels — le type de chiffre qu’un conseil et un directeur financier peuvent réellement utiliser.

  • Test d’intrusion web et API.

    Des tests applicatifs sur une application définie et ses API, avec une couverture authentifiée pour chaque rôle utilisateur. Nous allons au-delà du Top 10 de l’OWASP, jusqu’aux abus de logique métier propres à votre domaine — failles d’autorisation et IDOR, contrôle d’accès multi-rôles défaillant, gestion des sessions et des jetons, ainsi que les problèmes de l’OWASP API Security Top 10. Les constats arrivent avec des étapes de reproduction que vos équipes peuvent rejouer localement et une matrice de couverture OWASP WSTG / ASVS : le résultat est une preuve que votre auditeur, votre client grand compte et vos propres développeurs acceptent tous.

  • Test d’intrusion mobile.

    Nous testons les applications iOS et Android comme le ferait un attaquant maîtrisant déjà l’appareil — stockage côté client, transport, mauvais usage de la plateforme et back-end auquel l’application s’adresse — en nous alignant sur l’OWASP MASVS. Proposé à la demande plutôt que par défaut, car tous les programmes n’en ont pas besoin ; mais lorsque votre application se trouve dans la poche de chaque client, cela compte.

  • Test d’intrusion cloud.

    Des tests centrés sur l’exploitation des environnements AWS, Azure et GCP — identités et chemins de privilèges, services exposés et erreurs de configuration qui se chaînent en impact réel — en s’appuyant sur la matrice MITRE ATT&CK Cloud et les CIS Benchmarks comme base. Lorsque votre question est moins « est-ce exploitable ? » que « la configuration est-elle sûre par défaut ? », notre évaluation de sécurité cloud constitue le complément le mieux adapté.

Le périmètre est toujours établi sur votre surface d’attaque réelle et les actifs dont l’activité dépend — pas sur une liste générique. Les tests externes et internes sont les points de départ les plus fréquents ; le mobile et le cloud s’y ajoutent là où le risque se concentre.

Ce qui change.

  • Des tests manuels menés par des seniors — réalisés par des praticiens expérimentés, et non confiés à un junior muni d’une licence de scanner. Les constats qui comptent — chemins d’attaque chaînés, abus de logique métier, l’erreur de configuration qui ne devient critique qu’associée à deux autres — viennent de quelqu’un qui l’a déjà fait. Chaque livrable porte une validation senior avant de quitter le cabinet.

  • Des constats reproduits avec preuves — chaque constat inclut des étapes de reproduction et des preuves capturées (sortie de commande, capture d’écran, trace) suffisantes pour que votre équipe le recrée de façon autonome. Vous ne devriez jamais avoir à nous croire sur parole, et vos équipes ne devraient jamais perdre une journée à tenter de reproduire un constat décrit vaguement.

  • Une sévérité notée avec une lecture d’impact métier, pas seulement le CVSS — nous notons la sévérité technique avec le CVSS v3.1, puis appliquons une couche d’impact métier par-dessus, car un « moyen » sur un système qui manipule de l’argent n’est pas un « moyen » sur un site vitrine statique. Ici, l’inflation de sévérité est un défaut de qualité, pas une tactique commerciale — nous ne cherchons pas à vous effrayer pour vendre une mission plus large.

Notre méthodologie de test d’intrusion.

Des standards cités, un cycle en six étapes, une validation senior à chaque étape.

HackingByte n’invente pas de méthodologie — nous utilisons, citons et étendons des standards reconnus, et nous vous indiquons lesquels avant le début de la mission. Chaque test suit le même cycle en six étapes, pour que vous sachiez toujours ce qui vient ensuite.

Cadrage. Nous définissons les objectifs, les actifs, le modèle de menace, les règles d’engagement, les livrables et une fourchette tarifaire, jusqu’à un cahier des charges signé. Généralement 3 à 10 jours ouvrés.

Lancement. Nous confirmons les règles d’engagement, les contacts, les chemins d’escalade, le calendrier, les canaux de communication sécurisés et les accès lors d’un seul appel de 60 minutes.

Exécution. Le test lui-même, calibré sur la classe d’actifs. Les constats critiques vous sont escaladés dans les quatre heures ouvrées suivant leur découverte — jamais retenus jusqu’au rapport.

Reporting. Nous produisons le modèle à trois livrables et le soumettons à une revue par les pairs interne avant que vous ne le voyiez. Généralement 5 à 10 jours ouvrés.

Restitution. Deux sessions — une revue technique avec vos équipes et une restitution exécutive avec la direction — ainsi qu’un temps de questions sur le plan d’action.

Clôture et nouveau test optionnel. Le plan d’action est remis à ses responsables, et vous pouvez choisir un nouveau test ciblé des constats critiques et élevés, avec une attestation mise à jour.

La base de standards dépend de l’actif : PTES et MITRE ATT&CK pour le travail externe et interne ; l’OWASP Web Security Testing Guide et l’API Security Top 10 pour le web et les API ; l’OWASP MASVS pour le mobile ; la matrice MITRE ATT&CK Cloud et les CIS Benchmarks pour le cloud. Vous pouvez lire le cycle complet et le détail des standards sur notre page méthodologie.

Voir notre méthode

Comment nous rendons compte.

Le dossier de mission — trois altitudes, un même récit cohérent.

Le reporting est l’endroit où la plupart des missions échouent — un PDF de 200 pages que personne ne lit, des niveaux de sévérité auxquels personne ne se fie, et aucune réponse claire à « alors, que faisons-nous lundi matin ? ». Chaque mission HackingByte se conclut plutôt par trois livrables connectés.

  • Rapport technique — des constats reproductibles, avec preuves et remédiation par constat, rédigés pour vos équipes techniques.
  • Synthèse exécutive des risques — les mêmes constats traduits en risque métier pour la direction et le conseil, sans jargon.
  • Plan d’action — priorisé, avec un responsable désigné, et calibré sur ce que votre équipe peut réellement réaliser, et non sur un arriéré idéalisé.

À quoi ressemble une mission type.

Les acheteurs veulent généralement une idée du délai avant de s’engager. Un test d’intrusion externe ou interne représentatif s’étale sur environ quatre à six semaines de bout en bout : une semaine de cadrage jusqu’à un cahier des charges signé, une à trois semaines de test selon la taille de la surface, une semaine de reporting et de revue par les pairs, puis une restitution une fois le rapport entre vos mains. Un nouveau test optionnel des constats critiques et élevés ajoute une à trois semaines dès que votre équipe est prête.

Les missions web et API suivent la même forme ; les applications très volumineuses allongent la fenêtre de test. Les missions guidées par la menace et de red team ajoutent en amont une étape de renseignement sur la menace et de conception de scénarios. Rien de tout cela n’est figé — le calendrier est fixé lors du cadrage autour de votre échéance, qu’il s’agisse d’un jalon d’achat client, d’une date d’audit ou d’un renouvellement d’assurance.

Comment les tests d’intrusion sont tarifés.

Nous tarifons les missions au forfait, par fourchette selon le périmètre — et non à la journée. Pour un test externe ou interne, la fourchette dépend du nombre d’actifs concernés et de la complexité de l’environnement ; pour le web et les API, du nombre de rôles, de points de terminaison et de la complexité de la logique métier de l’application. Nous vous communiquons la fourchette lors du cadrage, avant toute signature, pour éviter les surprises liées aux taux journaliers et toute incitation à gonfler les heures.

Quelques principes que nous écartons délibérément : nous ne vendons pas de taux journaliers, nous ne revendons ni ne sur-vendons d’outillage, et nous ne réalisons pas de pilotes gratuits — l’échange de cadrage est gratuit, et tout ce qui suit est une mission définie et facturée. Si vous travaillez avec un budget donné, indiquez-le lors du cadrage et nous serons clairs sur ce qu’il couvre et ce qu’il ne couvre pas. L’objectif est un test dimensionné pour répondre à votre vraie question, pas la mission la plus large que nous pourrions justifier.

Quand les équipes nous appellent.

Les moments les plus fréquents où les organisations nous sollicitent pour un test d’intrusion :

  • Un nouveau client grand compte qui exige un test d’intrusion récent avant de signer.

  • Un constat d’auditeur sur les tests annuels pour ISO 27001, SOC 2 ou PCI-DSS.

  • Le lancement d’un produit sur une infrastructure publique.

  • Un questionnaire de renouvellement de cyber-assurance.

  • Un besoin post-incident de vérifier qu’une faille est réellement refermée.

  • Un conseil qui demande une assurance indépendante que l’équipe interne ne peut pas fournir sur son propre travail.

Questions fréquentes

En quoi est-ce différent d’un scan de vulnérabilités ?
Un scan dresse une liste de constats ; nous les vérifions manuellement et les chaînons pour démontrer un impact réel et exploitable — avec des preuves que vous pouvez reproduire.
Cela va-t-il perturber la production ?
Non. Le périmètre et les règles d’engagement sont convenus avant de commencer, avec une escalade claire si quelque chose de sensible apparaît.
Obtenons-nous un livrable que notre auditeur et notre conseil accepteront tous les deux ?
Oui — le dossier de mission couvre les publics technique, exécutif et de remédiation dans un seul livrable cohérent.
Combien coûte un test d’intrusion ?
Nous tarifons au forfait, par fourchette selon le périmètre, et vous communiquons la fourchette lors du cadrage, avant tout engagement. Nous ne proposons pas de taux journaliers. Le coût dépend de la taille de la surface d’attaque et de la complexité de l’environnement ou de l’application.
Combien de temps dure un test d’intrusion ?
Un test externe ou interne type dure environ quatre à six semaines de bout en bout : une semaine de cadrage, une à trois semaines de test, une semaine de reporting, puis une restitution. Nous fixons le calendrier exact autour de votre échéance.
Quels standards suivez-vous ?
PTES et MITRE ATT&CK pour les tests externes et internes ; l’OWASP WSTG et l’OWASP API Security Top 10 pour le web et les API ; l’OWASP MASVS pour le mobile ; MITRE ATT&CK Cloud et les CIS Benchmarks pour le cloud. Nous indiquons la base de standards dans chaque cahier des charges et chaque rapport.
Pouvez-vous effectuer un nouveau test après correction des constats ?
Oui. Un nouveau test ciblé des constats critiques et élevés est une option, accompagnée d’une attestation mise à jour que vous pouvez partager avec vos clients et vos auditeurs.
Conservez-vous nos données et nos constats de manière confidentielle ?
Oui. Chaque mission s’exécute sous accord de confidentialité, les preuves sont chiffrées au repos et conservées uniquement pour la durée contractuelle (12 mois par défaut), et nous n’utilisons jamais le nom d’un client à des fins marketing sans consentement écrit.

Services associés

La plupart des missions se combinent avec l'un des parcours ci-dessous — chacun mené par des seniors, à périmètre fixe et fondé sur les preuves, selon le même modèle de reporting.

Indiquez-nous le système qui vous inquiète et l’échéance que vous visez — nous cadrerons le test autour des deux.

Demander un échange de cadrage