Après l’incident CrowdStrike, la même discussion : produit de sécurité sur les contrôleurs de domaine ?
À mon avis, les entreprises qui souhaitent atténuer un risque comme celui-ci (où la même mise à jour a été poussée vers tous les agents, même ceux pour lesquels un anneau de déploiement plus lent avait été choisi) doivent simplement répartir leur parc entre plusieurs fournisseurs.
Le fournisseur EDR A et le fournisseur EDR B sont déployés à 50/50, avec une plateforme de reporting pour assurer la visibilité sur les deux, ou en centralisant les événements dans un seul SIEM.
C’est un exemple pour l’EDR — bien entendu, si vous déployez un type d’agent qui s’exécute en tant que SYSTEM ou administrateur, la même approche doit être adoptée.
Les serveurs effectuant des sauvegardes ne devraient pouvoir communiquer avec Internet d’aucune manière ; toutes leurs mises à jour d’agents/OS devraient être mises en attente par un serveur intermédiaire (pensez au cache WSUS mais aussi pour votre EDR). Si ces serveurs fonctionnent sous Windows, ils devraient être joints à un domaine « forêt rouge », qui n’est pas le même que votre AD de production. Ainsi, un attaquant dans l’AD de production n’a aucun privilège sur le domaine dans lequel se trouvent les serveurs de sauvegarde. Des mesures d’atténuation similaires doivent être pensées pour les hyperviseurs et la manière dont les administrateurs s’y authentifient.
Concernant les clés de récupération Bitlocker, l’ADDS ne devrait pas être le seul endroit où elles sont stockées. Les exporter dans un système de gestion des secrets via un script quotidien, ou utiliser un RMM qui capture les clés de récupération Bitlocker, sont des moyens de garantir leur disponibilité en cas de sinistre AD.