Amenazas e incidentes

¿Qué amenazas o incidentes gestionamos en este ciclo?

Contuvimos una campaña de phishing dirigida a finanzas en menos de 30 minutos desde el primer aviso.
Un bucket de S3 mal configurado expuso registros internos, pero no se vieron afectados datos de clientes.
El fin de semana hubo varios intentos de inicio de sesión por fuerza bruta contra nuestra pasarela VPN.
Controles y logros

¿Qué defensas, herramientas o procesos funcionaron bien?

Las reglas de correlación del SIEM detectaron pronto el intento de movimiento lateral.
El documento de traspaso de guardia hizo que la escalada de las 2 de la madrugada fuera rápida y fluida.
La contención automática de nuestro EDR nos ahorró horas de trabajo manual.
Brechas y vulnerabilidades

¿Dónde tuvimos puntos ciegos o debilidades?

No teníamos visibilidad sobre la aplicación SaaS de terceros que fue comprometida.
Por la fatiga de alertas, una señal real estuvo dos horas sin atenderse.
Nuestro ciclo de parcheo es demasiado lento para los CVE críticos.
Acciones y bastionado

¿Qué haremos para mejorar nuestra postura de seguridad?

Ajustar las reglas del SIEM para reducir los falsos positivos un 25 % antes de la próxima revisión.
Incluir la aplicación SaaS de terceros en el alcance de la monitorización continua.
Crear y probar un playbook de toma de control de cuentas en la nube en este sprint.

¿Qué es la retrospectiva de Operaciones de Ciberseguridad?

La retrospectiva de Operaciones de Ciberseguridad reúne a tu equipo de operaciones de seguridad para repasar el último ciclo: qué detectasteis, cómo respondisteis y cómo os recuperasteis. Está pensada para analistas del SOC, equipos de respuesta a incidentes, threat hunters e ingenieros de seguridad que quieren que las lecciones de alertas, incidentes y casi incidentes se conviertan en mejoras reales. El tablero tiene cuatro columnas. Amenazas e incidentes recoge lo que ocurrió. Controles y logros registra las herramientas y los procesos que funcionaron. Brechas y vulnerabilidades reúne los puntos ciegos y las debilidades que salieron a la luz. Acciones y bastionado es donde acordáis qué cambiar, con un responsable para cada punto. Si ya trabajáis con MITRE ATT&CK o NIST CSF, relacionad los hallazgos con estos marcos para seguir el progreso de un ciclo a otro. Mantén un enfoque sin culpables. Las personas solo hablarán de la alerta que se les pasó o del casi incidente que provocaron si saben que la conversación gira en torno a sistemas y procesos. Hazla después de un incidente grave, al final de una rotación de guardias o de forma periódica, y revisa las acciones del ciclo anterior antes de añadir otras nuevas.

Formato de la retrospectiva de Operaciones de Ciberseguridad

Amenazas e incidentes

¿Qué amenazas o incidentes gestionamos en este ciclo?

Enumerad las alertas, los eventos y los incidentes que el equipo gestionó en este periodo. Pide a todos que se ciñan a qué pasó, cuándo y a qué afectó, sin señalar culpables. Así todo el mundo parte de los mismos hechos antes de hablar de lo que funcionó.

Controles y logros

¿Qué defensas, herramientas o procesos funcionaron bien?

Nombrad los controles, la automatización y los traspasos que os protegieron, y concretad qué herramienta o proceso hizo el trabajo. En un equipo de seguridad es fácil saltarse los logros, y dejarlos por escrito os dice qué debéis seguir haciendo.

Brechas y vulnerabilidades

¿Dónde tuvimos puntos ciegos o debilidades?

Aquí salen a la luz las carencias de detección, los límites de las herramientas, las fricciones en los procesos y los riesgos sin parchear. Mantén el enfoque sin culpables para que la gente plantee los temas incómodos. Lo que aparece aquí suele marcar la mayor parte del plan de acción.

Acciones y bastionado

¿Qué haremos para mejorar nuestra postura de seguridad?

Convertid las brechas en acciones con un responsable y una fecha límite. Ordenadlas por probabilidad e impacto, y vinculad cada acción a la brecha que cierra para poder comprobar el progreso la próxima vez.

Cuándo utilizar este estudio retrospectivo

  • Después de un incidente o una brecha de seguridad importante, para recoger las lecciones sin buscar culpables.
  • Al final de una rotación de guardias o de turnos del SOC, para revisar las alertas y los traspasos.
  • Cada mes o cada trimestre, para seguir las brechas recurrentes y comprobar si las soluciones del ciclo anterior se han mantenido.
  • Después de un ejercicio de simulación, una prueba de red team o un test de penetración, para acordar qué significan los hallazgos para vuestro equipo.
  • Cuando habéis implantado nuevas herramientas o prácticas de SecOps y queréis comprobar que funcionan.

Preguntas sugeridas para romper el hielo

  • Si fueras hacker por un día, ¿cuál sería tu arma preferida y por qué?
  • ¿Cuál es el intento de phishing más creativo que has visto y estuvo a punto de funcionar?

¿Le gustaría que su equipo realizara un ejercicio de calentamiento, en lugar de limitarse a responder en voz alta? Eche un vistazo a los rompehielos gratuitos →

Ideas y consejos para su reunión retrospectiva

  • Mantén un enfoque sin culpables. Habla de sistemas y procesos, no de personas, para que la gente reconozca errores y casi incidentes.
  • Relaciona los hallazgos con un marco como MITRE ATT&CK o NIST CSF para que sea fácil seguir las mejoras a lo largo del tiempo.
  • Invita a analistas, equipos de respuesta, ingenieros y a un responsable. Cada rol ve puntos ciegos que los demás pasan por alto.
  • Pide que primero se añadan notas en privado o de forma anónima, para que los analistas junior puedan señalar problemas sin someterse a la antigüedad.
  • Limita el tiempo de cada columna y reserva la última parte de la sesión para convertir las brechas en acciones con responsables y fechas.
  • Haz seguimiento de las acciones de una retrospectiva a otra para que las vulnerabilidades recurrentes no se arrastren sin que nadie lo note.

Preguntas frecuentes

¿Cuándo deberíamos hacer una retrospectiva de Operaciones de Ciberseguridad?
Hazla después de un incidente grave, al final de una rotación de guardias o cada mes o trimestre. Una frecuencia regular os ayuda a detectar brechas recurrentes antes de que se conviertan en incidentes.
¿Cuánto dura una retrospectiva de Operaciones de Ciberseguridad?
Calcula entre 45 y 75 minutos, según el tamaño del equipo y cuántos incidentes haya que tratar. Limitar el tiempo de cada una de las cuatro columnas ayuda a mantener el ritmo.
¿En qué se diferencia de un postmortem de incidente estándar?
Un postmortem analiza a fondo un único incidente. Esta retrospectiva abarca todo el ciclo, desde las alertas gestionadas hasta los controles que funcionaron y las brechas detectadas. Las conclusiones de los postmortems son un buen punto de partida para ella.
¿Cómo mantenemos la retrospectiva sin culpables?
Hablad de sistemas, procesos y herramientas en lugar de personas, y empezad con notas privadas o anónimas. La gente comparte más casi incidentes cuando no teme que la culpen.
¿Quién debería participar en una retrospectiva de Operaciones de Ciberseguridad?
Analistas del SOC, equipos de respuesta a incidentes, threat hunters, ingenieros de seguridad y alguien de la dirección. Una combinación de roles revela puntos ciegos que un solo grupo pasaría por alto.
¿Podemos vincular los hallazgos a marcos de seguridad?
Sí. Relacionar los hallazgos con MITRE ATT&CK o NIST CSF les da una referencia común y facilita medir el progreso entre ciclos.
¿Está listo para llevar a cabo esta retrospectiva?Pruebe esta retransmisión en directo retrospectiva