Doogree
Reaktion · Behebung

Beheben mit Zustimmung: Korrigieren, ohne die Grenze zu überschreiten

06.07.2026 · ~5 Min. Lesezeit
BehebungNIST RespondTOFUSignierter Steuerkanal

Erkennung ist nur die halbe Arbeit. Die andere Hälfte ist das Beheben — aber blinde automatische Behebung ist genauso gefährlich wie das Problem selbst. Der Ansatz von Doogree ist einfach: Wir beheben nichts hinter Ihrem Rücken. Jedes behebbare Problem erscheint als Vorschlag, jemand genehmigt ihn, und erst dann macht sich eine bekannte, eingeschränkte, umkehrbare Aktion auf den Weg.

Die Anatomie eines Behebungsvorschlags

Jedes behebbare Problem läuft nicht von selbst — es wird vorgeschlagen. Der Betreiber sieht drei Buttons: Genehmigen / Beheben, Nicht jetzt, Verwerfen. Ein Tippen auf Genehmigen sendet eine modellierte, per Positivliste erlaubte Aktion — kein beliebiges Shell-Kommando — und dann verifiziert das System den Zustand erneut und durchläuft die Schleife noch einmal, bis das Problem gelöst oder verworfen ist. Es läuft kein „alles mit einem Klick beheben" im Verborgenen; es gibt eine kurze Kette aus Vorschlag → Genehmigung → Aktion → Verifizierung.

Ein Vorschlag, keine Ausführung. Die Voreinstellung ist immer, dass der Mensch (oder später — eine definierte Richtlinie) in der Schleife ist. Eine bedeutsame Aktion geschieht niemals ohne ausdrückliche Zustimmung, und jede hat einen vollständigen Audit-Trail — wer sie genehmigt hat, was gesendet wurde und was das Ergebnis war.

Warum es keine freie Shell gibt — das Vertrauensmodell

Das Geheimnis ist, dass die Aktionen nicht „führe dieses Kommando aus" lauten. Aktionen gegen einen Server werden über einen signierten, TOFU-gepinnten Steuerkanal gesendet (Trust On First Use): Die kanonische Form des Kommandos wird signiert, sodass ein Replay oder eine Manipulation sofort erkannt wird. Es gibt keine freie Shell — nur Aktionen aus einer Positivliste, die mit ihren ausdrücklichen Namen aufgerufen werden. Die praktische Bedeutung: Selbst wenn eine Cloud oder eine Datenbank kompromittiert wird, kann ein Angreifer kein Kommando fälschen und daraus RCE auf der Flotte machen. Die Grenze zwischen „erkennen" und „Code auf einem Gerät ausführen" wird eifersüchtig bewacht.

Least-Privilege in Aktion. Jede Aktion weiß genau, was sie darf, und nicht mehr. Es gibt keinen „Schlüssel zu jeder Tür" — es gibt spezifische, per Positivliste erlaubte Schlüssel, von denen jeder nur eine einzige Tür öffnet und eine Spur hinterlässt.

Kritischer Vorfall → Eindämmungs-Button

Beheben mit Zustimmung ist direkt mit der Vorfall-Engine verbunden. Wenn die SIEM-Lite-Engine mehrere Alarme zu einem korrelierten Vorfall mit dem Schweregrad hoch/kritisch zusammenfaltet, bietet sie automatisch einen Eindämmungs-Button. Das Genehmigen des Buttons handelt über denselben signierten Steuerkanal — dasselbe Vertrauensmodell, dieselbe Positivliste, dasselbe Audit. So wird die Angriffskette nicht nur erkannt und gekennzeichnet — sie erhält eine umkehrbare Reaktionsaktion, nur einen Fingertipp entfernt.

Warum das für ein kleines Unternehmen kritisch ist

Ein kleines Unternehmen hat in der Regel keinen fest angestellten Sicherheitsingenieur. Beheben mit Zustimmung gibt einem nicht fachkundigen Geschäftsinhaber einen sicheren „Das beheben"-Button — vollständig dokumentiert — statt eines teuren SOC. Und wenn es um etwas Bedeutsames geht, bleibt der Mensch in der Schleife; später kann man es hinter eine Richtlinie mit 2FA-Genehmigung (Push-Approval) setzen, sodass eine riskante Aktion erst nach Verifizierung ausgeht.

Der theoretische Rahmen: Das ist die Phase Respond von NIST — nicht nur erkennen, sondern kontrolliert reagieren. Alles baut auf Least-Privilege und auf Lieferketten-Sicherheit auf: Es gibt keinen Kanal, über den eine kompromittierte Cloud beliebige Kommandos in die Geräte werfen könnte. Behebung — ja. Die Grenze überschreiten — niemals.

← Zurück zum Blog · So funktioniert es →