Falco te dice qué hizo un contenedor, no qué podría hacer

Un clúster pasa todos los escaneos. Las imágenes están limpias, las políticas se aplican, la puntuación de postura está en verde. Después explotan un fallo de deserialización en una aplicación, se abre una shell inversa dentro de un contenedor en marcha, y el atacante pasa cuatro días leyendo secretos y moviéndose lateralmente. Nada en la cadena de herramientas previa al despliegue estaba mirando, porque ninguna de ellas vigila un proceso que ya ha arrancado.

Ese es el hueco que llena la detección en tiempo de ejecución, y es la capa más débil de casi todos los programas de seguridad cloud. Los equipos invierten mucho en lo que entra en el clúster y casi nada en lo que pasa dentro.

Qué ve de verdad

Falco observa eventos a nivel de núcleo, históricamente a través de un módulo del núcleo y ahora normalmente mediante eBPF, y los evalúa contra reglas. Como se sitúa en la frontera de las llamadas al sistema, ve lo que ocurrió de verdad y no lo que declaró un manifiesto.

Los eventos que merecen alerta caen en un número pequeño de categorías, y esta lista es casi todo el valor:

• Una shell abierta dentro de un contenedor. En un contenedor de producción que ejecuta una sola aplicación, una shell interactiva o es un ingeniero depurando de una forma que debería estar prohibida, o es una intrusión. En cualquier caso quieres saberlo.
• Un proceso escribiendo en un directorio donde no debería escribir nunca, como una ruta de binarios, que es como se establece normalmente la persistencia.
• Una conexión saliente inesperada, en particular desde un contenedor que solo debería recibir tráfico.
• Lecturas de ficheros sensibles: el token de la cuenta de servicio, un secreto montado, el socket del tiempo de ejecución de contenedores.
• Un contenedor corriendo con privilegios inesperados, o un proceso intentando escapar del espacio de nombres.
• Ejecución del gestor de paquetes en tiempo de ejecución, que en una imagen de producción significa que alguien está instalando herramientas.

Este último es un buen ejemplo de por qué importa esta capa. Un escáner de imágenes no puede decirte que se descargó y ejecutó una herramienta después de que el contenedor arrancara, porque no estaba en la imagen.

Las reglas por defecto son ruidosas, y ajustarlas es el proyecto

Instala Falco con las reglas por defecto en un clúster con trabajo y recibirás cientos de alertas al día. Casi todas serán comportamiento legítimo, y en dos semanas el canal estará silenciado. Esta es la única razón por la que fracasan casi todos los despliegues de Falco.

Planifica el ajuste como el trabajo, en vez de la instalación como el trabajo.

Ejecuta en modo auditoría primero durante dos semanas, recogiendo sin alertar. Después coge las reglas con más volumen y mira qué las disparó. Encontrarás tus propios trabajos de integración continua, tu agente de copias, el contenedor de inicialización de tu malla de servicios y una comprobación de salud haciendo algo inusual.

Escribe excepciones contra el proceso, la imagen y el contenedor concretos, no desactives la regla. Una regla desactivada es un punto ciego permanente; una excepción acotada es una decisión documentada. Mantén las excepciones en control de versiones con un comentario que explique cada una, y revísalas cada trimestre, porque las excepciones añadidas durante un incidente se vuelven permanentes por defecto.

Y después estrecha sin piedad. Diez reglas que se disparan solo ante comportamiento genuinamente inesperado valen más que doscientas que saltan constantemente, y el razonamiento es idéntico al de alertas que la gente atiende: en cuanto la tasa de falsos positivos pasa de aproximadamente uno de cada tres, la atención humana se derrumba.

Adónde tienen que ir las alertas

Una alerta que llega a un canal que nadie vigila es una entrada de registro con pasos de más.

Encamina la salida de Falco a tu SIEM y no a un panel, para que se correlacione con todo lo demás. Wazuh funciona bien para un equipo pequeño, como se ve en Wazuh como SIEM de un equipo pequeño, y lo mismo aplica a una plataforma comercial.

Cada regla necesita una severidad y un destino decididos de antemano. Una shell en un pod de producción avisa. Una lectura de fichero sensible en un namespace de desarrollo se convierte en un ticket. Casi todo lo demás se convierte en contexto buscable y nada más.

Y cada regla que alerta necesita una respuesta documentada antes de dispararse. ¿Qué hace quien está de guardia cuando se abre una shell en un pod de pagos a las tres de la madrugada? Si la respuesta no está escrita, la alerta produce confusión en vez de contención, que es la disciplina de el runbook que usas a las tres de la madrugada.

La respuesta, y la trampa de automatizarla

La tentación es matar el pod automáticamente ante una detección de severidad alta. Resístete al principio.

Matar el pod destruye la evidencia y, ante un falso positivo, provoca una caída. Además avisa al atacante, que ahora sabe que le han detectado y puede acelerar.

La secuencia que funciona es capturar primero: el árbol de procesos, las conexiones de red, el estado del sistema de ficheros del contenedor. Falco puede disparar una captura, y algunos despliegues toman una instantánea del nodo. Después contén aplicando una política de red que aísle el pod en vez de borrarlo, lo que detiene el movimiento lateral preservando el estado en marcha para el análisis forense. Y solo entonces remedia.

La respuesta automática pertenece al conjunto pequeño de detecciones en las que tienes confianza y donde la velocidad importa de verdad, como la minería de criptomonedas, y solo después de que la regla lleve meses en silencio.

Dónde encaja con todo lo demás

Falco es una capa y no sustituye a las otras.

Antes del despliegue se cazan vulnerabilidades conocidas y errores de configuración: escaneo de imágenes como en Trivy y Grype, y control de admisión como en Kyverno o Gatekeeper. Lo más barato y lo más temprano, y ciego a todo lo que pase después.

La postura de configuración comprueba el clúster contra estándares, que es el tema de Kubescape y la postura del clúster. Continuo y estático.

El tiempo de ejecución es la única capa que ve comportamiento. Es también la más cara de operar, porque las reglas necesitan ajuste y las alertas necesitan personas.

El orden importa. La detección en tiempo de ejecución sobre un clúster con contenedores privilegiados por todas partes y sin política de red te va a ahogar. Arregla primero la postura, y entonces la detección se vuelve significativa.

Lo que se olvida

• Es un DaemonSet en todos los nodos, con un coste de recursos y una posición privilegiada. Dale peticiones y límites, y vigila si está funcionando de verdad en todas partes, porque un nodo sin él es un hueco invisible.
• El controlador eBPF depende del núcleo. Una actualización de la imagen del nodo puede romperlo, y eso falla en silencio. Alerta cuando Falco deje de reportar desde un nodo.
• Los servicios gestionados varían. Algunas ofertas gestionadas de Kubernetes restringen lo que puedes cargar, y algunas nubes ofrecen su propia detección en tiempo de ejecución que puede ser más fácil de operar aunque menos flexible.
• No puede ver dentro de un proceso. Una aplicación comprometida que hace llamadas al sistema de aspecto legítimo le resulta invisible.
• Las actualizaciones de reglas cambian el comportamiento. Fija la versión del conjunto de reglas y revisa los cambios en vez de traer la última automáticamente.
• Los registros de auditoría son una segunda fuente. Los del servidor de API de Kubernetes cazan otra clase de actividad, y los dos juntos son bastante más fuertes que cualquiera por separado.

Qué hacer esta semana

Despliega Falco en un clúster de no producción en modo auditoría con las reglas por defecto, espera una semana y cuenta las alertas por regla. Ese recuento te dice dos cosas a la vez: cuánto ajuste necesita la herramienta, y cuánto del comportamiento de tus propias cargas está haciendo cosas que no esperabas. En nuestra experiencia el segundo hallazgo es el más interesante. Lo hacemos en la fase de detección de un proyecto de seguridad.