Vous venez de recevoir un bulletin d’information de votre fournisseur sur une vulnérabilité de sécurité récemment découverte. Un patch est également disponible. Devez-vous l’appliquer maintenant ou attendre? Bien sûr, vous devez attendre. Explorons pourquoi. Dans la communauté de la sécurité informatique, la devise générale est quand il s’agit de la gestion du code, «corriger tôt, réparer souvent». Sur son visage, cela ressemble à une bonne logique. Après tout, le temps écoulé entre la découverte d’une vulnérabilité critique et la présence d’une ferme dans la nature diminue, et souvent presque nul, voire négatif. Ainsi, tant que vous avez la possibilité d’exécuter des tests sur un nouveau correctif, il est logique d’aller de l’avant et de l’implémenter rapidement dans votre environnement de production.
Patcher / Patcher: le patcher peut ruiner les choses
Ici, les choses vont mal avec la gestion des correctifs. Car les correctifs cassent souvent les choses. Je ne peux pas compter à quelle fréquence Microsoft a publié un correctif pour résoudre un problème et le correctif lui-même a causé des problèmes supplémentaires. C’est comme demander à un mécanicien de réparer le volant de votre voiture et finir par avoir des problèmes avec les freins à cause de quelque chose que le mécanicien a fait. À titre d’exemple récent, voyez ce qui est arrivé à la vulnérabilité de contournement de la fonction de sécurité Kerberos KDC CVE-2020-17049. Cette vulnérabilité comprenait un contournement des fonctionnalités de sécurité qui existaient dans la façon dont le service du centre de distribution de clés (KDC) pour Active Directory détermine si un ticket de service peut être utilisé pour l’externalisation via la délégation Kerberos contrainte (KCD). Pour qu’un acteur malveillant puisse exploiter cette vulnérabilité, un service de compromis configuré pour utiliser KCD pourrait violer un ticket de service invalide pour forcer KDC à l’accepter. La Conseil en sécurité Publié par Microsoft Security Resource Center (MSRC) a ensuite corrigé cette vulnérabilité avec des instructions pour modifier la façon dont KDC valide les tickets de service avec un correctif utilisant la valeur de registre suivante:
HKLM System CurrentControlSet Services Kdc PerformTicketSignature
Cela semble assez simple, n’est-ce pas? La vulnérabilité est découverte, la vulnérabilité a été corrigée.
Ensuite, cependant, ils constatent que leur résolution peut causer des problèmes dans certains environnements, tels que le fait que les tickets de service Kerberos et les tickets TGT ne peuvent pas être renouvelés pour les clients Kerberos non Windows, et d’autres problèmes désagréables – Dépannage. Donc, ils n’y recourraient qu’en dernier recours publier un article d’assistance à ce sujet. Et ainsi de suite. Vous souhaiterez peut-être attendre que Microsoft corrige le correctif (ou corrige le correctif ou autre) avant de l’exécuter en production.
Le guidage de correction peut être modifié
Il y a une autre raison pour laquelle il est généralement préférable d’attendre que de corriger ou de corriger immédiatement lorsqu’une vulnérabilité est signalée. Ceci est dû au fait Les conseils du fournisseur pour un correctif ou un correctif peuvent changer. Encore une fois, utilisons CVE-2020-17049 comme exemple. Le 10 novembre de l’année dernière, lorsque Microsoft a publié pour la première fois des conseils de sécurité pour cette vulnérabilité, ils incluaient les conseils suivants:
Questions fréquentes
Dois-je suivre des étapes supplémentaires lors du développement de cette mise à jour?
Oui, pour les environnements de domaine complexes, une clé de registre a été fournie pour permettre le développement dans tous les domaines avant que le correctif ne soit entièrement activé. Dans une forêt complexe, où les billets Kerberos peuvent voyager dans de nombreuses régions, nous suggérons les étapes suivantes:
- Définissez la clé de registre sur 0 (désactivé).
- Développement complet sur tous les DC (et DC en lecture seule) de votre forêt.
- Une fois le développement terminé, définissez la clé de registre sur 1. Une version ultérieure supprimera cette clé de registre et exigera des signatures de ticket.
Ensuite, les instructions initiales du MSRC détaille les étapes que vous devez effectuer à l’aide de la valeur de registre PerformTicketSignature.
Deux jours plus tard, cependant, si vous regardez à nouveau le conseil, vous verrez que les conseils ci-dessus ont été modifiés pour se lire comme suit:
Questions fréquentes
Dois-je suivre des étapes supplémentaires lors du développement de cette mise à jour?
Dans un environnement simple avec un seul domaine, aucune action supplémentaire n’est requise.
Dans les environnements multi-domaines, une clé de registre est fournie pour permettre le déploiement du correctif sur tous les contrôleurs de domaine (DC) avant l’activation du nouveau comportement. Dans ces environnements complexes, nous suggérons les étapes suivantes…
Et si vous n’aviez qu’un seul domaine et que vous appliquiez le correctif immédiatement? Cela aurait-il un effet négatif? Vos actions devraient-elles être révoquées d’une manière ou d’une autre? Il n’y a rien à ce que Microsoft puisse répondre, mais cela soulève la question de savoir s’il n’est pas préférable d’attendre des conseils appropriés avant d’appliquer un correctif ou un correctif.
Avance rapide jusqu’à aujourd’hui. Maintenant, si vous recherchez des conseils auprès de Microsoft Advisory à ce sujet, vous trouverez quelque chose de complètement différent:
Questions fréquentes
Dois-je prendre d’autres mesures pour me protéger de cette vulnérabilité?
Oui. Les clients qui ont déjà installé les mises à jour de sécurité le 10 novembre 2020 doivent installer les mises à jour le 8 décembre 2020. Le 8 décembre 2020, les mises à jour de sécurité incluent des correctifs pour tous les problèmes connus qui ont été introduits à l’origine depuis la sortie de CVE-2020-17049 sur 10 novembre 2020. Cette mise à jour ajoute également la prise en charge de Windows Server 2008 SP2 et Windows Server 2008 R2.
Pour plus d’informations et pour plus d’informations sur la protection complète des serveurs de contrôleur de domaine, consultez Gestion du développement des modifications Kerberos S4U pour CVE-2020-17049.
Que faire si vous n’avez pas installé les mises à jour du 8 décembre pour une raison différente, par exemple en raison d’un problème de compatibilité d’application? Ou vous n’avez peut-être même pas les mises à jour du 10 novembre installées. Que devez-vous faire maintenant? Lisez l’autre article lié ici, je suppose. Et il y a beaucoup à digérer là-bas.
Ce qui est pire, à mon avis, c’est que le conseil utilise désormais la structure et la présentation «nouvelles et améliorées», que presque tous mes collègues travaillant dans la gestion informatique dans des environnements Windows Server disent détester. Principalement parce que la section “Résumé” a été supprimée de ces conseils, ce qui rend plus difficile pour ceux qui la lisent de bien l’assimiler.
Je suppose que Microsoft a supprimé ce résumé car ils ont du mal à savoir comment résoudre correctement certaines vulnérabilités. Par conséquent, ils ne veulent pas offrir un bref résumé de la question s’ils découvrent qu’ils ont tort plus tard. En d’autres termes, ils réparent les choses en déplacement. Ou peut-être qu’ils volent du siège de leur pantalon. Vous pouvez choisir la métaphore que vous préférez pour la décrire.
Alors quand il s’agit de gestion de code: patch ou veille?
Attendez. Oui.
Image en vedette: Shutterstock
Affichage des messages:
sept
Vous venez de recevoir un bulletin d’information de votre fournisseur sur une vulnérabilité de sécurité récemment découverte. Un patch est également disponible. Devez-vous l’appliquer maintenant ou attendre? Bien sûr, vous devez attendre. Explorons pourquoi. Dans la communauté de la sécurité informatique, la devise générale est quand il s’agit de la gestion du code, «corriger tôt, réparer souvent». Sur son visage, cela ressemble à une bonne logique. Après tout, le temps écoulé entre la découverte d’une vulnérabilité critique et la présence d’une ferme dans la nature diminue, et souvent presque nul, voire négatif. Ainsi, tant que vous avez la possibilité d’exécuter des tests sur un nouveau correctif, il est logique d’aller de l’avant et de l’implémenter rapidement dans votre environnement de production.
Patcher / Patcher: le patcher peut ruiner les choses
Ici, les choses vont mal avec la gestion des correctifs. Car les correctifs cassent souvent les choses. Je ne peux pas compter à quelle fréquence Microsoft a publié un correctif pour résoudre un problème et le correctif lui-même a causé des problèmes supplémentaires. C’est comme demander à un mécanicien de réparer le volant de votre voiture et finir par avoir des problèmes avec les freins à cause de quelque chose que le mécanicien a fait. À titre d’exemple récent, voyez ce qui est arrivé à la vulnérabilité de contournement de la fonction de sécurité Kerberos KDC CVE-2020-17049. Cette vulnérabilité comprenait un contournement des fonctionnalités de sécurité qui existaient dans la façon dont le service du centre de distribution de clés (KDC) pour Active Directory détermine si un ticket de service peut être utilisé pour l’externalisation via la délégation Kerberos contrainte (KCD). Pour qu’un acteur malveillant puisse exploiter cette vulnérabilité, un service de compromis configuré pour utiliser KCD pourrait violer un ticket de service invalide pour forcer KDC à l’accepter. La Conseil en sécurité Publié par Microsoft Security Resource Center (MSRC) a ensuite corrigé cette vulnérabilité avec des instructions pour modifier la façon dont KDC valide les tickets de service avec un correctif utilisant la valeur de registre suivante:
HKLM System CurrentControlSet Services Kdc PerformTicketSignature
Cela semble assez simple, n’est-ce pas? La vulnérabilité est découverte, la vulnérabilité a été corrigée.
Ensuite, cependant, ils constatent que leur résolution peut causer des problèmes dans certains environnements, tels que le fait que les tickets de service Kerberos et les tickets TGT ne peuvent pas être renouvelés pour les clients Kerberos non Windows, et d’autres problèmes désagréables – Dépannage. Donc, ils n’y recourraient qu’en dernier recours publier un article d’assistance à ce sujet. Et ainsi de suite. Vous souhaiterez peut-être attendre que Microsoft corrige le correctif (ou corrige le correctif ou autre) avant de l’exécuter en production.
Le guidage de correction peut être modifié
Il y a une autre raison pour laquelle il est généralement préférable d’attendre que de corriger ou de corriger immédiatement lorsqu’une vulnérabilité est signalée. Ceci est dû au fait Les conseils du fournisseur pour un correctif ou un correctif peuvent changer. Encore une fois, utilisons CVE-2020-17049 comme exemple. Le 10 novembre de l’année dernière, lorsque Microsoft a publié pour la première fois des conseils de sécurité pour cette vulnérabilité, ils incluaient les conseils suivants:
Questions fréquentes
Dois-je suivre des étapes supplémentaires lors du développement de cette mise à jour?
Oui, pour les environnements de domaine complexes, une clé de registre a été fournie pour permettre le développement dans tous les domaines avant que le correctif ne soit entièrement activé. Dans une forêt complexe, où les billets Kerberos peuvent voyager dans de nombreuses régions, nous suggérons les étapes suivantes:
- Définissez la clé de registre sur 0 (désactivé).
- Développement complet sur tous les DC (et DC en lecture seule) de votre forêt.
- Une fois le développement terminé, définissez la clé de registre sur 1. Une version ultérieure supprimera cette clé de registre et exigera des signatures de ticket.
Ensuite, les instructions initiales du MSRC détaille les étapes que vous devez effectuer à l’aide de la valeur de registre PerformTicketSignature.
Deux jours plus tard, cependant, si vous regardez à nouveau le conseil, vous verrez que les conseils ci-dessus ont été modifiés pour se lire comme suit:
Questions fréquentes
Dois-je suivre des étapes supplémentaires lors du développement de cette mise à jour?
Dans un environnement simple avec un seul domaine, aucune action supplémentaire n’est requise.
Dans les environnements multi-domaines, une clé de registre est fournie pour permettre le déploiement du correctif sur tous les contrôleurs de domaine (DC) avant l’activation du nouveau comportement. Dans ces environnements complexes, nous suggérons les étapes suivantes…
Et si vous n’aviez qu’un seul domaine et que vous appliquiez le correctif immédiatement? Cela aurait-il un effet négatif? Vos actions devraient-elles être révoquées d’une manière ou d’une autre? Il n’y a rien à ce que Microsoft puisse répondre, mais cela soulève la question de savoir s’il n’est pas préférable d’attendre des conseils appropriés avant d’appliquer un correctif ou un correctif.
Avance rapide jusqu’à aujourd’hui. Maintenant, si vous recherchez des conseils auprès de Microsoft Advisory à ce sujet, vous trouverez quelque chose de complètement différent:
Questions fréquentes
Dois-je prendre d’autres mesures pour me protéger de cette vulnérabilité?
Oui. Les clients qui ont déjà installé les mises à jour de sécurité le 10 novembre 2020 doivent installer les mises à jour le 8 décembre 2020. Le 8 décembre 2020, les mises à jour de sécurité incluent des correctifs pour tous les problèmes connus qui ont été introduits à l’origine depuis la sortie de CVE-2020-17049 sur 10 novembre 2020. Cette mise à jour ajoute également la prise en charge de Windows Server 2008 SP2 et Windows Server 2008 R2.
Pour plus d’informations et pour plus d’informations sur la protection complète des serveurs de contrôleur de domaine, consultez Gestion du développement des modifications Kerberos S4U pour CVE-2020-17049.
Que faire si vous n’avez pas installé les mises à jour du 8 décembre pour une raison différente, par exemple en raison d’un problème de compatibilité d’application? Ou vous n’avez peut-être même pas les mises à jour du 10 novembre installées. Que devez-vous faire maintenant? Lisez l’autre article lié ici, je suppose. Et il y a beaucoup à digérer là-bas.
Ce qui est pire, à mon avis, c’est que le conseil utilise désormais la structure et la présentation «nouvelles et améliorées», que presque tous mes collègues travaillant dans la gestion informatique dans des environnements Windows Server disent détester. Principalement parce que la section “Résumé” a été supprimée de ces conseils, ce qui rend plus difficile pour ceux qui la lisent de bien l’assimiler.
Je suppose que Microsoft a supprimé ce résumé car ils ont du mal à savoir comment résoudre correctement certaines vulnérabilités. Par conséquent, ils ne veulent pas offrir un bref résumé de la question s’ils découvrent qu’ils ont tort plus tard. En d’autres termes, ils réparent les choses en déplacement. Ou peut-être qu’ils volent du siège de leur pantalon. Vous pouvez choisir la métaphore que vous préférez pour la décrire.
Alors quand il s’agit de gestion de code: patch ou veille?
Attendez. Oui.
Image en vedette: Shutterstock
Affichage des messages:
sept
Post Views:
135
