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


L'un de nos clients est une société PCI de premier plan et leurs auditeurs ont formulé une suggestion à notre égard en tant qu'administrateurs système et de nos droits d'accès.

Nous administrons leur infrastructure entièrement basée sur 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  
  • WS est le compte qui se connecte uniquement aux postes de travail, est un administrateur local sur les postes de travail
  • VRS est le compte qui se connecte uniquement aux serveurs autres que DC, est l'administrateur local sur les serveurs
  • DC est le compte qui se connecte uniquement aux contrôleurs de domaine, effectivement un compte d'administrateur de domaine

Des stratégies sont alors 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 des ordinateurs autres que le contrôleur de domaine).

Cela permet d'éviter qu'un poste de travail compromis puisse exposer un jeton de connexion d'administrateur de domaine et le réutiliser sur le contrôleur de domaine.

Cela semble être non seulement une politique très intrusive pour nos opérations quotidiennes, mais également un travail considérable, pour traiter ce qui est une attaque / exploit relativement improbable (c'est ce que je comprends de toute façon, peut-être ai-je mal compris la faisabilité de cet exploit) .

Je suis intéressé par le point de vue d’autres administrateurs, en particulier ceux qui ont été impliqués dans une société enregistrée PCI et vous-même, vous avez des recommandations similaires. Quelles sont vos politiques en matière de connexion 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 n'utilisons souvent que le compte d'administrateur de domaine pour les opérations quotidiennes, bien que cela soit techniquement contraire aux règles de notre société (je suis sûr que vous comprenez!).


14
2018-04-18 10:19


origine


Etant un niveau 1, je suis en fait surpris que leur réseau prenant en charge les paiements CC se trouve sur le même réseau que celui sur lequel cette infrastructure Windows est activée et ne soit pas segmenté par lui-même. Facilite la conformité. - TheCleaner
Cela aurait du sens, non, mais malheureusement pas. Cependant, ils ne font pas partie du domaine utilisateur. Nos comptes d’administrateur ne peuvent donc pas gérer ces systèmes. Techniquement, nous n’avons pas accès aux machines qui traitent les paiements. - Patrick
Je ne suis pas l'expert du PCI ici ... mais j'en ai vu quelques-uns. Cependant, je ne me rappelle pas que cela soit une exigence. Suggérer ou obliger est une grande différence. Je travaillerais plus fort pour faire ce que vous dites dans votre dernier paragraphe, en mettant en place des mesures pour aider à faire en sorte que ce soit une réalité. - TheCleaner
Cela ressemble à une expérience similaire à serverfault.com/questions/224467/… - En gros, c'est un bon plan, qui peut prévenir certaines attaques désagréables. - Iain Hallam


Réponses:


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

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

Il est maintenant plus efficace de compromettre un système en utilisant un hash 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 maintenant des moyens plus faciles d'attaquer un système. En aucun cas, vous ne devez supposer ou conclure que ce type d’attaque est improbable. Les attaques de hachage sont maintenant le vecteur d'attaque de facto.

Les attaques par hachage sont en réalité pires avec les comptes de carte à puce, ce qui est ironique, car la plupart des gens s’attendent à ce que l’implémentation de cartes à puce augmente la sécurité d’un système.

Si un compte est compromis en raison d'une attaque par pass-the-hash, la réponse habituelle consiste à changer le mot de passe du compte. Cela modifie le hachage utilisé pour s'authentifier. En outre, une expiration / modification de mot de passe normale peut faire surface avec une incursion, du fait que 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 ne l'utilise jamais pour s'authentifier), de sorte que le hachage ne change jamais. Cela signifie qu'avec une carte à puce, une incursion peut passer inaperçue beaucoup plus longtemps qu'avec un compte utilisant un mot de passe.

Voici les mesures d'atténuation que je considérerais:

  • Pour les comptes activés par carte à puce, que beaucoup de grandes entreprises utilisent pour comptes privilégiés, changez le mot de passe du compte sur un compte intervalle fréquent. Cela change le hash. Vous pouvez aussi changer le hachage par non-carte à puce permettant le compte, puis re-carte à puce permettant il. Microsoft le fait toutes les 24 heures, mais vous devez évaluer la impact potentiel que cela peut avoir sur votre environnement, et établissez une programme sain pour ne pas créer de problèmes supplémentaires.

  • Pour les postes de travail, je n’utiliserais pas les comptes de domaine à des fins administratives, si possible. Nous avons un compte local qui peut être utilisé pour élever pour UAC opérations de type. Ceci satisfait 99,9% de la plupart des élévations exigences. Les postes de travail ont tendance à être des vecteurs d’attaque chauds, en raison de la absence de contrôle du changement réglementé et existence de Java JRE et de Flash.

    Cette approche fonctionne pour nous en raison à 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 permettant à quelqu'un de demander le mot de passe. Il existe également des applications commerciales qui peuvent effectuer cette fonction.

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

  • Pour les comptes les plus privilégiés (administrateur d'entreprise, administrateur de domaine, etc), utilisez uniquement un serveur de saut. Ce serveur serait soumis à la sécurité la plus restrictive, contrôle des modifications, et audit. Pour tout autre type de fonction de type administratif, envisager d'avoir un compte administratif séparé. Le serveur de saut doit être redémarré redémarre quotidiennement pour effacer les jetons de processus du processus LSA.

  • N'effectuez aucune tâche administrative à partir de votre poste de travail. Utilisez un serveur renforcé ou un serveur de saut.

  • Pensez à utiliser une réinitialisation aisée des ordinateurs virtuels comme boîtes de saut, qui peuvent être réinitialiser pour effacer la mémoire après chaque session.

Lectures complémentaires:

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

Rapport de Microsoft sur les activités de renseignement de sécurité, volume 13, janvier à juin 2012
http://www.microsoft.com/security/sir/archive/default.aspx 

Lisez la section "Défense contre les attaques par passe-le-hachage".

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


18
2018-04-22 14:04



+1 bonne lecture, merci - Dan