Qu'est-ce que bits ?

bits est la famille de petits binaires signés que Cert-IX place sur vos hôtes. Ils existent parce qu'il y a une question à laquelle un scanner cloud ne peut pas répondre depuis l'extérieur : qu'y a-t-il réellement sur cette machine, dans quel état est-elle, et pouvez-vous le prouver ?

Tout ce qui suit est écrit pour la personne qui a une échéance — celle qui répond à une question NIS2, DORA, ISO 27001 ou SecNumCloud et qui a besoin d'une réponse qui résiste à la contestation.

Les tâches, dans l'ordre

Un parc que vous ne connaissez qu'à moitié crée cinq tâches, et elles doivent être menées dans cet ordre :

#	La tâche	Qui s'en charge
1	Savoir ce que je possède.	bitcollector
2	Trouver ce que je ne sais pas posséder.	bitscanner
3	Savoir dans quel état c'est.	bitcollector
4	Changer cet état sans danger.	bitenforcer
5	Prouver tout cela à un auditeur.	la famille — et c'est tout l'enjeu

Presque tous les outils du marché font 1 et 3. La tâche 2 est celle qu'un inventaire fondé sur des agents ne peut pas accomplir par construction : il ne peut jamais contenir que les machines sur lesquelles quelqu'un a installé un agent, de sorte que l'imprimante, le switch du laboratoire et le portable du prestataire manquent non pas parce que quelque chose a échoué, mais parce que personne ne savait qu'il fallait chercher. Et très peu d'outils font 5 honnêtement. C'est autour de cela que bits est construit : non pas la « visibilité », mais une réponse défendable.

La tâche 5 n'est pas un rapport que l'on exporte à la fin. C'est une propriété que la donnée possède dès l'instant où elle est capturée : chaque lot de télémétrie bitcollector est signé sur l'hôte et chaîné au lot précédent, de sorte que vous pouvez prouver que votre propre inventaire n'a pas été modifié après coup, y compris par nous. Voir bitcollector pour le fonctionnement, et ses limites honnêtes.

La frontière qui tranche toutes les questions

Il existe exactement une règle pour décider quel binaire détient une capacité, et elle porte sur le verbe, pas sur le domaine fonctionnel :

Le verbe est la frontière

• bitcollector LIT et PUBLIE. Il est l'unique publieur de ce qu'un hôte est. Il n'écrit jamais sur l'hôte et n'applique jamais rien.
• bitscanner REGARDE VERS L'EXTÉRIEUR et PUBLIE. Même verbe, direction opposée : bitcollector lit l'hôte sur lequel il s'exécute, bitscanner lit le segment autour de cet hôte. Lui non plus n'écrit jamais sur l'hôte, et par défaut il ne met aucun paquet sur le réseau.
• bitenforcer DÉTIENT L'ÉCRITURE, et PROUVE SA PROPRE ÉCRITURE. Il est le seul binaire autorisé à écrire un état de durcissement : exécution unique, locale, déclenchée par un opérateur. Il ne transmet jamais de télémétrie. Il s'agit d'une règle de propriété sur la famille de produits, et non d'une description de la v1 — bitenforcer v1 ne modifie aucun hôte ; il planifie et signale uniquement.

Le test : si la réponse porte sur cette machine et doit être continuellement vraie sur tout le parc, c'est bitcollector. Si elle porte sur le fil sur lequel se trouve cette machine — une adresse qui répond et que rien dans votre inventaire n'explique — c'est bitscanner. Si la question est « le changement que je viens de faire a-t-il bien atterri sur cette machine ? », c'est bitenforcer.

Une répartition par domaine — « le collecteur fait l'inventaire, l'enforcer fait le durcissement » — paraît plus nette et s'effondre immédiatement, car bitenforcer doit lire les sysctls et bitcollector doit rapporter le mode SELinux. La frontière est donc le verbe, et aucune capacité n'est construite dans les deux. C'est aussi pourquoi bitscanner ne collecte ni processus, ni paquets, ni comptes : ceux-là appartiennent au collecteur, quand bien même le même binaire se tient sur le même hôte.

Ce que bitenforcer v1 fait aujourd'hui

bitenforcer v1 ne modifie aucun hôte. Il livre validate et apply --dry-run : il lit votre politique, planifie chaque changement et vous montre l'ensemble complet des modifications — puis refuse de les appliquer. C'est une décision de périmètre délibérée, et les raisons méritent d'être lues avant de planifier un déploiement. Voir bitenforcer.

Les binaires

bitcollector — une vérité sur les actifs de qualité probante

Un agent léger qui s'exécute en continu et rapporte ce que l'hôte est : matériel et système d'exploitation, logiciels installés, processus en cours d'exécution, ports en écoute, pairs réseau établis, comptes locaux et posture de sécurité en temps réel de la machine.

Ce qui le distingue d'un agent d'inventaire :

• Chaque lot est signé sur l'hôte et chaîné par hachage au précédent. Votre auditeur peut vérifier la chaîne hors ligne, sans réseau et sans aucun accès à Cert-IX, à l'aide de la sous-commande verify de l'agent lui-même et d'une ancre de confiance qu'il récupère depuis votre hôte avec export-pubkey.
• La confidentialité est l'état par défaut, pas un réglage qu'il faut penser à activer. Les lignes de commande des processus sont désactivées par défaut. Les variables d'environnement et le contenu des fichiers ne sont jamais collectés. Le collecteur de comptes locaux publie des UID plutôt que des identifiants de connexion, sauf activation explicite de votre part — avec une exception documentée dans le binaire que vous pouvez télécharger aujourd'hui (0.2.0-ga) : les enregistrements de processus portent l'identifiant de connexion du compte propriétaire, et aucun réglage ne le supprime, sinon la désactivation du collecteur de processus. La prochaine version ajoute collectors.process.identity, qui publie par défaut l'uid et jamais le nom. Voir confidentialité et comptes locaux.
• La posture est observée, jamais supposée. La configuration effective de sshd provient de sshd -T, le pare-feu du jeu de règles actif, les sysctls de /proc — jamais de la relecture d'un fichier de configuration qui peut ne pas correspondre à ce que fait le noyau.

→ bitcollector en détail

bitscanner — les équipements que votre inventaire ne contient pas

Un agent léger qui regarde vers l'extérieur depuis l'hôte sur lequel il est installé et rapporte ce qu'il y a d'autre sur le segment : les voisins avec leurs adresses, leurs fabricants de MAC et leurs types d'équipement, les routes et passerelles de sortie, et — uniquement si vous l'armez — les services que ces voisins exécutent.

Ce qui le distingue d'un scanner réseau :

• Il est livré inerte. Deux interrupteurs distincts doivent être vrais tous les deux avant qu'un seul paquet ne soit envoyé, et chaque sonde est désactivée par défaut : ainsi, scanning.enabled: true à lui seul n'envoie toujours rien. Mesuré sur un hôte comptant 118 voisins ARP réels : quatre cycles consécutifs, zéro sonde.
• L'autorisation ne peut pas venir de l'environnement. scanning.* et security.* ne sont lisibles que depuis le fichier de configuration. En définir un depuis une variable d'environnement arrête l'agent et nomme la variable — parce qu'un acquittement qu'un profil de shell pourrait fournir ne serait pas un acquittement.
• Chaque paquet est autorisé au moment où il part, par un seul garde-fou, contre une seule liste d'autorisation, avec un motif exploitable par une machine enregistré pour chaque décision — et non par une liste de cibles filtrée trois fonctions plus tôt.

→ bitscanner en détail

bitenforcer — validation de politique de durcissement et contrôle préalable

Un outil en ligne de commande à exécution unique. Vous lui donnez une politique de durcissement déclarative ; il vous dit exactement ce que l'application de cette politique ferait à cet hôte — chaque fichier, unité systemd, règle de pare-feu, sysctl et compte, dans l'ordre où il y toucherait — avec le contenu candidat passé dans les vrais validateurs (sshd -t, visudo -c, nft -c, iptables-restore --test) et avec les constats de verrouillage mesurés par rapport à la session dans laquelle vous êtes en train de travailler.

La v1 ne livre que validate et apply --dry-run. Elle n'écrit pas sur l'hôte, et aucune option ne l'y contraint. « Montrez-moi exactement ce qui changerait, et refusez de deviner » : voilà le produit.

→ bitenforcer en détail

bitmapper — à quoi cet hôte parle

bitmapper observe les paquets qui traversent les propres interfaces d'un hôte et attribue chacun d'eux au processus propriétaire de la socket. Là où un inventaire vous dit qu'une machine existe, une capture vous dit à quoi elle parle réellement, et ce qui, sur elle, prend la parole.

Il est livré, et c'est le plus étroit des quatre. 0.1.0-ga est publié et signé pour linux/amd64 uniquement — la capture exige une libpcap liée à la compilation, si bien que bitmapper est le seul bit qui ne peut pas être compilé de manière croisée. Ce qui atteint la plateforme, ce sont des enregistrements de flux : extrémités, ports, protocole, compteurs, état de la connexion et processus attribué — aucun octet de charge utile, aucune capture de paquets, et pas la ligne de commande du processus. Des parties de l'agent ne sont toujours pas construites (pas d'agrégation de topologie de services, pas de métriques Prometheus), et ses pages les listent plutôt que de vous laisser les découvrir.

→ bitmapper en détail

Pourquoi l'ensemble vaut mieux que chacun pris isolément

bitcollector rapporte qu'un hôte porte un paquet vulnérable et qu'un contrôle précis est vérifié comme effectivement appliqué sur ce même hôte. Cela transforme « 4,000 résultats » en « les 40 où le contrôle compensatoire n'est pas réellement là ».

bitscanner répond à la question qu'aucun des autres ne peut poser : le segment sur lequel se trouvent ces hôtes porte-t-il aussi des équipements qui ne rapportent rien du tout ? Un nombre de résultats ne vaut que ce que vaut l'honnêteté du dénominateur qui le sous-tend.

bitenforcer prend la politique qui fermerait ces 40 et vous montre l'ensemble exact des changements avant que quiconque ne touche à quoi que ce soit — y compris ce qu'elle ferait à votre propre accès.

Ce que vous obtenez pour un audit

Ce que l'auditeur demande	Ce que vous lui remettez
« Qu'y avait-il sur cet hôte le 12 mars ? »	Le lot de télémétrie attesté, avec la signature et la position dans la chaîne
« Comment puis-je savoir qu'il n'a pas été modifié après coup ? »	bitcollector verify, exécuté par lui, hors ligne, sur votre spool
« Comment puis-je savoir que Cert-IX ne l'a pas modifié ? »	L'ancre de confiance provient de votre hôte, pas de nous
« Le contrôle X est-il appliqué, ou seulement écrit dans un fichier de configuration ? »	La posture est un état d'hôte observé — sshd -T, jeu de règles actif, /proc
« Y a-t-il sur ce segment quelque chose qui n'est pas dans l'inventaire ? »	Les enregistrements de voisins de bitscanner, avec l'adresse, la MAC, le fabricant et la date de première observation — ainsi que l'enveloppe de scan montrant ce qu'il était autorisé à regarder
« Que changerait ce socle de durcissement ? »	bitenforcer apply --dry-run, point par point

Avant toute installation

Les quatre binaires sont compilés de façon reproductible, livrés avec un SBOM CycloneDX et signés avec cosign à l'aide de la même clé de famille. La signature ne vaut que ce que vaut la vérification de la clé, alors commencez ici :

Produit	Version	Plateformes
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

Les listes de plateformes diffèrent volontairement — chaque page dit ce qui est retenu et pourquoi, et le tableau des versions rassemble les raisons en un seul endroit.

→ Vérifier vos téléchargements — y compris le problème d'ancre de confiance que la plupart des instructions de vérification passent discrètement sous silence.

Étapes suivantes

• bitcollector — ce qu'il collecte, comment l'exécuter et ce qu'il coûte. Puis la chaîne de preuves et la confidentialité et les comptes locaux.
• bitscanner — ce qu'il découvre, puis les deux interrupteurs qui arment le scan et ce qui quitte l'hôte.
• bitenforcer — ce que fait la v1, et pourquoi elle n'applique délibérément rien.
• Vérifier vos téléchargements — prouvez les octets avant de les exécuter.
• Gestion des actifs — là où atterrit la télémétrie.

Des questions ? Écrivez à [email protected]. Les problèmes de sécurité vont à [email protected].