Hacker légalement : le cadre juridique – podcast
L’intrusion informatique traîne une imagerie tenace : une cave, une capuche, un écran vert. C’est pourtant un métier exercé au grand jour, sous contrat, et facturé. J’étais invité d’un épisode consacré précisément à cette question : à quelles conditions entrer dans un système qui ne vous appartient pas est-il parfaitement légal ?
L’épisode est enregistré en slovaque. Le résumé ci-dessous en reprend les points principaux en français.
Qu’est-ce qu’un test d’intrusion ?
Un test d’intrusion consiste à examiner des applications, des infrastructures et des réseaux pour y trouver les failles avant qu’un attaquant réel ne les trouve. La différence avec l’attaque qu’il imite tient à une seule chose, et elle est décisive : le mandat. Une entreprise, une administration ou un éditeur nous demande par écrit de simuler une attaque, et c’est ce document qui change la nature juridique de l’acte.
Ce qui rend l’exercice légal
Tout tient à trois conditions. Aucune n’est facultative, et aucune ne se rattrape après coup.
1. L’autorisation écrite, avant toute chose
Sans mandat, il n’y a pas de test : il y a une infraction. En droit français, l’accès et le maintien frauduleux dans un système de traitement automatisé de données sont réprimés par les articles 323-1 et suivants du code pénal, et la bonne intention n’est pas un moyen de défense. C’est pourquoi tous nos tests sont réalisés sur mandat écrit, signé par la personne qui a qualité pour l’accorder — ce qui suppose, au passage, de vérifier que votre interlocuteur a bien cette qualité lorsque le système est hébergé ou exploité par un tiers.
2. Le périmètre, et rien que le périmètre
L’autorisation ne vaut que pour ce qu’elle couvre. Le périmètre nomme les systèmes concernés, les adresses, les environnements, les créneaux, et les actions exclues. Sortir du périmètre, même par curiosité et même sans dommage, fait sortir du mandat. C’est la raison pour laquelle une note de cadrage écrite vaut mieux qu’un accord oral : elle protège le client autant que le prestataire.
3. La divulgation responsable
Une faille trouvée se signale, elle ne s’exploite pas au-delà de ce qui est nécessaire pour en démontrer l’impact, et elle ne se conserve pas. Le client reçoit la preuve, la reproduction et la recommandation ; les données collectées en cours de mission sont restituées ou supprimées selon ce que prévoit le contrat.
Ce que l’entreprise y gagne
Corriger avant l’incident plutôt qu’après. Le coût d’une faille trouvée en test est celui de son correctif. Le coût de la même faille trouvée par un attaquant inclut l’interruption, la notification, et l’explication à donner à vos clients.
Une vue que l’outillage seul ne donne pas. Un scanner signale les versions vulnérables connues. Il ne comprend pas votre logique métier et ne voit pas qu’un utilisateur peut consulter les commandes d’un autre.
Une preuve opposable. Un rapport de test est le document que réclament un auditeur, un client grand compte ou un assureur. C’est souvent ce qui déclenche la commande, avant même la préoccupation technique.
Pourquoi cela compte
Les techniques d’attaque évoluent en continu, et un système jugé sûr il y a deux ans ne l’est plus nécessairement aujourd’hui — la configuration a changé, une dépendance a été mise à jour, une brique a été ajoutée. Tester régulièrement, dans un cadre défini, est la seule façon de savoir où l’on en est plutôt que de le supposer.
Si vous souhaitez la version appliquée à votre système d’information, voyez nos tests d’intrusion ou l’article sur le choix d’un prestataire.
