osquery convierte tu parque en una tabla que puedes consultar

Se publica una vulnerabilidad en una librería muy usada. La pregunta desde dirección es simple: ¿nos afecta, y en cuántas máquinas? La respuesta honesta en la mayoría de las organizaciones lleva dos días, implica preguntar a los equipos en un canal de chat, y está mal.

La misma forma de pregunta llega durante una auditoría, durante un incidente, y cada vez que alguien quiere saber qué está corriendo de verdad en los portátiles. Es una pregunta de inventario, y el inventario es algo que casi todas las organizaciones creen tener y casi ninguna tiene.

La idea es que el sistema operativo es una base de datos

osquery expone el estado de una máquina como tablas SQL. Procesos en ejecución, puertos a la escucha, paquetes instalados, usuarios, tareas programadas, módulos del núcleo, extensiones del navegador, estado del cifrado de disco, certificados, sockets abiertos con el proceso que los posee.

Y entonces consultas:

SELECT name, version FROM deb_packages WHERE name LIKE '%openssl%';

Ejecuta eso en el parque entero y tienes la respuesta a la pregunta de la vulnerabilidad en el tiempo que tarden en llegar los resultados. Ese es el argumento entero, y basta.

Funciona en Linux, macOS y Windows con un esquema en buena medida compartido, lo que importa porque la mayoría de los parques son mixtos y la mayoría de las herramientas de inventario no lo son.

Dos modos, y en el programado está el coste

Las consultas en vivo son puntuales: preguntas al parque ahora y recibes respuestas. Es el caso de uso de respuesta a incidentes e inventario, y el que aporta valor el primer día.

Las consultas programadas se ejecutan con un intervalo en todos los equipos y envían resultados a tu pipeline de registro, o como foto completa o como diferencial mostrando qué cambió desde la última vez.

El segundo modo es donde se tuercen los despliegues. Una consulta sobre la tabla de procesos cada treinta segundos en dos mil equipos produce un volumen enorme de datos de registro, que después cuesta dinero ingerir y almacenar exactamente como se describe en los logs son la línea que crece.

Disciplina que funciona: programa un número pequeño de consultas con intervalos sensatos, prefiere resultados diferenciales para obtener cambios en vez de estado repetido, mantén las tablas que cambian rápido como la de procesos solo en consulta en vivo salvo que tengas una necesidad concreta de detección, y mide el volumen de datos por equipo antes de desplegar a lo ancho.

Vigila además el coste de recursos en el equipo. Algunas tablas son caras de materializar, y una consulta programada mal elegida es una queja de rendimiento de todos los usuarios a la vez.

Qué consultar de verdad

Empieza por las preguntas que ya te hacen.

Inventario y cumplimiento. Software instalado y versiones, nivel de parcheo del sistema, cifrado de disco activado, bloqueo de pantalla configurado, estado del cortafuegos, antivirus en marcha. Este conjunto responde a buena parte de un cuestionario de auditoría y es el retorno más rápido, y alimenta directamente la disciplina de evidencia de automatizar la evidencia de SOC 2.

Deriva de configuración. Usuarios con permisos de administrador local, claves SSH en directorios personales, entradas de elevación de privilegios, servicios activados al arranque, tareas programadas inesperadas.

Estado relevante para seguridad. Puertos a la escucha con el proceso que los posee, conexiones establecidas hacia destinos inesperados, extensiones del navegador, módulos del núcleo, binarios en directorios temporales, ficheros modificados recientemente en rutas del sistema.

La pregunta concreta de la semana. Aquí es donde las consultas en vivo se ganan su sitio, y es por lo que la herramienta sigue siendo útil después del proyecto inicial.

Existen paquetes públicos de consultas y son un punto de partida razonable, con la misma advertencia que en todo lo demás: están escritos para un entorno genérico y serán ruidosos en el tuyo.

Detección con ello, con cuidado

osquery puede apoyar la detección, y merece ser honesto sobre el encaje.

Es bueno en detección basada en estado: apareció una cuenta nueva de administrador local, hay un servicio inesperado activado, apareció un binario en un directorio temporal, se añadió un mecanismo de persistencia. Las consultas programadas diferenciales hacen visibles estas cosas como cambios y no como un estado que hay que interpretar.

Es malo en detección basada en eventos. El modelo de sondeo significa que un proceso que arranca y termina entre dos ejecuciones es invisible, así que no puede sustituir a una herramienta situada en la frontera de las llamadas al sistema. Ese es el trabajo de la detección en tiempo de ejecución de Falco te dice qué hizo un contenedor, y las dos son complementarias, no alternativas.

Encamina los resultados a tu SIEM en vez de construir un sistema de alertado paralelo, que es el mismo argumento de detección como código. Las reglas van donde ocurre la correlación.

El despliegue y la parte que sí es difícil

El agente es sencillo. La gestión no, que es por lo que existen herramientas de gestión de parque alrededor.

Necesitas una forma de distribuir configuración y paquetes de consultas sin editar ficheros en los equipos, una forma de recoger resultados de forma central, una forma de lanzar una consulta en vivo al parque desde un sitio, y una forma de saber qué equipos no están reportando. Esta última es la que más importa y la más fácil de descuidar: un equipo que dejó de reportar se parece exactamente a un equipo que no tiene nada que reportar.

Varios gestores de parque libres y comerciales dan esto. Uses el que uses, trata el paquete de consultas como código en un repositorio con revisión, por las mismas razones por las que las reglas de detección van en uno.

Despliega por etapas. Un grupo piloto, después un departamento, después el parque, vigilando el uso de recursos y el volumen de datos en cada paso.

La cuestión de gobernanza que hay que responder primero

Esta herramienta puede ver muchísimo sobre la máquina de una persona, y desplegarla sin ser explícito al respecto es un error que daña la confianza de forma permanente.

Decide y publica qué recoges y qué deliberadamente no. El historial del navegador, el contenido de documentos, las pulsaciones de teclado y los nombres de ficheros personales son ejemplos de cosas que no deberías recoger, y decirlo con claridad vale más que cualquier control técnico. Restringe quién puede lanzar consultas en vivo, registra cada consulta lanzada y quién la lanzó, y haz que ese registro sea revisable.

En Europa esto no es solo una cuestión de confianza. Vigilar los dispositivos de las personas empleadas activa obligaciones de protección de datos y, en muchas jurisdicciones, consulta con la representación de las personas trabajadoras. Documenta la finalidad y la base jurídica antes del despliegue y no después, en la línea de el RGPD como controles de ingeniería.

Lo que se olvida

• Un equipo que deja de reportar es un hallazgo. Alerta sobre ello, o tu cobertura se degrada en silencio.
• El esquema difiere por plataforma. Una consulta escrita para Linux puede no devolver nada en macOS en vez de fallar de forma ruidosa.
• Las diferencias de versión importan. Las tablas y columnas cambian entre versiones; fija la versión del agente y prueba los paquetes contra ella.
• Corre con privilegios altos. El agente y su canal de configuración son un objetivo valioso, y la configuración es en la práctica selección remota de código a ejecutar.
• Los resultados son datos personales en algunas jurisdicciones. La conservación aplica.
• Responde preguntas, no arregla nada. Combínalo con una herramienta de gestión de configuración, o tendrás informes excelentes sobre problemas que nadie remedia.

Qué hacer esta semana

Coge el último aviso de vulnerabilidad que te importó y escribe la consulta que habría respondido a "¿nos afecta?". Ejecútala en diez máquinas. El tiempo que tardas hoy en obtener esa respuesta, comparado con el que tardarías con un agente desplegado, es el argumento de negocio entero, y normalmente se mide en días frente a segundos. Lo acotamos en la fase de detección de un proyecto de seguridad.