¿Qué es bits?

bits es la familia de binarios pequeños y firmados que Cert-IX coloca en sus hosts. Existen porque hay una pregunta que un escáner en la nube no puede responder desde fuera: ¿qué hay realmente en esta máquina, en qué estado se encuentra y puede demostrarlo?

Todo lo que sigue está escrito para quien tiene una fecha límite — quien responde a una pregunta de NIS2, DORA, ISO 27001 o SecNumCloud y necesita una respuesta que resista ser cuestionada.

Los trabajos, en orden

Un parque que solo conoce a medias genera cinco trabajos, y hay que hacerlos en este orden:

#	El trabajo	Quién lo hace
1	Saber qué tengo.	bitcollector
2	Encontrar lo que no sé que tengo.	bitscanner
3	Saber en qué estado está.	bitcollector
4	Cambiar ese estado de forma segura.	bitenforcer
5	Demostrarlo todo a un auditor.	la familia — y esta es la clave

Casi todas las herramientas del mercado hacen 1 y 3. El trabajo 2 es el que un inventario basado en agentes no puede hacer por construcción: solo puede llegar a contener máquinas en las que alguien instaló un agente, así que la impresora, el switch del laboratorio y el portátil del contratista no faltan porque algo haya fallado, sino porque nadie sabía que había que mirar. Y muy pocas hacen 5 con honestidad. Es en torno a eso que está diseñado bits: no en torno a la "visibilidad", sino a una respuesta defendible.

El trabajo 5 no es un informe que se exporta al final. Es una propiedad que el dato tiene desde el momento en que se captura — cada lote de telemetría de bitcollector se firma en el host y se encadena al lote anterior, de modo que usted puede demostrar que su propio inventario no fue alterado después, ni siquiera por nosotros. Consulte bitcollector para ver cómo funciona, y cuáles son sus límites honestos.

La frontera que zanja cualquier discusión

Hay exactamente una regla para decidir qué binario es dueño de una capacidad, y tiene que ver con el verbo, no con el área temática:

El verbo es la frontera

• bitcollector LEE y PUBLICA. Es el único publicador de lo que un host es. Nunca escribe en el host y nunca aplica nada.
• bitscanner MIRA HACIA FUERA y PUBLICA. El mismo verbo, en dirección opuesta: bitcollector lee el host en el que se ejecuta, bitscanner lee el segmento que rodea a ese host. Tampoco escribe nunca en el host y, por defecto, no pone ni un solo paquete en la red.
• bitenforcer ES DUEÑO DE LA ESCRITURA, y DEMUESTRA SU PROPIA ESCRITURA. Es el único binario que puede escribir jamás el estado de endurecimiento: de un solo disparo, local, invocado por un operador. Nunca envía telemetría. Esta es una regla de propiedad sobre la familia de productos, no una descripción de la v1 — bitenforcer v1 no modifica hosts; solo planifica e informa.

La prueba: si la respuesta es sobre esta máquina y debe ser continuamente cierta en toda la flota, eso es bitcollector. Si es sobre el cable en el que está esta máquina — una dirección que responde y que nada en su inventario explica — eso es bitscanner. Si la pregunta es "¿el cambio que acabo de hacer llegó a esta máquina?", eso es bitenforcer.

Una división por dominios — "el collector hace inventario, el enforcer hace endurecimiento" — suena más ordenada y se derrumba de inmediato, porque bitenforcer tiene que leer sysctls y bitcollector tiene que reportar el modo de SELinux. Así que la división es el verbo, y ninguna capacidad se construye en los dos. Es también la razón por la que bitscanner no recopila procesos, paquetes ni cuentas: esos son del collector, aunque sea el mismo binario el que está sobre el mismo host.

Qué hace bitenforcer v1 hoy

bitenforcer v1 no modifica hosts. Incluye validate y apply --dry-run: lee su política, planifica todos los cambios y le muestra el conjunto de cambios completo — y entonces se niega a aplicarlo. Es una decisión de alcance deliberada, y vale la pena leer las razones antes de planificar un despliegue. Consulte bitenforcer.

Los binarios

bitcollector — verdad sobre los activos con valor probatorio

Un agente ligero que se ejecuta de forma continua y reporta lo que el host es: hardware y sistema operativo, software instalado, procesos en ejecución, puertos a la escucha, pares de red establecidos, cuentas locales y la postura de seguridad viva de la máquina.

Lo que lo distingue de un agente de inventario:

• Cada lote se firma en el host y se encadena por hash con el anterior. Su auditor puede verificar la cadena sin conexión, sin red y sin ningún acceso a Cert-IX, usando el propio subcomando verify del agente y un ancla de confianza que obtiene de su host con export-pubkey.
• La privacidad es el estado por defecto, no un ajuste que hay que acordarse de activar. Las líneas de comandos de los procesos están desactivadas por defecto. Las variables de entorno y el contenido de los ficheros nunca se recopilan. El recopilador de cuentas locales publica UID en lugar de nombres de inicio de sesión salvo que usted lo autorice explícitamente — con una excepción documentada en el binario que puede descargar hoy (0.2.0-ga): los registros de procesos llevan el nombre de inicio de sesión de la cuenta propietaria, y ningún ajuste lo suprime salvo desactivar el recopilador de procesos. La próxima versión añade collectors.process.identity, que por defecto publica el uid y nunca el nombre. Consulte privacidad y cuentas locales.
• La postura se observa, nunca se supone. La configuración efectiva de sshd viene de sshd -T, el firewall del conjunto de reglas vivo, los sysctls de /proc — nunca de releer un fichero de configuración que puede no ser lo que el kernel está haciendo.

→ bitcollector en detalle

bitscanner — los dispositivos que su inventario no contiene

Un agente ligero que mira hacia fuera desde el host en el que está instalado y reporta qué más hay en el segmento: los vecinos con sus direcciones, sus fabricantes de MAC y sus tipos de dispositivo, las rutas y pasarelas de salida y — solo si usted lo arma — los servicios que esos vecinos están ejecutando.

Lo que lo distingue de un escáner de red:

• Se entrega inerte. Dos interruptores distintos tienen que ser ciertos a la vez antes de que se envíe un solo paquete, y cada sonda viene desactivada por defecto, de modo que scanning.enabled: true por sí solo sigue sin enviar nada. Medido en un host con 118 vecinos ARP reales: cuatro ciclos consecutivos, cero sondas.
• La autorización no puede venir del entorno. scanning.* y security.* solo se pueden leer del fichero de configuración. Definir uno de ellos desde una variable de entorno detiene el agente y nombra la variable — porque una aceptación que pudiera aportar un perfil de shell no sería una aceptación.
• Cada paquete se autoriza en el momento en que sale, por un único guardián, contra una única lista de permitidos, con un motivo legible por máquina registrado para cada decisión — y no por una lista de objetivos filtrada tres funciones antes.

→ bitscanner en detalle

bitenforcer — validación de política de endurecimiento y comprobación previa

Una herramienta de línea de comandos de un solo disparo. Usted le da una política de endurecimiento declarativa; ella le dice exactamente qué haría aplicar esa política a este host — cada fichero, unidad de systemd, regla de firewall, sysctl y cuenta, en el orden en que los tocaría — con el contenido candidato pasado por los validadores reales (sshd -t, visudo -c, nft -c, iptables-restore --test) y con los hallazgos de bloqueo de acceso medidos contra la sesión en la que usted está sentado.

v1 incluye únicamente validate y apply --dry-run. No escribe en el host, y ninguna opción hace que lo haga. "Muéstrame exactamente qué cambiaría, y niégate a adivinar" es el producto.

→ bitenforcer en detalle

bitmapper — con qué está hablando este host

bitmapper observa los paquetes que atraviesan las propias interfaces de un host y atribuye cada uno al proceso propietario del socket. Donde un inventario le dice que una máquina existe, una captura le dice con qué habla realmente, y qué hay en ella que está hablando.

Se distribuye, y es el más estrecho de los cuatro. 0.1.0-ga se publica y se firma solo para linux/amd64 — la captura necesita una libpcap enlazada en la compilación, así que bitmapper es el único bit que no puede compilarse de forma cruzada. Lo que llega a la plataforma son registros de flujo: extremos, puertos, protocolo, contadores, estado de la conexión y el proceso atribuido — ningún byte de carga útil, ninguna captura de paquetes, y no la línea de comandos del proceso. Partes del agente siguen sin construirse (sin agregación de topología de servicios, sin métricas de Prometheus), y sus páginas las enumeran en lugar de dejar que las descubra.

→ bitmapper en detalle

Por qué el conjunto supera a cualquiera de ellos por separado

bitcollector reporta que un host tiene un paquete vulnerable y que un control concreto está verificado como aplicado en ese mismo host. Eso convierte "4000 hallazgos" en "los 40 en los que el control compensatorio no está realmente ahí".

bitscanner responde a la pregunta que nada de eso puede responder: si el segmento en el que están esos hosts lleva además dispositivos que no reportan absolutamente nada. Un recuento de hallazgos solo es tan honesto como el denominador que tiene detrás.

bitenforcer toma la política que cerraría esos 40 y le muestra el conjunto exacto de cambios antes de que nadie toque nada — incluido lo que le haría a su propio acceso.

Qué obtiene para una auditoría

Lo que pregunta el auditor	Lo que usted entrega
"¿Qué había en este host el 12 de marzo?"	El lote de telemetría atestado, con la firma y la posición en la cadena
"¿Cómo sé que no se editó después?"	bitcollector verify, ejecutado por ellos, sin conexión, contra su spool
"¿Cómo sé que Cert-IX no lo editó?"	El ancla de confianza sale de su host, no de nosotros
"¿El control X está aplicado, o solo escrito en un fichero de configuración?"	La postura es estado observado del host — sshd -T, conjunto de reglas vivo, /proc
"¿Hay algo en ese segmento que no esté en el inventario?"	Los registros de vecinos de bitscanner, con la dirección, la MAC, el fabricante y la hora de primera observación — y el sobre de escaneo que muestra qué estaba autorizado a mirar
"¿Qué cambiaría esta línea base de endurecimiento?"	bitenforcer apply --dry-run, elemento por elemento

Antes de instalar nada

Los cuatro binarios se compilan de forma reproducible, incluyen un SBOM CycloneDX y están firmados con cosign usando la misma clave de familia. La firma vale solo lo que valga la comprobación de la clave, así que empiece aquí:

Producto	Versión	Plataformas
bitcollector	0.1.0-ga	linux amd64/arm64, macOS amd64/arm64, Windows amd64
bitscanner	0.1.3-ga	linux amd64/arm64
bitenforcer	0.1.0-ga	linux amd64/arm64
bitmapper	0.1.0-ga	linux amd64

Las listas de plataformas difieren a propósito — cada página dice qué se retiene y por qué, y la tabla de releases reúne las razones en un solo sitio.

→ Verificación de sus descargas — incluido el problema del ancla de confianza que la mayoría de las instrucciones de verificación pasan por alto discretamente.

Próximos pasos

• bitcollector — qué recopila, cómo ejecutarlo y cuánto cuesta. Después, la cadena de evidencia y la privacidad y las cuentas locales.
• bitscanner — qué descubre, y después los dos interruptores que arman el escaneo y qué sale del host.
• bitenforcer — qué hace v1, y por qué deliberadamente no aplica cambios.
• Verificación de sus descargas — demuestre los bytes antes de ejecutarlos.
• Gestión de activos — dónde aterriza la telemetría.

¿Preguntas? Escriba a [email protected]. Los problemas de seguridad van a [email protected].