Coût d'un test d'intrusion SOC 2

Pourquoi un référentiel qui ne mentionne jamais les tests en exige quand même

SOC 2 repose sur les Trust Services Criteria, rédigés comme des résultats et non comme une liste d'activités. Il n'existe pas de contrôle intitulé « test d'intrusion ». Cela pousse à l'une de deux erreurs : supposer qu'aucun test n'est nécessaire, ou en acheter un gros parce qu'un prestataire de préparation l'a dit.

Le cadrage utile est de considérer le test d'intrusion comme une preuve, non comme une exigence. C'est la façon la plus praticable, pour la plupart des organisations, de démontrer deux choses :

• CC4.1 - que vous réalisez des évaluations pour déterminer si vos contrôles sont réellement en place et fonctionnent. Un test indépendant est une évaluation directe, datée et produite en externe, exactement ce que recherche ce critère.
• CC7.1 - que vous détectez les vulnérabilités et les changements de configuration non autorisés. L'analyse couvre une partie de cela en continu ; un test couvre la partie que l'analyse n'atteint pas.

Parce qu'il s'agit d'une question de preuves et non d'une case de conformité, c'est l'avis de votre auditeur qui compte. Demandez-lui précisément et par écrit ce qu'il acceptera avant de cadrer quoi que ce soit. Les auditeurs diffèrent, et la différence vaut parfois plusieurs milliers de dollars de périmètre.

À quoi doivent ressembler les preuves

Un rapport seul est la façon la plus courante dont ce contrôle reçoit malgré tout une observation. La chaîne de preuves complète comporte quatre parties, et les manques sont presque toujours sur les deux dernières.

• Périmètre. Le périmètre testé doit correspondre de façon reconnaissable au système décrit dans votre rapport SOC 2. Si votre description du système couvre une plateforme SaaS multi-locataires et que le test a couvert un site vitrine non authentifié, l'écart saute aux yeux.
• Constats. Notés en gravité, avec une justification explicite plutôt qu'une couleur inexpliquée, et avec des étapes de reproduction.
• Remédiation. Documentée, datée, et avec une décision consignée pour tout ce qui est accepté plutôt que corrigé. L'acceptation du risque est permise ; le silence ne l'est pas.
• Vérification. La preuve que les correctifs ont été contre-testés et confirmés. C'est la partie qui manque le plus souvent, et c'est celle qui transforme un rapport en preuve qu'un contrôle fonctionne.

Une lettre d'attestation indiquant ce qui a été testé, quand, par qui et avec quel résultat est ce qui relie tout cela pour l'auditeur, et c'est ce que vos clients demanderont plus tard. Elle devrait faire partie de la mission et non constituer un achat séparé.

Calendrier et fenêtre d'observation

Pour le Type I, qui évalue la conception à un instant donné, un test récent et un plan de remédiation crédible suffisent généralement. Pour le Type II, qui évalue l'efficacité opérationnelle sur une période typiquement de trois à douze mois, le test, la remédiation et le contre-test doivent tous tomber dans la fenêtre. Réserver un test trois semaines avant la clôture de la fenêtre ne laisse aucune marge au cycle corriger-contre-tester, et c'est l'erreur de planification la plus fréquente.

À rebours : trois à cinq jours ouvrés de test pour une petite application, une à trois semaines pour que vos ingénieurs corrigent l'essentiel, et quelques jours pour le contre-test. Un mois à l'intérieur de la fenêtre est confortable. Une semaine ne l'est pas.

Cadrer pour SOC 2 sans surpayer

Le périmètre devrait être le système de votre description du système, soit pour la plupart des éditeurs SaaS le produit et l'infrastructure qui le fait tourner. En pratique, cela signifie l'application authentifiée avec tous les rôles utilisateurs, la frontière entre locataires, l'API et l'environnement cloud qui l'héberge.

Ce qui est fréquemment vendu dans le périmètre SOC 2 et y a rarement sa place : votre parc de portables, s'il est hors de la description du système ; une évaluation complète d'Active Directory, si vous n'avez pas de domaine d'entreprise ; et une mission red team, qui répond à une question entièrement différente de celle que pose CC4.1. Si un prestataire de préparation vous a chiffré tout cela, demandez-lui quel critère chaque ligne démontre.

Ce que cela coûte

SOC 2 ne change pas le coût du test, seulement la documentation qu'il vous en faut. Pour un produit SaaS typique, un périmètre applicatif démarre à 500 $ et couvre le produit authentifié, les rôles, l'isolation entre locataires et l'API. Dès que l'infrastructure cloud ou un réseau d'entreprise entre réellement dans la description du système, cela devient un périmètre infrastructure dès 1 500 $.

L'accompagnement à la remédiation, le contre-test et la lettre d'attestation sont inclus plutôt que facturés à part, ce qui compte ici davantage que sur la plupart des missions, puisque ce sont précisément les éléments que l'auditeur demandera. La page de service test d'intrusion SOC 2 traite du test lui-même plus en profondeur, coût d'un test d'intrusion explique le modèle général, et le rapport type montre le format que recevra un auditeur.

Si vous êtes également soumis à PCI DSS, les deux peuvent souvent partager une seule mission, même si les exigences de preuve diffèrent. Voyez coût d'un test d'intrusion PCI DSS, ou test piloté par la conformité pour la gestion des référentiels qui se recoupent.