Acciones remotas y su rastro de auditoría

Las acciones remotas son las únicas operaciones de la consola que cambian un equipo en vez de observarlo. Por eso necesitan un rastro propio: quién la lanzó, con qué rol, sobre qué equipo, bajo qué ticket y con qué resultado. Sin él pasan tres cosas. Quien analiza el equipo después no distingue lo que hizo el atacante de lo que hizo la defensa (un proceso terminado desde la consola parece un proceso que murió solo). Nadie puede reconstruir la línea de tiempo de la respuesta. Y nadie puede demostrar que la acción tenía autorización.

Abre la estación y lee roles-de-la-consola.txt y acciones-remotas.csv. La regla de la consola es que toda acción remota lleva un ticket de incidente. Una fila sin ticket puede ser una urgencia legítima, pero es la primera que un auditor va a preguntar, y a quien la ejecutó hay que pedirle el motivo y regularizarla.

Aislar un equipo no tiene fecha de caducidad propia: dura hasta que alguien lo libera. Por eso el registro importa también al final: cuánto estuvo aislado un equipo es parte del impacto del incidente y se informa. La liberación debe quedar con el mismo ticket que el aislamiento.

El registro anota también lo que no llegó a hacerse. Una acción rechazada es un dato: muestra que el control de roles funcionó y que alguien intentó algo que su rol no permite. Casi siempre es una urgencia bien intencionada y no un ataque, pero merece una pregunta a su autor y, si el caso lo justifica, que un respondedor lo haga con el ticket.

Mira la fila de las 14:05.