Stratégie de compte des administrateurs de domaine (après audit PCI)

L'un de nos clients est une société PCI de niveau 1, et leurs auditeurs ont fait une suggestion à notre sujet en tant qu'administrateurs système et nos droits d'accès.

Nous administrons leur infrastructure entièrement Windows d'environ 700 postes de travail / 80 serveurs / 10 contrôleurs de domaine.

Ils suggèrent que nous passions à un système où nous avons trois comptes distincts:

DOMAIN.CO.UK\UserWS  
DOMAIN.CO.UK\UserSRV  
DOMAIN.CO.UK\UserDC  

• Où WS est le compte qui se connecte uniquement aux stations de travail, est un administrateur local sur les stations de travail
• Où SRV est le compte qui se connecte uniquement aux serveurs non DC, est Administrateur local sur les serveurs
• Où DC est le compte qui se connecte uniquement aux contrôleurs de domaine, en fait un compte d'administrateur de domaine

Des stratégies sont ensuite en place pour empêcher la connexion au mauvais type de système à partir du mauvais compte (ce qui inclut la suppression de la connexion interactive pour les comptes d'administrateur de domaine sur les machines non DC)

Cela permet d'éviter la situation où un poste de travail compromis peut exposer un jeton de connexion des administrateurs de domaine et le réutiliser contre le contrôleur de domaine.

Cela semble non seulement être une politique très intrusive pour nos opérations quotidiennes, mais aussi une quantité considérable de travail, pour répondre à ce qui est une attaque / exploit relativement peu probable (c'est ce que je comprends de toute façon, peut-être que je comprends mal la faisabilité de cet exploit) .

Je suis intéressé d'entendre les opinions d'autres administrateurs, en particulier ceux ici qui ont été impliqués dans une société enregistrée PCI et vous avez des expériences avec des recommandations similaires. Quelles sont vos politiques concernant les ouvertures de session d'administrateur.

Pour mémoire, nous avons actuellement un compte d'utilisateur de domaine que nous utilisons normalement, avec un compte d'administrateur de domaine que nous élevons également lorsque nous avons besoin des droits supplémentaires. En toute honnêteté, nous sommes tous un peu paresseux et utilisons souvent le compte d'administrateur de domaine pour les opérations quotidiennes, bien que cela soit techniquement contraire aux politiques de notre entreprise (je suis sûr que vous comprenez!).

Je suis chez un fournisseur PCI de niveau 1. Nous avons quelque chose comme ça en place, avec quelques différences.

Les auditeurs tentent en fait de décrire un problème très réel, mais font un travail incroyablement pauvre en expliquant les implications et l'analyse des besoins.

Il est désormais plus efficace de compromettre un système en utilisant un hachage d'un mot de passe ou un jeton existant. En clair, votre attaquant n'a plus besoin de votre nom d'utilisateur et de votre mot de passe. Il existe désormais des moyens plus simples d'attaquer un système. En aucun cas, vous ne devez supposer ou conclure que ce type d'attaque est peu probable. Les attaques de hachage sont désormais le vecteur d'attaque de facto .

Les attaques de hachage sont en fait pires avec les comptes de cartes à puce, ce qui est ironique, car la plupart des gens s'attendent à ce que la mise en œuvre de cartes à puce augmente la sécurité d'un système.

Si un compte est compromis en raison d'une attaque passe-le-hachage, la réponse habituelle consiste à modifier le mot de passe du compte. Cela modifie le hachage utilisé pour l'authentification. En outre, une expiration / modification normale du mot de passe peut faire surface à une incursion, car le hachage de l'attaquant commencerait à échouer. Cependant, avec les cartes à puce, le mot de passe est «géré par le système» (l'utilisateur n'entre jamais le mot de passe pour s'authentifier), donc le hachage ne change jamais. Cela signifie qu'avec les comptes de carte à puce, une incursion peut passer inaperçue beaucoup plus longtemps qu'avec un compte qui utilise un mot de passe.

Voici les atténuations que je considérerais:

• Pour les comptes activés par carte à puce, que de nombreuses grandes entreprises utilisent pour les comptes hautement privilégiés, modifiez le mot de passe du compte à intervalles réguliers. Cela change le hachage. Vous pouvez également modifier le hachage en désactivant la carte à puce en activant le compte, puis en réactivant la carte à puce en l'activant. Microsoft le fait toutes les 24 heures, mais vous devez évaluer l'impact potentiel que cela peut avoir sur votre environnement et établir un calendrier sain afin de ne pas créer de problèmes supplémentaires.

• Pour les postes de travail, je n'utiliserais pas du tout les comptes de domaine à des fins d'administration, si possible. Nous avons un compte local qui peut être utilisé pour élever pour les opérations de type UAC. Cela satisfait 99,9% de la plupart des exigences d'élévation. Les postes de travail ont tendance à être des vecteurs d'attaque à chaud, en raison du manque de contrôle des changements enrégimentés et de l'existence de Java JRE et Flash.

  Cette approche fonctionne pour nous car nous avons un mécanisme formel pour gérer et appliquer le mot de passe pour les comptes locaux et que le mot de passe est unique sur chaque système, et qu'il existe une méthode sécurisée pour que quelqu'un demande le mot de passe. Il existe également des applications commerciales qui peuvent remplir cette fonction.

• Si vous ne pouvez pas fournir une solution de compte local pour les postes de travail, alors oui, un compte de domaine distinct doit être utilisé pour l'accès administratif aux postes de travail, et ce compte ne doit pas être utilisé pour l'accès administratif aux serveurs. Une autre option peut consister à utiliser des outils de gestion de support distants et non interactifs qui utilisent LocalSystem pour effectuer des activités et un mécanisme d'authentification distinct de Windows.

• Pour les comptes privilégiés les plus élevés (administrateur d'entreprise, administrateur de domaine, etc.), utilisez uniquement un serveur de saut. Ce serveur serait soumis à la sécurité, au contrôle des modifications et à l'audit les plus restrictifs. Pour tous les autres types de fonctions de type administratif, envisagez d'avoir un compte administratif distinct. Le serveur de saut doit être redémarré tous les jours pour redémarrer les jetons de processus du processus LSA.

• N'effectuez pas de tâches administratives à partir de votre poste de travail. Utilisez un serveur renforcé ou un serveur de saut.

• Pensez à réinitialiser facilement les machines virtuelles comme boîtes de saut, qui peuvent être réinitialisées pour vider la mémoire après chaque session.

Lectures complémentaires:

https://blogs.technet.com/b/security/archive/2012/12/06/new-guidance-to-mitigate-determ-adversaries-favorite-attack-pass-the-hash.aspx

Rapport Microsoft Security Intelligence, Volume 13, janvier - juin 2012
http://www.microsoft.com/security/sir/archive/default.aspx

Lisez la section: "Se défendre contre les attaques Pass-the-Hash".

Vaincre les attaques redoutées de passe-hachage
https://www.infoworld.com/d/security/defeat-dreaded-pass-the-hash-attacks-179753