Cos'è bits?

bits è la famiglia di piccoli binari firmati che Cert-IX installa sui tuoi host. Esistono perché c'è una domanda a cui uno scanner cloud non può rispondere dall'esterno: cosa c'è davvero su questa macchina, in che stato si trova e sei in grado di dimostrarlo?

Tutto ciò che leggi qui è scritto per chi ha una scadenza — per chi deve rispondere a una domanda NIS2, DORA, ISO 27001 o SecNumCloud e ha bisogno di una risposta che regga alle contestazioni.

I compiti, in ordine

Un parco macchine che conosci solo a metà genera cinque compiti, e vanno svolti in quest'ordine:

#	Il compito	Chi lo svolge
1	Sapere cosa ho.	bitcollector
2	Trovare ciò che non so di avere.	bitscanner
3	Sapere in che stato si trova.	bitcollector
4	Modificare quello stato in sicurezza.	bitenforcer
5	Dimostrare tutto questo a un auditor.	la famiglia — ed è questo il punto

Quasi tutti gli strumenti sul mercato fanno 1 e 3. Il compito 2 è quello che un inventario basato su agenti non può svolgere per costruzione: può contenere soltanto le macchine su cui qualcuno ha installato un agente, così la stampante, lo switch di laboratorio e il portatile del consulente esterno mancano non perché qualcosa sia fallito, ma perché nessuno sapeva di doverli cercare. E pochissimi strumenti fanno 5 in modo onesto. È attorno a questo che bits è costruito: non "visibilità", ma una risposta difendibile.

Il compito 5 non è un report che esporti alla fine. È una proprietà che il dato possiede dal momento in cui viene acquisito: ogni batch di telemetria di bitcollector viene firmato sull'host e concatenato tramite hash al batch precedente, così puoi dimostrare che il tuo inventario non è stato alterato in seguito, nemmeno da noi. Vedi bitcollector per capire come funziona, e per i suoi limiti dichiarati con onestà.

Il confine che risolve ogni questione

C'è esattamente una regola per decidere quale binario possiede una capacità, e riguarda il verbo, non l'area tematica:

Il confine è il verbo

• bitcollector LEGGE e PUBBLICA. È l'unico publisher di ciò che un host è. Non scrive mai sull'host e non applica mai nulla.
• bitscanner GUARDA VERSO L'ESTERNO e PUBBLICA. Stesso verbo, direzione opposta: bitcollector legge l'host su cui gira, bitscanner legge il segmento attorno a quell'host. Nemmeno lui scrive mai sull'host e, per impostazione predefinita, non mette alcun pacchetto sulla rete.
• bitenforcer POSSIEDE LA SCRITTURA, e DIMOSTRA LA PROPRIA SCRITTURA. È l'unico binario che possa mai scrivere lo stato di hardening: esecuzione singola, locale, avviata dall'operatore. Non invia mai telemetria. Questa è una regola di proprietà sulla famiglia di prodotti, non una descrizione della v1 — bitenforcer v1 non modifica gli host; pianifica e segnala soltanto.

La prova del nove: se la risposta riguarda questa macchina e deve essere continuamente vera su tutta la flotta, è bitcollector. Se riguarda il cavo su cui si trova questa macchina — un indirizzo che risponde e che nulla nel tuo inventario spiega — è bitscanner. Se la domanda è "la modifica che ho appena fatto è arrivata su questa macchina?", è bitenforcer.

Una divisione per dominio — "il collector fa l'inventario, l'enforcer fa l'hardening" — suona più ordinata e crolla immediatamente, perché bitenforcer deve leggere le sysctl e bitcollector deve riportare la modalità SELinux. Quindi la divisione è il verbo, e nessuna capacità viene costruita in entrambi. È anche il motivo per cui bitscanner non raccoglie processi, pacchetti o account: quelli sono del collector, anche se lo stesso binario si trova sullo stesso host.

Cosa fa oggi bitenforcer v1

bitenforcer v1 non modifica gli host. Fornisce validate e apply --dry-run: legge la tua policy, pianifica ogni modifica e ti mostra l'insieme completo delle modifiche — e poi si rifiuta di applicarle. È una decisione deliberata sull'ambito, e le ragioni meritano una lettura prima di pianificare un rollout. Vedi bitenforcer.

I binari

bitcollector — verità sugli asset con valore probatorio

Un agente leggero che gira in modo continuo e riporta ciò che l'host è: hardware e sistema operativo, software installato, processi in esecuzione, porte in ascolto, peer di rete stabiliti, account locali e la postura di sicurezza attiva della macchina.

Cosa lo distingue da un agente di inventario:

• Ogni batch è firmato sull'host e concatenato tramite hash al precedente. Il tuo auditor può verificare la catena offline, senza rete e senza alcun accesso a Cert-IX, usando il sottocomando verify dell'agente stesso e un'ancora di fiducia (trust anchor) che ottiene dal tuo host con export-pubkey.
• La privacy è l'impostazione predefinita, non un'opzione da ricordarsi di attivare. Le righe di comando dei processi sono disattivate per impostazione predefinita. Le variabili d'ambiente e il contenuto dei file non vengono mai raccolti. Il collector degli account locali pubblica gli UID anziché i nomi di login, a meno che tu non scelga esplicitamente il contrario — con un'eccezione documentata nel binario che puoi scaricare oggi (0.2.0-ga): i record dei processi riportano il nome di login dell'account proprietario, e nessuna impostazione lo elimina, se non disattivando il collector dei processi. La prossima versione aggiunge collectors.process.identity, che per impostazione predefinita pubblica l'uid e mai il nome. Vedi privacy e account locali.
• La postura viene osservata, mai presunta. La configurazione effettiva di sshd proviene da sshd -T, il firewall dal ruleset attivo, le sysctl da /proc — mai dalla rilettura di un file di configurazione che potrebbe non corrispondere a ciò che il kernel sta facendo.

→ bitcollector nel dettaglio

bitscanner — i dispositivi che il tuo inventario non contiene

Un agente leggero che guarda verso l'esterno dall'host su cui è installato e riporta cos'altro c'è sul segmento: i vicini con i loro indirizzi, i produttori dei MAC e i tipi di dispositivo, le route e i gateway in uscita e — solo se lo armi — i servizi che quei vicini stanno eseguendo.

Cosa lo distingue da uno scanner di rete:

• Viene fornito inerte. Due interruttori distinti devono essere entrambi veri prima che venga inviato un solo pacchetto, e ogni sonda è disattivata per impostazione predefinita, quindi scanning.enabled: true da solo non invia comunque nulla. Misurato su un host con 118 vicini ARP reali: quattro cicli consecutivi, zero sonde.
• L'autorizzazione non può venire dall'ambiente. scanning.* e security.* sono leggibili soltanto dal file di configurazione. Impostarne uno da una variabile d'ambiente arresta l'agente e nomina la variabile — perché una dichiarazione di accettazione che un profilo di shell potrebbe fornire non sarebbe una dichiarazione di accettazione.
• Ogni pacchetto è autorizzato nel momento in cui parte, da un'unica guardia, rispetto a un'unica allowlist, con una motivazione leggibile da una macchina registrata per ogni decisione — non da una lista di bersagli filtrata tre funzioni prima.

→ bitscanner nel dettaglio

bitenforcer — convalida delle policy di hardening e pre-flight

Uno strumento da riga di comando a esecuzione singola. Gli fornisci una policy di hardening dichiarativa; lui ti dice esattamente cosa farebbe l'applicazione di quella policy a questo host — ogni file, unità systemd, regola di firewall, sysctl e account, nell'ordine in cui li toccherebbe — con il contenuto candidato passato attraverso i validatori reali (sshd -t, visudo -c, nft -c, iptables-restore --test) e con i rilievi di lockout misurati rispetto alla sessione in cui sei seduto.

La v1 fornisce solo validate e apply --dry-run. Non scrive sull'host, e nessun flag glielo fa fare. "Mostrami esattamente cosa cambierebbe, e rifiutati di tirare a indovinare" è il prodotto.

→ bitenforcer nel dettaglio

bitmapper — con cosa sta parlando questo host

bitmapper osserva i pacchetti che attraversano le interfacce dell'host stesso e attribuisce ciascuno di essi al processo che possiede il socket. Dove un inventario ti dice che una macchina esiste, una cattura ti dice con cosa parla davvero, e cosa, al suo interno, sta parlando.

È distribuito, ed è il più stretto dei quattro. 0.1.0-ga è pubblicato e firmato solo per linux/amd64 — la cattura richiede una libpcap compilata dentro il binario, quindi bitmapper è l'unico bit che non può essere compilato in modo incrociato. Ciò che raggiunge la piattaforma sono record di flusso: estremi, porte, protocollo, contatori, stato della connessione e il processo attribuito — nessun byte di payload, nessuna cattura di pacchetti, e non la riga di comando del processo. Parti dell'agente non sono ancora costruite (nessuna aggregazione della topologia dei servizi, nessuna metrica Prometheus), e le sue pagine le elencano anziché lasciartele scoprire.

→ bitmapper nel dettaglio

Perché l'insieme batte ciascuno di loro preso singolarmente

bitcollector riporta che un host ha un pacchetto vulnerabile e che uno specifico controllo risulta verificato come applicato su quello stesso host. Questo trasforma "4000 rilievi" nei "40 in cui il controllo compensativo non c'è davvero".

bitscanner risponde alla domanda a cui nulla di tutto ciò può rispondere: se il segmento su cui si trovano quegli host porti anche dispositivi che non riportano assolutamente nulla. Un conteggio di rilievi è onesto quanto lo è il denominatore che gli sta dietro.

bitenforcer prende la policy che chiuderebbe quei 40 e ti mostra l'esatto insieme delle modifiche prima che qualcuno tocchi qualcosa — compreso cosa farebbe al tuo stesso accesso.

Cosa ottieni per un audit

Cosa chiede l'auditor	Cosa gli consegni
"Cosa c'era su questo host il 12 marzo?"	Il batch di telemetria attestato, con la firma e la posizione nella catena
"Come faccio a sapere che non è stato modificato dopo?"	bitcollector verify, eseguito da lui, offline, sul tuo spool
"Come faccio a sapere che Cert-IX non l'ha modificato?"	L'ancora di fiducia si ottiene dal tuo host, non da noi
"Il controllo X è applicato, o solo scritto in un file di configurazione?"	La postura è stato dell'host osservato — sshd -T, ruleset attivo, /proc
"C'è qualcosa su quel segmento che non è nell'inventario?"	I record dei vicini di bitscanner, con l'indirizzo, il MAC, il produttore e l'istante di primo avvistamento — più l'inviluppo di scansione che mostra cosa era autorizzato a guardare
"Cosa cambierebbe questa baseline di hardening?"	bitenforcer apply --dry-run, voce per voce

Prima di installare qualsiasi cosa

Tutti e quattro i binari hanno build riproducibili, includono un SBOM CycloneDX e sono firmati con cosign usando la stessa chiave di famiglia. La firma vale quanto vale la verifica della chiave, quindi parti da qui:

Prodotto	Versione	Piattaforme
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

Gli elenchi di piattaforme differiscono di proposito — ogni pagina dice cosa viene trattenuto e perché, e la tabella delle release raccoglie le ragioni in un unico posto.

→ Verificare i tuoi download — compreso il problema dell'ancora di fiducia che la maggior parte delle istruzioni di verifica salta in silenzio.

Passi successivi

• bitcollector — cosa raccoglie, come eseguirlo e quanto costa. Poi la catena delle evidenze e privacy e account locali.
• bitscanner — cosa scopre, poi i due interruttori che armano la scansione e cosa lascia l'host.
• bitenforcer — cosa fa la v1, e perché deliberatamente non applica nulla.
• Verificare i tuoi download — dimostra l'autenticità dei byte prima di eseguirli.
• Asset Management — dove atterra la telemetria.

Domande? Scrivi a [email protected]. Le questioni di sicurezza vanno a [email protected].