SOC 2 et tests d’intrusion : ce que les auditeurs attendent vraiment

À chaque saison d’audit, le même message atterrit dans notre boîte de réception. Un fondateur nous transfère la note de son auditeur qui réclame une “preuve de test d’intrusion”, la fenêtre d’audit se referme dans trois semaines, et en pièce jointe se trouve un scan de vulnérabilités du trimestre dernier avec la question : est-ce que ça compte ? Non. Et c’est précisément dans cet écart, entre ce qu’une équipe suppose suffisant et ce qu’un évaluateur va réellement valider, que le test d’intrusion SOC 2 s’effondre discrètement.

Disons d’emblée ce qui dérange. SOC 2 n’impose pas de test d’intrusion. Aucune clause des Trust Services Criteria ne dit “tu pentesteras chaque année”. Ce que le référentiel exige, c’est que vous surveilliez les vulnérabilités et prouviez que vos contrôles de sécurité fonctionnent réellement. Un vrai pentest se trouve être la preuve la plus nette que vous puissiez présenter à un auditeur pour démontrer les deux, et c’est pourquoi presque chaque rapport Type II que nous accompagnons finit par s’appuyer sur un test.

Alors cessez de demander “ai-je besoin d’un pentest pour SOC 2”. Posez les deux questions qui comptent : que doit prouver le test, et que doit dire le rapport.

Points essentiels

• SOC 2 ne nomme jamais explicitement le test d’intrusion, mais il exige une surveillance des vulnérabilités et la preuve que les contrôles fonctionnent, et un pentest est la preuve la plus solide pour les deux.
• Un pentest se rattache le plus directement aux Common Criteria sur l’évaluation des risques et l’exploitation des systèmes, en particulier CC7.1, avec l’appui de CC3.2 et CC4.1.
• Les auditeurs veulent un périmètre qui correspond à la frontière de votre système de production, ainsi que la preuve que les vulnérabilités ont été suivies et corrigées, et non une jolie page de synthèse.
• Un test annuel est la référence admise, complété par un nouveau test après des changements significatifs et après la correction des vulnérabilités élevées et critiques.
• Un scan de vulnérabilités n’est pas un test d’intrusion, et faire passer l’un pour l’autre est la raison la plus fréquente du rejet des preuves.

Ce que SOC 2 demande réellement

SOC 2 repose sur les Trust Services Criteria de l’AICPA. La catégorie Security, les Common Criteria, est obligatoire dans chaque rapport SOC 2. Les critères qui touchent aux tests se trouvent dans les domaines de l’évaluation des risques et de l’exploitation des systèmes.

CC7.1 est celui qu’il faut retenir. Il attend de vous des procédures de détection et de surveillance qui repèrent les changements de configuration introduisant des vulnérabilités ainsi que l’exposition aux vulnérabilités nouvellement découvertes. Un test d’intrusion est un moyen direct et défendable de montrer que vous faites exactement cela contre votre propre surface d’attaque, au lieu de supposer que vos défenses tiennent. CC3.2 couvre l’identification et l’analyse des risques. CC4.1 couvre l’évaluation continue du bon fonctionnement des contrôles. Un rapport de pentest bien construit répond aux trois à la fois. C’est pourquoi les évaluateurs aiment en recevoir un.

Voici le point sur lequel SOC 2 est vraiment pointilleux : l’efficacité opérationnelle dans la durée. Dans un rapport Type II, qui couvre une période d’observation plutôt qu’une date unique, il ne suffit pas de dire qu’un contrôle existe. Vous devez montrer qu’il a fait son travail sur toute la fenêtre. Un test qui fait remonter de vrais problèmes, assorti d’une trace de correction qui les referme, raconte cette histoire bien mieux qu’un PDF de politique ne le fera jamais.

Comment un pentest se rattache aux Common Criteria

L’erreur récurrente consiste à traiter le pentest comme un artefact isolé au lieu de le relier à des critères précis. Les auditeurs raisonnent en correspondances de contrôles. Alors donnez-leur la correspondance.

Concrètement : la section périmètre et méthodologie soutient CC3.2, l’identification et l’analyse des risques. Les vulnérabilités elles-mêmes constituent la preuve pour CC7.1, la détection des vulnérabilités. L’activité de correction et de nouveau test soutient CC7.4, la réponse aux problèmes de sécurité identifiés et leur résolution. Structurez le rapport de sorte qu’un évaluateur puisse pointer une vulnérabilité, puis le ticket qui l’a corrigée, puis le nouveau test qui a confirmé la correction, et vous aurez couvert ce sur quoi la plupart des entreprises butent : prouver que le contrôle a fonctionné, et pas seulement qu’il existait sur le papier.

Le rapport qu’un auditeur adore est ennuyeux dans le meilleur sens du terme. Périmètre clair, vraies vulnérabilités, correction suivie, nouveau test confirmé. Pas de drame, une traçabilité totale.

Quel périmètre un pentest SOC 2 doit-il couvrir ?

Le périmètre doit refléter la frontière du système décrite dans votre rapport SOC 2. En pratique, cela signifie votre application de production et l’infrastructure qui la soutient. Si votre plateforme SaaS, son API et l’environnement cloud qui la porte sont tous nommés dans le rapport, ils ont leur place dans le test. Un pentest qui écarte discrètement précisément ce à quoi vos clients se connectent chaque jour est un signal d’alerte, et un évaluateur expérimenté le remarquera.

Pour la plupart des entreprises SaaS qui abordent SOC 2, cela se décompose en une poignée de chantiers concrets. Un test de l’application web couvrant à la fois la surface authentifiée et non authentifiée, car le broken access control et les failles d’autorisation sont ce que nous rapportons le plus souvent sur ces missions. Un test d’API, puisqu’une si grande part de la véritable surface d’attaque se cache désormais dans des endpoints non documentés ou insuffisamment testés. Et, le cas échéant, un test réseau externe des services exposés sur Internet inclus dans le périmètre.

Nous fixons la frontière par écrit avant qu’une seule requête ne parte. La toute première cause d’un litige ultérieur sur les preuves est un énoncé de périmètre flou où personne ne peut dire si un composant était dedans ou dehors. Fixez-le. Listez les hôtes et les applications inclus dans le périmètre. Notez chaque exclusion et sa raison.

Comment nous le menons, et ce qui figure dans le rapport

Un test aligné sur SOC 2 se déroule tout de même comme un vrai pentest, pas comme un rituel de conformité. Nous partons d’une méthodologie établie, les guides de test OWASP pour le web et l’API ainsi qu’une méthodologie réseau standard pour l’infrastructure, associons l’outillage automatisé à la vérification manuelle, et confirmons chaque vulnérabilité à la main. Burp Suite pour le travail interactif, ffuf pour la découverte de contenu et de paramètres, nuclei pour balayer les problèmes connus à grande échelle. Ceux-là nous donnent la couverture. Les vulnérabilités critiques proviennent presque toujours de la couche manuelle : enchaîner une faille d’autorisation jusqu’aux données d’un autre locataire, ou transformer une stack trace verbeuse en une fuite d’information qui alimente l’étape suivante.

C’est précisément ce travail manuel que SOC 2 cherche à sonder. Un auditeur veut savoir si vos contrôles résistent à un attaquant motivé. Un scanner qui signale un chiffrement TLS faible ne répond pas à cette question. Un testeur qui démontre qu’un compte à faibles privilèges peut atteindre une fonction réservée aux administrateurs, oui.

Supposons qu’un compte de test soit limité à l’ID de compte 1042 et que nous parcourions l’identifiant d’objet à la main :

$ curl -s https://app.acme-corp.example.com/api/v2/accounts/1043/invoices \
    -H "Authorization: Bearer <low-priv-user-token>"

{"account_id":1043,"invoices":[ ... another tenant's billing data ... ]}

Une insecure direct object reference de ce type, CWE-639, se lit de façon bien plus convaincante pour un auditeur qu’une page de sortie de scanner. Elle montre qu’un contrôle qui aurait dû exister n’était tout simplement pas là.

Le rapport a besoin de quelques éléments précis pour survivre à l’examen d’audit. Un énoncé clair du périmètre et de la frontière. Une description de la méthodologie. Des vulnérabilités classées par gravité, avec assez de détail technique pour les reproduire et prouver qu’elles sont réelles, pas théoriques. Des recommandations de correction par vulnérabilité. Des dates de test qui tombent pendant la période d’audit ou raisonnablement avant. Et, idéalement, une attestation de nouveau test confirmant que les éléments élevés et critiques ont été refermés. C’est ce dernier morceau qui transforme “nous avons trouvé des problèmes” en “notre contrôle a fonctionné et nous avons comblé l’écart”. Cette phrase, c’est tout le récit de SOC 2.

À quelle fréquence faut-il tester pour SOC 2 ?

Une fois par an est la référence admise, et c’est ce que la plupart des auditeurs attendent pour un rapport Type II récurrent. Au-delà de la cadence annuelle, refaites un test après tout changement significatif du système inclus dans le périmètre, et refaites un test pour confirmer la correction des vulnérabilités élevées et critiques. Livrez une fonctionnalité majeure en milieu d’année, et un test antérieur à cette mise en production devient une preuve plus faible pour la période en cours. Un évaluateur aiguisé signalera le décalage.

Pour un premier SOC 2, testez pendant la phase de préparation, avant l’ouverture de la fenêtre d’observation. Vous gagnez du temps pour corriger les vulnérabilités et bâtir une trace de correction propre, au lieu de vous démener pour refermer les points critiques alors que l’auditeur observe déjà.

Comment CyberXplore vous aide

Nous menons des tests d’intrusion SOC 2 conçus pour aller droit à votre auditeur. Un périmètre aligné sur la frontière de votre système, un test à dominante manuelle qui repère ce que les scanners manquent, des vulnérabilités rattachées aux Common Criteria pertinents, et un nouveau test pour boucler la boucle sur les éléments élevés et critiques. Si vous préparez un Type I ou un Type II, notre service de préparation SOC 2 prend en charge le test et la mise en forme des preuves ensemble, pour que vous n’ayez pas à traduire vous-même un rapport de pentest brut en langage d’audit. Quand vous êtes prêt à en définir le périmètre, demandez un devis et nous alignerons la mission sur la frontière de votre rapport et votre calendrier d’audit.

FAQ

SOC 2 exige-t-il un test d’intrusion ?

Pas nommément. SOC 2 exige que vous surveilliez les vulnérabilités et démontriez que vos contrôles fonctionnent efficacement, principalement à travers les Common Criteria comme CC7.1. Un test d’intrusion est le moyen le plus direct et le plus largement accepté de produire cette preuve, si bien que la plupart des rapports SOC 2 s’appuient sur un test même si la norme n’emploie jamais l’expression exacte.

Un scan de vulnérabilités suffit-il pour SOC 2 ?

Non, et c’est la raison la plus fréquente du renvoi des preuves. Un scan liste des problèmes connus issus d’une base de signatures. Un test d’intrusion y ajoute le test manuel, l’exploitation et une analyse de la logique métier qu’un scanner ne peut pas réaliser. Les auditeurs connaissent de plus en plus la différence et demanderont si le test manuel faisait partie du travail.

À quelle fréquence devons-nous réaliser un test d’intrusion SOC 2 ?

Une fois par an est la référence, plus un nouveau test après des changements systèmes significatifs et après la correction des vulnérabilités élevées ou critiques. Pour un premier audit, testez pendant la phase de préparation afin d’avoir le temps de corriger les problèmes avant l’ouverture de la fenêtre d’observation.

Que doit contenir le rapport de pentest pour l’auditeur ?

Un périmètre et une frontière système définis, une description de la méthodologie, des vulnérabilités classées par gravité avec le détail de reproduction, des recommandations de correction, des dates de test comprises dans la période d’audit ou avant, et idéalement une attestation de nouveau test. La trace de correction et de nouveau test est ce qui prouve que le contrôle a réellement fonctionné, ce qui est au cœur d’un rapport Type II.

Qui définit le périmètre, nous ou l’auditeur ?

Vous et votre partenaire de test le définissez, mais il doit correspondre à la frontière du système décrite dans votre rapport SOC 2. Si l’audit couvre votre application de production, votre API et l’infrastructure de support, le test doit couvrir la même chose. Tester une tranche plus étroite que ce que décrit le rapport est le classique décalage de périmètre qui provoque des litiges par la suite.