Cisco Secure Email Gateway et SD-WAN Manager : vérifier les correctifs et préserver les preuves de compromission

Ce que c'est

État au 25 octobre 2026. Cet article s’appuie sur la version 1.0 de l’avis Cisco relatif à la messagerie, datée du 14 octobre 2026, et sur la version 1.1 de l’avis SD-WAN, datée du 2 octobre 2026. Consulter à nouveau les deux avis, leurs tableaux de versions corrigées et les consignes de restauration du support avant toute intervention.

CVE-2026-76519 affecte le traitement des fichiers de Secure Email Gateway ; CVE-2026-76504 permet de contourner l’authentification dans Catalyst SD-WAN Manager. La CISA les a ajoutées à son catalogue de vulnérabilités exploitées respectivement le 14 octobre et le 30 septembre 2026. Entrée relative à la messagerie, entrée relative à SD-WAN.

Pourquoi c'est important

Traiter séparément les décisions concernant l’exposition, l’installation des correctifs et l’investigation d’une compromission. La procédure de restauration SD-WAN de Cisco exige explicitement de recueillir les preuves avant la mise à niveau, puis de les faire analyser par le support. Une fois les preuves recueillies, la mise à niveau ne doit pas attendre les résultats de ces analyses. Appliquer la procédure de restauration correspondant au produit et au type de déploiement concernés ; une consigne générique de restauration depuis une sauvegarde ne suffit pas.

Comment l'appliquer

• Exposition et correctif de la messagerie : vérifier si AMP File Reputation est affecté à une politique de messagerie et si la version de Content Scanner Tools est antérieure à 25.3.0.5525. Les versions corrigées d’AsyncOS sont 15.5.5-014 et 16.5.0-780 ; la branche 16.0 nécessite une migration. Cisco recommande 16.5.0-780 pour les branches plus anciennes. Les versions prises en charge et sous licence peuvent également recevoir le paquet corrigé de l’analyseur. Avis relatif à la messagerie.
• Vérification de la messagerie : exécuter contentscannerstatus ; demander si nécessaire une mise à jour manuelle avec contentscannerupdate ; vérifier ensuite que la version est 25.3.0.5525 ou ultérieure. La mise à jour de ce paquet ne nécessite aucun redémarrage. Sur chaque membre du cluster, examiner :

grep "System Security" system_logs

Transmettre au support Cisco les messages signalant une suspicion de compromission ou une analyse incomplète. Recouper les informations avec les journaux réseau externes.

• Restauration de la messagerie : préserver d’abord les preuves. Pour les appliances virtuelles soupçonnées d’être compromises, déployer des remplacements corrigés, recréer la configuration sans importer d’anciens fichiers et renouveler les identifiants et les éléments cryptographiques. Restaurer chaque membre d’un cluster affecté. La restauration des appliances physiques nécessite l’intervention du support Cisco. Poursuivre la surveillance.
• Correctifs SD-WAN : les versions antérieures à chaque seuil applicable sont vulnérables, quelle que soit leur configuration. Utiliser le tableau des premières versions corrigées fourni par l’éditeur :

Branche de versions	Première version corrigée
Antérieure à 20.9	Migrer vers une version corrigée
20.9	20.9.10.1
20.12	20.12.8.2
20.15	20.15.6.1
20.18	20.18.4.1
26.1	26.1.2.1
26.2	26.2.1

Le bouclier Live Protect offre une protection partielle temporaire et ne constitue pas une remédiation. Restreindre l’accès d’administration aux hôtes de confiance pendant la préparation de la mise à niveau. Avis SD-WAN.

• Investigation SD-WAN : recueillir la sortie de request admin-tech sur tous les Managers, y compris les nœuds de cluster et de reprise après sinistre, avant la mise à niveau. Sélectionner Log et Tech. Mettre tous les nœuds à niveau, puis transmettre les dossiers au support Cisco pour rechercher des indicateurs ; suivre ses consignes de restauration supplémentaires lorsqu’une compromission est constatée. Rester sur la version majeure actuelle, sauf instruction contraire du support. Procédure de remédiation.
• Examen des journaux SD-WAN : corréler les activités d’authentification inattendues dans /var/log/nms/containers/service-proxy/serviceproxy-access.log et /var/log/nms/vmanage-server.log avec les adresses non autorisées. Le guide de remédiation emploie toutefois service_proxy pour le nom du répertoire du conteneur ; confirmer si nécessaire le chemin local auprès du support. L’absence d’un journal ne permet pas de conclure à l’absence de compromission. Les seuls noms réservés de comptes de service ne suffisent pas à établir une compromission. Préserver les observations pour le support plutôt que supprimer des comptes sur la seule base d’une correspondance de nom.

Pièges

Une demande de mise à jour de l’analyseur ne prouve pas que sa nouvelle version a été installée. De même, l’échec d’une analyse de sécurité ne permet pas de conclure à l’absence de compromission. Avant de clôturer l’incident, conserver dans le dossier de validation opérationnelle la version obtenue sur chaque nœud, la référence du dossier de preuves, la conclusion de l’investigation et les tâches de restauration encore en attente.