Planeación de compromiso

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2 y Windows Server 2012.

Ley número uno: Nadie cree que nada malo le puede pasar hasta que ocurre. - 10 leyes inmutables sobre la administración de la seguridad

Los planes de recuperación ante desastres de muchas organizaciones se centran en la recuperación ante desastres o errores regionales que provocan la pérdida de servicios informáticos. Sin embargo, al trabajar con clientes en riesgo, a menudo encontramos que la recuperación desde riesgos intencionales no está presente en sus planes de recuperación ante desastres. Esto es especialmente cierto cuando el riesgo da lugar a robos de propiedad intelectual o destrucción intencionada que aprovecha los límites lógicos (como la destrucción de todos los dominios de Active Directory o todos los servidores) en lugar de los límites físicos (como la destrucción de un centro de datos). Aunque una organización puede tener planes de respuesta a incidentes que definen las actividades iniciales que se deben realizar cuando se detecta un riesgo, estos planes suelen omitir los pasos para recuperarse de un riesgo que afecte a toda la infraestructura informática.

Como Active Directory proporciona funcionalidades enriquecidas de administración de identidades y acceso para usuarios, servidores, estaciones de trabajo y aplicaciones, invariablemente es un objetivo de los atacantes. Si un atacante obtiene acceso con privilegios elevados a un dominio o un controlador de dominio de Active Directory, ese acceso se puede aprovechar para acceder, controlar o incluso destruir todo el bosque de Active Directory.

En este documento, se han analizado algunos de los ataques más comunes contra Windows y Active Directory, y las contramedidas que puede implementar para reducir la superficie expuesta a ataques, pero la única manera segura de recuperarse en caso de que se produzca un riesgo completo de Active Directory es estar preparado para el riesgo antes de que ocurra. Esta sección se centra menos en los detalles técnicos de implementación que las secciones anteriores de este documento, y más en las recomendaciones generales que puede usar para crear un enfoque integral y holístico para proteger y administrar los recursos críticos empresariales y de TI de la organización.

Tanto si la infraestructura nunca ha sido atacada, como si ha resistido a intentos de vulneración o ha sucumbido a los ataques y se ha puesto en peligro por completo, debe asumir la inevitable realidad de que será atacada una y otra vez. No es posible evitar los ataques, pero puede ser posible evitar vulneraciones significativas o un riesgo completo. Cada organización debe evaluar estrechamente sus programas de administración de riesgos existentes y realizar los ajustes necesarios para ayudar a reducir su nivel general de vulnerabilidad mediante la realización de inversiones equilibradas en prevención, detección, contención y recuperación.

Para crear defensas eficaces mientras se siguen proporcionando servicios a los usuarios y empresas que dependen de la infraestructura y las aplicaciones, es posible que tenga que considerar nuevas formas de prevenir, detectar y contener los riesgos en su entorno y, a continuación, recuperarse del riesgo. Es posible que los enfoques y recomendaciones de este documento no le ayuden a reparar una instalación de Active Directory en peligro, pero puede ayudarle a proteger la siguiente.

Las recomendaciones para recuperar un bosque de Active Directory se presentan en Recuperación del bosque de AD: pasos para restaurar el bosque. Es posible que pueda evitar que el nuevo entorno se ponga en peligro por completo, pero incluso si no es posible, tendrá herramientas para recuperarse y retomar el control del entorno.

Replanteamiento del enfoque

Ley número ocho: La dificultad de defender una red es directamente proporcional a su complejidad. - 10 leyes inmutables sobre la administración de la seguridad

Es comúnmente aceptado que si un atacante ha obtenido acceso de sistema, administrador, raíz o equivalente a un equipo, independientemente del sistema operativo, ese equipo ya no se puede considerar de confianza, con independencia de cuántos esfuerzos se realicen para "limpiarlo". Active Directory no es diferente. Si un atacante ha obtenido acceso con privilegios a un controlador de dominio o a una cuenta con privilegios elevados en Active Directory, a menos que tenga un registro de cada modificación que el atacante realice o una copia de seguridad correcta conocida, nunca podrá restaurar el directorio a un estado de confianza total.

Cuando un atacante pone en peligro y manipula una estación de trabajo o un servidor miembro, el equipo ya no es de confianza, pero las estaciones de trabajo y los servidores vecinos que no se hayan puesto en riesgo pueden seguir siendo de confianza. El peligro que sufre un equipo no implica que todos los equipos estén en riesgo.

Sin embargo, en un dominio de Active Directory, todos los controladores de dominio hospedan réplicas de la misma base de datos de AD DS. Si un único controlador de dominio está en riesgo y un atacante modifica la base de datos de AD DS, esas modificaciones se replican en todos los demás controladores de dominio del dominio y, en función de la partición en la que se realicen las modificaciones, en el bosque. Incluso si vuelve a instalar todos los controladores de dominio del bosque, simplemente se vuelven a instalar los hosts en los que reside la base de datos de AD DS. Las modificaciones malintencionadas en Active Directory se replicarán en los controladores de dominio recién instalados tan fácilmente como en los controladores de dominio que han estado en ejecución durante años.

En la evaluación de entornos en peligro, normalmente encontramos que lo que se creía que era el primer "evento" de vulneración se desencadenó realmente después de semanas, meses o incluso años después de que los atacantes hubieran puesto en peligro inicialmente el entorno. Normalmente, los atacantes obtuvieron las credenciales de las cuentas con privilegios elevados mucho antes de detectar una vulneración y aprovecharon esas cuentas para poner en peligro el directorio, los controladores de dominio, los servidores miembros, las estaciones de trabajo e incluso los sistemas no Windows conectados.

Estos resultados son coherentes con varios resultados del Informe de investigaciones de vulneraciones de datos de Verizon del año 2012, que indica que:

• El 98 % de las vulneraciones de datos proceden de agentes externos.

• El 85 % de las vulneraciones de datos tardaron semanas o más en detectarse.

• Un tercero detectó el 92 % de los incidentes.

• El 97 % de las vulneraciones eran evitables mediante controles simples o intermedios.

Un peligro en el grado descrito anteriormente es efectivamente irreversible y el consejo estándar para "aplanar y volver a crear" todos los sistemas en peligro simplemente no es factible ni incluso posible si Active Directory se ha puesto en peligro o destruido. Incluso la restauración a un estado correcto conocido no elimina los defectos que han permitido inicialmente que el entorno se ponga en peligro.

Aunque debe defender todas las facetas de la infraestructura, un atacante solo necesita encontrar suficientes defectos en las defensas para llegar a su objetivo deseado. Si su entorno es relativamente sencillo y prístino, e históricamente bien administrado, la implementación de las recomendaciones proporcionadas anteriormente en este documento puede ser una propuesta sencilla.

Sin embargo, hemos visto que cuanto más antiguo, más grande y más complejo es el entorno, es más probable que las recomendaciones de este documento sean inviables o incluso imposibles de implementar. Es mucho más difícil proteger una infraestructura después de un ataque que comenzar de nuevo y construir un entorno que sea resistente a ataques y riesgos. Pero como se ha indicado antes, no es sencillo volver a crear un bosque de Active Directory completo. Por estos motivos, se recomienda un enfoque más centrado y dirigido para proteger los bosques de Active Directory.

En lugar de centrarse en todas las cosas que están "rotas" y tratar de corregirlas, considere un enfoque en el que se asignen prioridades en función de lo que es más importante para el negocio y la infraestructura. En lugar de intentar corregir un entorno lleno de sistemas y aplicaciones obsoletos y configurados incorrectamente, considere la posibilidad de crear un nuevo entorno pequeño y seguro en el que pueda portar de forma segura la información, los sistemas y los usuarios más críticos para su empresa.

En esta sección, se describe un enfoque mediante el cual se puede crear un bosque de AD DS prístino que actúe como "balsa salvavidas" o "refugio seguro" para su infraestructura empresarial principal. Un bosque prístino es simplemente un bosque de Active Directory recién instalado, normalmente de tamaño y ámbito limitados, y que se ha creado mediante sistemas operativos y aplicaciones actuales, y con los principios descritos en Reducción de la superficie expuesta a ataques de Active Directory.

Al implementar las opciones de configuración recomendadas en un bosque recién creado, puede crear una instalación de AD DS desde cero con configuraciones y procedimientos seguros, y puede reducir los desafíos que acompañan a la compatibilidad con sistemas y aplicaciones heredados. Aunque las instrucciones detalladas para el diseño y la implementación de una instalación prístina de AD DS están fuera del ámbito de este documento, debe seguir algunos principios generales e instrucciones para crear un "refugio seguro" en el que puede hospedar sus activos más críticos. Estas directrices son las siguientes:

1. Identificar los principios para separar y proteger los recursos críticos.

2. Definir un plan de migración limitado basado en riesgos.

3. Aprovechar las migraciones "no migratorias" cuando sea necesario.

4. Implementar la "destrucción creativa".

5. Aislar las aplicaciones y los sistemas heredados.

6. Simplificar la seguridad para los usuarios finales.

Identificación de los principios para separar y proteger los recursos críticos

Las características del entorno prístino que se va a crear para hospedar los activos críticos pueden variar mucho. Por ejemplo, puede optar por crear un bosque prístino en el que migre solo los usuarios VIP y los datos confidenciales a los que solo puedan acceder esos usuarios. Puede crear un bosque prístino en el que migre no solo los usuarios VIP, sino que se implemente como bosque administrativo, implementando los principios descritos en Reducción de la superficie expuesta a ataques de Active Directory para crear cuentas administrativas seguras y hosts que se pueden usar para administrar los bosques heredados desde el bosque prístino. Puede implementar un bosque "diseñado específicamente" que contenga las cuentas VIP, las cuentas con privilegios y los sistemas que requieran seguridad adicional, como los servidores que ejecutan los Servicios de certificados de Active Directory (AD CS) con el único objetivo de separarlos de bosques menos seguros. Por último, puede implementar un bosque prístino que se convierta en la ubicación de facto para todos los nuevos usuarios, sistemas, aplicaciones y datos, lo que le permite retirar finalmente el bosque heredado mediante la deserción.

Independientemente de si el bosque prístino contiene unos pocos usuarios y sistemas o si constituye la base para una migración más agresiva, debe seguir estos principios en el planeamiento:

1. Dé por supuesto que los bosques heredados se han puesto en peligro.

2. No configure un entorno prístino para que confíe en un bosque heredado, aunque puede configurar un entorno heredado para que confíe en un bosque prístino.

3. No migre cuentas de usuario ni grupos de un bosque heredado a un entorno prístino si existe la posibilidad de que las pertenencias a grupos, el historial de SID u otros atributos de las cuentas se hayan modificado de forma malintencionada. En su lugar, use enfoques "no migratorios" para rellenar un bosque prístino. (Los enfoques no migratorios se describirán más adelante en esta sección).

4. No migre equipos de bosques heredados a bosques prístinos. Implemente servidores recién instalados en el bosque prístino, instale las aplicaciones en los servidores recién instalados y migre los datos de las aplicaciones a los sistemas recién instalados. En el caso de los servidores de archivos, copie los datos en servidores recién instalados, establezca las ACL mediante el uso de usuarios y grupos del nuevo bosque y, a continuación, cree los servidores de impresión de forma similar.

5. No permita la instalación de aplicaciones ni sistemas operativos heredados en el bosque prístino. Si una aplicación no se puede actualizar y volver a instalar, déjela en el bosque heredado y considere la posibilidad de usar la destrucción creativa para sustituir la funcionalidad de la aplicación.

Definición de un plan de migración limitado basado en riesgos

La creación de un plan de migración limitado basado en riesgos simplemente significa que, al decidir qué usuarios, aplicaciones y datos se van a migrar al bosque prístino, debe identificar los objetivos de migración en función del grado de riesgo al que se expone la organización si uno de los usuarios o sistemas está en peligro. Los usuarios VIP cuyas cuentas tienen más probabilidades de ser objetivo de atacantes se deben hospedar en el bosque prístino. Las aplicaciones que proporcionan funciones empresariales vitales se deben instalar en servidores recién creados en el bosque prístino y los datos altamente confidenciales se deben mover a servidores protegidos del bosque prístino.

Si todavía no tiene una imagen clara de los usuarios, sistemas, aplicaciones y datos más críticos para la empresa del entorno de Active Directory, colabore con las unidades de negocio para identificarlos. Se debe identificar cualquier aplicación necesaria para que la empresa funcione, al igual que los servidores en los que se ejecutan las aplicaciones críticas y se almacenan los datos críticos. Al identificar los usuarios y recursos necesarios para que la organización siga funcionando, se crea una colección de recursos con prioridad natural en la que centrar sus esfuerzos.

Aprovechamiento de las migraciones "no migratorias"

Tanto si sabe que el entorno se ha puesto en peligro, sospecha que se ha puesto en peligro o simplemente prefiere no migrar datos y objetos heredados de una instalación heredada de Active Directory a una nueva, tenga en cuenta los enfoques de migración que técnicamente no "migran" objetos.

Cuentas de usuario

En una migración tradicional de Active Directory de un bosque a otro, se usa el atributo SIDHistory (historial de SID) de los objetos de usuario para almacenar el SID de los usuarios y los SID de grupos de los que los usuarios eran miembros en el bosque heredado. Si las cuentas de usuario se migran a un bosque nuevo y acceden a los recursos del bosque heredado, se usan los SID del historial de SID para crear un token de acceso que permita a los usuarios acceder a los recursos a los que tenían acceso antes de migrar las cuentas.

Sin embargo, el mantenimiento del historial de SID ha demostrado ser problemático en algunos entornos, ya que rellenar los tokens de acceso de los usuarios con SID actuales e históricos puede dar lugar a una saturación de tokens. La saturación de tokens es un problema en el que el número de SID que se deben almacenar en el token de acceso de un usuario usa o supera la cantidad de espacio disponible en el token.

Aunque los tamaños de token se pueden aumentar en una medida limitada, la solución final para la saturación de tokens es reducir el número de SID asociados a las cuentas de usuario, ya sea racionalizando las pertenencias a grupos, eliminando el historial de SID o una combinación de ambos. Para obtener más información sobre la saturación de tokens, consulte MaxTokenSize y saturación de tokens de Kerberos.

En lugar de migrar los usuarios de un entorno heredado (especialmente uno en el que las pertenencias a grupos y los historiales de SID puedan estar en peligro) mediante el uso del historial de SID, considere la posibilidad de aprovechar las aplicaciones de metadirectorio para "migrar" los usuarios, sin llevar los historiales de SID al nuevo bosque. Cuando se crean las cuentas de usuario en el nuevo bosque, puede usar una aplicación de metadirectorio para asignar las cuentas a sus cuentas correspondientes del bosque heredado.

Para proporcionar a las nuevas cuentas de usuario acceso a los recursos del bosque heredado, puede usar las herramientas de metadirectorio para identificar los grupos de recursos a los que se concedió acceso a las cuentas heredadas de los usuarios y, a continuación, agregar las nuevas cuentas de los usuarios a esos grupos. En función de la estrategia de grupos del bosque heredado, es posible que tenga que crear grupos locales de dominio para el acceso a los recursos o convertir los grupos existentes en grupos locales de dominio para permitir que las nuevas cuentas se agreguen a los grupos de recursos. Al centrarse primero en las aplicaciones y los datos más críticos y migrarlos al nuevo entorno (con o sin historial de SID), puede limitar la cantidad de esfuerzo empleado en el entorno heredado.

Servidores y estaciones de trabajo

En una migración tradicional de un bosque de Active Directory a otro, la migración de equipos suele ser relativamente sencilla en comparación con la migración de usuarios, grupos y aplicaciones. Según el rol de equipo, la migración a un bosque nuevo puede ser tan simple como quitar la unión a un dominio antiguo y unirse a uno nuevo. Sin embargo, la migración de cuentas de equipo intactas a un bosque prístino derrota el propósito de crear un nuevo entorno. En lugar de migrar las cuentas de equipo (potencialmente en peligro, configuradas incorrectamente u obsoletas) a un bosque nuevo, debe instalar nuevos servidores y estaciones de trabajo en el nuevo entorno. Puede migrar los datos de los sistemas del bosque heredado a los sistemas del bosque prístino, pero no los sistemas que hospedan los datos.

APLICACIONES

Las aplicaciones pueden presentar el desafío más importante en cualquier migración de un bosque a otro, pero en el caso de una migración "no migratoria", uno de los principios más básicos que debe aplicar es que las aplicaciones del bosque prístino deben ser actuales, compatibles y recién instaladas. Los datos se pueden migrar desde las instancias de las aplicaciones del bosque antiguo siempre que sea posible. En situaciones en las que una aplicación no se puede "volver a crear" en el bosque prístino, debe considerar enfoques como la destrucción creativa o el aislamiento de las aplicaciones heredadas, como se describe en la sección siguiente.

Implementación de la destrucción creativa

La destrucción creativa es un término económico que describe el desarrollo económico creado por la destrucción de un orden anterior. En los últimos años, el término se ha aplicado a las tecnologías de la información. Normalmente, hace referencia a los mecanismos por los que se elimina la infraestructura antigua, no mediante su actualización, sino mediante la sustitución por algo completamente nuevo. El Simposio ITXPO de Gartner del año 2011 para CIO y ejecutivos sénior de TI presentó la destrucción creativa como uno de sus temas clave para reducir los costos y aumentar la eficiencia. Las mejoras en la seguridad son posibles como un crecimiento natural del proceso.

Por ejemplo, una organización se puede componer de varias unidades de negocio que usan una aplicación diferente que realiza una funcionalidad similar, con distintos grados de modernización y soporte técnico del proveedor. Históricamente, el equipo de TI podría ser responsable de mantener la aplicación de cada unidad de negocio por separado y los esfuerzos de consolidación consistirían en intentar averiguar qué aplicación ofrecía la mejor funcionalidad y, a continuación, migrar los datos a esa aplicación desde las demás.

En la destrucción creativa, en lugar de mantener aplicaciones obsoletas o redundantes, se implementan aplicaciones completamente nuevas para sustituir a las antiguas, se migran los datos a las nuevas aplicaciones y se retiran las aplicaciones antiguas y los sistemas en los que se ejecutan. En algunos casos, puede implementar la destrucción creativa de las aplicaciones heredadas mediante la implementación de una nueva aplicación en su propia infraestructura, pero siempre que sea posible, debe considerar la posibilidad de migrar la aplicación a una solución basada en la nube.

Al implementar aplicaciones basadas en la nube para sustituir las aplicaciones internas heredadas, no solo se reducen los costos y los esfuerzos de mantenimiento, sino que se reduce la superficie expuesta a ataques de la organización mediante la eliminación de aplicaciones y sistemas heredados que presentan vulnerabilidades que los atacantes pueden aprovechar. Este enfoque proporciona una manera más rápida de que una organización obtenga la funcionalidad deseada al mismo tiempo que elimina los objetivos de ataque heredados de la infraestructura. Aunque el principio de destrucción creativa no se aplica a todos los recursos de TI, proporciona una opción a menudo viable para eliminar las aplicaciones y los sistemas heredados al mismo tiempo que se implementan aplicaciones sólidas, seguras y basadas en la nube.

Aislamiento de las aplicaciones y los sistemas heredados

Un crecimiento natural de la migración de los usuarios y sistemas críticos para la empresa a un entorno prístino y seguro es que el bosque heredado contendrá información y sistemas menos valiosos. Aunque las aplicaciones y los sistemas heredados que permanecen en el entorno menos seguro pueden presentar un riesgo elevado de peligro, también representan una gravedad reducida del peligro. Al volver a hospedar y modernizar los recursos empresariales críticos, puede centrarse en la implementación de una administración y supervisión eficaces, sin necesidad de adaptarse a la configuración y los protocolos heredados.

Al quitar estos sistemas de los dominios en los que forzaron la implementación de una configuración heredada, puede aumentar posteriormente la seguridad de los dominios mediante su configuración para admitir solo sistemas operativos y aplicaciones actuales. Aunque es preferible retirar las aplicaciones y los sistemas heredados siempre que sea posible. Si la retirada simplemente no es factible para un pequeño segmento de la población heredada, la separación en un dominio independiente (o bosque) le permite realizar mejoras incrementales en el resto de la instalación heredada.

Simplificación de la seguridad para los usuarios finales

En la mayoría de las organizaciones, los usuarios que tienen acceso a la información más confidencial debido a la naturaleza de sus roles en la organización suelen tener la menor cantidad de tiempo disponible para dedicarse al aprendizaje de controles y restricciones de acceso complejos. Aunque debe tener un programa integral de educación sobre seguridad para todos los usuarios de la organización, también debe centrarse en hacer que la seguridad sea lo más fácil de usar posible mediante la implementación de controles transparentes y simplificando los principios a los que se adhieren los usuarios.

Por ejemplo, puede definir una directiva por la cual los ejecutivos y otros usuarios VIP deben usar estaciones de trabajo seguras para acceder a datos y sistemas confidenciales, lo que les permite usar sus otros dispositivos para acceder a datos menos confidenciales. Este es un principio sencillo para que los usuarios lo recuerden, pero puede implementar una serie de controles de back-end para ayudar a aplicar el enfoque.

Puede usar la garantía de mecanismo de autenticación para permitir que los usuarios accedan a datos confidenciales solo si han iniciado sesión en sus sistemas seguros mediante sus tarjetas inteligentes y puede usar IPsec y las restricciones de derechos de usuario para controlar los sistemas desde los que pueden conectarse a los repositorios de datos confidenciales. Puede implementar el Control de acceso dinámico para restringir el acceso a los datos en función de las características de un intento de acceso, traduciendo la reglas de negocio a controles técnicos.

Desde la perspectiva del usuario, el acceso a los datos confidenciales desde un sistema protegido "simplemente funciona" y si intenta hacerlo desde un sistema no seguro "simplemente no funciona". Sin embargo, desde la perspectiva de la supervisión y administración del entorno, está ayudando a crear patrones identificables sobre el modo en el que los usuarios acceden a los datos y sistemas confidenciales, lo que facilita la detección de intentos de acceso anómalos.

En entornos en los que la resistencia del usuario a contraseñas largas y complejas ha dado lugar a directivas de contraseña insuficientes, especialmente para los usuarios VIP, considere enfoques alternativos para la autenticación. Entre los enfoques alternativos se incluyen las tarjetas inteligentes (que incorporan una serie de factores de forma y características adicionales para reforzar la autenticación), controles biométricos, como los lectores de dedo, o incluso datos de autenticación protegidos por chips de módulo de plataforma segura (TPM) en los equipos de los usuarios. La autenticación multifactor no impide ataques de robo de credenciales si un equipo ya está en peligro. Pero al proporcionar a los usuarios controles de autenticación fáciles de usar, puede asignar contraseñas más sólidas a las cuentas de los usuarios para los que los controles tradicionales de nombre de usuario y contraseña son difíciles de usar.