🔥 🚒 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?