Votre environnement cloud vient d'être touché par un ransomware. Que faites-vous dans les 60 prochaines minutes ?Les ransomwares dans les environnements cloud se comportent différemment de ceux sur site : ils attaquent le stockage cloud natif, chiffrent les volumes EBS, suppriment les sauvegardes et exfiltrent les données vers un stockage contrôlé par les attaquants. Ce playbook fournit des procédures étape par étape pour les premières heures critiques d’un incident de ransomware cloud.
Points clés à retenir
- Les 60 premières minutes sont critiques :Les actions de confinement au cours de la première heure déterminent si l'incident est une perturbation ou une catastrophe.
- Ne payez pas la rançon :Le paiement ne garantit pas la récupération des données et finance des opérations criminelles. Concentrez-vous sur la récupération à partir des sauvegardes.
- Le ransomware cloud cible les sauvegardes :Les attaquants ciblent et suppriment spécifiquement les sauvegardes cloud (instantanés, versionnage S3) avant de chiffrer les données de production.
- Les sauvegardes immuables sont votre assurance :Les sauvegardes qui ne peuvent pas être modifiées ou supprimées par des informations d'identification compromises constituent la seule méthode fiable de récupération contre un ransomware.
- La compromission des informations d'identification active les ransomwares cloud :Les ransomwares cloud démarrent généralement avec des identifiants IAM volés, et non avec des logiciels malveillants sur un serveur.
Manuel de réponse aux ransomwares cloud
Phase 1 : Détection et évaluation initiale (0-15 minutes)
- Confirmez l'incident :Vérifiez les indicateurs de ransomware : fichiers cryptés, notes de rançon, activité API inhabituelle (chiffrement d'objets S3 en masse, suppression d'instantanés EBS)
- Activer l'équipe de réponse aux incidents :Informer le commandant de l'incident, l'équipe IR, l'ingénierie, le service juridique et le sponsor exécutif
- Évaluer la portée :Identifiez les comptes, les régions et les services concernés. Vérifiez CloudTrail/Activity Log pour connaître l'activité récente des informations d'identification compromises
- Déterminer le vecteur d'attaque :Comment l’attaquant a-t-il pu y accéder ? Phishing, vol d'identifiants, application vulnérable, tiers compromis ?
Phase 2 : Confinement (15-60 minutes)
- Révoquer les identifiants compromis :Désactivez tous les utilisateurs IAM et les clés d'accès associés à l'attaque. Révoquer toutes les sessions actives
- Isoler les ressources affectées :Appliquez des groupes de sécurité de quarantaine aux instances compromises (refusez tout ce qui est entrant/sortant). Désactiver les fonctions Lambda concernées
- Protéger les sauvegardes :Vérifiez l'intégrité de la sauvegarde. Déplacez les sauvegardes critiques vers un compte isolé avec des informations d'identification distinctes. Activez le verrouillage d'objet S3 s'il n'est pas déjà configuré
- Bloquer l'infrastructure des attaquants :Bloquez les adresses IP des attaquants connus dans les groupes de sécurité, WAF et les ACL réseau. Bloquer les domaines des attaquants dans DNS
- Préserver les preuves :Capturez un instantané de tous les volumes EBS concernés. Exportez les journaux CloudTrail pertinents vers un compte verrouillé distinct. Capturer les métadonnées de l'instance
Phase 3 : Éradication (1 à 24 heures)
- Identifier la persistance :Recherchez les utilisateurs, les rôles, les politiques, les fonctions Lambda et les tâches planifiées IAM créés par l'attaquant
- Supprimez tous les accès des attaquants :Supprimez les ressources créées par l’attaquant. Faites pivoter toutes les informations d'identification des comptes concernés, pas seulement ceux compromis
- Corrigez le point d'entrée :Correction de la vulnérabilité qui a permis l'accès initial (mettre à jour l'application, corriger une mauvaise configuration, recycler l'utilisateur)
- Vérifier l'état propre :Analysez toutes les instances à la recherche de logiciels malveillants. Examinez toutes les politiques IAM pour détecter les modifications non autorisées. Vérifier les configurations réseau
Phase 4 : Récupération (24-72 heures)
- Restauration à partir de sauvegardes propres :Restaurez les données à partir de sauvegardes vérifiées et propres. Ne pas restaurer à partir d'instantanés ayant pu être pris après le début de la compromission
- Reconstruire l'infrastructure compromise :Reconstruisez les instances affectées à partir d'AMI/images propres plutôt que d'essayer de nettoyer les instances compromises
- Valider la récupération :Vérifiez l'intégrité des données, la fonctionnalité des applications et les contrôles de sécurité avant de revenir en production
- Surveiller intensivement :Mettre en œuvre une surveillance améliorée pendant 30 jours après la récupération pour détecter toute présence restante d'un attaquant
Phase 5 : Post-incident (1 à 4 semaines)
- Effectuer une analyse des causes profondes :Documentez la chronologie complète de l'attaque, depuis l'accès initial jusqu'à la détection et le confinement
- Soumettre les notifications réglementaires :NIS2 nécessite une alerte précoce de 24 heures et une notification détaillée de 72 heures. GDPR nécessite une notification dans les 72 heures si les données personnelles ont été affectées
- Mettre en œuvre des améliorations :Traiter la cause première, renforcer la détection, améliorer la résilience des sauvegardes, mettre à jour les procédures IR en fonction des enseignements tirés
- Effectuer une autopsie irréprochable :Partagez les résultats à l’échelle de l’organisation pour éviter toute récidive sans blâmer
Prévention contre les ransomwares : contrôles spécifiques au cloud
| Contrôle | AWS Implémentation | Azure Implémentation |
|---|---|---|
| Sauvegardes immuables | S3 Verrouillage d'objet, AWS Verrouillage du coffre-fort de sauvegarde | Stockage Blob immuable, Azure Immuabilité de la sauvegarde |
| Protection des informations d'identification | MFA sur racine, IAM Access Analyzer, SCP | MFA sur tous les administrateurs, accès conditionnel, PIM |
| Moindre privilège IAM | Politiques IAM minimales, pas de clés d'administrateur | Rôles RBAC minimaux, pas d'administrateur permanent |
| Surveillance | GuardDuty, CloudTrail, Centre de sécurité | Defender pour Cloud, Sentinel, journal d'activité |
| Segmentation du réseau | Isolement VPC, groupes de sécurité, NACL | Isolation du réseau virtuel, NSG, pare-feu Azure |
Comment Opsio protège contre les ransomwares
- Prévention :Nous mettons en œuvre des sauvegardes immuables, le moindre privilège IAM et une surveillance de sécurité qui détecte les indicateurs de ransomware avant le début du chiffrement.
- Détection :Notre SOC surveille les indicateurs de ransomware 24 heures sur 24 et 7 jours sur 7 : activité inhabituelle de API, opérations de fichiers en masse, tentatives de suppression de sauvegarde et TTP de ransomware connues.
- Réponse :Les playbooks de confinement automatisés s'exécutent en quelques secondes, révoquant les informations d'identification et isolant les ressources avant que le ransomware ne se propage.
- Récupération :Nous maintenons et testons les procédures de récupération des sauvegardes afin que la restauration soit rapide et fiable en cas de besoin.
- Conformité NIS2 :Nous aidons à préparer et à soumettre les notifications réglementaires dans les délais NIS2 et GDPR.
Foire aux questions
Devons-nous payer la rançon ?
Non. Le paiement ne garantit pas la récupération des données : de nombreuses victimes qui paient ne reçoivent jamais de clés de décryptage fonctionnelles. Le paiement finance des opérations criminelles et marque votre organisation comme prête à payer (augmentant la probabilité d’attaques futures). Concentrez les ressources sur la récupération à partir des sauvegardes et sur la prévention des récidives. Les forces de l’ordre recommandent universellement de ne pas payer.
Comment pouvons-nous garantir que les sauvegardes survivent aux ransomwares ?
Implémentez des sauvegardes immuables qui ne peuvent pas être modifiées ou supprimées même par les informations d'identification de l'administrateur. AWS S3 Le verrouillage des objets en mode Conformité empêche la suppression pendant une période de conservation définie. Azure Immuable Blob Storage offre une protection équivalente. Stockez les copies de sauvegarde dans un compte AWS distinct ou un abonnement Azure avec des informations d'identification indépendantes qui ne sont pas accessibles depuis l'environnement de production.
À quelle vitesse pouvons-nous nous remettre d’un ransomware cloud ?
Grâce à des procédures de sauvegarde et de récupération testées, la plupart des environnements cloud peuvent restaurer les systèmes critiques en 4 à 24 heures et terminer la restauration en 1 à 3 jours. Sans procédures testées, la récupération prend des semaines. La clé réside dans des tests réguliers : effectuez des exercices de récupération tous les trimestres pour vérifier que les sauvegardes sont valides et que les procédures de restauration fonctionnent.