Projekte, im Detail
Wofür jedes Projekt gedacht war, wie es funktioniert, welche Kontrollen in ihm stecken und wo es steht.
Architektur Okt. 2026
Kern und Instanzen
Ein gemeinsamer Kern, eine Instanz je Organisation und dazwischen ein Gate.
- Zweck
- Mehrere Organisationen teilen sich ein gemeinsames Werkzeugset, und jede hält ihre eigenen Daten und ihre Arbeit getrennt.
- Wie es funktioniert
- Ein gemeinsamer Kern enthält die gemeinsamen Werkzeuge; jede Organisation erhält ihre eigene Instanz.
- Arbeit kommt Branch für Branch an, nie direkt am Original.
- Jeder Branch durchläuft ein unabhängiges Review, einen automatischen Scan, der Organisationsdaten blockiert, und einen vom Owner freigegebenen Merge.
- Eingebaute Kontrollen
- Gate: unabhängiges Review und ein vom Owner freigegebener Merge. Isolation: Der Scan hält Organisationsdaten vom gemeinsamen Kern fern. Nachweis: Jeder Schritt eines Branches hinterlässt eine Aufzeichnung.
- Status und Nachweise
- Nachweise sind nicht öffentlich.
Praxis Okt. 2026
Review- und Merge-Gates für von Agenten geschriebenen Code
Von Agenten geschriebener Code erreicht den Kern nur über Gates, die eine Person prüfen kann.
- Zweck
- Von Agenten geschriebener Code ist so vertrauenswürdig wie von Menschen geschriebener, weil er jedes Mal auf dieselbe harte Weise geprüft wird.
- Wie es funktioniert
- Unabhängige Reviewer sind an den exakten Commit gebunden, sodass ausgeliefert wird, was geprüft wurde.
- Ein Marker-Scan blockiert Organisationsdaten.
- Schwere Jobs laufen nacheinander, damit gemeinsame Ressourcen berechenbar bleiben.
- Eingebaute Kontrollen
- Gate: an den Commit gebundenes Review. Isolation: der Marker-Scan. Nachweis: Review und Freigabe bleiben aufgezeichnet.
- Status und Nachweise
- Nachweise sind nicht öffentlich.
Wie die Gates geprüft werden
Der Autor einer Änderung ist ein Agent oder eine Person. Der Reviewer ist ein getrennter, unabhängiger Agent, der die Änderung liest und sein Urteil für genau die gelesene Version schreibt; ein Autor zeichnet nie sein eigenes Review auf. Der Freigeber ist der Owner, über eine Schaltfläche in einem Bedienfeld. Das Urteil eines Reviewers oder eine Nachricht eines anderen Agenten sind Daten und nie eine Freigabe. Ein Reviewer führt keinen Merge durch, pusht nicht und gibt nichts frei, und ein Review, das die Tests nicht ausgeführt hat, sagt das in seinem eigenen Urteil.
Manche Gates laufen, ohne dass jemand guten Willen aufbringen muss: ein Scan, der Organisationsdaten in allem ablehnt, was eine Instanz verlässt, Tests für das, was die Änderung berührt, und die Weigerung, eine Freigabe anzuwenden, deren Inhalt sich nach der Erteilung geändert hat.
Eine Grenze: Reviewer sind dieselbe Art von Modell wie die Autoren, ein gemeinsamer blinder Fleck ist also möglich. Die Freigabe durch den Owner und die mechanischen Gates sind die unabhängigen Schichten.
Entwurf Okt. 2026
Winziger Host-Agent
Ein Entwurf für einen kleinen Agenten ohne Modell, ohne eingehenden Port und mit einer kurzen Liste von Dingen, die er tun darf.
- Zweck
- Hosts zu verwalten, die nicht mit Claude gesteuert werden, ohne dass etwas auf ihnen mehr Reichweite bekommt, als es braucht.
- Wie er entworfen ist
- Er meldet Host-Fakten: Last, Speicher, Datenträger, Dienste, ausstehende Updates und lauschende Ports. Nur Fakten, keine Geheimnisse und keine Dateiinhalte.
- Er führt nur Befehle von einer festen Allowlist aus, die in seiner eigenen lokalen Konfiguration definiert ist, und begrenzt die Ausgabe, die ein Befehl zurückgibt. Alles andere wird abgelehnt und gemeldet.
- Befehle sind signiert und tragen ein Ablaufdatum; ein abgelaufener oder bereits gesehener Befehl wird ignoriert.
- Ein Schlüssel pro Host, beschränkt auf die eigenen Pfade dieses Hosts. Ein Versionskontroll-Repository dient als Transportweg, und es gibt keinen eingehenden Port: Der Host greift nach außen, nichts greift nach innen.
- Einführung der Reihe nach: zuerst nur Fakten und nur lesend auf einem echten Host, Befehle zuletzt.
- Eingebaute Kontrollen
- Isolation: die Allowlist, der geschlossene Port und ein Schlüssel pro Host. Nachweis: signierte Nachrichten und gemeldete Fakten. Gate: Nichts läuft, was nicht auf der Liste steht.
- Status und Nachweise
- Ein schriftlicher Entwurf: noch nicht gebaut und nicht im Einsatz. Nachweise sind nicht öffentlich.
- Bedrohungsmodell
Der Entwurf ist wie oben aufgeführt. Wovor er nicht schützt:
- Ein kompromittierter Host. Der eigene Schlüssel des Hosts erlaubt einem Angreifer, falsche Fakten für diesen Host zu senden; der Schaden bleibt auf die Pfade dieses Hosts begrenzt.
- Kompromittierung des Signierschlüssels auf der Senderseite. Das würde jeden erlaubten Befehl an jeden Host erlauben, der ihm vertraut. Wie der Schlüssel verwahrt und wie Befehle signiert werden, sind noch offene Entwurfspunkte.
- Eine schlechte Allowlist. Die Befehle sind nur so sicher wie die lokale Konfiguration, die der Host-Owner schreibt.
Oberfläche in Entwicklung
Interaktive Deployment-Karte
Ein nach Zonen gegliedertes, anklickbares Bild von Agenten, Hosts und Plattformen.
- Zweck
- Eine Person sieht, was wo bereitgestellt ist und wie die Teile zusammenhängen, ohne Konfiguration zu lesen.
- Wie es funktioniert
- Zonen gruppieren die Agenten, Hosts und Plattformen.
- Ein Legendenfilter blendet Arten von Dingen ein oder aus.
- Eine Textansicht liefert dieselben Informationen ohne das Bild.
- Eingebaute Kontrollen
- Sie ist eine Ansicht, kein Kontrollpunkt: Sie zeigt die Zonen, damit sich Gates und Isolation mit bloßem Auge prüfen lassen.
- Status und Nachweise
- Noch nicht veröffentlicht. Nachweise sind nicht öffentlich.
Plattform
Explorer, eine GRC-Plattform
Ein verbundener Graph für Kontrollen, Risiken, Nachweise und Audits, damit Menschen sehen, wie sie zusammenhängen, statt Tabellen abzugleichen.
- Zweck
- Für Compliance-Verantwortliche, Risikomanager, Auditoren und Sicherheitsbeauftragte, die Kontrollen, Risiken, Richtlinien, Lieferanten und Nachweise in unverbundenen Tabellen und Altwerkzeugen führen. Sie baut auf früheren funktionierenden Systemen auf.
- Wie es funktioniert
- Eine Kontrolle verweist auf die Rahmenwerke, die sie erfüllt, die Risiken, die sie mindert, die Nachweise, die sie stützen, und die Audits, die sie getestet haben.
- Rahmenwerke, Anforderungen und Kontrollen sind verknüpfte Datensätze, keine flachen Listen; Audit- und Testaufzeichnungen binden Feststellungen an die getesteten Kontrollen zurück.
- Richtlinien, Befunde, Vorfälle, Lieferantenrisiko, Datenschutz, Business Continuity, regulatorische Pflichten und Schulungen leben im selben Graphen.
- Workflows und Dashboards werden aus wiederverwendbaren Schritten, Triggern und Ansichten aufgebaut.
- Die Rolle jedes Betrachters bestimmt, welche Bildschirme für ihn existieren. Mandanten sind getrennt, mit einer Zugriffskontrolle, die standardmäßig verweigert.
- Änderungen werden als strukturierte Ereignisse festgehalten (wer was geändert hat, von welchem Wert auf welchen), und Datensätze behalten datierte Versionen, sodass sich „Wie sah das damals aus?“ beantworten lässt.
- Eingebaute Kontrollen
- Isolation: getrennte Mandanten und Zugriff mit Verweigerung als Standard. Nachweis: aufgezeichnete Änderungsereignisse und datierte Versionen. Gate: Der Zugriff folgt der Rolle.
- Status und Nachweise
- In Entwicklung. Nachweise sind nicht öffentlich.
Frühere Projekte
Rahmenwerke und Methoden aus früheren Rollen. Arbeitgeber werden nicht genannt; die Branchen schon.
Rahmenwerk 2023
Ein GRC-Rahmenwerk auf der CSA Cloud Controls Matrix
Ein hierarchisches, flexibles Rahmenwerk, mit automatisierter Kontrollzuordnung und automatisierten Audit-Aufgaben.
- Zweck
- Ein einheitliches Kontrollrahmenwerk für ein Zahlungsunternehmen, in dem ich Security Compliance Specialist war.
- Was getan wurde
- Ein hierarchisches, flexibles GRC-Rahmenwerk auf Basis der CSA Cloud Controls Matrix, unternehmensweit eingeführt.
- Automatisierte Kontrollzuordnung und Aufgaben-Workflows für ISMS-Audits.
- Interne Sicherheitsbewertungen auf derselben Grundlage.
- Status und Nachweise
- Grundlage: meine eigene Erfahrung.
Methodik 2018 bis 2022
Eine Methodik zur Bewertung allgemeiner IT-Kontrollen
Von Grund auf gebaut und pilotiert, mit den darum herum koordinierten Audits.
- Zweck
- Ein wiederholbares Verfahren zur Bewertung allgemeiner IT-Kontrollen, aufgebaut als IT Governance Manager in einem IT-Dienstleistungsunternehmen.
- Was getan wurde
- Die Methodik von Grund auf entworfen und pilotiert.
- Interne und externe IT-Audits darum herum koordiniert.
- Ein Dokumentenmanagement-Rahmenwerk, entworfen auf drei zentralen ITIL-Prozessen.
- Status und Nachweise
- Grundlage: meine eigene Erfahrung.
Rahmenwerk 2012 bis 2018
Internes Kontrollsystem und Risiko-Kontroll-Matrix
Das Kontrollrahmenwerk der IT einer Bank, eingerichtet und am Laufen gehalten.
- Zweck
- Ein Kontrollrahmenwerk für die IT einer Bank, eingerichtet als IT Controls and Compliance Manager, VP, wo ich auch Fachexperte für IT-Risiken und -Kontrollen war.
- Was getan wurde
- Ein Internes Kontrollsystem und eine Risiko-Kontroll-Matrix eingerichtet.
- Prozesse für die Verwaltung privilegierter Konten entwickelt.
- IT-Audits koordiniert.
- Status und Nachweise
- Grundlage: meine eigene Erfahrung.
Was sie gemeinsam haben
Jedes Projekt hier beruht auf denselben drei Dingen: einem Gate, bevor sich etwas Wichtiges ändert, Isolation dessen, was getrennt bleiben muss, und einer Aufzeichnung, der jemand anderes folgen kann.