Security Center:Gérer les vulnérabilités

Procédure de remédiation

1. Avant la remédiation

   • Confirmation des actifs : Vérifiez que les versions logicielles concernées sont bien présentes sur vos actifs serveur.

   • Évaluation des risques : Évaluez l'impact métier afin de déterminer l'urgence et la nécessité de la remédiation. Toutes les vulnérabilités ne requièrent pas une correction immédiate.

   • Tests approfondis : Déployez le correctif dans un environnement de préproduction. Validez entièrement sa compatibilité et sa sécurité, puis générez un rapport de test détaillé.

   • Sauvegarde des données : Effectuez une sauvegarde complète du serveur, par exemple en créant un snapshot ECS, afin de permettre un retour arrière rapide en cas d'erreur.

   • Planification de la remédiation : Effectuez la remédiation pendant les heures creuses afin de minimiser l'impact sur l'activité.

2. Pendant la remédiation

   • Opération à deux personnes : Assurez-vous qu'au moins deux professionnels sont présents. Pour prévenir les erreurs, l'un effectue l'opération tandis que l'autre la vérifie et l'enregistre.

   • Suivi du plan : Respectez strictement le plan de remédiation et appliquez les correctifs séquentiellement.

3. Après la remédiation

   • Vérification des résultats : Confirmez que la vulnérabilité est corrigée et que toutes les fonctions système ainsi que les applications métier s'exécutent correctement.

   • Archivage de la documentation : Documentez l'intégralité du processus dans un rapport final de remédiation des vulnérabilités et archivez-le.

Atténuation des risques

• Élaboration d'un plan détaillé : Créez un plan de remédiation réalisable, ayant fait l'objet de tests et de validations approfondis. Respectez scrupuleusement les étapes définies lors de l'exécution.

• Tests dans un environnement simulé : Mettez en place un environnement de test simulé identique à l'environnement de production, y compris son système, ses applications et ses données, afin de valider entièrement le plan de remédiation.

• Sauvegarde complète du système : Sélectionnez l'option Automatically Create Snapshot and Fix Risk pour effectuer une sauvegarde complète du système, incluant le système, les applications et les données. Vérifiez la capacité de restauration de la sauvegarde afin de garantir que vous pourrez restaurer rapidement les services en cas de problème.

Vulnérabilités manquantes et problèmes de scan

• Aucune vulnérabilité n'est affichée sur la page de gestion des vulnérabilités. Que faire ?

  Une liste de vulnérabilités vide peut signifier qu'aucun risque n'est actuellement détecté, ou que l'étendue de la requête ou le statut du service limite les résultats. Vérifiez les points suivants dans l'ordre :

  1. Vérifiez la région : La liste des vulnérabilités est affichée par région. Le sélecteur de région en haut de la page (par exemple, the Chinese mainland) détermine l'étendue de la requête. Basculez vers la région de vos actifs cibles et actualisez la page.

  2. Vérifiez l'édition et le statut d'activation : Certaines fonctionnalités liées aux vulnérabilités dépendent d'un service à valeur ajoutée. Si la page affiche Pay-as-you-go vulnerability fixing: Not activated, la fonctionnalité associée n'est pas activée et l'étendue disponible est limitée. Accédez à la page Overview pour confirmer l'édition et le statut d'activation de Security Center.

  3. Déclenchez manuellement un scan : Si aucun scan n'a encore été exécuté, ou si le dernier scan remonte à longtemps, cliquez sur One-click scan en haut de la page pour déclencher un scan, puis actualisez la page une fois le scan terminé.

  4. Comprenez l'état vide : Si des onglets tels que Linux software vulnerability ou Windows system vulnerability affichent No records found, aucun résultat n'a été détecté selon les conditions de filtrage actuelles. Ceci est normal et n'indique pas un dysfonctionnement. Vous pouvez basculer vers un autre onglet, tel que Urgent Vulnerabilities, pour confirmer que la page renvoie bien des données.

  5. Distinguez les vulnérabilités des alertes : Si vous avez reçu une alerte de sécurité telle qu'une attaque sortante depuis le serveur, mais que la page de gestion des vulnérabilités n'affiche aucun enregistrement, sachez que le scan des vulnérabilités et les alertes constituent deux dimensions de détection différentes, et qu'une alerte ne correspond pas nécessairement à une vulnérabilité. Consultez Afficher et gérer les événements d'alerte pour enquêter sur l'événement de sécurité.

Limites et principes de remédiation

• Pourquoi le bouton Fix est-il grisé ?

  • Problème : Limitations de l'édition du produit

    • Cause : La fonctionnalité one-click fix n'est pas prise en charge dans les éditions Basic Edition ou Anti-virus Edition.

    • Résolution : Achetez le value-added service « Vulnerability Fixing », ou effectuez une mise à niveau vers l'édition Enterprise Edition ou Ultimate Edition.

  • Problème : Problèmes côté serveur

    Problèmes liés aux serveurs Linux

    • Le système d'exploitation a atteint sa fin de vie (EOL) : L'éditeur ne fournit plus de patch. Vous devez mettre à niveau manuellement le operating system. La correction des vulnérabilités dans les systèmes d'exploitation suivants nécessite une mise à niveau du système d'exploitation :

      • Red Hat 5, Red Hat 6, Red Hat 7, Red Hat 8

      • CentOS 5

      • Ubuntu 12

      • Debian 8, 9, 10

    • Espace disque insuffisant : L'espace disque disponible est inférieur à 3 Go. Libérez de l'espace ou étendez le disque.

    • Processus en cours d'utilisation : Le processus apt ou yum est en cours d'exécution. Attendez la fin du processus et réessayez, ou terminez manuellement le processus.

    • Permissions insuffisantes : L'utilisateur exécutant la commande de remédiation ne dispose pas des permissions suffisantes. Assurez-vous que le propriétaire du fichier est l'utilisateur root et définissez des permissions appropriées, telles que 755.

    Problèmes liés aux serveurs Windows

    • Espace disque insuffisant : L'espace disque disponible est inférieur à 500 Mo. Libérez de l'espace ou étendez le disque.

    • Le service Windows Update ne fonctionne pas comme prévu : Le service est désactivé ou une installation de patch est déjà en cours.

      • Si le service est désactivé, accédez au gestionnaire de services sur le server, activez le service Windows Update, puis essayez à nouveau de corriger la vulnerability.

      • Si une mise à jour est en cours, attendez que le processus Wusa.exe se termine ou mettez fin manuellement au processus, puis essayez à nouveau de corriger la vulnerability.

• Quelle est la différence entre une vulnérabilité applicative et une vulnérabilité système ? Pourquoi la correction en un clic ne prend-elle pas en charge les vulnérabilités applicatives ?

  • Une system vulnerability, telle qu'une Linux software vulnerability ou une Windows system vulnerability, affecte le operating system ou ses composants. Ces vulnérabilités disposent de chemins de remédiation standardisés, ce qui permet de les corriger avec la fonctionnalité one-click fix.

  • Une application vulnerability existe dans une application gérée par vos soins, telle que le code d'un site web ou un logiciel tiers. La méthode de remédiation pour ce type de vulnerability est étroitement liée à votre logique métier et à votre code spécifiques. Étant donné que les outils automatisés ne peuvent pas comprendre votre contexte métier, vous devez corriger ces vulnérabilités manuellement.

• Pourquoi mon serveur présente-t-il autant de vulnérabilités ?

  À mesure que de nouvelles méthodes d'attaque émergent, des vulnérabilités sont continuellement découvertes dans les logiciels plus anciens. Le scan régulier et l'application de correctifs constituent des tâches de sécurité essentielles et continues. Pour vous aider à vous concentrer sur les risques les plus critiques, activez l'option Show Only Exploitable Vulnerabilities.

Opérations de remédiation

• Que faire si l'erreur « Permission acquisition failed, please check permissions and retry » apparaît lors de l'exécution d'une commande de correction ?

  • Cause : Le propriétaire du fichier requis pour effectuer l'opération de réparation n'est pas root, ce qui entraîne des permissions insuffisantes.

  • Résolution :

    1. Localisez le fichier :

       Dans Security Center, consultez les détails de la vulnerability pour identifier le fichier et le chemin spécifiques nécessitant une remédiation.

    2. Modifiez les permissions :

       Connectez-vous au serveur et exécutez la commande suivante pour changer le propriétaire du fichier en root.

    3. Réessayez la correction :

       Revenez à la console Security Center et relancez l'opération de remédiation sur la vulnerability.

• Lorsque je corrige des vulnérabilités par lot, dans quel ordre sont-elles corrigées ?

  Les Linux software vulnerability sont corrigées dans l'ordre où elles apparaissent dans la liste de la console. Certaines Windows system vulnerabilities nécessitent l'installation préalable d'un patch prerequisite. Lorsque vous exécutez une correction par lot pour les Windows system vulnerabilities, ces types de vulnérabilités sont prioritaires. Les vulnérabilités restantes sont corrigées dans l'ordre où elles apparaissent dans la liste de la console.

• Pourquoi un redémarrage ne fonctionne-t-il pas après avoir corrigé une vulnérabilité du noyau sur Ubuntu ?

  • Symptôme : Après avoir utilisé la fonctionnalité de correction en un clic dans Security Center pour appliquer un correctif à une vulnérabilité du noyau sur un serveur Ubuntu, un message « Fixed, pending restart » s'affiche. Toutefois, après le redémarrage du serveur, l'alerte de vulnérabilité persiste car le système n'utilise pas le noyau nouvellement installé.

  • Cause : Ce problème survient généralement si l'ordre de démarrage par défaut du menu de démarrage GRUB a été modifié manuellement. Le script de remédiation ne peut alors pas définir le nouveau kernel comme option de démarrage par défaut.

  • Résolution :

    Solution 1 : Configurer automatiquement le nouveau noyau

    Cette solution ignore votre configuration GRUB personnalisée existante et permet au système d'appliquer automatiquement les paramètres par défaut pour le nouveau kernel.

    Procédure :

    1. Avant de corriger la vulnérabilité, connectez-vous à votre server Ubuntu.

    2. Exécutez la commande suivante pour définir la variable d'environnement :

       <BASH>
       
       export DEBIAN_FRONTEND=noninteractive

    3. Revenez à la console Security Center et effectuez une correction en un clic sur la vulnerability.

    4. Une fois la correction terminée, redémarrez le server comme indiqué. Le système active automatiquement le dernier kernel.

    Solution 2 : Modifier manuellement l'ordre de démarrage

    Si vous devez conserver votre configuration GRUB existante, vous pouvez utiliser cette solution.

    Procédure :

    1. Dans la console Security Center, effectuez une one-click fix et redémarrez le server comme indiqué.

    2. Après le redémarrage du server, connectez-vous à votre server Ubuntu.

    3. Modifiez manuellement l'ordre de démarrage GRUB pour définir la version du kernel nouvellement installée comme option de démarrage par défaut.

       Remarque

       La procédure implique généralement la modification du fichier /etc/default/grub et l'exécution de la commande update-grub. Pour plus d'informations, consultez Modifier l'ordre de démarrage du noyau d'une instance ECS Linux CentOS.

    4. Redémarrez à nouveau le server pour que le nouvel ordre de démarrage prenne effet.

• Dois-je redémarrer le système après avoir corrigé une vulnérabilité ?

  • Windows : Un redémarrage est requis.

  • Linux Software Vulnerability : Un redémarrage est requis si l'une des conditions suivantes est remplie :

    • Une vulnerability du kernel a été corrigée.

    • Dans l'onglet Linux Software Vulnerability de la page Risk Governance > Vulnerabilities de la console Security Center, le bulletin de la vulnerability comporte un tag Restart Required.

• Pourquoi une opération de rollback de vulnérabilité échoue-t-elle ?

  Si une opération de vulnerability rollback échoue, examinez les causes possibles suivantes :

  1. Vérifiez le statut de l'agent

     L'opération de rollback nécessite que l'agent Security Center soit en ligne. Si l'agent est hors ligne, la commande ne peut pas être transmise. Vous devez d'abord résoudre le problème du statut hors ligne de l'agent.

  2. Confirmez que le snapshot de sauvegarde est valide

     La fonctionnalité de rollback s'appuie sur le backup snapshot créé avant la remédiation. Si le snapshot a expiré ou a été supprimé manuellement, l'opération de rollback ne peut pas être effectuée.

• Pourquoi la création de snapshot échoue-t-elle lors de la correction d'une vulnérabilité ?

  La création d'un snapshot peut échouer pour les raisons suivantes :

  • Opération effectuée par un utilisateur RAM : Si un RAM user sans la permission requise effectue l'opération, la création du snapshot échoue. Nous vous recommandons d'utiliser votre Alibaba Cloud account pour effectuer l'opération. Pour plus d'informations sur les RAM user, consultez Présentation.

  • Serveur non Alibaba Cloud : La création de snapshot pour la remédiation des vulnérabilités n'est pas prise en charge sur les non-Alibaba Cloud server.

Statut après correction et vérification

• J'ai corrigé une vulnérabilité, mais Security Center la signale toujours. Que dois-je faire ?

  • Cause : Ce problème survient car certaines vulnérabilités, telles que les vulnérabilités du noyau Linux kernel, nécessitent un redémarrage du serveur server après la correction.

  • Résolution : Sur la page des détails de la vulnérabilité vulnerability, cliquez sur Restart. Une fois le redémarrage terminé, cliquez sur Verify. Si le statut passe à « Repaired », la vulnérabilité vulnerability est correctement corrigée.

• J'ai corrigé une vulnérabilité sans mettre à jour la version du logiciel, mais Security Center la signale toujours. Que dois-je faire ?

  • Cause : Security Center détecte les Application Vulnerability et les Urgent Vulnerability en comparant le numéro de version du logiciel ou du composant. Si vous atténuez une vulnérabilité au lieu de passer à une version sécurisée, par exemple en activant SafeMode dans fastjson pour désactiver AutoType, le numéro de version reste dans la plage affectée. Les analyses suivantes continuent de signaler la vulnérabilité, et cliquer sur Verify ne change pas le statut en « fixed ».

  • Résolution : Après avoir confirmé que l'atténuation a éliminé le risque, accédez à la page Vulnerabilities et appliquez l'option Ignore ou Add to Whitelist à la vulnérabilité pour arrêter les alertes répétées. L'option Ignore prend effet uniquement pour le processus actuel. Si l'application redémarre ou si un nouveau processus démarre, Security Center peut détecter à nouveau la vulnérabilité. L'option Add to Whitelist supprime les alertes pour ce type de vulnérabilité dans la portée configurée jusqu'à ce que vous supprimiez manuellement la règle de liste d'autorisation. Pour connaître les différences entre ces deux actions et les procédures correspondantes, consultez la section « Différer la correction » de cette rubrique.

• Pourquoi le statut des correctifs de vulnérabilités Windows passe-t-il à « Invalid » ?

  Le mécanisme de détection des vulnérabilités Windows a été mis à jour. Suite aux mises à jour mensuelles des règles de vulnérabilités Windows, le statut des vulnérabilités existantes affectées par ces modifications de règles sera marqué comme « Invalid ».

• Après avoir corrigé une vulnérabilité, pourquoi la console affiche-t-elle toujours le statut « Not fixed » ?

  Cela peut se produire pour les raisons suivantes :

  1. Délai de vérification : Après une correction manuelle, vous devez cliquer sur le bouton Verify pour déclencher une analyse immédiate. La mise à jour du statut peut prendre quelques minutes.

  2. Cache du navigateur : La page de la console console peut être mise en cache dans votre navigateur. Essayez d'actualiser la page de force ou attendez quelques minutes.

  3. Correction incomplète : L'opération de correction n'a peut-être pas été entièrement réussie. Par exemple, une vulnérabilité vulnerability peut comporter plusieurs chemins vulnérables, mais un seul a été corrigé. Vérifiez les étapes de correction et réessayez.

• Fixed and Pending Restarted: Security Center peut-il vérifier automatiquement une vulnérabilité dans cet état ?

  Non. Vous devez redémarrer le serveur server depuis la console console de Security Center ou le redémarrer manuellement. Après le redémarrage du serveur server, cliquez sur Verify pour confirmer que la vulnérabilité vulnerability est corrigée.

  Important

  Si vous ne vérifiez pas manuellement le correctif, Security Center vérifie automatiquement le statut lors de la prochaine analyse planifiée. Pour éviter les faux négatifs dus à des problèmes réseau, le système conserve l'enregistrement de la vulnérabilité vulnerability pendant trois jours s'il n'est pas détecté lors de la première analyse. Si la vulnérabilité vulnerability reste non détectée pendant trois jours consécutifs, le système supprime l'enregistrement.

• Pourquoi le statut de vérification ne se met-il pas à jour après avoir corrigé manuellement une vulnérabilité ?

  Après avoir corrigé manuellement une vulnérabilité sur un serveur, si la fonctionnalité « Verify » de la console Security Center ne parvient pas à mettre à jour le statut de la vulnérabilité en « Fixed », ce problème survient généralement pour les deux raisons suivantes :

  • Le niveau d'analyse des vulnérabilités n'est pas entièrement configuré

    • Cause : Security Center analyse et met à jour le statut uniquement pour les niveaux de risque sélectionnés dans Vulnerability Settings. Si le niveau de risque de la vulnérabilité cible vulnerability, tel que High ou Medium, n'est pas sélectionné, le système ne met pas à jour son statut.

    • Résolution : Vérifiez les paramètres d'analyse dans Vulnerability Settings et assurez-vous que le niveau de risque de la vulnérabilité cible vulnerability est sélectionné.

  • L'agent Security Center est hors ligne

    • Raison : La fonction « Verification » repose sur une communication en temps réel entre la console et le client sur le serveur. Si le client est hors ligne, la console ne peut pas envoyer de commandes de vérification ni recevoir les résultats.

    • Résolution : Résolvez le problème de l'agent agent hors ligne. Une fois que l'agent agent est de nouveau en ligne, essayez de vérifier à nouveau.