Un comptable et un expert en sécurité entrent dans un bar… SOC2 n’est pas une blague.
Que vous soyez une entreprise publique ou privée, vous envisagez probablement de passer un audit SOC (Service Organization Controls). Pour les sociétés cotées en bourse, ces rapports sont exigés par la Securities and Exchange Commission (SEC) et exécutés par un expert-comptable agréé (CPA). Cependant, les clients demandent souvent des rapports SOC2 dans le cadre de leur processus de diligence raisonnable des fournisseurs.
Parmi les trois types de rapports SOC, SOC2 est la norme pour satisfaire avec succès les exigences réglementaires et signale une sécurité et une résilience élevées au sein de l’organisation – et est basé sur les exigences d’attestation de l’American Institute of Certified Public Accountants (AICPA). Le but de ce rapport est d’évaluer les systèmes d’information d’une organisation concernant la sécurité, la disponibilité, l’intégrité du traitement, la confidentialité et la vie privée — sur une période de temps (environ six à douze mois).
Dans le cadre d’un audit SOC2, il est nécessaire d’effectuer des contrôles de sécurité sur la pile SaaS de l’entreprise qui rechercheront des paramètres mal configurés tels que la détection et la surveillance pour garantir l’efficacité continue des contrôles de sécurité des informations et empêcher l’accès non autorisé/inapproprié aux actifs physiques et numériques et Emplacements.
Si vous commencez ou êtes sur un parcours d’audit SOC2, une solution SSPM (SaaS Security Posture Management) peut rationaliser le processus et raccourcir le temps nécessaire pour réussir un audit SOC2, couvrant entièrement votre posture de sécurité SaaS.
Découvrez comment rationaliser la conformité SOC2 de votre organisation
Que sont les critères des services de confiance de l’AICPA (TSC) ?
Lorsque des auditeurs externes s’engagent dans un audit SOC 2, ils doivent comparer ce que vous faites à une longue liste d’exigences établies par SCT de l’AICPA. Les « contrôles communs » se répartissent en cinq groupes :
- Sécurité – Comprend des sous-contrôles de l’accès logique et physique (CC6)
- Disponibilité – Comprend des sous-contrôles des opérations du système (CC7)
- Intégrité du traitement : Comprend des sous-contrôles des opérations du système (CC7)
- Confidentialité: Inclut les sous-contrôles de l’accès logique et physique (CC6)
- Vie privée – Comprend les sous-contrôles des activités de surveillance (CC4)
Dans chaque contrôle commun se trouvent un ensemble de sous-contrôles qui transforment la norme globale en tâches exploitables.
Réussir un audit SOC 2 demande beaucoup de temps, d’efforts et de documentation. Lors d’un audit SOC2, vous devez non seulement montrer que vos contrôles fonctionnent pendant la période d’audit, mais vous devez également montrer que vous avez la capacité de surveiller en permanence votre sécurité.
Parcourir l’ensemble du cadre TSC est trop long pour un article de blog. Cependant, un rapide coup d’œil sur quelques contrôles d’accès logique et physique (CC6) et d’opérations système (CC7) vous donne une idée de ce à quoi ressemblent certains des contrôles et comment vous pouvez utiliser un SSPM pour faciliter l’audit SOC2.
Obtenez une démonstration de 15 minutes sur la façon dont un SSPM peut aider votre audit SOC 2 TSC
Contrôles d’accès logiques et physiques
Cette section définit les types de contrôles nécessaires pour empêcher l’accès non autorisé ou inapproprié aux actifs et emplacements physiques et numériques. La gestion des autorisations d’accès, de l’authentification et de l’autorisation des utilisateurs dans l’ensemble du parc SaaS pose de nombreux défis. En fait, alors que vous cherchez à sécuriser vos applications cloud, la nature distribuée des utilisateurs et la gestion des différentes politiques d’accès deviennent de plus en plus difficiles.
Sous le contrôle CC6.1, les entités doivent :
- Identifier, classer et gérer les actifs informationnels
- Restreindre et gérer l’accès des utilisateurs
- Envisagez la segmentation du réseau
- Enregistrer, autoriser et documenter la nouvelle infrastructure
- Renforcez la sécurité en chiffrant les données au repos
- Protéger les clés de chiffrement
Exemple
Le département qui utilise une application SaaS est souvent celui qui l’achète et la met en œuvre. Le marketing peut implémenter une solution SaaS pour surveiller les prospects tandis que les ventes implémentent le CRM. Pendant ce temps, chaque application a son propre ensemble de capacités d’accès et de configurations. Cependant, ces propriétaires de SaaS peuvent ne pas être formés à la sécurité ou capables de surveiller en permanence les paramètres de sécurité de l’application, de sorte que l’équipe de sécurité perd de la visibilité. Dans le même temps, l’équipe de sécurité peut ne pas connaître le fonctionnement interne du SaaS comme le propriétaire, de sorte qu’elle peut ne pas comprendre les cas plus complexes qui pourraient conduire à une faille de sécurité.
Une solution SSPM cartographie toutes les autorisations utilisateur, le chiffrement, les certificats et toutes les configurations de sécurité disponibles pour chaque application SaaS. En plus de la visibilité, la solution SSPM aide à corriger toute erreur de configuration dans ces domaines, en tenant compte des fonctionnalités et de la convivialité uniques de chaque application SaaS.
Dans le contrôle CC.6.2, les entités doivent :
- Créez des identifiants d’accès aux actifs en fonction de l’autorisation du propriétaire des actifs du système ou du dépositaire autorisé
- Établir des processus pour supprimer l’accès aux informations d’identification lorsque l’utilisateur n’a plus besoin d’y accéder
- Examiner périodiquement l’accès des personnes inutiles et inappropriées avec des informations d’identification
Exemple
Les dérives d’autorisations se produisent lorsqu’un utilisateur dispose de certaines autorisations dans le cadre d’une appartenance à un groupe, mais se voit ensuite attribuer une autorisation spécifique qui est plus privilégiée que celle dont dispose le groupe. Au fil du temps, de nombreux utilisateurs obtiennent des autorisations supplémentaires. Cela sape l’idée de l’approvisionnement à l’aide de groupes.
Problèmes de déprovisionnement classiques, une solution SSPM peut repérer les utilisateurs inactifs et aider les organisations à remédier rapidement, ou à tout le moins, alerter l’équipe de sécurité du problème.
Sous le contrôle CC.6.3, les entités doivent :
- Établir des processus pour créer, modifier ou supprimer l’accès aux informations et actifs protégés
- Utiliser des contrôles d’accès basés sur les rôles (RBAC)
- Examiner périodiquement les rôles d’accès et les règles d’accès
Exemple
Vous gérez peut-être 50 000 utilisateurs sur cinq applications SaaS, ce qui signifie que l’équipe de sécurité doit gérer un total de 250 000 identités. Pendant ce temps, chaque SaaS a une manière différente de définir les identités, de les visualiser et de sécuriser les identités. Ajoutant au risque, les applications SaaS ne s’intègrent pas toujours les unes aux autres, ce qui signifie que les utilisateurs peuvent se retrouver avec des privilèges différents sur différents systèmes. Cela conduit alors à des privilèges inutiles qui peuvent créer un risque potentiel pour la sécurité.
Une solution SSPM permet une visibilité sur les privilèges des utilisateurs et les autorisations sensibles sur toutes les applications SaaS connectées, en mettant en évidence les écarts par rapport aux groupes et profils d’autorisation.
Opérations système
Cette section se concentre sur la détection et la surveillance pour garantir l’efficacité continue des contrôles de sécurité des informations sur les systèmes et les réseaux, y compris les applications SaaS. La diversité des applications SaaS et le potentiel de mauvaises configurations rendent difficile le respect de ces exigences.
Dans le contrôle CC7.1, les entités doivent :
- Définir les normes de configuration
- Surveiller l’infrastructure et les logiciels pour la non-conformité aux normes
- Établir des mécanismes de détection des changements pour alerter le personnel en cas de modification non autorisée des fichiers critiques du système, de la configuration ou du contenu
- Établir des procédures pour détecter l’introduction de composants connus ou inconnus
- Effectuer des analyses de vulnérabilité périodiques pour détecter les vulnérabilités potentielles ou les erreurs de configuration
Il est irréaliste d’attendre de l’équipe de sécurité qu’elle définisse une « norme de configuration » conforme à SOC2 sans comparer avec une base de connaissances intégrée de toutes les erreurs de configuration SaaS pertinentes et qu’elle se conforme en permanence à SOC2 sans utiliser une solution SSPM.
