Saltar a contenido

3.4.1.-Intercambio de información de incidentes

3.4.1. Intercambio de información de incidentes y uso de TLP

Cuando una organización sufre un incidente, investigar técnicamente es solo una parte del trabajo. La otra parte, igual de importante, consiste en compartir la información adecuada con las personas y entidades adecuadas. En la práctica, esto puede incluir al proveedor de correo, al proveedor de servicios en la nube, al SOC externo, al CSIRT de referencia o a un organismo competente que pueda aportar contexto, apoyo o capacidad de coordinación.

El problema es que compartir demasiado puede exponer datos sensibles, pero compartir demasiado poco puede retrasar la respuesta. Por eso este tema gira en torno a una idea central: intercambiar información no es reenviar datos sin más, sino comunicar con criterio operativo, legal y técnico.

En este punto de la unidad, lo importante es que entendáis tres mensajes:

  • para qué se comparte información durante un incidente;
  • qué debe compartirse y qué conviene reservar o minimizar;
  • y cómo usar el protocolo TLP para marcar límites claros de difusión.
Código Referencia literal de normativa Aplicación en este tema
RA3 "Investiga incidentes de ciberseguridad analizando los riesgos implicados y definiendo las posibles medidas a adoptar" El intercambio de información forma parte de la investigación útil, porque permite obtener contexto, apoyo técnico y coordinación externa.
CEd "Se ha intercambiado información de incidentes, con proveedores y/o organismos competentes que podrían hacer aportaciones al respecto." Este documento desarrolla qué compartir, con quién, por qué canal y cómo limitar la difusión con TLP.

Definición

El intercambio de información de incidentes es el proceso mediante el cual una organización comunica datos relevantes de un incidente a terceros que pueden ayudar a analizarlo, contenerlo, mitigarlo, coordinarlo o escalarlo, aplicando límites de difusión y medidas de protección acordes con la sensibilidad de la información.

Idea clave del tema

Compartir información no significa publicar todo lo que sabemos. Significa entregar a cada destinatario lo necesario para actuar, sin perder el control sobre la confidencialidad, la privacidad y el impacto del incidente.

1. Por qué es necesario intercambiar información

En una respuesta a incidentes real, rara vez una organización puede resolverlo todo sola. Muchas veces necesita apoyarse en terceros porque parte de la infraestructura, de la evidencia o de la capacidad de actuación está fuera de su control directo.

Por ejemplo:

  • si el incidente afecta al correo, puede ser necesario coordinarse con el proveedor de correo o con el proveedor DNS;
  • si hay una campaña activa, un CERT o CSIRT puede aportar contexto adicional, indicadores o casos relacionados;
  • si existe actividad maliciosa desde una IP externa, el proveedor de internet o el hosting puede ayudar a bloquear, mitigar o escalar;
  • si la organización tiene un MSSP o un equipo de respuesta subcontratado, compartir observables e hipótesis acelera mucho la investigación.

Dicho de forma sencilla: compartimos información para poder responder mejor.

Según INCIBE-CERT, el servicio de respuesta a incidentes incluye la notificación a afectados y el mantenimiento de contacto con proveedores de Internet y otros CERT cuando sea necesario para limitar o impedir la continuidad del incidente. Esto encaja exactamente con el criterio de evaluación que trabajamos aquí: la investigación no termina en el análisis interno, sino que se apoya también en la cooperación con terceros.

Lo importante aquí

El objetivo no es "informar por informar". El objetivo es conseguir una acción útil: bloqueo, análisis, validación, atribución técnica, coordinación o mitigación.

2. Qué información conviene compartir

No todo lo que aparece en una investigación debe compartirse de la misma forma. Antes de enviar un correo, abrir un ticket o escalar un caso, conviene separar la información en bloques y preguntarse qué necesita realmente el destinatario.

Una forma práctica de ordenar la información es esta:

Tipo de información Ejemplos Para qué sirve
Contexto del incidente fecha, sistema afectado, tipo de impacto, estado actual Sitúa al destinatario y evita malentendidos.
Observables e IoC IP, dominio, URL, hash, dirección de correo, nombre de proceso Permite buscar, bloquear o correlacionar.
Comportamiento y TTP persistencia, ejecución, movimiento lateral, exfiltración Ayuda a entender cómo actúa el adversario.
Alcance e impacto sistemas afectados, usuarios, datos comprometidos, criticidad Prioriza respuesta y escalado.
Evidencias resumidas logs relevantes, eventos correlacionados, línea temporal resumida Aporta soporte técnico sin volcar toda la investigación.
Medidas aplicadas aislamiento, reseteo de credenciales, bloqueos, reglas EDR Evita duplicidades y mejora la coordinación.
Necesidad de apoyo "necesitamos validación", "solicitamos mitigación", "requerimos análisis" Define claramente la acción esperada del tercero.

Lo importante no es solo qué sabemos, sino qué necesita saber la otra parte para actuar.

Error frecuente

Un fallo muy habitual es reenviar un informe entero cuando el tercero solo necesita tres cosas: el IoC, el activo afectado y la acción que se le pide.

2.1. Qué conviene minimizar o proteger especialmente

Hay datos que pueden ser necesarios en una investigación interna, pero no deben compartirse sin filtrar:

  • datos personales innecesarios;
  • credenciales, tokens o secretos;
  • configuraciones internas sensibles;
  • nombres de clientes o terceros si no aportan valor operativo;
  • detalles que puedan facilitar una explotación adicional.

En la práctica, esto significa que el intercambio debe cumplir una regla muy útil:

compartir lo suficiente para que el destinatario pueda actuar, pero no tanto como para crear un riesgo nuevo.

3. Con quién se intercambia la información

El criterio de evaluación habla de proveedores y/u organismos competentes. Eso no significa siempre lo mismo. Depende del tipo de incidente y del entorno de la organización.

Podemos distinguir varios grupos habituales.

3.1. Proveedores técnicos

Aquí entran, por ejemplo:

  • proveedor de correo o filtrado de correo;
  • proveedor de nube o hosting;
  • operador de telecomunicaciones o ISP;
  • MSSP, SOC externo o equipo de respuesta subcontratado;
  • proveedor de plataforma EDR, SIEM o herramienta de seguridad.

En estos casos, la información se comparte porque el proveedor puede investigar, bloquear, aislar, ampliar trazas o aplicar mitigaciones.

3.2. CERT, CSIRT y organismos competentes

En España, según el tipo de entidad y su ámbito, pueden intervenir actores como INCIBE-CERT, CCN-CERT u otros CSIRT sectoriales o de referencia. Su valor suele estar en:

  • coordinar la respuesta;
  • aportar inteligencia adicional;
  • facilitar el contacto con otros actores;
  • orientar sobre notificación y gestión;
  • y ayudar a limitar la continuidad del incidente.

Esto es especialmente útil cuando el incidente supera el perímetro interno de la organización o cuando hace falta coordinación entre varias entidades.

3.3. Otros terceros relevantes

En función del caso también puede haber que coordinarse con:

  • clientes afectados;
  • entidades afiliadas o matriz del grupo;
  • responsables jurídicos o de protección de datos;
  • fuerzas y cuerpos de seguridad, cuando proceda por la naturaleza del hecho.

Este tema se centra sobre todo en el intercambio técnico y operativo, pero es importante que entendáis que un incidente serio casi nunca se gestiona solo desde el puesto del analista.

4. TLP: un marco simple para compartir con criterio

Cuando varias personas u organizaciones colaboran en un incidente, aparece una pregunta inmediata: "esto que voy a enviar, ¿hasta dónde se puede difundir?"

El Traffic Light Protocol o TLP existe precisamente para responder a esa pregunta de forma rápida y comprensible.

FIRST define TLP como un conjunto de cuatro etiquetas para indicar los límites de difusión que deben aplicar los destinatarios. Es importante recordar dos detalles:

  • las etiquetas válidas son TLP:RED, TLP:AMBER, TLP:GREEN y TLP:CLEAR;
  • deben mantenerse en mayúsculas, sin espacios y en su forma original, aunque el resto del contenido se traduzca.

Aclaración importante

TLP no sustituye a la normativa interna, a la clasificación documental ni a las obligaciones legales de notificación. Sirve para marcar cómo se puede redistribuir la información compartida.

4.1. Conceptos que necesitas entender antes de aplicar TLP

El estándar de FIRST aclara tres términos que suelen generar dudas:

  • organización: grupo con afiliación formal y políticas comunes;
  • comunidad: grupo más amplio unido por objetivos, prácticas y relaciones de confianza;
  • clientes: personas o entidades que reciben servicios de ciberseguridad de una organización.

Esto importa porque la diferencia entre organización, clientes y comunidad cambia el alcance real de cada etiqueta.

5. Significado operativo de cada color

Ahora sí, veamos el TLP como lo usaríais en un incidente real.

5.1. TLP:RED

TLP:RED se usa cuando la información solo debe llegar a destinatarios individuales concretos y no puede redistribuirse.

Etiqueta TLP:RED
TLP:RED: información solo para destinatarios individuales, sin redistribución posterior.

Se utiliza cuando una difusión más amplia puede suponer un riesgo significativo para la privacidad, la reputación o las operaciones de las organizaciones implicadas.

Ejemplos típicos:

  • un incidente en curso todavía no contenido;
  • datos que podrían alertar al atacante;
  • detalles sensibles de una investigación interna;
  • información que, si se difunde, podría dañar gravemente a la organización.

Ejemplo

Una dirección de seguridad comparte con dos responsables concretos los detalles de una exfiltración todavía activa y una hipótesis sobre la cuenta comprometida. Esa información no debe circular fuera de ese grupo reducido.

5.2. TLP:AMBER

TLP:AMBER permite compartir la información dentro de la organización y, por defecto, con sus clientes, siempre bajo criterio de necesidad de conocer.

Etiqueta TLP:AMBER
TLP:AMBER: difusión limitada a la organización receptora y, por defecto, a sus clientes cuando sea necesario para protegerse.

Es muy útil cuando la información requiere apoyo para actuar, pero sigue siendo sensible si se difunde fuera del entorno controlado.

Aquí aparece una variante importante:

  • TLP:AMBER+STRICT restringe la difusión a la organización receptora únicamente.

Los casos de uso de FIRST aclaran algo que en clase conviene recordar bien: TLP:AMBER no debería compartirse automáticamente con proveedores externos de servicios de ciberseguridad, salvo que el originador lo autorice mediante instrucciones adicionales.

Punto fino que suele caer en examen

Que algo esté en TLP:AMBER no significa "puedo enviarlo a cualquier empresa colaboradora". Si el receptor quiere compartirlo con un proveedor externo, debe existir permiso del originador o una instrucción explícita.

5.3. TLP:GREEN

TLP:GREEN permite compartir la información dentro de una comunidad de confianza, pero no en canales públicos.

Etiqueta TLP:GREEN
TLP:GREEN: difusión dentro de una comunidad de confianza, pero no en canales públicos.

Este nivel es útil cuando lo que se pretende es aumentar la conciencia y ayudar a otros equipos u organizaciones similares a protegerse.

Por ejemplo:

  • compartir IoC de una campaña con una comunidad sectorial;
  • avisar a un grupo de responsables de ciberseguridad de una red académica;
  • intercambiar TTP con organizaciones homólogas del mismo ámbito.

FIRST añade un matiz muy útil: si la comunidad no está definida, suele asumirse la comunidad de ciberseguridad o defensa; aun así, definir la comunidad de forma explícita reduce ambigüedades.

5.4. TLP:CLEAR

TLP:CLEAR indica que la información puede difundirse sin restricciones específicas de redistribución.

Etiqueta TLP:CLEAR
TLP:CLEAR: información apta para difusión pública conforme a las reglas aplicables.

Se usa cuando el riesgo de uso indebido es mínimo o no previsible y la información puede hacerse pública.

Ejemplos típicos:

  • una alerta pública con IoC ya desensibilizados;
  • recomendaciones generales de mitigación;
  • un aviso de campaña sin datos internos de la víctima.

Regla rápida

Si una información expone a la organización, al atacante o a la investigación en curso, probablemente no debería salir como TLP:CLEAR.

6. Cómo decidir el color adecuado

La mejor forma de aplicar TLP no es memorizar colores como si fueran una lista aislada, sino plantearse tres preguntas:

  1. ¿Quién necesita realmente esta información para actuar?
  2. ¿Qué pasaría si el contenido se reenvía más de la cuenta?
  3. ¿La utilidad de compartir más compensa el riesgo de difundirla?
flowchart TD
    A["Necesitas compartir información del incidente"] --> B{"¿Su difusión amplia puede dañar a la organización,\nla investigación o la privacidad?"}
    B -->|Sí, de forma alta| C["TLP:RED\nSolo destinatarios concretos"]
    B -->|Sí, pero requiere apoyo interno o con alcance muy controlado| D{"¿Debe quedarse solo dentro de la organización receptora?"}
    D -->|Sí| E["TLP:AMBER+STRICT"]
    D -->|No| F["TLP:AMBER"]
    B -->|No de forma alta, pero no debe publicarse| G{"¿Se compartirá dentro de una comunidad de confianza?"}
    G -->|Sí| H["TLP:GREEN"]
    G -->|No, puede difundirse públicamente| I["TLP:CLEAR"]

En la práctica, este flujo ayuda a evitar dos extremos:

  • compartir de menos y bloquear la coordinación;
  • compartir de más y crear un problema añadido.

7. Cómo aplicar TLP en mensajes, documentos y tickets

El protocolo no sirve de mucho si el etiquetado queda ambiguo o escondido. Por eso conviene aplicarlo de forma visible.

Según la guía operativa del TLP:

  • en mensajería o correo, la etiqueta debe figurar antes de la información y también en el asunto;
  • en documentos, debe aparecer en encabezado y pie de cada página;
  • en intercambios automatizados, su implementación debe respetar la norma aunque el detalle dependa de la plataforma.

7.1. Ejemplo de asunto y cuerpo de correo

Asunto: [TLP:AMBER] Actividad de phishing con entrega de malware en dominio corporativo

Resumen:
- Fecha de detección: 2026-04-22 08:45
- Impacto observado: 3 buzones afectados, 1 endpoint aislado
- Acción solicitada: revisión de trazas de correo y bloqueo de remitentes/URL

IoC principales:
- Remitente: factura@dominio-ejemplo.com
- URL: hxxps://portal-validacion-ejemplo[.]com/login
- SHA256: 5c1f...

Restricción adicional:
Esta información puede compartirse como TLP:AMBER+STRICT con el equipo de respuesta contratado para apoyar la investigación.

Este ejemplo deja clara una idea importante: TLP marca el límite general, pero el originador puede añadir instrucciones adicionales cuando necesite ajustar más el alcance.

8. Flujo recomendado de intercambio durante un incidente

Una organización madura no improvisa cada notificación desde cero. Lo habitual es seguir una secuencia parecida a esta:

  1. identificar qué tercero puede aportar valor;
  2. preparar un resumen técnico mínimo y útil;
  3. eliminar o reducir datos innecesarios;
  4. asignar un TLP adecuado;
  5. usar un canal seguro;
  6. registrar qué se ha compartido, con quién y cuándo;
  7. revisar si hay que ampliar, corregir o escalar el intercambio.
flowchart LR
    A["Detectáis una necesidad de apoyo externo"] --> B["Definís destinatario y objetivo"]
    B --> C["Seleccionáis datos útiles del incidente"]
    C --> D["Minimizáis datos sensibles innecesarios"]
    D --> E["Asignáis etiqueta TLP y restricciones adicionales"]
    E --> F["Compartís por canal seguro"]
    F --> G["Registráis el intercambio en el caso"]
    G --> H["Recibís respuesta, coordináis y actualizáis"]

Canal seguro

Si el contenido es sensible, no basta con etiquetarlo con TLP. También hay que usar un canal adecuado: ticket autenticado, portal del proveedor, correo cifrado o plataforma de coordinación segura.

9. Caso práctico: una campaña de phishing con apoyo externo

Imaginad esta situación.

Una empresa detecta varios correos de phishing con un enlace a una página de captura de credenciales. Un usuario ha introducido sus datos y poco después se observan accesos sospechosos al correo corporativo. El equipo interno aísla el endpoint, resetea la contraseña y necesita coordinarse con terceros.

La información podría intercambiarse así:

Destinatario Información compartida TLP orientativo Motivo
Proveedor de correo remitentes, mensajes, URL, usuarios afectados, ventana temporal TLP:AMBER Necesita aplicar búsquedas, bloqueos y trazas.
MSSP o equipo IR externo IoC, cronología resumida, actividad observada, medidas aplicadas TLP:AMBER o TLP:AMBER+STRICT Debe ayudar a investigar sin ampliar difusión.
CERT o CSIRT de referencia campaña, observables, impacto resumido, solicitud de apoyo TLP:GREEN o TLP:AMBER según sensibilidad Puede aportar contexto y coordinar con otros actores.
Comunicación pública aviso preventivo sin datos internos de la víctima TLP:CLEAR Sirve para alertar sin exponer detalles sensibles.

Lo importante aquí es entender que el mismo incidente puede generar varios intercambios con distintos niveles TLP. No existe un único color válido para todo el caso.

10. Errores frecuentes al intercambiar información

Estos fallos aparecen mucho en entornos reales y también en supuestos prácticos:

  • compartir un informe entero cuando bastaba un resumen técnico;
  • olvidar indicar qué acción se espera del receptor;
  • usar TLP como si fuera una clasificación legal completa;
  • marcar TLP:AMBER y reenviar después a terceros sin permiso;
  • publicar IoC útiles, pero acompañados de detalles internos innecesarios;
  • no registrar qué se ha compartido ni con quién;
  • olvidar que distintos destinatarios pueden necesitar versiones distintas del mismo incidente.

Error conceptual típico

TLP no dice si una información es "secreta" o "pública" en sentido legal. Lo que indica es cómo puede redistribuirla el receptor.

11. Qué debe recordar un analista al terminar este tema

Si tuvierais que quedaros con una sola idea, sería esta:

en respuesta a incidentes, compartir información bien no consiste en enviar más datos, sino en enviar los datos adecuados, a la persona adecuada, con el nivel adecuado de difusión.

El TLP es valioso porque convierte esa decisión en algo visible y operativo. Ayuda a coordinarse con proveedores, CERT y organismos competentes sin perder de vista algo fundamental: la información también es un activo que hay que proteger mientras respondemos al incidente.

Fuentes y referencias