Workflow de gestion des risques pour la conformité TI

Exemple de bout en bout : Risque d'accès trop privilégié

Suivez comment Sarah, administratrice de la conformité, et Maria, propriétaire des risques, identifient et gèrent un risque de conformité qui menace la politique pour les exigences de moindre privilège.

Phase 1 : Identification et enregistrement du risque

Sarah ouvre la Bibliothèque de scénarios de risque pour trouver un modèle de risque de contrôle d'accès. Elle sélectionne le scénario Accès surprivilégié aux données confidentielles, qui fournit une description normalisée et des cotes de probabilité/impact suggérées basées sur des risques similaires dans d'autres organisations.

Elle crée un Risque de conformité appelé Accès surprivilégié aux données clients basé sur le modèle de scénario. Le risque décrit la menace que le personnel informatique puisse obtenir un accès non autorisé aux données des clients en raison d'autorisations excessives dans les systèmes de production.

Sarah attribue Maria, la directrice informatique, en tant que propriétaire des risques. Maria est responsable de s'assurer que les contrôles d'atténuation sont en place et d'intervenir lorsque le risque se matérialise.

Sarah définit la catégorie de risque sur Contrôle d'accès et le statut sur Identifié. Le risque n'a pas encore été évalué ni évalué.

Phase 2 : Définition du périmètre de risque

Sarah crée un enregistrement Étendue du risque pour définir ce que ce risque menace et les mesures de protection qui le protègent. Elle utilise des enregistrements junction pour créer des liens traçables :

• Mappage des processus métiers : Associez le risque au processus des opérations commerciales Traitement des données clients. Ce mappage montre le workflow opérationnel que le risque menace.
• Type de périmètre de risque : Appliquez un périmètre de risque au risque en utilisant un type de périmètre de risque qui catégorise les éléments à risque, par exemple le type de périmètre de risque de l'élément de configuration pointant vers les comptes AWS de production suivis dans la CMDB. Si aucun Type d'étendue de risque approprié n'existe, Sarah en crée un en premier. Consultez Définition et application du périmètre de risque pour la conformité TI.
• Mappage de stratégies : Liez le risque à la stratégie d'accès aux données : RBAC avec la clause de police Least Privilege. Le risque représente une infraction potentielle à la politique interne.
• Mappage d'actifs : Liez le risque aux comptes AWS de production suivis en tant qu'actifs dans la CMDB. Ce mappage montre les systèmes spécifiques vulnérables.
• Mappage de contrôle : Liez le risque à la version de contrôle Contrôle de l'application de la loi du RBAC. Ce contrôle est conçu pour limiter les risques en vérifiant que les droits d'accès correspondent aux fonctions des tâches. Elle attribue un taux d'efficacité du contrôle de 80 %, indiquant que lorsque le contrôle fonctionne correctement, il réduit l'impact du risque de 80 %.

Phase 3 : Évaluation du risque

Sarah crée une évaluation du risque de conformité pour évaluer officiellement le risque. Elle définit la date d'évaluation sur la date actuelle et la méthodologie sur Enquête auprès des parties prenantes.

Sarah crée une évaluation des risques de conformité en utilisant les enquêtes Salesforce. L'enquête comprend deux questions clés :

• Probabilité : « Quelle est la probabilité que le personnel des TI obtienne un accès non autorisé aux données des clients en raison d'un accès trop privilégié? » (Échelle : 1 = Très faible, 5 = Très élevé)
• Impact : « En cas d'accès non autorisé, quelle serait la gravité de l'impact sur la Customer Trust, la conformité réglementaire et les opérations commerciales? » (Échelle : 1 = Très faible, 5 = Très élevé)

Sarah envoie l'enquête à Maria (directrice informatique) et à trois autres parties prenantes : le CISO, le responsable de l'infrastructure Cloud et le responsable de la conformité. Chaque partie prenante reçoit une notification par e-mail avec un lien vers l'enquête.

Toutes les parties prenantes terminent leur évaluation. La cote de probabilité moyenne est 3 (Moyen) et la cote d'impact moyenne est 4 (Élevé).

Phase 4 : Calculer les scores de risque

Lorsque toutes les parties prenantes ont soumis leurs réponses à l'enquête, Sarah examine les commentaires agrégés et calcule les scores de risque en utilisant le Moteur de règles métiers.

Le risque inhérent est la gravité naturelle du risque sans aucun contrôle appliqué. La formule est : Inherent Risk = Likelihood × Impact

Selon les résultats de l'enquête, le score de risque inhérent est calculé sur 12, ce qui correspond à la plage Élevée (10-15). Cela signifie que, sans aucun contrôle, le risque d'accès privilégié constitue une menace importante pour l'organisation.

Le risque résiduel correspond à la gravité restante après l'application des contrôles. La formule est Residual Risk = Inherent Risk × (1 - Control Effectiveness).

Le contrôle du Contrôle d'application de la loi du RBAC est lié au risque avec un taux d'efficacité de 80 %. Le score de risque résiduel calculé de 2,4 se situe dans la plage inférieure (0-5). Cela signifie que le contrôle RBAC réduit efficacement le risque de Élevé à Faible.

Sarah enregistre les deux scores dans l'enregistrement Évaluation du risque de conformité et met à jour le statut de l'enregistrement sur Terminé.

Phase 5 : Examen du résumé des risques générés par l’IA

Sarah génère un Résumé des risques pour créer un récit piloté par l’IA qui explique les facteurs de risque et la justification du score. Le résumé identifie trois facteurs de risque : les audits périodiques ont détecté des autorisations excessives, les systèmes de production contiennent des données confidentielles soumises aux réglementations de conformité et la croissance de l'infrastructure cloud rend les audits manuels plus difficiles.

Le résumé confirme que l'efficacité de 80 % du contrôle RBAC reflète l'historique des tests (8 tests sur 10 réussis) et recommande de poursuivre les tests trimestriels plus la surveillance continue. Le risque résiduel étant faible, aucun traitement immédiat n'est nécessaire.

Phase 6: Surveillance continue et carte thermique

Sarah configure un agent de surveillance en arrière-plan pour surveiller les nouveaux utilisateurs, les changements de rôle IAM et contrôler les échecs de test. Lorsqu'il est détecté, l'agent déclenche une nouvelle évaluation du risque et notifie Maria.

Sarah examine le risque dans le tableau de bord Carte thermique du risque. La carte thermique trace les risques par probabilité et impact, avec un code couleur sur Faible (vert) pour le risque d'accès surprivilégié basé sur son score de risque résiduel de 2,4, montrant que les contrôles atténuent efficacement la menace.

Phase 7 : Contrôle des déclencheurs de défaillance Mise à jour dynamique du risque

Au deuxième trimestre, le contrôle RBAC échoue à son test trimestriel. Trois utilisateurs ont un accès privilégié.

Le système met automatiquement à jour le risque :

• Contrôle de l'efficacité réduit à 0 %
• Recalcul du risque résiduel : 12 × (1 - 0.00) = 12 (High)
• Maria reçoit une alerte indiquant que le risque résiduel est passé de 2,4 à 12
• La carte thermique passe du vert au rouge
• Un agent en arrière-plan crée un Constat de conformité

Phase 8 : Plan de traitement des risques

Sarah crée un plan de traitement des risques en utilisant le modèle de réparation des droits d'accès. Le modèle inclut des tâches de révision des droits d'accès, de révocation d'autorisations excessives, de documentation des modifications, de réexécution du test et de chargement de preuves.

L'équipe de Maria termine la dépollution. Lorsque le nouveau test réussit :

• Contrôle de l'efficacité restaure à 80 %
• Recalcul du risque résiduel : 12 × (1 - 0.80) = 2.4 (Low)
• Maria reçoit la confirmation que le risque a diminué de 12 à 2,4
• La carte thermique revient au vert

Sarah ferme le plan de traitement et marque le statut de risque sur Atténué.

Hiérarchie des risques et relations parent-enfant

Établissez des relations parent-enfant dans lesquelles un risque parent élevé cumule plusieurs risques enfants. Par exemple, un risque parent appelé Global Data Center Security Vulnerabilities peut être lié à des risques enfants pour des serveurs spécifiques (système d'exploitation périmé sur le serveur A) et des pare-feux (certificats TLS expirés sur les pare-feux périphériques).

Le système cumule automatiquement les scores de risque enfant pour le parent. Les dirigeants affichent le score agrégé pendant que les équipes informatiques explorent des systèmes spécifiques. Lorsqu'un score de risque enfant augmente en raison d'une défaillance du contrôle, le score de risque parent est automatiquement mis à jour.