Escalar bien — el reporte que sirve

El reporte de traspaso cuenta el incidente, no tu tarde. A quien lo recibe no le sirve «estuve dos horas revisando y al final encontré algo raro»; le sirve «la cuenta svc-backup abrió sesión interactiva externa a las 03:20 y cifró el recurso de finanzas a las 03:30». Los hechos, con su marca de tiempo, en el orden en que ocurrieron. La narración de tu proceso se queda para ti; el reporte es para que otro actúe.

Un reporte lleno de rodeos obliga al que lo recibe a rehacer tu trabajo para encontrar los datos entre la prosa. Escribir los hechos directos es lo que hace que el traspaso ahorre tiempo en vez de duplicarlo.

Un reporte honesto separa la observación de la interpretación. «Vi cuarenta fallos de contraseña seguidos y luego una sesión aceptada» es un hecho: está en los registros. «La cuenta está comprometida por fuerza bruta» es una interpretación: probablemente cierta, pero es tu lectura de los hechos. Mezclarlas hace que el nivel 2 no pueda distinguir el dato de tu conjetura, y si tu conjetura falla, arrastra al dato con ella.

La forma correcta es dar los dos, marcados: esto observé, esto concluyo. Así, si el nivel 2 tiene información que tú no tenías, puede reinterpretar tus hechos sin descartar tu trabajo. La evidencia es de todos; la conclusión es tuya y revisable.

Escalar es también decir con qué urgencia y qué pides. No es lo mismo «incidente, cuenta comprometida, cifrado en curso, pido aislar el equipo ya» que «actividad sospechosa, para revisar cuando puedan». La severidad orienta la cola del que recibe: lo crítico se atiende antes que lo que puede esperar. Y pedir algo concreto —aislar un equipo, deshabilitar una cuenta, conservar los registros— convierte el reporte en una acción, no en una notificación.

El nivel 1 no ejecuta la contención en incidentes grandes, pero sí la recomienda con criterio. Un reporte que describe el problema y no dice qué hacer con él deja al que lo recibe empezando de cero en la decisión más urgente.

Un buen reporte deja indicadores que otro equipo puede buscar en sus propios registros: el destino externo del canal de mando, el nombre de la tarea de persistencia, la cuenta comprometida. Son concretos y reutilizables —«el dominio updates-delta-cargo.net» sirve para rastrear si el mismo canal aparece en otra máquina; «vi algo raro en la red» no sirve para nada—. El indicador es lo que hace que el trabajo de un turno proteja a toda la empresa, no solo al equipo que lo vio.

Elegir el indicador estable es parte del oficio: el destino del canal o el nombre de la tarea aguantan, mientras que un identificador de sesión suelto cambia y no sirve para buscar mañana. Se reporta lo que otro puede volver a encontrar.

Cuando escalas, adjuntas una copia de los registros que sostienen tu veredicto. Esa copia puede acabar sirviendo a una investigación larga o incluso a algo con consecuencias legales, y entonces alguien preguntará si se pudo manipular por el camino. Lo que la protege no es esconderla, sino dejar escrito su recorrido: quién la tomó, cuándo, de qué fuente y cómo se ha guardado desde entonces. Ese rastro es lo que permite afirmar que lo que llega arriba es lo mismo que estaba en el origen.

El analista de nivel 1 no lleva el caso hasta el final, pero sí abre bien ese rastro al escalar. Una prueba sin origen anotado pierde la mitad de su peso, por muy clara que parezca.

El incidente consolidado de Delta tiene un hilo: una sola cuenta que aparece tanto en el acceso externo como en el cifrado del recurso de finanzas. Esa es la que el reporte pide deshabilitar. Localízala en la consola.