El informe de vulnerabilidades que el SOC sí usa

Antes de leer un solo hallazgo, se pregunta qué equipos están en el informe. Un informe de vulnerabilidades solo habla de lo que el escáner alcanzó, y los activos críticos que no están en él son los más peligrosos de ignorar: parecen limpios porque no hay filas, cuando lo que no hay es cobertura. Es el control 1 de CIS visto desde el otro lado.

Ejecuta inventario | where criticidad == "crítica" para ver los activos de criticidad crítica y informe_hosts para ver cuáles reporta el escáner.

En informe_hosts, el servidor de archivos aparece con cero hallazgos y la columna autenticado en «no». Un escaneo sin credenciales ve lo que se ve desde la red: puertos, banners y versiones expuestas. Un escaneo autenticado entra al equipo con una cuenta de lectura y ve los paquetes y las configuraciones instaladas. Por eso uno sin credenciales encuentra mucho menos, y cero hallazgos en uno de esos no quiere decir que el equipo esté al día.

La columna estado cuenta una historia que el puntaje no cuenta. Una fila nueva apareció desde el último escaneo; una corregida ya no se detecta; una reabierta fue corregida y el escáner la volvió a ver. Esa última es la más interesante para el SOC: algo deshizo el parche, o el cambio nunca llegó a todas las copias del equipo.

Ejecuta informe_hallazgos | where estado == "reabierta".

Un hallazgo es tan útil como lo reciente que sea su escaneo. Ejecuta informe_hosts | sort by ultimo_escaneo asc: la primera fila es la fotografía más vieja del informe. Hoy es 5 de octubre; el cálculo es la diferencia en días entre esa fecha y hoy.

De un informe de quinientas filas, el analista toma pocas cosas para el caso: qué hallazgos abiertos tiene el equipo de la alerta, con qué puntaje y desde cuándo, cuándo se escaneó por última vez y si fue con credenciales. Eso cabe en tres líneas del ticket. Lo demás es trabajo de gestión de vulnerabilidades, y está bien que lo sea.