Tests d'intrusion : attaquer votre produit avant les autres

Une faille trouvée chez vous coûte un correctif. La même faille trouvée par un autre coûte un incident.

Un test d’intrusion, c’est mettre votre produit entre les mains de quelqu’un dont le seul objectif est de le faire céder : lire ce qu’il ne devrait pas lire, exécuter ce qu’il ne devrait pas exécuter, prendre la main là où personne ne l’attend. Nous le faisons pour vous, dans un cadre convenu, et nous vous laissons un rapport que vos développeurs peuvent transformer en correctifs.

Ce que nous testons

Produits embarqués et IoT

• Interfaces physiques : ports de debug (JTAG, SWD, UART) laissés ouverts, lecture de la flash, extraction du firmware.
• Chaîne de démarrage et de mise à jour : une image non signée démarre-t-elle ? Peut-on revenir à une ancienne version vulnérable ? La mise à jour radio se laisse-t-elle détourner ?
• Secrets embarqués : clés, mots de passe et certificats lisibles dans le firmware ou la mémoire.
• Liaisons radio : Bluetooth Low Energy, LoRaWAN.

Applications web et API

• Authentification et gestion des sessions.
• Contrôle d’accès : un utilisateur peut-il lire ou modifier les données d’un autre ?
• Injections, validation des entrées, exposition de données sensibles dans les API REST.

Protocoles industriels

• Modbus/TCP, OPC UA et passerelles OT : qui peut lire et écrire les registres d’un automate, et avec quelle preuve d’identité ?
• Accès de maintenance et liaisons entre le réseau de production et le réseau bureautique.

Réseau et infrastructure

• Services exposés et versions vulnérables.
• Segmentation entre IT et OT.
• Accès distants : VPN, outils de télémaintenance.

Pourquoi des ingénieurs firmware pour attaquer un produit

Nous concevons des bootloaders, des chaînes de mise à jour signées et des produits industriels. Nous savons donc où se cachent les raccourcis pris sous la pression d’un planning : le port de debug « qu’on fermera en production », la clé de signature d’exemple jamais remplacée, le service Modbus ouvert à tout le réseau. Notre méthode est publique : le wiki CRA & Dev documente, avec code et banc d’essai, les attaques et les défenses que nous testons (mise à jour LoRaWAN signée, intégrité des données, secrets au repos), et nos publications rassemblent le reste.

Et parce que nous savons aussi construire, nous ne nous arrêtons pas au constat : nous pouvons corriger avec vos équipes.

Comment se déroule un test

1. Cadrage, gratuit : ce que vous voulez protéger, ce qui est dans le périmètre, ce qui ne l’est pas. Il aboutit à un devis.
2. Autorisation écrite : périmètre, fenêtres d’intervention, contacts en cas d’urgence. Nous ne testons rien sans elle.
3. Tests : sur votre matériel, votre application ou votre réseau, selon le périmètre convenu.
4. Rapport : chaque vulnérabilité avec sa gravité, la preuve, les étapes pour la reproduire et la correction recommandée. Une synthèse pour la direction, le détail pour les développeurs.
5. Restitution : nous présentons les résultats à vos équipes et répondons à leurs questions.
6. Correction, si vous le souhaitez : nous corrigeons avec vous, puis nous vérifions que la faille est bien fermée.

Un test d’intrusion, c’est aussi une preuve CRA

Le Cyber Resilience Act demande au fabricant de soumettre son produit à des tests et revues de sécurité efficaces et réguliers (Annexe I, partie II, point 3), et de protéger son produit contre l’accès non autorisé (Annexe I, partie I). Le rapport de test, et la trace de ce qui a été corrigé, entrent directement dans votre documentation technique. Les vulnérabilités trouvées suivent le même circuit que les autres : correction, publication, mise à jour.

Si vous préparez la conformité de votre produit, le test d’intrusion s’articule avec notre accompagnement CRA ; il peut aussi se commander seul.

Prix

Sur devis, après le cadrage gratuit : l’effort dépend du périmètre (un firmware, une application, un réseau d’usine) et de la profondeur souhaitée.

➡️ Réserver un appel de cadrage, ou écrivez-nous à info@adnt.io.