Política de cuenta de administradores de dominio (después de la auditoría PCI)

Uno de nuestros clientes es una empresa PCI de nivel 1, y sus auditores nos han hecho una sugerencia con respecto a nosotros como Administradores del sistema y nuestros derechos de acceso.

Administramos su infraestructura completamente basada en Windows de aproximadamente 700 computadoras de escritorio / 80 servidores / 10 controladores de dominio.

Sugieren que nos traslademos a un sistema donde tenemos tres cuentas separadas:

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

• Donde WS es la cuenta que inicia sesión solo en WorkStations, es un administrador local en WorkStations
• Donde SRV es la cuenta que inicia sesión solo en servidores que no son DC, es administrador local en servidores
• Donde DC es la cuenta que inicia sesión solo en controladores de dominio, efectivamente una cuenta de administrador de dominio

Luego se implementan políticas para evitar el inicio de sesión en el tipo de sistema incorrecto desde la cuenta incorrecta (que incluye eliminar el inicio de sesión interactivo para cuentas de administrador de dominio en máquinas que no son DC)

Esto es para evitar la situación en la que una estación de trabajo comprometida puede exponer un token de inicio de sesión de Administradores de dominio y reutilizarlo en el Controlador de dominio.

Esto parece no solo ser una política muy intrusiva para nuestras operaciones diarias, sino también una cantidad considerable de trabajo, para abordar lo que es un ataque / explotación relativamente poco probable (de todos modos, esto es lo que entiendo, tal vez no entiendo la viabilidad de esta explotación) .

Estoy interesado en escuchar las opiniones de otros administradores, especialmente aquellos aquí que han estado involucrados en una empresa registrada en PCI y que tiene experiencias con recomendaciones similares. ¿Cuáles son sus políticas con respecto a los inicios de sesión de administrador?

Para el registro, actualmente tenemos una cuenta de usuario de dominio que usamos normalmente, con una cuenta de administrador de dominio que también elevamos cuando necesitamos los derechos adicionales. Honestamente, todos somos un poco vagos y, a menudo, solo usamos la cuenta de administrador de dominio para las operaciones diarias, aunque esto es técnicamente contrario a las políticas de nuestra empresa (¡estoy seguro de que lo comprende!).

Estoy en un proveedor PCI de nivel 1. Tenemos algo como esto en su lugar, con algunas diferencias.

Los auditores en realidad están intentando describir un problema muy real, pero están haciendo un trabajo increíblemente pobre explicando las implicaciones y el análisis de necesidades.

Ahora es más efectivo comprometer un sistema mediante el uso de un hash de contraseña o un token existente. En pocas palabras, su atacante ya no necesita su nombre de usuario y contraseña. Ahora hay formas más fáciles de atacar un sistema. Bajo ninguna circunstancia debe suponer o concluir que este tipo de ataque es poco probable. Los ataques de hash ahora son el vector de ataque de facto .

Los ataques de hash en realidad son peores con las cuentas de tarjetas inteligentes, lo cual es irónico, porque la mayoría de la gente espera que la implementación de tarjetas inteligentes aumente la seguridad de un sistema.

Si una cuenta se ve comprometida debido a un ataque de pasar el hash, la respuesta habitual es cambiar la contraseña de la cuenta. Esto cambia el hash que se usa para autenticar. Además, un vencimiento / cambio de contraseña normal puede hacer surgir una incursión, debido a que el hash del atacante comenzaría a fallar. Sin embargo, con las tarjetas inteligentes, la contraseña está 'administrada por el sistema' (el usuario nunca ingresa la contraseña para autenticarse), por lo que el hash nunca cambia. Eso significa que con las cuentas de tarjeta inteligente, una incursión puede pasar desapercibida durante mucho más tiempo que con una cuenta que usa una contraseña.

Aquí hay mitigaciones que consideraría:

• Para las cuentas habilitadas con tarjeta inteligente, que muchas grandes empresas usan para cuentas con privilegios elevados, cambie la contraseña de la cuenta en un intervalo frecuente. Esto cambia el hash. También puede cambiar el hash desarmando la tarjeta inteligente habilitando la cuenta, luego volviendo a habilitar la tarjeta inteligente. Microsoft hace esto cada 24 horas, pero debe evaluar el impacto potencial que esto puede causar en su entorno y establecer un cronograma sensato para que no cree problemas adicionales.

• Para estaciones de trabajo, no usaría cuentas de dominio con fines administrativos, si es posible. Tenemos una cuenta local que puede usarse para elevar las operaciones de tipo UAC. Esto satisface el 99.9% de la mayoría de los requisitos de elevación. Las estaciones de trabajo tienden a ser vectores de ataque en caliente, debido a la falta de control de cambio reglamentado y la existencia de Java JRE y Flash.

  Este enfoque funciona para nosotros debido a que tenemos un mecanismo formal para administrar y hacer cumplir la contraseña de las cuentas locales y que la contraseña es única en cada sistema, y ​​que existe un método seguro para que alguien solicite la contraseña. También hay aplicaciones comerciales que pueden realizar esta función.

• Si no puede proporcionar una solución de cuenta local para estaciones de trabajo, entonces sí, se debe usar una cuenta de dominio separada para el acceso administrativo a las estaciones de trabajo, y esa cuenta no se debe usar para el acceso administrativo a los servidores. Otra opción puede ser usar herramientas de administración de soporte remotas, no interactivas, que usan LocalSystem para realizar actividades, y un mecanismo de autenticación que es independiente de Windows.

• Para las cuentas con los privilegios más altos (Administrador de empresa, Administrador de dominio, etc.), use solo un servidor de salto. Este servidor estaría sujeto a la seguridad, el control de cambios y la auditoría más restrictivos. Para todos los demás tipos de funciones de tipo administrativo, considere tener una cuenta administrativa separada. El servidor de salto debe reiniciarse diariamente para reiniciar los tokens del proceso del proceso LSA.

• No realice tareas administrativas desde su estación de trabajo. Utilice un servidor reforzado o un servidor de salto.

• Considere usar máquinas virtuales de restablecimiento fácil como sus cuadros de salto, que se pueden restablecer para borrar la memoria después de cada sesión.

Otras lecturas:

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

Informe de inteligencia de seguridad de Microsoft, volumen 13, enero - junio de 2012
http://www.microsoft.com/security/sir/archive/default.aspx

Lea la sección: "Defensa contra ataques Pass-the-Hash".

Derrota los temidos ataques de pasar el hash
https://www.infoworld.com/d/security/defeat-dreaded-pass-the-hash-attacks-179753