Hola,
Esta es la segunda parte de un blog que escribí anteriormente. La premisa de la primera parte era comprender mejor cuáles son las opciones a las que se enfrentan las empresas en caso de que su Directorio Activo se vea comprometido. ¿Cómo pueden volver a funcionar lo antes posible? ¿Cómo pueden hacerlo con tantas garantías como sea posible de que no están restaurando malware en la instancia del bosque de Active Directory restaurado?
Para entender bien la segunda parte, le animo a leer la primera, que encontraráaquí.
Para los que ya habéis leído la primera parte, gracias por los comentarios. Todos buenos puntos y comentarios.
Empecemos revisando el caso de uso que dejé en la primera parte...
Todo está encriptado. Los aparcamientos están vacíos. Las fábricas están en silencio y el director general habla por teléfono cada 30 segundos diciendo algo "pintoresco" sobre tu ascendencia. Por desgracia, este no es un escenario que me haya inventado. Es una conversación mensual y casi hoy en día semanal que tengo. Forma parte del negocio en el que estoy y últimamente es un dilema muy duro y realista del mundo real.
Los comentarios que recibí a la primera parte del blog se centraron en dos áreas. El primero sugería utilizar un sistema de gestión de permisos más seguro. Siempre es una buena idea, pero en este caso es demasiado tarde. Aunque podemos estudiarlo como parte del proceso de recuperación. Más adelante hablaremos de ello. El segundo fue una reconstrucción parcial de un bosque separado. Este segundo bosque sería esencialmente un bosque "VIP" donde se asentaría toda la información de los activos importantes de la empresa. Tal vez. ¿Pero cuánto tiempo llevaría? ¿Dispone la empresa de los recursos necesarios para rediseñar un bosque entero sobre la marcha? Hay que tener en cuenta que tengo que ponerlo en marcha ayer.
Si el escenario anterior es un ataque y sabes a qué hora te infectaron y cómo entraron, entonces la respuesta de lo que tienes que hacer a mis ojos es razonablemente sencilla. Es cuestión de hacer una copia de seguridad de tu Directorio Activo del día anterior al ataque y hacer una restauración Forestal. (Hablaré del reto del rootkit en un minuto). Entonces la única pregunta es: ¿has invertido en una solución que automatiza la restauración de Forest y la recupera en un par de horas o tu copia de seguridad es más bien una copia de seguridad tradicional del estado del sistema de Active Directory, en la que no tienes procesos automatizados especializados para restaurar Active Directory en su totalidad? Si se trata de esto último, debe prever un periodo de inactividad de cuatro o cinco días laborables para reconstruir manualmente el bosque a su máxima capacidad.
En realidad, algunos de los escenarios de ataque anteriores podrían tener un rootkit incrustado. Es un enigma interesante... con el escenario anterior, ¿cómo se elimina un rootkit de un controlador de dominio? Es difícil porque para restaurar necesitas tener el estado del sistema, donde podrías muy bien estar reintroduciendo al atacante. Esto también significa que un backuprestore de metal desnudo no funcionará ya que todavía tiene el mismo riesgo.
¿Recuerda todo el mundo la película "Jungla de Cristal" en la que los malos saben que, en situaciones de crisis con rehenes, el FBI corta la electricidad y así es como consiguen entrar en la cámara acorazada del banco? Es el mismo ejercicio aquí. Yo sé, y usted sabe lo que se necesita para restaurar un DC, pero el verdadero problema es - también lo hacen los malos. Van a confiar en que todo el mundo siga el "procedimiento operativo estándar" de Microsoft. Qué mejor manera de ser persistentes.
DE ACUERDO. Entonces, ¿qué haría en el escenario en el que el atacante ha estado en tu sistema durante un tiempo o, como en la mayoría de los casos, no estás realmente seguro de cuándo entró, cómo entró, etc.?
La primera parte sería restablecer todas las contraseñas, o al menos todas las cuentas con privilegios/sensibles. Sí, una tarea muy difícil, pero yo diría que mucho más fácil y rápida que una reconstrucción total o parcial. Ten en cuenta que el tiempo corre. Por supuesto, no hace falta decir que, como parte de la restauración de permisos, hay que integrar las mejores prácticas de configuración de permisos o, en este caso, de restablecimiento.
El siguiente paso sería adoptar una solución automatizada de recuperación forestal. Para ser claros, esto tiene que estar en marcha antes de que ocurra nada de esto. No es una herramienta que se pueda utilizar el día después. La recuperación de varios días frente a la de un par de horas habla por sí sola en términos del beneficio que aporta. Otra consideración que muchos no tienen en cuenta es que para que muchas de las otras soluciones de recuperación ante desastres funcionen, AD tiene que estar en funcionamiento, porque a menudo dependen de AD para la autenticación y autorización para acceder a la solución de recuperación ante desastres.
Dentro de nuestra solución Forest Recovery está la respuesta al problema de los rootkits. Parte de nuestro proceso de restauración de bosques es algo que llamamos "restauración limpia". No voy a entrar en el cómo (eso es otro blog), pero el resultado es que nos aseguramos de que sólo se restauren las partes AD del estado del sistema, no el propio sistema operativo. Ahora puede utilizar un nuevo servidor de hardware, cargar una nueva ISO de Windows y recuperar AD sin riesgo de reintroducir el malware.
También hay otra ventaja integrada en la solución Forest Recovery que vale la pena mencionar, y es la capacidad de no depender del hardware al restaurar AD en un controlador de dominio. Antes de esta funcionalidad, si quería restaurar AD tenía que hacerlo en el mismo hardware, el mismo sistema operativo, los mismos niveles de parches y los mismos niveles de Service Pack. De lo contrario, lo más probable es que se produjera un pantallazo azul durante la restauración y pasara unas cuantas horas averiguando los controladores que faltaban y similares. En la actualidad, como parte de nuestra solución Forest Recovery, no tenemos en cuenta el hardware, los paquetes de servicios ni los niveles de parches del controlador de dominio en cuestión. Lo único que debe coincidir es que debe restaurarse con el mismo número de sistema operativo con el que se realizó la copia de seguridad.
Esto aporta mucha más flexibilidad en situaciones como la restauración de sistemas físicos a virtuales, la creación de laboratorios y la restauración de AD en la nube.
Alprincipio dela primeraparte mencioné que quería escribir sobre este tema porque, aunque existe cierta documentación y algunas "orientaciones" sobre lo que hay que hacer, me parecieron lentas, incompletas y, en muchos casos, poco realistas. La otra motivación vino de una perspectiva de tiempo. Cuando empecé a estudiar este tema hace unos años, se trataba más bien de un debate académico o teórico. Un artículo aquí o allá. Ahora, en la OMI, ha pasado de ser un caso extremo interesante a una cuestión habitual de planificación de contingencias. Las organizaciones están empezando a darse cuenta de que si han invertido en tener un SLA de, digamos, un día, para su planificación de recuperación de desastres, es muy posible que tengan que añadir muchos más días, ya que nada funcionará sin el servicio AD en funcionamiento.
Por último, nunca ha habido tanto en juego. Está en juego la supervivencia de empresas enteras. No me malinterpreten: no tengo LA "bala de plata". Nadie la tiene. Pero espero haber aportado algunas consideraciones nuevas sobre un problema muy difícil.
Si quiere saber más sobre nuestra tecnología o si simplemente quiere debatir conmigo... No dude en ponerse en contacto conmigo.
