Eso suena super hombre incompleto. La política es correcta ... Suena como una aplicación que me gustaría implementar y probar mis habilidades de pentesting. :)
Iría con la política y presionaría a los desarrolladores para que proporcionen una guía de protección estándar a los derechos mínimos posibles para evitar vulnerabilidades a su host y, en última instancia, a toda su red si el host está comprometido. Las vulnerabilidades débiles en una aplicación web podrían permitir a un pirata informático generar shell para ejecutar comandos en su host, obtener una posición en su red y comenzar ataques dentro de su red ...
Probablemente lo probaría en un servidor de laboratorio de desarrollo ... seguir ajustando y fortaleciendo los derechos básicos de los usuarios. Luego siga endureciendo hasta que se rompa la aplicación. Una vez endurecido, solo debe usar una cuenta de administrador que no sea de dominio en el cuadro. Lo más importante es que con un administrador que no sea de dominio, debe ser una palabra muy compleja, sin diccionario, y una contraseña de al menos 14 caracteres que solo se use para esa casilla. Evitar el reciclaje de credenciales.
Luego, cuando inicie sesión como administrador después de que se hayan eliminado todos los credenciales del dominio y se haya endurecido la casilla, si la cuenta de administrador de la caja se obtiene a través de ataques de escalamiento de privilegios, se reducirá la amenaza creciente de la superficie del ataque. El atacante tiene que iniciar la recuperación en el suelo-0 en el pivote porque las credenciales de los administradores de dominio no residirán en el sistema de herramientas como mimikatz o fgdump. Luego, tienen que enumerar y comenzar desde cero, lo que le da tiempo a su equipo de operaciones de seguridad para responder. No es mucho tiempo, pero es suficiente para detectar los comportamientos anormales de las cuentas de servicio.
Si solo está buscando un conjunto básico de instrucciones sobre cómo iniciar el trabajo de refuerzo básico en Windows. Es posible que desee realizar una inmersión profunda y experimentar con un cuadro de desarrollo aislado para Windows hasta que tenga su endurecimiento hacia abajo. Simplemente configure IIS con un "shell web" básico y bloquéelo hasta que su shell web sea casi inútil. Puede google "ASP Webshell" y le dará algo de código para probar en IIS. A continuación, elimine el webshell del sistema por completo! < - ¡muy importante por razones obvias!
Sigue afinando tu endurecimiento hasta que estés listo para ejecutar la configuración de producción y asegúrate de tomar muchas notas. Estoy seguro de que hay guías y MSDN tiene muchos recursos para ayudar.
Visión general básica de lo que estará haciendo ... esto se debe principalmente a la memoria de elementos básicos esenciales, consulte las guías de endurecimiento de CIS para obtener recomendaciones de políticas más detalladas.
- Crear una cuenta funcional
- Eliminar los derechos de usuario de esa cuenta
- Preferiblemente a bordo de esa cuenta en una solución de contraseña como CyberArk
- Cree un grupo de seguridad para los derechos de "Ejecutar como un servicio"
- Abra SecPol y elimine todos los derechos para Ejecutar como un Servicio, excepto su nuevo grupo de seguridad
- Agregar esa cuenta funcional a ese grupo de seguridad
- Restrinja ese grupo de seguridad de muchas funciones básicas del usuario que no sean los requisitos mínimos
- Configure IIS y los servicios del grupo de aplicaciones para que se ejecuten en estas cuentas restringidas y nunca confíe en que la aplicación se ejecute con "servicios de red" porque un atacante obtendrá inmediatamente los privilegios de nivel "Sistema" si el ataque es exitoso.
- Asegúrese de que este sistema no sea de confianza para los privilegios de AD.
- Refuerce el sistema de archivos de esa cuenta de servicio y solo permita que acceda a la cantidad mínima de datos necesarios para operar. (Bibliotecas .Net según sea necesario, registro de IIS, etc.)