Un test d'intrusion est-il obligatoire pour SOC 2 ?

Non. SOC 2 n’exige pas explicitement de test d’intrusion. Les Trust Services Criteria sur lesquels repose un examen SOC 2 n’emploient jamais les mots « test d’intrusion ». Ce qu’ils exigent, c’est que vous trouviez et gériez vos vulnérabilités, et en pratique la plupart des auditeurs attendent un test d’intrusion comme preuve que vous le faites vraiment. La réponse honnête est donc la suivante : non obligatoire à la lettre, mais bel et bien attendu par ceux qui signent votre rapport.

La réponse courte

SOC 2 est une attestation, pas une liste d’outils à cocher. Un cabinet de CPA agréé émet une opinion sur le fait que vos contrôles répondent aux critères que vous avez choisi de faire examiner. Nulle part dans ce processus ne figure une ligne disant « réalisez un test d’intrusion ». Il n’y a pas non plus de ligne disant « utilisez un pare-feu » ou « chiffrez vos sauvegardes ». Les critères décrivent des résultats, et vous montrez à l’auditeur comment vous les atteignez.

C’est cette conception qui fait revenir la question sans cesse. Comme rien n’est nommé, les équipes se demandent à juste titre si un test d’intrusion est obligatoire, facultatif ou un gaspillage de budget. La réalité du terrain se situe entre les deux premières options : c’est le moyen le plus propre de satisfaire un contrôle que tout rapport SOC 2 incluant la Sécurité doit traiter, et les auditeurs en ont fait la preuve par défaut.

Ce que SOC 2 demande réellement

Un rapport SOC 2 porte sur les contrôles d’un prestataire de services qui sont, selon les termes de l’AICPA, “relevant to security, availability, processing integrity, confidentiality, or privacy”. Ce sont les cinq trust services categories, et seule la première est obligatoire. La Sécurité, aussi appelée common criteria, figure dans chaque examen SOC 2. Les quatre autres ne sont ajoutées que si elles comptent pour votre service et vos clients.

À l’intérieur du socle commun se trouve le contrôle qui anime toute la question du test d’intrusion. CC7.1 demande à l’organisation d’utiliser des procédures de détection et de surveillance pour identifier à la fois les nouvelles vulnérabilités introduites par des changements de configuration et la sensibilité aux vulnérabilités nouvellement découvertes. Ses points de focus mentionnent des scans de vulnérabilités menés périodiquement et après tout changement significatif. Le texte décrit le résultat attendu, trouver vos faiblesses avant qu’un autre ne le fasse, et laisse la méthode à vous et à votre auditeur.

Où s’inscrit le test d’intrusion

C’est là que la différence entre un scan et un test commence à compter, et c’est une vraie différence, pas une différence marketing. Le NIST trace la ligne nettement. Un scan de vulnérabilités est un processus automatisé qui signale des faiblesses potentielles. Un test d’intrusion est un exercice manuel où, selon la définition du NIST, “assessors mimic real-world attacks to identify methods for circumventing the security features of an application, system, or network”. Le NIST SP 800-115 découpe ce travail en quatre phases : planification, découverte, attaque et reporting. La phase d’attaque est précisément ce qu’un scanner ne sait pas faire : elle vérifie une vulnérabilité suspectée en tentant de l’exploiter.

Pour SOC 2, les deux sont complémentaires plutôt qu’interchangeables. Un scan apporte l’étendue et la fréquence : il tourne souvent et couvre tout à faible coût, ce qui correspond exactement à la formule « périodiquement » de CC7.1. Un test d’intrusion apporte la profondeur et la preuve : il confirme lesquelles de ces faiblesses un attaquant pourrait réellement enchaîner jusqu’à un accès. Les auditeurs aiment voir les deux parce qu’ensemble ils répondent à la vraie question des critères, qui n’est pas « possédez-vous un scanner » mais « cherchez-vous activement, et corrigez-vous, les façons dont votre système peut être brisé ». Pour le détail complet de ce qui sépare les deux méthodes, nous avons écrit un guide scan de vulnérabilités contre test d’intrusion sur ce sujet précis.

Un test d’intrusion n’est donc pas strictement exigé par la norme. C’est en revanche la preuve unique la plus défendable que vous puissiez remettre à un auditeur pour les contrôles d’identification des vulnérabilités, et s’en passer tend à susciter des questions que vous préféreriez éviter pendant les travaux d’audit.

À quelle fréquence, et que tester

Une fois admis qu’un test est de fait attendu, deux questions pratiques suivent : à quelle fréquence, et sur quel périmètre.

Côté fréquence, un test d’intrusion annuel est la base courante, avec un test supplémentaire après tout changement significatif du système concerné. La raison tient en partie à la formule « après changement significatif » des critères, et en partie au calendrier. Un rapport SOC 2 de Type II examine si les contrôles ont fonctionné efficacement sur une période plutôt qu’à une seule date : le test, et toute remédiation qui en découle, doivent donc tomber dans cette fenêtre d’observation pour compter comme preuve de la période.

Côté périmètre, le test doit couvrir le système décrit dans le cadrage de votre SOC 2 : l’application de production, l’infrastructure qui la soutient et la surface accessible de l’extérieur qu’un attaquant rencontrerait réellement. Tester un site vitrine situé hors du périmètre ne prouve rien sur les contrôles examinés. Un test cadré sur les mauvais actifs vaut moins que pas de test du tout, car il coûte de l’argent et laisse en place la faille que l’auditeur trouvera.

Deux détails supplémentaires décident si le test aide ou nuit le jour du rapport. D’abord, la remédiation. Un rapport rempli de constats ouverts sans preuve de correction se lit comme un contrôle qui ne fonctionne pas. Le schéma attendu par les auditeurs est trouver, corriger, puis re-tester, avec l’attestation de re-test au dossier. Ensuite, l’indépendance. La valeur de l’exercice vient de ce que quelqu’un qui n’a pas construit le système tente de le casser, dans l’esprit de l’accent que met la phase de planification du NIST sur un périmètre écrit et des règles d’engagement convenues avant tout test.

Type I et Type II changent le calendrier

Les deux types de rapport SOC 2 traitent votre test d’intrusion différemment, et il vaut la peine de savoir lequel vous visez avant d’en planifier un.

Un rapport de Type I évalue si vos contrôles sont conçus correctement à une date donnée. Pour cela, un test d’intrusion récent et un plan documenté pour traiter ses constats peuvent suffire à montrer que le contrôle existe et qu’il est sain par conception.

Un rapport de Type II va plus loin et vérifie si ces contrôles ont fonctionné efficacement sur une période de plusieurs mois. Ici, un seul test ponctuel est nécessaire mais pas suffisant à lui seul : l’auditeur veut voir que l’identification des vulnérabilités a tourné tout au long de la fenêtre, ce qui signifie en général le test d’intrusion plus l’activité continue de scan et de remédiation qui l’entoure. Planifiez le test assez tôt pour que les constats puissent être corrigés et re-testés avant la clôture de la période d’observation, et non dans la dernière semaine.

Questions rapides

SOC 2 exige-t-il explicitement un test d’intrusion ? Non. Les Trust Services Criteria n’emploient jamais l’expression. Ils exigent que vous identifiiez et gériez vos vulnérabilités, et un test d’intrusion est la preuve que la plupart des auditeurs attendent pour ce contrôle.

Un scan de vulnérabilités suffit-il à lui seul ? Parfois pour la lettre de CC7.1, rarement pour la tranquillité de l’auditeur. Un scan satisfait la formule « périodique », mais il ne peut pas confirmer l’exploitabilité comme le fait la phase d’attaque d’un test. La plupart des équipes font les deux.

À quelle fréquence faut-il tester pour SOC 2 ? Une fois par an est la base courante, plus un test après tout changement significatif du système concerné. Pour un rapport de Type II, assurez-vous que le test se situe dans la période d’observation.

Qui peut réaliser le test ? Quiconque possède les compétences requises, mais la valeur vient de l’indépendance. Un testeur qui n’a pas construit le système, travaillant selon un périmètre écrit et des règles d’engagement convenues à l’avance, produit une preuve sur laquelle un auditeur peut s’appuyer.

Que veut concrètement voir l’auditeur ? Un test cadré sur le système concerné, réalisé dans la période, avec des constats corrigés et re-testés. Le rapport est la preuve ; les constats clos sont le contrôle qui fonctionne.

Un test d’intrusion réussi garantit-il la réussite de SOC 2 ? Non. Le test couvre une famille de contrôles. SOC 2 examine aussi la gestion des accès, la gestion des changements, la surveillance et davantage. Un bon test élimine une source fréquente de friction d’audit ; il ne remplace pas le reste.