🔥 🚒 Planificación de un ejercicio de Red Team

Este documento ayuda a informar la planificación del red team contrastándola con el estilo de red team muy específico descrito en Red Teams. Este método expresa varios sesgos para optimizar el valor y el entusiasmo del blue team. Evita específicamente los intentos de motivar mediante el castigo del red team.

Revisa las preguntas a continuación para comprobar si tu planificación del red team se ha pensado a fondo para el valor de tu blue team.

❌ Motivaciones negativas

Las siguientes son razones comunes para impulsar un ejercicio de red team. Tienen cualidades dañinas para la moral o la cohesión del equipo. Un ejercicio puede ser la herramienta equivocada para tus objetivos.

• Demostrar la inseguridad de otra organización
• Mostrar dominio sobre un grupo de personas
• Demostrar o hacer un punto a través del shock y la sorpresa
• Enumerar y descubrir tantas vulnerabilidades como sea posible
• Probar si los mecanismos de detección simples están funcionando

👍 Partes interesadas

Nada podría ser más inútil que un ejercicio sin ningún patrocinio o seguimiento por parte del liderazgo o personas influyentes. Asegúrate de que los aprendizajes de un ejercicio sean defendidos por un grupo entusiasta de partes interesadas. Asegúrate de que este grupo esté informado y pueda generar impulso.

• Establecer expectativas y un hogar/dueño conocido para impulsar los resultados del ejercicio
• Asegurarse de que haya apertura al cambio y contar con patrocinio preparado para impulsar el cambio.
• ¿Es la organización un participante dispuesto en este ejercicio?
• ¿Estarían los participantes abiertos a cualquier calibración del riesgo, o a una revisión de su hoja de ruta actual?
• ¿Existe una deuda significativa que tendría prioridad sobre cualquier hallazgo del Red Team?
• ¿Serán los hallazgos del Red Team tan predecibles que no era necesario un ejercicio desde el principio?

📅 Estimaciones de tiempo

Puedes proyectar la cantidad de tiempo a asignar desde esta fase de planificación hasta el final de una fase de mitigación, o algo intermedio. Las expectativas de tiempo dependen en gran medida de las decisiones tomadas para cada fase.

• Planificación (Semanas/Meses): Planificar la ejecución general, llenar los vacíos de este documento.
• Ataque (Minutos/Semanas): Incorporación del red team y creación activa del incidente.
• Respuesta (Horas/Semanas): Si se descubre el incidente, la duración de la respuesta inmediata.
• Tabletop (Días/Semanas): Si no se descubre el incidente, la duración de la respuesta forzada o tabletop.
• Respuesta a Incidentes (Corto Plazo) (Días/Semanas): El tiempo para eliminar el acceso del red team, tapar cualquier vulnerabilidad descubierta, eliminación del adversario.
• Revelación del Red Team (Horas): Mostrar las acciones del Red Team para calibrar sobre las realidades de la Respuesta a Incidentes (IR).
• Respuesta a Incidentes (Post Mortem) (Horas/Días): Organización de las lecciones aprendidas y presentación amplia.
• Mitigación a Largo Plazo (Semanas/Meses): Finalización de lecciones aprendidas más difíciles, refactorización y crecimiento antes de considerar el próximo red team.

👪 Personas

Identifica a todas las personas que puedan necesitar conocer los planes y secretos del Red Team. Aquí es donde querrás mitigar cualquier riesgo de "Break Glass" y tener a mano los detalles de contacto para un giro fuera del ejercicio debido a cualquier emergencia.

• Firmas consultoras: ¿Contratarás a una parte externa como red team?
• Recursos internos: ¿Los empleados internos actuarán como red team?
• ¿Quién es responsable de (en este caso, retener) una llamada a la policía?
• ¿Quién es responsable de las relaciones públicas / comunicaciones entrantes?
• ¿Quién es responsable de las interacciones con los clientes?
• ¿Quién es el recurso de notificación de brechas? (abogado interno/externo)
• ¿Quién es el "Game Master" general que dirigirá los problemas y será la fuente última de buen juicio?

📉 Estrategia

Decide dónde vas a acumular tu valor a partir de esta experiencia. Hay compensaciones en todas partes que pueden no abordar lo que intentas resolver con un ejercicio.

• ¿Son conscientes los potenciales defensores de que se debe esperar un red team en algún momento?
  • ¿Deberían serlo? ¿Necesitas establecer esta expectativa?
• ¿Anunciarás también una ventana en la que se deba esperar un red team?
  • ¿Esto causará una emoción saludable y un sprint de preparación?
• ¿Los atacantes serán guiados fuertemente con trampas, o será de forma libre?
  • Esta compensación se trata del valor de la respuesta a incidentes y el descubrimiento de vulnerabilidades.
• ¿Se ha informado al equipo de que habrá reglas estrictas sobre la vergüenza?
  • Quieres evitar cualquier sensación de que esto es un castigo por una seguridad deficiente.
• ¿Se ha informado al equipo de que esto está pensado como un regalo para un blue team, no para castigar la mala seguridad? Es decir, esto no es una prueba, es un combate de entrenamiento.
  • Reforzando este punto. Asegúrate de que se sepa que este es un valioso bucle de retroalimentación, no un ciclo de rendimiento de empleados.
• ¿Se ha seleccionado un método específico o una "kill chain" realista para enmarcar el ejercicio?
• ¿Tu objetivo es simular un incidente en un riesgo fuertemente mitigado, o en un riesgo con mucha menos telemetría / medidas preventivas?
• Durante cada fase, ¿cuál es el "break glass"? ¿Cómo se anuncia ampliamente cuál es la verdad y qué debe suceder a continuación, en caso de que un red team se desvíe y cause una interrupción?
• ¿Bajo qué circunstancias quieres "suspender" al red team?
  • Considera cuándo se completa naturalmente, una interferencia externa requiere un cierre, o cuando la experiencia ya no es valiosa para los participantes.

🔧 Diseño del ataque

Un ataque representa los riesgos que intentas mitigar, el incidente que intentas manejar o las personas que esperas incluir en la respuesta. Todas estas decisiones tienen cargas de planificación que es útil identificar lo antes posible.

• ¿El ataque realmente necesita mucha experiencia y esfuerzo, o puedes tener recreaciones simples de un ataque para descubrir? ¿Son siquiera necesarias partes externas?
• ¿Dónde debería comenzar el ataque en la kill chain? (p. ej., temprano: spear phishing, o tarde: movimiento lateral con administrador de dominio)
• ¿Qué credenciales / acceso físico / documentación se requieren para apoyar el inicio del ataque? ¿Quién los proporcionará? ¿Hay implicaciones de seguridad que deban abordarse más adelante?
• Si el red team tiene éxito temprano, ¿deberían comenzar con pruebas de penetración o evaluación de vulnerabilidades? ¿Deberían intentar ser detectados?
• ¿Debería el atacante hacerse pasar por un adversario específico o un método de ataque?
• Si el red team es detectado, ¿habrá un plan de respaldo o un segundo ataque? ¿Recurrirá el red team a una prueba de penetración?
• ¿Dónde y cómo estará documentando sus comportamientos el red team? Estos deben capturarse para cualquier tabletop de seguimiento y para confirmar la remediación y las lecciones aprendidas. ¿Se puede recopilar un historial de bash? ¿Un volcado TCP? ¿Notas manuales?
• ¿Los métodos del Red Team se basarán en la realidad? ¿Están utilizando métodos que no están disponibles para un atacante realista?

🚨 Respuesta a incidentes

Si puedes prever qué tan maduro será tu proceso de respuesta, puedes manipular la respuesta para obtener un mayor beneficio. Un equipo de respuesta inmaduro puede ser guiado fuertemente por el Game Master, o un equipo de respuesta maduro puede dejarse solo para identificar puntos de fricción en la coordinación y la comunicación.

• ¿Existe un método o plan de coordinación específico que la respuesta a incidentes deba seguir? Por ejemplo, la agenda y el método descritos en Security Breach 101 o An Incident Response Plan for Startups
• ¿La Respuesta a Incidentes necesitará unirse de forma natural, para que puedas eliminar la fricción en su proceso?
• ¿Se unirá la Respuesta a Incidentes de forma artificial para forzar la respuesta prevista como práctica?
• ¿Querrás escalar el incidente artificialmente para poder controlar la Respuesta a Incidentes?
• ¿Quién comunicará con el Red Team, si hay preguntas honestas del Blue Team? (Por ejemplo: "Creemos que encontramos una brecha separada")
• ¿Quién documentará los puntos débiles del Red Team a medida que el Blue Team mitiga? ("Seguías eliminando nuestras balizas y era difícil recuperarlas, ¡no esperábamos que las encontraras todas a la vez!")
• Si la Respuesta a Incidentes no avanza de manera oportuna, ¿quién o cómo se filtrarán indicadores al Blue Team?
  • ¿Se hará esto en un formato tabletop?
• ¿Se están recopilando mitigaciones a corto plazo / medidas preventivas a largo plazo como parte de tu respuesta a incidentes?

🔍 Revelación del Red Team

El Blue Team tendrá todo tipo de preguntas para el red team. Este puede ser un momento de emoción si se hace correctamente. Mantener esta relación saludable es fundamental. El red team debe ser visto como un compañero de entrenamiento invaluable. Mejor aún, un conejo que perseguir.

• ¿Están las acciones del Red Team durante la fase de ataque muy bien documentadas y comprendidas?
• ¿El proceso de respuesta a incidentes ha omitido alguna acción sustancial del Red Team?
• ¿Hay algún IOC o artefacto que aún esté emitiendo balizas o sea descubrible en el futuro?
• ¿Alguna puerta trasera u otros cambios en riesgo han sobrevivido a la respuesta a incidentes?
• ¿Qué tan minuciosa fue la investigación y contención del Blue Team?

💀 Post Mortem

Un post mortem de alta calidad informará meses de trabajo de seguridad en la hoja de ruta y calibrará a todos en una misión a través de una experiencia compartida.

• ¿Se ha llevado a cabo un proceso de entrevistas exhaustivo o una reunión informativa con todos los participantes del ejercicio?
• ¿Se han recopilado todos los elementos de mitigación de seguimiento de forma centralizada y priorizados según el sentimiento de valor de los participantes?
• ¿Se están concluyendo y presentando estos sentimientos a los participantes?
• ¿Tienes una reunión bloqueada para presentarlos?
• ¿Quién los presenta?
• ¿Está el Red Team disponible para comentar sobre estos sentimientos, o disponible para responder preguntas?
• ¿Se está recompensando a los participantes por participar?
• ¿Se les da suficiente tiempo para informar y discutir?
• ¿Es esta una calibración valiosa hacia riesgos prácticos?

👶 Ejercicios pequeños

Puedes mantener un ejercicio pequeño y con una participación mínima de otros. Sé creativo.

Simplemente haz que un miembro del equipo simule un incidente que creas que podrías responder con éxito. Por ejemplo, puedes instalar un software que tenga funcionalidad de actualización automática y fingir que es malware. Luego "cazarías" el "C&C" que sería solo su baliza de actualización. Por ejemplo, ¿puedes demostrar que está aislado en este host y no en otros?

O bien, haz que un miembro del equipo realice un "cambio no autorizado" y arma una línea de tiempo del incidente que documente el evento y qué seguimientos importarían.

Solo asegúrate de documentar tus hallazgos, tus lecciones y tus seguimientos para presentarlos a los demás. Los red teams no son valiosos si sus lecciones están aisladas, y no necesitan ser complicados.