¿Cuándo debe un analista de SOC escalar un incidente a Tier 2 o a IR?

Qué es una escalada profesional

La escalada es la transferencia de responsabilidad o el intercambio de responsabilidad a una entidad con mayor autoridad, experiencia o acceso. Se requiere cuando existe una brecha entre las necesidades del incidente y la capacidad de tratamiento actual: no hay permiso para recopilar un Artifact específico, es necesario aislar un servidor de producción, existe una indicación de movimiento lateral, o la decisión puede afectar la actividad comercial.

Es importante distinguir entre la escalada funcional y la escalada jerárquica. La escalada funcional se traslada a un experto, por ejemplo, Tier 2, un investigador de DFIR, un administrador de Active Directory o un equipo de nube. La escalada jerárquica asciende a un gerente de turno, CISO, dirección o entidad comercial debido a un impacto, riesgo o necesidad de decisión. En un incidente complejo, es posible que ambos caminos ocurran simultáneamente.

La escalada no exime al analista inicial de la responsabilidad de la documentación y la continuidad. Hasta que la siguiente parte confirme la recepción, el propietario del Ticket debe mantener el seguimiento, evitar acciones destructivas y señalar qué acciones urgentes aún están pendientes.

La diferencia entre Tier 1, Tier 2 y Incident Response

Tier 1 verifica que la alerta es relevante, comprueba el contexto básico, elimina el ruido evidente e identifica las señales que requieren una profundización. Tier 2 conecta fuentes adicionales, ejecuta consultas complejas, construye una línea de tiempo amplia, comprueba el Scope y formula una Hypothesis. El equipo de Incident Response interviene cuando hay un incidente confirmado o una sospecha significativa que requiere contención, recopilación de pruebas, coordinación entre sistemas y recuperación.

El límite no se define solo por el tiempo. Un analista de Tier 1 puede resolver un caso complejo si tiene la capacitación y la autoridad, mientras que un incidente simple puede requerir IR debido a un activo sensible. Por lo tanto, cada organización debe definir previamente las autoridades: quién puede aislar un Endpoint, deshabilitar una cuenta, bloquear una dirección, restablecer un Token, recopilar una Memory Image o contactar a un proveedor externo.

Un buen modelo también presenta un SLA para la escalada: cuánto tiempo se permite dejar un incidente nuevo sin Owner, en qué ventana de tiempo se debe transferir un incidente High, y cuándo un gerente de turno debe recibir una actualización incluso si la investigación aún no ha terminado.

Disparadores técnicos para la escalada

Un disparador técnico es una señal que aumenta la probabilidad de un ataque, el alcance del incidente o la necesidad de una capacidad especial. Ejemplos clave son la ejecución de código desconocido en un servidor crítico, Credential Dumping, cambio de permisos Privileged, Persistence, movimiento lateral, uso de una cuenta de servicio, eliminación de logs, desactivación de EDR, comunicación con infraestructura hostil o una secuencia de varias técnicas MITRE ATT&CK.

La falta de datos también puede justificar una escalada. Si el EDR no está disponible, el servidor no envía logs o hay un Clock Skew significativo, Tier 1 no puede cerrar con seguridad. En este caso, el paquete de escalada debe especificar explícitamente lo que falta y lo que se necesita recopilar.

Otro disparador es un Scope inestable. Si el mismo Hash, usuario o IP aparece en varios activos, no trate cada alerta por separado. Escaléelo a un incidente unificado para evitar acciones contradictorias y comprender si se trata de una campaña más amplia.

• Activo crítico: Domain Controller, servidor de respaldo, sistema financiero o entorno de Production.
• Identidad sensible: Global Admin, cuenta de servicio o usuario con acceso a información sensible.
• Comportamiento con impacto: Cifrado de archivos, Exfiltration, Persistence o Lateral Movement.
• Afectación de la capacidad de monitoreo: Eliminación de logs, desactivación de Agent o cambio de Audit Policy.
• Incidente multisistema: Identidad, Endpoint, correo electrónico y nube en la misma Timeline.
• Necesidad de una acción irreversible o con impacto comercial.

Disparadores comerciales y organizacionales

La gravedad técnica por sí sola no es suficiente. Un inicio de sesión anómalo en una cuenta de prueba puede ser Low, mientras que el mismo inicio de sesión en una cuenta de administrador financiero antes de una transferencia de pago podría recibir una Priority alta. Verifique la criticidad del servicio, el tipo de información, el número de usuarios, la ventana de actividad, la regulación relevante y la dependencia de los procesos comerciales.

Hay incidentes en los que es necesario involucrar a una parte no técnica temprano: sospecha de fuga de información personal, actividad de un empleado, afectación a un cliente, incidente con un proveedor, interrupción de un servicio público o un aviso de ransomware. El analista no decide por sí solo sobre la obligación de informar o el mensaje externo; proporciona hechos y activa el canal de coordinación definido en el plan de respuesta.

Si no existe una política clara, no se debe inventar durante el incidente. Se debe contactar al gerente de turno y documentar que la decisión se tomó a un nivel de autoridad superior.

Qué debe incluirse en el paquete de escalada

Un buen paquete de escalada permite al siguiente interlocutor comenzar desde el punto en que finalizó la revisión, sin repetir las mismas acciones. Debe ser lo suficientemente conciso para una lectura rápida y lo suficientemente preciso para una toma de decisiones. Empiece con una frase: qué sucedió, a quién, cuándo y por qué está escalando.

Luego, separe los hechos, la interpretación y las suposiciones. Adjunte los identificadores de Incident y Alert, los activos y usuarios, la Timeline principal, las Queries realizadas, las pruebas de respaldo, las acciones de respuesta, las limitaciones de información y la evaluación del impacto. Termine con una pregunta clara: “Se requiere una decisión sobre el aislamiento del servidor y la recopilación de Memory”, no “Por favor, verifique”.

Si el incidente está activo, indique también el Next Check Time y quién mantiene el Ownership hasta la aceptación de la escalada. No se deben enviar archivos sospechosos a través de un canal no autorizado ni pegar información sensible en un sistema no destinado a ello.

• Resumen de 2-4 líneas.
• Severity y Priority con justificación.
• Entities: Usuarios, Hosts, IP, Domains, Hashes.
• Timeline concisa de los eventos esenciales.
• Acciones ya realizadas y sus resultados.
• Evidencia y fuentes de datos, incluyendo brechas.
• Scope conocido y Scope aún no revisado.
• La pregunta o decisión requerida del siguiente equipo.

Cuándo involucrar a IT, Legal, la dirección o un tercero

El equipo de IT es necesario cuando hay que realizar un cambio operativo: desconexión de un servicio, restablecimiento de una cuenta, bloqueo de una Rule, restauración desde una copia de seguridad o verificación de un Change. El equipo de IR o DFIR es necesario para la recopilación y preservación de pruebas, un Scope amplio y una contención coordinada. Legal y Privacy se involucran cuando existe la posibilidad de una exposición legal, contractual o regulatoria. La dirección es necesaria cuando la decisión afecta la continuidad del negocio, a los clientes o la comunicación.

La consulta a un proveedor MSSP, Cloud Provider, Cyber Insurance o autoridades se realizará según el acuerdo y el procedimiento. Documente quién aprobó, qué se transfirió, por qué canal y qué se conservó. El propósito de la documentación no es la burocracia, sino mantener la continuidad y la responsabilidad.

Ejercicio: Ocho escenarios

Medición de la calidad de las escaladas

No mida solo cuántos incidentes se escalaron. Verifique cuántas escaladas se aceptaron sin solicitudes de complementos, cuántas se devolvieron por falta de evidencia, el tiempo desde la identificación hasta la escalada, la tasa de incidentes que resultaron críticos y qué disparadores recurrentes no se definieron en el Playbook.

Hay que tener cuidado con el Gaming: un objetivo de “menos escaladas” puede fomentar el cierre temprano; un objetivo de “escalada en cinco minutos” puede crear transferencias vacías. La medida correcta combina velocidad, calidad, precisión e impacto.

Lista de verificación práctica

• ✓¿El incidente excede mi autoridad de acción?
• ✓¿Están involucrados activos o identidades críticas?
• ✓¿Existe alguna indicación de afectación activa o de expansión del Scope?
• ✓¿Falta información que no puedo obtener por mi cuenta?
• ✓¿Se requiere una acción con impacto comercial?
• ✓¿He creado un resumen, una Timeline y una lista de pruebas?
• ✓¿He formulado una pregunta clara para el siguiente interlocutor?
• ✓¿He documentado el Owner y la próxima hora de verificación?

Errores comunes

• Escalar sin resumir lo que ya se ha verificado.
• Esperar al 100% de certeza mientras el ataque está activo.
• Usar la Severity de la herramienta como único criterio.
• Transferir la responsabilidad sin asegurarse de que la otra parte la haya recibido.
• Involucrar a demasiadas partes innecesariamente y crear canales de comunicación paralelos.
• Realizar aislamientos o deshabilitaciones más allá de la autoridad sin aprobación.

Resumen y CTA

Elija tres incidentes que haya manejado en el laboratorio y escriba para cada uno un paquete de escalada de una página. Luego compárelo con la estructura de investigación del artículo “Cómo investigar una alerta de seguridad en un SOC de principio a fin”. En el curso Cybersecurity & AI de HPI, se practica el trabajo con alertas, SIEM, documentación y escalada como parte de un proceso SOC práctico.

Preguntas frecuentes