Was ist bits?

bits ist die Familie kleiner, signierter Binaries, die Cert-IX auf Ihre Hosts bringt. Sie existieren, weil es eine Frage gibt, die ein Cloud-Scanner von außen nicht beantworten kann: Was ist tatsächlich auf dieser Maschine, in welchem Zustand ist sie, und können Sie das belegen?

Alles hier ist für die Person mit einer Frist geschrieben — für diejenige, die eine NIS2-, DORA-, ISO 27001- oder SecNumCloud-Frage beantwortet und eine Antwort braucht, die einer Anfechtung standhält.

Die Aufgaben, in dieser Reihenfolge

Ein Bestand, den Sie nur halb kennen, erzeugt fünf Aufgaben, und sie müssen in dieser Reihenfolge erledigt werden:

#	Die Aufgabe	Wer sie erledigt
1	Wissen, was ich habe.	bitcollector
2	Finden, wovon ich nicht weiß, dass ich es habe.	bitscanner
3	Wissen, in welchem Zustand es ist.	bitcollector
4	Diesen Zustand sicher ändern.	bitenforcer
5	All das einem Auditor belegen.	die Familie — und darum geht es

Fast jedes Werkzeug am Markt erledigt 1 und 3. Aufgabe 2 ist diejenige, die ein agentenbasiertes Inventar bauartbedingt nicht leisten kann: Es kann immer nur die Maschinen enthalten, auf denen jemand einen Agenten installiert hat, sodass der Drucker, der Switch im Labor und der Laptop des externen Dienstleisters nicht deshalb fehlen, weil etwas fehlgeschlagen wäre, sondern weil niemand wusste, dass er nachsehen müsste. Und sehr wenige Werkzeuge erledigen 5 ehrlich. Genau darum herum ist bits gebaut: nicht um „Sichtbarkeit“, sondern um eine belastbare Antwort.

Aufgabe 5 ist kein Bericht, den Sie am Ende exportieren. Sie ist eine Eigenschaft, die die Daten von dem Moment an haben, in dem sie erfasst werden — jeder Batch bitcollector-Telemetrie wird auf dem Host signiert und per Hash an den vorherigen Batch gekettet, sodass Sie belegen können, dass Ihr eigenes Inventar nachträglich nicht verändert wurde, auch nicht von uns. Siehe bitcollector dazu, wie das funktioniert, und zu seinen ehrlichen Grenzen.

Die Grenze, die jede Frage entscheidet

Es gibt genau eine Regel, um zu entscheiden, welches Binary eine Fähigkeit besitzt, und sie betrifft das Verb, nicht das Sachgebiet:

Das Verb ist die Grenze

• bitcollector LIEST und VERÖFFENTLICHT. Er ist der einzige Publisher dessen, was ein Host ist. Er schreibt niemals auf den Host und erzwingt niemals etwas.
• bitscanner BLICKT NACH AUSSEN und VERÖFFENTLICHT. Dasselbe Verb, entgegengesetzte Richtung: bitcollector liest den Host, auf dem er läuft, bitscanner liest das Segment rund um diesen Host. Auch er schreibt niemals auf den Host, und standardmäßig bringt er überhaupt keine Pakete ins Netz.
• bitenforcer SCHREIBT und BELEGT SEINEN EIGENEN SCHREIBVORGANG. Er ist der einzige Schreiber des Härtungszustands: einmalig, lokal, vom Operator aufgerufen. Er versendet niemals Telemetrie. Dies ist eine Eigentumsregel für die Produktfamilie, keine Beschreibung von v1 — bitenforcer v1 ändert keine Hosts; es plant und berichtet nur.

Der Test: Wenn die Antwort diese Maschine betrifft und über die gesamte Flotte hinweg dauerhaft wahr sein muss, ist das bitcollector. Wenn sie die Leitung betrifft, an der diese Maschine hängt — eine Adresse, die antwortet und die nichts in Ihrem Inventar erklärt —, ist das bitscanner. Wenn die Frage lautet „ist die Änderung, die ich gerade gemacht habe, auf dieser Kiste angekommen“, ist das bitenforcer.

Ein fachlicher Schnitt — „der Collector macht Inventar, der Enforcer macht Härtung“ — klingt ordentlicher und bricht sofort zusammen, denn bitenforcer muss sysctls lesen und bitcollector muss den SELinux-Modus melden. Also ist der Schnitt das Verb, und keine Fähigkeit wird in beiden gebaut. Das ist auch der Grund, warum bitscanner keine Prozesse, Pakete oder Konten erfasst: Die gehören dem Collector, auch wenn dasselbe Binary auf demselben Host steht.

Was bitenforcer v1 heute tut

bitenforcer v1 ändert keine Hosts. Er liefert validate und apply --dry-run aus: Er liest Ihre Richtlinie, plant jede Änderung und zeigt Ihnen den vollständigen Änderungssatz — und weigert sich dann, ihn anzuwenden. Das ist eine bewusste Entscheidung über den Funktionsumfang, und die Gründe sollten Sie lesen, bevor Sie einen Rollout planen. Siehe bitenforcer.

Die Binaries

bitcollector — beweisfähige Asset-Wahrheit

Ein schlanker Agent, der kontinuierlich läuft und meldet, was der Host ist: Hardware und Betriebssystem, installierte Software, laufende Prozesse, lauschende Ports, bestehende Netzwerk-Gegenstellen, lokale Konten und die aktuelle Sicherheitslage der Maschine.

Was ihn von einem Inventar-Agenten unterscheidet:

• Jeder Batch wird auf dem Host signiert und per Hash an den vorherigen gekettet. Ihr Auditor kann die Kette offline verifizieren, ohne Netzwerk und ganz ohne Cert-IX-Zugang, mit dem verify-Unterbefehl des Agenten selbst und einem Vertrauensanker, den er sich mit export-pubkey von Ihrem Host holt.
• Datenschutz ist die Voreinstellung, keine Einstellung, an die Sie denken müssen. Prozess-Kommandozeilen sind standardmäßig aus. Umgebungsvariablen und Dateiinhalte werden niemals erfasst. Der Collector für lokale Konten veröffentlicht UIDs statt Login-Namen, sofern Sie sich nicht aktiv dafür entscheiden — mit einer dokumentierten Ausnahme in dem Binary, das Sie heute herunterladen können (0.2.0-ga): Prozess-Datensätze führen den Login-Namen des besitzenden Kontos mit, und es gibt keine Einstellung, die das unterdrückt, außer den process-Collector abzuschalten. Die nächste Version ergänzt collectors.process.identity, das standardmäßig die uid und nie den Namen veröffentlicht. Siehe Datenschutz und lokale Konten.
• Die Sicherheitslage wird beobachtet, nie angenommen. Die effektive Konfiguration von sshd stammt aus sshd -T, die Firewall aus dem laufenden Regelwerk, sysctls aus /proc — niemals aus dem erneuten Lesen einer Konfigurationsdatei, die vielleicht nicht das ist, was der Kernel tatsächlich tut.

→ bitcollector im Detail

bitscanner — die Geräte, die Ihr Inventar nicht enthält

Ein schlanker Agent, der von dem Host, auf dem er installiert ist, nach außen blickt und meldet, was sonst noch auf dem Segment ist: Nachbarn mit ihren Adressen, MAC-Herstellern und Gerätetypen, die Routen und Gateways nach draußen und — nur wenn Sie ihn scharfstellen — die Dienste, die diese Nachbarn betreiben.

Was ihn von einem Netzwerk-Scanner unterscheidet:

• Er wird inert ausgeliefert. Zwei getrennte Schalter müssen beide wahr sein, bevor ein einziges Paket gesendet wird, und jede Sonde ist standardmäßig aus, sodass scanning.enabled: true für sich allein immer noch nichts sendet. Gemessen auf einem Host mit 118 echten ARP-Nachbarn: vier aufeinanderfolgende Zyklen, null Sondierungen.
• Die Autorisierung kann nicht aus der Umgebung kommen. scanning.* und security.* sind ausschließlich aus der Konfigurationsdatei lesbar. Einen davon über eine Umgebungsvariable zu setzen, stoppt den Agenten und benennt die Variable — denn eine Bestätigung, die ein Shell-Profil liefern könnte, wäre keine Bestätigung.
• Jedes Paket wird in dem Moment autorisiert, in dem es hinausgeht, durch einen einzigen Guard, gegen eine einzige Allowlist, mit einem maschinenlesbaren Grund, der für jede Entscheidung festgehalten wird — nicht durch eine Zielliste, die drei Funktionen früher gefiltert wurde.

→ bitscanner im Detail

bitenforcer — Validierung und Pre-Flight von Härtungsrichtlinien

Ein einmalig ausgeführtes Kommandozeilenwerkzeug. Sie geben ihm eine deklarative Härtungsrichtlinie; es sagt Ihnen genau, was die Anwendung dieser Richtlinie auf diesem Host bewirken würde — jede Datei, jede systemd-Unit, jede Firewall-Regel, jeden sysctl und jedes Konto, in der Reihenfolge, in der sie angefasst würden — mit Kandidateninhalten, die durch die echten Validatoren (sshd -t, visudo -c, nft -c, iptables-restore --test) laufen, und mit Aussperr-Feststellungen, gemessen an genau der Sitzung, in der Sie gerade sitzen.

v1 liefert ausschließlich validate und apply --dry-run aus. Es schreibt nicht auf den Host, und kein Flag bringt es dazu. „Zeig mir genau, was sich ändern würde, und rate nicht“ ist das Produkt.

→ bitenforcer im Detail

bitmapper — womit dieser Host spricht

bitmapper beobachtet die Pakete, die über die eigenen Schnittstellen eines Hosts laufen, und ordnet jedes davon dem Prozess zu, dem der Socket gehört. Wo Ihnen ein Inventar sagt, dass eine Maschine existiert, sagt Ihnen ein Mitschnitt, womit sie tatsächlich spricht — und was auf ihr dabei spricht.

Er wird ausgeliefert, und er ist der schmalste der vier. 0.1.0-ga ist ausschließlich für linux/amd64 veröffentlicht und signiert — der Mitschnitt braucht ein einkompiliertes libpcap, weshalb bitmapper das einzige bit ist, das sich nicht cross-kompilieren lässt. Was die Plattform erreicht, sind Flow-Datensätze: Endpunkte, Ports, Protokoll, Zähler, Verbindungszustand und der zugeordnete Prozess — keine Nutzlast-Bytes, keine Paketmitschnitte und nicht die Kommandozeile des Prozesses. Teile des Agenten sind weiterhin nicht gebaut (keine Aggregation der Service-Topologie, keine Prometheus-Metriken), und seine Seiten führen sie auf, statt sie Ihnen zum Entdecken zu überlassen.

→ bitmapper im Detail

Warum das Ganze besser ist als jeder Teil für sich

bitcollector meldet, dass ein Host ein verwundbares Paket hat, und dass eine bestimmte Kontrolle auf genau demselben Host nachweislich durchgesetzt ist. Das macht aus „4.000 Feststellungen“ die „40, bei denen die kompensierende Kontrolle tatsächlich nicht vorhanden ist“.

bitscanner beantwortet die Frage, die all das nicht beantworten kann: ob das Segment, auf dem diese Hosts stehen, auch Geräte trägt, die überhaupt nichts melden. Eine Zahl von Feststellungen ist nur so ehrlich wie der Nenner dahinter.

bitenforcer nimmt die Richtlinie, die diese 40 schließen würde, und zeigt Ihnen den genauen Änderungssatz, bevor irgendjemand irgendetwas anfasst — einschließlich dessen, was sie mit Ihrem eigenen Zugang machen würde.

Was Sie für ein Audit bekommen

Der Auditor fragt	Was Sie übergeben
„Was war am 12. März auf diesem Host?“	Den attestierten Telemetrie-Batch, mit Signatur und Kettenposition
„Woher weiß ich, dass er danach nicht bearbeitet wurde?“	bitcollector verify, von ihm selbst ausgeführt, offline, gegen Ihren Spool
„Woher weiß ich, dass Cert-IX ihn nicht bearbeitet hat?“	Der Vertrauensanker stammt von Ihrem Host, nicht von uns
„Ist Kontrolle X durchgesetzt oder nur in einer Konfigurationsdatei aufgeschrieben?“	Die Sicherheitslage ist beobachteter Host-Zustand — sshd -T, laufendes Regelwerk, /proc
„Gibt es auf diesem Segment etwas, das nicht im Inventar steht?“	Die Nachbar-Datensätze von bitscanner, mit Adresse, MAC, Hersteller und Zeitpunkt der Erstsichtung — und dem Scan-Envelope, der zeigt, was er anschauen durfte
„Was würde diese Härtungs-Baseline ändern?“	bitenforcer apply --dry-run, Punkt für Punkt

Bevor Sie irgendetwas installieren

Alle vier Binaries werden reproduzierbar gebaut, liefern eine CycloneDX-SBOM mit und sind mit cosign unter demselben Familienschlüssel signiert. Die Signatur ist nur so viel wert wie die Prüfung des Schlüssels, also fangen Sie hier an:

Produkt	Version	Plattformen
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

Die Plattformlisten unterscheiden sich mit Absicht — jede Seite sagt, was zurückgehalten wird und warum, und die Release-Tabelle sammelt die Gründe an einer Stelle.

→ Ihre Downloads verifizieren — einschließlich des Vertrauensanker-Problems, das die meisten Verifizierungsanleitungen stillschweigend überspringen.

Nächste Schritte

• bitcollector — was er erfasst, wie Sie ihn betreiben und was er kostet. Dann die Nachweiskette und Datenschutz und lokale Konten.
• bitscanner — was er entdeckt, dann die zwei Schalter, die das Scannen scharfstellen und was den Host verlässt.
• bitenforcer — was v1 tut, und warum es bewusst nichts durchsetzt.
• Ihre Downloads verifizieren — belegen Sie die Bytes, bevor Sie sie ausführen.
• Asset Management — wo die Telemetrie landet.

Fragen? Schreiben Sie an [email protected]. Sicherheitsprobleme gehen an [email protected].