Tests d'intrusion pilotés par la conformité
La plupart des tests d'intrusion sont achetés parce qu'une réglementation les impose. Le référentiel détermine le périmètre, la fréquence et - la partie que l'on sous-estime - les preuves que vous devrez être capable de produire ensuite. Cette page compare les régimes contre lesquels je teste, pour que vous identifiiez celui qui vous concerne réellement.
Les référentiels comparés
Chacun de ces régimes impose des tests de sécurité indépendants ou les exige dans les faits. Les différences qui comptent : qui est concerné, à quelle fréquence, et ce que vous devrez démontrer ensuite.
Arabie saoudite
- NCA Essential Cybersecurity Controls (en anglais) - le socle national pour les entités publiques, leurs prestataires et les infrastructures critiques. Le contrôle 2-11 porte sur les tests d'intrusion : définis, documentés, approuvés et mis en œuvre, avec un périmètre couvrant au minimum les services exposés sur Internet et l'infrastructure technique située derrière. De façon périodique.
- NCA Critical Systems Cybersecurity Controls - lorsque des systèmes sont classés critiques, la fréquence passe à au moins tous les six mois. C'est ce changement de rythme qui fait généralement voler en éclats l'hypothèse budgétaire.
- SAMA Cyber Security Framework (en anglais) - banques, assureurs, sociétés de financement et prestataires de paiement supervisés par la banque centrale saoudienne. Tests externes indépendants au moins annuels, couvrant les systèmes exposés sur Internet, les applications web et l'infrastructure réseau.
Émirats arabes unis
- NESA / UAE Information Assurance Standards (en anglais) - entités fédérales et infrastructures d'information désignées critiques. Les évaluations de vulnérabilités et les tests d'intrusion sont réalisés et suivis, annuellement en pratique, avec remédiation documentée et preuve de contre-test pour les constats critiques et élevés dans un délai défini. Les auditeurs examinent les qualifications du testeur.
- Dubai ISR (DESC) - entités publiques de Dubaï et leurs fournisseurs. S'applique en parallèle de NESA ; une seule mission peut documenter les deux.
- CBUAE, DFSA et ADGM (en anglais) - banques et sociétés de financement onshore, sociétés du DIFC, sociétés de l'ADGM. Des tests indépendants réguliers sont attendus dans les trois cas.
- VARA - prestataires de services sur actifs virtuels de Dubaï. Test d'intrusion indépendant au moins annuel au titre du Technology and Information Rulebook, avec tests pilotés par le renseignement lorsque VARA l'estime proportionné.
- ADHICS (en anglais) - établissements de santé d'Abou Dabi et leurs fournisseurs technologiques.
International
- PCI DSS - pour quiconque stocke, traite ou transmet des données de porteurs de cartes. L'exigence 11.4 impose des tests d'intrusion internes et externes au moins annuels et après tout changement significatif, ainsi que des tests de segmentation lorsque celle-ci sert à réduire le périmètre.
- SOC 2 - pas une obligation prescriptive, mais le test d'intrusion est la preuve que la plupart des auditeurs attendent au titre de CC4.1 et CC7.1, et les grands comptes l'exigent de plus en plus dans le rapport.
- ISO 27001 - gestion des vulnérabilités techniques au titre de l'annexe A, où le test est le moyen concret de démontrer que le contrôle fonctionne.
Ce que les auditeurs demandent réellement
Le rapport est nécessaire mais pas suffisant. Quatre éléments composent un dossier de preuves complet, et la plupart des organisations n'arrivent qu'avec le deuxième :
- Un document de périmètre - ce qui a été testé, ce qui ne l'a pas été, et pourquoi ce périmètre correspondait au contrôle. Un test qui exclut précisément les systèmes visés par le contrôle échoue, aussi bon soit-il.
- Le rapport - constats, gravités, détail de reproduction et rattachement aux contrôles concernés.
- La remédiation documentée - ce que vous avez corrigé, quand, et ce que vous avez accepté comme risque avec sa justification. Accepter un risque est permis ; ne pas consigner la décision ne l'est pas.
- La preuve du contre-test - la confirmation que les constats critiques et élevés sont réellement clos, dans le délai prévu par votre référentiel. L'attente de 90 jours chez NESA est celle qui piège : un test réalisé au onzième mois ne laisse aucune marge pour un contre-test avant la fin du cycle.
Une lettre d'attestation - qui, quel périmètre, quelles dates - relie le dossier et constitue généralement ce qui est archivé ou transmis à un client. Chaque mission ici en comprend une.
L'indépendance est l'exigence que l'on interprète mal
Plusieurs de ces référentiels emploient le mot indépendant, avec un sens précis : le test ne peut pas être réalisé par ceux qui ont construit ou qui exploitent le système testé. Une équipe sécurité interne testant l'infrastructure de sa propre organisation satisfait certains référentiels et pas d'autres ; l'équipe qui a écrit l'application et qui la teste n'en satisfait aucun.
C'est une grande part de la raison d'être des consultants externes sur ce marché, et il vaut la peine de vérifier ce point au regard de votre obligation précise avant de supposer que vos capacités internes suffisent. Se tromper ici coûte cher, parce que vous le découvrez à l'audit et non au cadrage.
Comment je cadre une mission de conformité
Le premier échange porte sur l'obligation, pas sur la technique : quel référentiel, quel contrôle, quelle échéance, et si quelque chose a changé de façon significative depuis le dernier test. À partir de là, je peux généralement vous dire en un appel si une seule mission couvre tout ce à quoi vous êtes soumis, et ce que le périmètre doit inclure pour produire des preuves qui survivent à un audit.
Ce que vous obtenez : un prix ferme avant tout démarrage, un test réalisé par la personne à qui vous avez parlé, une notification immédiate de tout élément critique plutôt qu'une surprise dans le document final, un rapport écrit à la fois pour la direction et pour les ingénieurs, un accompagnement pendant la remédiation, un contre-test et la lettre d'attestation. Il existe un rapport type si vous souhaitez voir le format d'abord (en anglais), et la page tarifs pour les ordres de grandeur.
Par région
Pour le Golfe, les pages régionales approfondissent les régimes applicables et leurs interactions : tests d'intrusion en Arabie saoudite et tests d'intrusion aux Émirats. Pour le reste, les pages de services traitent du test lui-même, et un message reste le chemin le plus rapide vers une réponse claire.
Questions sur les tests de conformité
Oui, le plus souvent, et c'est bien moins coûteux que l'inverse. Le périmètre technique se recoupe largement - surface externe, applications web et API, réseau interne, Active Directory, cloud - ce qui diffère, c'est la correspondance avec les contrôles et la forme du rapport, pas le test lui-même. La condition est de le cadrer ainsi dès le départ : un test cadré uniquement pour PCI ne produira pas les preuves qu'attend NESA, alors que le travail sous-jacent est quasiment identique. Indiquez-moi tous les régimes auxquels vous êtes soumis lors du cadrage, et le rapport rattachera les constats à chacun d'eux.
Non, et c'est la raison la plus fréquente de rejet des preuves. Un scan compare des signatures connues à des versions connues et produit une liste ; un test d'intrusion enchaîne les constats pour montrer ce que quelqu'un pourrait réellement en faire. Les référentiels le disent de plus en plus explicitement, et les auditeurs repèrent désormais très bien un rapport de scan habillé en test d'intrusion - le signe distinctif étant que chaque constat est une CVE et qu'aucun ne se relie aux autres. La différence en détail (en anglais).
Quatre éléments, et la plupart des organisations n'ont que le deuxième. Un document de périmètre montrant ce qui a été testé et pourquoi ce périmètre était approprié. Le rapport lui-même, avec les constats, les niveaux de gravité et le détail de reproduction. La remédiation documentée des constats critiques et élevés. Et la preuve d'un contre-test confirmant que les correctifs ont fonctionné, dans le délai fixé par votre référentiel - 90 jours est courant. Une lettre d'attestation précisant qui a testé, sur quel périmètre et à quelles dates relie l'ensemble, et c'est généralement la page qui finit au dossier.
Annuellement est la base habituelle - SAMA, NESA, VARA et PCI DSS convergent tous là. Deux choses raccourcissent ce délai : une classification en système critique au titre des CSCC saoudiens, qui impose un test au moins tous les six mois, et les changements significatifs. Presque tous les référentiels exigent un nouveau test après une modification substantielle de l'environnement, indépendamment de la date du dernier test annuel - une migration majeure ou une nouvelle application exposée sur Internet remet donc le compteur à zéro.
Généralement oui, et les causes sont prévisibles : périmètre trop étroit au regard de ce qu'exige le contrôle ; test réalisé par l'équipe qui a construit le système, donc non indépendant ; absence de preuve de contre-test ; ou scan présenté comme un test d'intrusion. Les quatre se corrigent, et le remède tient normalement en une mission correctement cadrée, pas en un programme. Envoyez-moi le constat de l'auditeur et le rapport précédent, et je vous dirai duquel des quatre il s'agit avant que vous ne dépensiez quoi que ce soit.
Vous ne savez pas quel référentiel s'applique ?
Un court échange suffit généralement - et indique si un seul test peut tous les couvrir.