Ciberseguridad

Qué es el triage informático y cuándo debe aplicarse

¿Qué pasaría si durante una crisis de seguridad tu equipo perdiera tiempo valioso analizando una alerta de baja prioridad mientras un ataque crítico compromete sistemas esenciales? Esta situación es más común de lo que imaginamos, pero puede evitarse con una metodología efectiva de triage informático.

El triage informático se ha convertido en una disciplina fundamental para cualquier organización. No se trata solo de clasificar alertas, es un proceso estratégico que permite optimizar recursos, minimizar el impacto de incidentes y mantener la continuidad operativa cuando más se necesita.

Origen del concepto

El término ‘triage’ no es exclusivo del ámbito informático, su origen se remonta a la medicina militar del siglo XVIII, donde había que decidir a toda prisa qué soldados podían salvarse.

Los médicos clasificaban heridos en tres grupos: imposibles de salvar, urgentes y leves.

Hoy, en el mundo de la ciberseguridad, el concepto no ha cambiado tanto… En lugar de soldados, clasificamos incidentes. Y en lugar de heridas, evaluamos daños potenciales a sistemas y datos.

Hoy la definición canónica aparece en la guía del NIST SP 800‑61r3, que describe lo qué es triage como al proceso llevado a cabo para analizar, clasificar y priorizar eventos de seguridad según su gravedad, impacto y urgencia, para así, decidir con rapidez qué incidentes requieren atención inmediata y cuáles pueden esperar.

Este proceso es llevado a cabo, en la mayoría de las organizaciones, por los equipos de respuesta a incidentes, conocidos como CSIRT (Computer Security Incident Response Teams). Son los “médicos de urgencias” que reciben alertas, hacen el diagnóstico inicial y deciden si el incidente es real, y si lo es, si estamos ante algo leve, grave o crítico.

Su capacidad para hacer un buen triage puede marcar la diferencia entre contener una amenaza a tiempo o sufrir una brecha seria.

Función principal

El triage no solo clasifica, sino que trata de responder preguntas clave. ¿Qué pasó? ¿Cómo ocurrió? ¿Cuándo, dónde y por qué? Para eso, se recolectan datos específicos del sistema que ayuden a entender el incidente y activar la respuesta adecuada.

Su función es doble:

• Reducir el tiempo de exposición: Cuanto antes se detecte y etiquete un evento crítico, antes se activa la respuesta y se limita el daño.
• Optimizar recursos: En los entornos reales nunca sobran analistas, así que en el triage se asigna cada alerta al nivel de atención apropiado, permitiendo que los perfiles más especializados se enfoquen en incidentes complejos y no en tareas rutinarias.

Momento de aplicación

En la práctica, el contexto lo es todo. Un mismo evento puede ser irrelevante en un entorno de pruebas, pero crítico si afecta a un servidor en producción o a un usuario con privilegios.

El momento de aplicación del triage es clave y debe aplicarse tan pronto como se detecta un incidente de seguridad. No debemos malgastar recursos en falsos positivos y actuar rápido ante las amenazas reales. El NIST lo ubica dentro de la fase de Incident Handling, justo entre la detección y la respuesta activa.

Esto cobra aún más sentido en entornos con alto volumen de alertas y recursos limitados. Por ejemplo, según buenas prácticas como las de ITIL v4, conviene activar el triage cuando:

• El servicio empieza a operar por encima de su capacidad normal y los SLA corren peligro (criterio de Major Incident en ITIL v4).
• Se producen incidentes en cadena (como un ataque DDoS seguido de ransomware).
• Hay ambigüedad en la criticidad de las alertas.

Una vez se ha recibido una alerta o indicio de actividad sospechosa, el equipo de respuesta (CSIRT o similar) inicia el proceso de triage para determinar:

• ¿El evento realmente constituye un incidente?
• ¿Qué tipo de incidente es?
• ¿Qué tan grave es?
• ¿Qué prioridad debe tener la respuesta?

Tipos de incidentes y criterios de clasificación

Desde un simple intento de phishing hasta un ataque de ransomware a gran escala, cada incidente presenta características únicas que requieren una evaluación y clasificación precisas. Para una gestión eficaz, es fundamental comprender los diferentes tipos de incidentes y los criterios que nos permiten priorizarlos adecuadamente.

Priorizar no es solo es decidir qué hacer en primer lugar, sino que hacer ahora con los recursos que tienes.

Amenazas de alta gravedad

No todos los incidentes son iguales. Algunos tienen un impacto limitado, pero otros pueden comprometer servicios esenciales, datos sensibles o incluso la continuidad del negocio.

Los incidentes de alta gravedad son aquellos que afectan directamente a la confidencialidad, integridad o disponibilidad de los sistemas críticos, y requieren una respuesta inmediata y coordinada.

Cuando una alerta tiene potencial real de interrumpir el negocio o exfiltrar datos sensibles en cuestión de minutos, la etiquetamos como P1. Son los incendios que no esperan a la reunión del lunes.

ENISA (European Union Agency for Cybersecurity) los define como aquellos que afectan a la confidencialidad, integridad o disponibilidad de activos esenciales y requieren acción inmediata, 24/7.

Recuerda: en triage, la etiqueta P1 no es un adorno. Si dudas, sobre‑prioriza y reduce después. Es más barato rebajar el nivel que lamentar un incidente de gran impacto.

Incidentes leves pero frecuentes

En el otro extremo, nos encontramos con los incidentes leves pero frecuentes. Las alertas de fuerza bruta o phishing genérico pueden clasificarse en P3.

Aunque no son críticos, su volumen puede saturar a los equipos. Gartner advierte de que los incidentes menores pueden consumir una parte sustancial de la jornada del soporte técnico si no se automatizan y se filtra correctamente el ruido.

Como una buena solucion, es un playbook automático (más adelante, vemos mejor de que se trata) que pueda cerrar cuentas temporalmente y notificar al usuario. Eso sí, la clave está en no ignorarlos, ya que su volumen puede revelar vulnerabilidades sistémicas (por ejemplo, son habituales los malos hábitos de contraseña).

Importancia del contexto

Un fallo en un servidor de desarrollo a las 3 AM no es urgente. El mismo fallo en producción en horario comercial es crítico.

Por eso, ante cualquier alerta, conviene hacerse siempre estas preguntas:

• ¿Qué sistemas afecta?
• ¿A cuántos usuarios?
• ¿Exponen datos sensibles?

Para estructurar este análisis, se recomienda utilizar marcos como SSVC (Stakeholder‑Specific Vulnerability Categorization) del CERT, que incorpora factores como la exposición pública, el impacto en los objetivos estratégicos y la urgencia de respuesta desde la perspectiva de los interesados.

SSVC utiliza un árbol de decisión con los factores Exploitation, Technical Impact, Automation y Mission Prevalence para recomendar si parchear de inmediato, programar la corrección o simplemente monitorizar la vulnerabilidad.

Fases de un proceso de triage eficaz

El triage no es solo una reacción rápida ante una alerta. Es un proceso estructurado, casi quirúrgico, que define cómo respondemos, qué priorizamos y a quién involucramos. No se trata de apagar fuegos, sino de tomar decisiones informadas que minimicen el impacto y optimicen recursos. Estas fases deben incluir evidencias forenses iniciales (logs, hashes, capturas de pantalla) para soportar análisis posteriores.

Aquí te comparto una secuencia de fases que, aunque pueden variar según la organización, siguen una lógica común que funciona.

Recolección y análisis inicial

Todo empieza con los datos. Una alerta, un correo sospechoso, un log que no cuadra. Aquí no se trata de correr, sino de observar, pero tampoco es cuestión de ser tortugas, en 10 min deberías tener todos los datos esenciales recopilados. ¿Qué ha pasado exactamente? ¿De dónde viene? ¿Es ruido o hay algo real detrás?

En esta fase recogemos toda la información posible: logs, eventos del SIEM, reportes de usuarios, incluso indicadores de compromiso si los hay. El objetivo es tener una imagen clara antes de etiquetar nada. Esta es la base para cualquier decisión posterior, todo debe quedar registrado: quién, qué, cuándo y cómo. Durante esta fase inicial es clave identificar claramente el alcance potencial del incidente.

Valora un filtrado exprés, basado en puntuaciones heurísticas o en machine learning, eliminando el ruido y deja en la bandeja del analista solo los incidentes que de verdad requieren atención.

Evaluación y etiquetado

Antes de escalar nada, el analista revisa tres datos esenciales: cómo entró el ataque, qué credenciales tocó y si las copias de seguridad siguen intactas. Con esa “foto rápida” coloca dos etiquetas:

• Táctica ATT&CK: Indica qué está haciendo el atacante. Puede ser Phishing, Privilege Escalation o Lateral Movement. Sirve para encontrar patrones y aprender de incidentes previos.
• Severidad P1/P2/P3: marca cuán urgente es responder. Con P1 no se duerme, pero un P3 se puede revisar con más calma.

Separar técnica y gravedad evita mezclar churras con merinas: “P1 + Privilege Escalation” no se trata igual que “P3 + Phishing genérico”. Un vistazo basta para que el siguiente turno sepa por qué y con qué prisa actuar.

ENISA recomienda usar taxonomías comunes (ATT&CK, VERIS, FIRST) para facilitar la coordinación, sobre todo si hay que escalar a un CERT externo.

Priorización y escalado

Los roles deben estar bien definidos y los canales de escalado, probados. No es el momento de improvisar.

Con la puntuación de riesgo y el contexto del activo, el incidente se coloca en la matriz Impacto × Probabilidad. Si supera el umbral, se escala al equipo de respuesta o a proveedores externos.

Regla de oro: Si un incidente afecta a >15% de usuarios/sistemas de producción o viola SLA de disponibilidad, lo escalamos como P1.

Herramientas clave para un triage moderno

Un triage eficaz no depende solo del talento del analista. Se necesitan herramientas que aceleren la detección, reduzcan el ruido y automaticen lo repetitivo. Aquí van las piezas clave del engranaje.

Sistemas SIEM y automatización SOAR

El SIEM (Security Information and Event Management) es el radar del SOC. Centraliza logs, detecta patrones y lanza alertas. Pero por sí solo no basta. Si no se configura bien, se convierte en una fábrica de ruido.

Los incidentes deben gestionarse de forma estructurada, trazable y medible. Es más que recomendable que los procesos de respuesta estén orquestados y documentados, y que el personal esté entrenado en su uso.

Ahí entra el SOAR (Security Orchestration, Automation and Response), que automatiza tareas repetitivas, como cerrar tickets, aislar máquinas, enviar notificaciones. Automatizar la respuesta inicial reduce el tiempo medio de contención y mejora la consistencia. Y ojo, automatizar no es deshumanizar, es liberar tiempo para lo que realmente importa, pero debe contar siempre con supervisión humana para evitar falsos positivos o negativos.

Playbooks y protocolos de actuación

Cuando el incidente es grave, no hay tiempo para improvisar. Por eso existen los playbooks que son guías de actuación predefinidas que indican qué hacer, quién lo hace y en qué orden. Ayudan a reducir el margen de error y a ganar tiempo cuando más importa.

Aquí tienes una guía exprés de triage para un incidente P1 (prioridad máxima):

• Aislar el sistema afectado (segmentación SDN, ACL, modo avión).
• Capturar evidencia volátil antes de reiniciar: memoria, sesiones, puertos.
• Formalizar la activación del protocolo P1: asignar un Incident Commander, registrar el incidente, notificar al equipo y documentar desde el minuto cero.
• Notificar a negocio y, si procede, a la AEPD en < 72 h.
• Escalar recursos (forense, legal, comunicación) sin pedir permiso.

Por otro lado, los protocolos de actuación son directrices más amplias que establecen los principios y las políticas generales para la gestión de incidentes. Mientras que un playbook se centra en el “cómo” para un incidente específico, un protocolo define el “qué” y el “por qué” a un nivel más estratégico.

Este tipo de protocolos deben estar definidos, probados y accesibles. No basta con tenerlos en un word olvidado de la mano de dios… hay que entrenarlos.

Tecnologías emergentes

Como todo en IT, el triage también evoluciona. Estas son algunas tecnologías que están cambiando las reglas del juego:

• XDR (Extended Detection and Response): rompe los silos entre endpoint, red, correo y nube. Ofrece una visión unificada y correlacionada. En este artículo os conté más al detalle: XDR: Detección y Respuesta Extendida
• Threat Intelligence en tiempo real: integración directa con fuentes OSINT, feeds comerciales y plataformas como MISP o MITRE CTI.
• IA generativa y LLMs: para redactar informes, resumir alertas complejas o incluso sugerir respuestas automáticas. No reemplazan al analista, pero sí le dan superpoderes.
• UEBA (User and entity behavior analytics) o análisis de comportamiento: detecta desviaciones en el comportamiento de usuarios y entidades. Ideal para detectar movimientos laterales o accesos anómalos.

Factores humanos y buenas prácticas en la gestión del triage

Aunque el triage tiene una base técnica clara, su eficacia depende en gran parte de las personas que lo ejecutan y de cómo se organizan. No basta con tener herramientas potentes: hace falta criterio, coordinación y experiencia.

Equipos bien coordinados

Una respuesta eficaz ante incidentes requiere roles definidos, comunicación fluida y procedimientos claros. El triage no es un trabajo en solitario. Analistas, responsables de seguridad y personal técnico deben trabajar coordinados. Y si el incidente escala, puede ser necesario implicar también a quienes gestionan aspectos legales de cumplimiento normativo (como el RGPD) o la comunicación con terceros.

Evidentemente, el tiempo es el mismo para todos, y cada persona tiene una jornada laboral y dentro de su jornada laboral, es realmente eficiente un número de horas determinadas. Por lo que un equipo de trabajo reducido, encargados de gestionar una gran cantidad de incidentes o alertas, les va a generar un gran estrés, y será mucho más complicado ser realmente eficiente. Por eso, contar con un equipo más amplio y bien distribuido permite repartir la carga de tareas, mantener la calidad del análisis y responder mejor ante situaciones críticas.

En España, este trabajo en equipo puede extenderse más allá de nuestra organización. Cuando un incidente supera ciertas capacidades o tiene impacto nacional, entra en juego el INCIBE-CERT, que actúa como equipo de referencia para ciudadanos, empresas, instituciones académicas y operadores críticos. Su colaboración es clave en incidentes complejos, especialmente cuando se requiere coordinación con otros CERTs o con organismos públicos.

Capacitación continua

En la actualidad, existe una gran demanda de profesionales que sepan de repuestas ante incidentes, por eso nuestro Curso de triage informático: Priorización y respuesta a incidentes y esta guía te vendrá de perlas, de cara a poder suplir de manera introductoria esa gran demanda, tanto para el sector público como privado.

El NIST recomienda documentar cada incidente y revisar qué funcionó y qué no. Esto no solo mejora el triage, sino que fortalece todo el proceso de respuesta.

Obligación de notificar incidentes: lo que dice la ley

En España, no todo queda en buenas prácticas. Según el Real Decreto-ley 12/2018 y su desarrollo en el Real Decreto 43/2021, ciertas organizaciones están legalmente obligadas a notificar los incidentes de ciberseguridad que sufran. Este tipo de notificación debe contener elementos específicos (tipo de incidente, alcance, impacto estimado).

Esto aplica a:

• Operadores de servicios esenciales (como energía, salud, transporte…)
• Proveedores de servicios digitales (como plataformas en la nube o marketplaces)
• Operadores críticos del sector privado

En estos casos, el INCIBE-CERT actúa como CSIRT de referencia, y es el organismo al que deben dirigirse las notificaciones. La ley exige reportar tanto los incidentes que hayan tenido un impacto real como aquellos que, aunque no hayan causado daño aún, puedan afectar a la prestación de servicios esenciales (acuérdate de lo que ocurrió el pasado 28 de abril de 2025 en España, con el corte de luz…).

Desde 2022, la Ley 8/2022 amplía estas obligaciones a operadores críticos privados, y la futura transposición de NIS 2 (prevista para finales de 2025) endurecerá aún más los requisitos de notificación y las sanciones por retraso.

Esto convierte al triage en una herramienta no solo técnica, sino también regulatoria, ya que ayuda a determinar si un incidente debe ser notificado, a quién y con qué urgencia.

Lecciones aprendidas post incidente

Cada incidente es una oportunidad para afinar el proceso. ¿Se clasificó bien? ¿Se priorizó a tiempo? ¿Se escaló correctamente? Aquí es donde entra en juego la mejora continua. Nos toca revisar lo ocurrido, ajustar los playbooks y compartir aprendizajes dentro del equipo (y con otros, si procede) es parte del ciclo de madurez.

Aquí, el INCIBE-CERT también juega un papel importante, ya que publica informes, alertas y guías que permiten aprender de casos reales y evitar reinventar la rueda.

En muchos casos, contar con una auditoría externa puede ayudar a detectar puntos ciegos en el proceso. La norma ISO/IEC 27001:2022 exige revisar periódicamente la eficacia de la gestión de incidentes y documentar formalmente las lecciones aprendidas para que no se pierdan en el olvido.

Conclusiones

El triage exige criterio, y el criterio se entrena. Las amenazas evolucionan, las herramientas cambian y los atacantes no se quedan quietos.

Si pretendías estudiar un grado o FP de Tecnología, y al terminar pensabas que ya estaba todo hecho… Spoiler: va a ser que no (Suerte que contamos con las formaciones de OpenWebinars!) Por eso, en el triage informático y otras muchas áreas de IT, una buena práctica es mantener al equipo actualizado con simulacros, formación técnica, elaboración de frameworks de documentación, análisis inicial, avanzado y post-mortem de incidentes reales, etc…

En cualquier empresa, por pequeña que sea, aunque no disponga de un departamento dedicado a ello, es muy importante disponer de unas estrategias sólidas de contención y recuperación ante desastres, para minimizar al máximo posible lamentos que pudieron ser evitables.

De cara al futuro, veremos como las herramientas se vuelven cada vez más sofisticadas gracias a la IA, pero tener en cuenta que “los malos” también usan la IA, por lo que deberemos seguir aprendiendo todo lo posible para hacer bien nuestros deberes.

Especialmente en este caso documentar, colaborar, compartir y practicar (en casos reales a ser posible), es lo que más nos puede ayudar a ser mejores profesionales y poder vitaminar nuestros entornos para convertirlos en sitios más seguros y confiables. Gracias al uso de estas buenas prácticas mejoraremos la imagen y reputación de nuestras compañías.