Integración con el SIEM

Falco puede escribir sus alertas en varios canales (salida estándar, archivo, syslog, un programa o un punto HTTP) y existe un reenviador, Falcosidekick, que las distribuye a más de cincuenta destinos. Pero el canal es lo de menos si el contenido no tiene estructura. Una línea de texto libre obliga a analizar con expresiones frágiles; una línea JSON ya trae cada dato en su campo. Por eso se configura la salida en JSON.

Una alerta en JSON es un objeto con la hora, la regla, la prioridad, el nodo y un bloque de campos del evento. Eso es lo que el SIEM indexa y lo que permite filtrar, agrupar y unir.

Entre la alerta y el SIEM hay un mapeo: una tabla que dice a qué campo del SIEM va cada campo de la alerta. Lo que el mapeo no nombra no se indexa, o se guarda sin forma. Un campo olvidado es un hueco silencioso: la alerta llega, pero sin el dato que habría permitido unirla con otras fuentes.

Abre salida/alertas.jsonl para ver qué campos trae el bloque de campos del evento, y siem/mapeo-campos.csv para ver cuáles recoge el mapeo.

Un canal puede fallar sin ruido. Lo que protege es comparar siempre las dos puntas: cuántas alertas emitió el sensor y cuántas recibió el SIEM. Si cuadran todos los días y un día no, ese día se perdió información, y hay que averiguar por qué antes de confiar en los totales.

Abre siem/ingesta-diaria.csv y calcula cuántas alertas se perdieron el 6 de octubre. Lee también siem/estado-ingesta.log.

La alerta de shell del sensor tiene más valor al unirla con la auditoría de la API, como en la sala 1: un shell sin una petición de exec que lo explique es lo que merece atención. Esa unión la hace el SIEM con una regla de correlación: dos fuentes, una clave común (el pod) y una ventana de tiempo.

Abre siem/reglas-correlacion.txt y busca la regla que une el shell con la auditoría.

Si el sensor se cae, el SIEM no recibe alertas, y un SIEM sin alertas se ve igual que un clúster tranquilo. Para no confundirlos, se vigila el silencio: si de un nodo no llega nada en un tiempo razonable, o la cifra de la ingesta cae de golpe, se avisa. Lo mismo vale para el receptor: una cuota excedida es una pérdida de datos de seguridad, no un detalle de facturación.