Diagrama de flujo de respuesta a incidentes de phishing

¿Qué es diagrama de flujo de respuesta a incidentes de phishing?

La respuesta a incidentes de phishing es lo que ocurre después de que una persona reenvía un correo. El disparador es un reporte y no una alerta: alguien pulsa el botón de reporte en su cliente de correo, o llama a la mesa de servicio por un mensaje que no le cuadra. A partir de ahí el trabajo es un ciclo corto y repetible. Triar la muestra hasta un veredicto, encontrar cada otra copia que llegó a la organización, retirar esas copias y bloquear lo que señalaban, deshacer lo que los destinatarios ya hicieron, y contar a la gente qué pasó. El diagrama de abajo sigue un reporte de principio a fin a lo largo de seis fases, desde la recepción pasando por el triaje, la delimitación del alcance, la contención y la recuperación, hasta el trabajo de métricas y concienciación que decide cuántos reportes recibiréis el mes que viene.

Esto es solo el caso que llega por correo. No es el ciclo de vida general de respuesta a incidentes de ciberseguridad que ejecuta un centro de operaciones de seguridad a partir de una alerta de detección: ese proceso arranca desde la telemetría y no desde una persona, y este diagrama le entrega el caso en '¿Hay señales de cuenta comprometida?' cuando un buzón resulta estar bajo el control de otro. Tampoco es la escala de gravedad de un proceso de escalado de incidentes de seguridad, ni un restablecimiento de contraseña rutinario, porque el restablecimiento aquí es contención de una credencial que un atacante ya posee y va acompañado de revocación de sesiones. Tampoco es notificación de brechas: si datos personales han llegado a un atacante, la evaluación, el reloj legal y la conversación con un regulador corresponden a jurídico y al delegado de protección de datos, y corren en paralelo a este diagrama en vez de dentro de él. Tratad el diagrama como un punto de partida educativo que adaptar bajo vuestros propios procedimientos de respuesta a incidentes, la normativa que os aplique y la revisión de vuestro responsable de seguridad.

Cuatro decisiones sostienen el proceso. '¿Es malicioso el mensaje reportado?' es el veredicto que separa una molestia de un incidente, y recae en el analista SOC y no en la mesa de servicio, porque un dominio parecido y una autenticación de remitente fallida no son un juicio de primera línea. '¿Alguien hizo clic o respondió?' convierte un trabajo de higiene del correo en un trabajo de identidad, y todo lo costoso del diagrama depende de ella. '¿Qué hizo el usuario afectado?' está dibujada como una única rama de tres vías en vez de una cola de preguntas de sí y no, porque introducir credenciales, ejecutar un adjunto y un cuasi incidente necesitan equipos distintos trabajando con relojes distintos. '¿Hace falta una advertencia a toda la plantilla?' está a propósito en el carril de Dirección de seguridad: un mensaje a toda la plantilla es una decisión de comunicación con un coste, y el analista que encontró la campaña no debería ser la única persona que la toma.

Qué cubre este diagrama de flujo

En esta plantilla

• Cinco carriles (Empleado / usuario que reporta, Mesa de servicio, Analista SOC, TI / equipo de identidad y Dirección de seguridad) repartidos en seis fases: Aviso y recepción, Triaje y veredicto, Alcance de la campaña, Contención y erradicación, Recuperación y comunicación, y Cierre y aprendizaje
• Dos vías de entrada hacia una sola cola: pulsar el botón de reporte, que envía la muestra directamente al equipo de seguridad, y un ticket de la mesa de servicio para quien llama en su lugar, registrado con el mensaje original adjunto en vez de descrito
• Una decisión de veredicto, '¿Es malicioso el mensaje reportado?', cuya rama inocua responde a quien reportó, ajusta el filtro de correo y cierra el reporte como no malicioso en vez de descartarlo en silencio, porque es la respuesta lo que mantiene a la gente reportando
• Delimitación del alcance antes de eliminar con 'Busca en el tenant otras copias' y '¿Alguien hizo clic o respondió?', luego una ronda de contención que elimina cada copia, bloquea al remitente, las URL y los hashes de archivo, y da vueltas en '¿Siguen llegando más copias?' mientras la campaña sigue llegando
• Una rama de tres vías '¿Qué hizo el usuario afectado?': introducir credenciales va a 'Restablece la contraseña y revoca las sesiones' en el carril de identidad, un adjunto abierto va a aislar el equipo y un análisis completo, y '¿Hay señales de cuenta comprometida?' escala en vez de cerrar
• Comunicación y cierre: '¿Hace falta una advertencia a toda la plantilla?' se aprueba en el carril de Dirección de seguridad, se indica a los destinatarios qué vigilar, y el reporte solo cierra cuando quedan registrados los indicadores, la cronología, la tasa de reporte y de clics, y un seguimiento de concienciación

Cuándo usar esta plantilla

• Tenéis un botón de reporte en Outlook o Gmail sin un playbook acordado detrás, así que lo que le pasa a un correo reportado depende de qué analista lo recoja
• Los usuarios reenvían correo sospechoso a una bandeja compartida que nadie posee de verdad, y necesitáis la recepción, el veredicto y la respuesta a quien reportó dibujados como un solo camino
• Acaba de aterrizar una campaña de phishing de credenciales y queréis la eliminación, el restablecimiento, la revocación de sesiones y la revisión de reglas del buzón ordenados antes de que llegue la siguiente
• Estáis escribiendo la sección de phishing de un plan de respuesta a incidentes y necesitáis que entregue el caso con limpieza al proceso más amplio de incidentes de seguridad en vez de duplicarlo
• Un auditor ha preguntado cómo reporta el personal un posible evento de seguridad y qué pasa después, que es el mecanismo de reporte que pide el control 6.8 del anexo A de ISO/IEC 27001:2022

Cómo funciona

1. Cambia los carriles por vuestros roles

   Sustituye Empleado / usuario que reporta, Mesa de servicio, Analista SOC, TI / equipo de identidad y Dirección de seguridad por los roles que tenéis de verdad. Muchas organizaciones no tienen carril de mesa de servicio porque el botón de reporte va directo a seguridad, y muchas llevan el trabajo de identidad dentro del SOC. Borra un carril antes que dejarlo sin nadie, y divide uno si un proveedor de servicios gestionados posee parte de él.

2. Anota cada canal de entrada

   Enumera cada forma en que puede llegar un reporte de phishing: el botón de reporte, un buzón compartido, el teléfono de la mesa de servicio, un responsable que reenvía en nombre de alguien, un cliente que os cuenta que su factura fue redirigida. Marca luego cuáles de ellos caen automáticamente en la cola de triaje y cuáles dependen de que alguien se acuerde de reenviarlo, porque ese hueco es donde se pierden los reportes en silencio.

3. Fija los criterios del veredicto de triaje

   Abre '¿Es malicioso el mensaje reportado?' y anota las comprobaciones que de verdad hacen vuestros analistas: coherencia de la autenticación del remitente, dominios parecidos o registrados hace poco, detonación de URL, sandboxing de adjuntos, y si el mensaje pide credenciales, un pago o urgencia. Di también qué pasa con un mensaje molesto pero inocuo, para que el spam sea una decisión y no un encogimiento de hombros.

4. Ajusta la búsqueda de alcance antes de eliminar

   La eliminación es tan buena como la búsqueda que la precede. Registra sobre qué buscáis, que debería incluir la dirección del remitente, el nombre mostrado, el asunto, la URL y el hash del adjunto, y hasta dónde llega vuestra herramienta hacia atrás, que suele ser una ventana retroactiva corta solo sobre buzones en la nube. Anotad aparte cómo encontráis copias en buzones on-premises, archivos y todo lo ya reenviado fuera.

5. Acuerda la respuesta de identidad y quién la ordena

   Decidid a qué os compromete 'Restablece la contraseña y revoca las sesiones' y quién puede ordenarlo a las tres de la madrugada. Un restablecimiento por sí solo deja funcionando un token de sesión robado, así que la revocación y la revisión de métodos MFA, reglas del buzón y aplicaciones con permiso concedido pertenecen al mismo paso. Indicad cómo llega la nueva credencial al usuario por un canal que el atacante no controla.

6. Decide quién autoriza una advertencia a toda la plantilla

   Poned un nombre junto a '¿Hace falta una advertencia a toda la plantilla?' y un umbral debajo: cuántos destinatarios, qué marcas o directivos se suplantan, si alguien ya ha pagado o ha introducido credenciales. Redactad el aviso con antelación, porque la versión escrita bajo presión es la que avisa de un asunto que el atacante cambió hace una hora.

7. Recórrelo con un correo reportado real

   Coged dos reportes recientes, uno que resultó ser spam y otro que se convirtió en un incidente real, y seguid cada uno por el diagrama con quienes los gestionaron. Los pasos para los que nadie sabe nombrar un responsable, y los pasos que claramente ocurrieron pero no están dibujados, son los hallazgos que merece la pena corregir antes de publicar el playbook y ejercitarlo.

Preguntas frecuentes

¿Cuáles son los pasos de un proceso de respuesta a incidentes de phishing?

Un empleado detecta un correo sospechoso y lo reporta, con el botón de su cliente de correo o abriendo un ticket en la mesa de servicio con el mensaje original adjunto. Un analista examina cabeceras, enlaces y adjuntos y llega a un veredicto. Un mensaje molesto pero inocuo obtiene una respuesta a quien reportó, un cambio de filtro y un reporte cerrado. Uno malicioso se delimita: buscar en el tenant otras copias, y establecer si alguien hizo clic o respondió. La contención elimina entonces cada copia, bloquea al remitente, las URL y los hashes de archivo, y se repite mientras siguen llegando copias. Lo que hizo el usuario afectado decide el resto. Introducir credenciales significa restablecer la contraseña con revocación de sesiones y revisar métodos MFA, reglas del buzón y aplicaciones con permiso concedido; un adjunto abierto significa aislar el equipo y un análisis; las señales de cuenta comprometida escalan a respuesta a incidentes. Si no, el equipo valora una advertencia a toda la plantilla, indica a los destinatarios qué vigilar, registra los indicadores y las métricas, y cierra con quien reportó.

¿En qué se diferencia la respuesta a phishing de la respuesta a incidentes de ciberseguridad?

Alcance y disparador. La respuesta a phishing es un proceso de alto volumen, en gran medida repetible, que empieza con una persona reportando un mensaje, y la mayoría de los casos terminan sin que se llegue a declarar un incidente: el correo se elimina, los indicadores se bloquean y se responde a quien reportó. Un proceso de respuesta a incidentes de ciberseguridad arranca desde una detección o una vulneración confirmada y recorre declaración, gravedad, un responsable del incidente, forense, erradicación y recuperación. Los dos se encuentran en un único punto de este diagrama. Cuando las comprobaciones de identidad muestran que un buzón ya no está bajo el control de su dueño, la respuesta a phishing ha hecho su trabajo y entrega el caso. Mantenerlos separados importa en ambas direcciones: pasar cada correo reportado por un ciclo de incidente completo agota al equipo, y tratar una toma de cuenta activa como una limpieza de buzón deja escapar al atacante.

¿Basta con restablecer la contraseña después de que alguien introduzca credenciales en una página de phishing?

Normalmente no. Los kits modernos de phishing de credenciales funcionan como un adversario en el medio: la página falsa hace de proxy del inicio de sesión real, así que tanto la contraseña como la solicitud multifactor se retransmiten al servicio genuino, y el atacante captura los tokens de sesión y de actualización que vuelven. Esos tokens siguen funcionando después de cambiar la contraseña, por lo que este diagrama empareja el restablecimiento con la revocación de sesiones en el mismo paso y lo sigue con una revisión de los métodos MFA registrados, las reglas de reenvío del buzón y las aplicaciones OAuth con permiso concedido, los tres sitios donde los atacantes suelen dejarse una vía de vuelta. A más largo plazo, el control que elimina el ataque en vez de limpiar después de él es la autenticación resistente al phishing. La guía de CISA señala los autenticadores FIDO/WebAuthn y los métodos basados en PKI como las tarjetas inteligentes como las formas resistentes al phishing, porque atan el inicio de sesión al dominio real y fallan ante un proxy.

¿Se puede eliminar un correo de phishing de todos los buzones después de que se haya entregado?

En parte, y conviene conocer los límites antes de prometerlo. Las plataformas de correo en la nube ofrecen eliminación retroactiva para mensajes que resultan maliciosos después de la entrega. El zero-hour auto purge de Microsoft, por ejemplo, actúa sobre correo ya entregado en buzones en la nube, su búsqueda cubre las últimas 48 horas de correo entregado, y no funciona en buzones on-premises protegidos por Microsoft 365. La búsqueda y eliminación dirigida por un analista desde el portal de seguridad os da una red más amplia, pero sigue siendo solo sobre los buzones que tiene esa plataforma. Lo que ninguna eliminación alcanza es una copia que el destinatario ya reenvió fuera, un mensaje bajado a un archivo local, o una captura de pantalla en un hilo de chat. Por eso el diagrama da vueltas en '¿Siguen llegando más copias?' en vez de tratar la eliminación como un evento único, y por eso indicar a los destinatarios qué vigilar se queda en el camino crítico.

¿Hay que reportar un incidente de phishing a un regulador?

Depende de lo que consiguiera el atacante, y no es una decisión que el analista deba tomar solo. Bajo el RGPD del Reino Unido y de la UE, un responsable del tratamiento debe notificar a su autoridad de control una violación de datos personales sin dilación indebida y, cuando sea posible, a más tardar 72 horas después de tener constancia de ella, salvo que sea improbable que la violación entrañe un riesgo para los derechos y libertades de las personas; una notificación tardía debe justificar los motivos del retraso. Regímenes sectoriales, contratos y pólizas de ciberseguro imponen sus propios plazos encima de ese. La regla práctica es que en el momento en que este diagrama llega a señales de cuenta comprometida, jurídico y el delegado de protección de datos se involucran en paralelo mientras el trabajo técnico continúa. Aparte, varias autoridades nacionales reciben la propia muestra: en el Reino Unido, el Suspicious Email Reporting Service del NCSC acepta mensajes reenviados a report@phishing.gov.uk.