Protection Shield

Akuter defensiver Einsatz

Nur für eigene oder ausdrücklich autorisierte Systeme, Netze und Server. Zuerst Asset-ID, Owner, Ausführungsautorität, laufende Sperren, Auswirkungsradius und vorhandenen Notfall-/Rollbackweg feststellen. Ein Alarm oder eine Auffälligkeit allein ist keine Freigabe für produktive Netzänderungen. Keine Gegenangriffe, kein Zugriff auf fremde Assets und kein unautorisierter Port- oder Dienstescan.

1. Lage sichern: Uhrzeit UTC, betroffene Dienste, aktuelle Konfiguration und begrenzte relevante Logauszüge/Hashes aufnehmen; Geheimnisse redigieren, Originale privat erhalten. Symptome, bestätigte Kompromittierung und Hypothesen getrennt führen.
2. Bestehende Autorität prüfen: Projekt-Runbook, Standing-Entscheid, privates Assetprofil und konkrete config.json-Aktion lesen. Ohne gültige Deckung nur lesend analysieren und die tatsächlich nötige Restentscheidung als Ticket routen. Technische Blocker an Worker statt pauschal an den Nutzer.
3. Maßnahme eingrenzen: etwa einen eigenen Dienst über den vorhandenen Service-Manager stoppen, eine konkret exponierte Regel im vorhandenen Firewall-Workflow ändern, Zugang über die dafür bestimmte Rotation sperren oder einen Patch über security-tech-stack-check ausführen. Exakter Zielhost, Regel/Dienst, erwartete Wirkung, Zeitfenster und Rückweg müssen gebunden sein. Keine pauschalen Netzsperren und keine Admin-Erhöhung durch den Skill.
4. Ausführen und verifizieren: nur mit vorhandenen nativen Tools und gültigem Asset-/Aktionsscope; vorher/nachher Zustand, Exitcode, Funktionsprobe, Logwirkung und Nebenwirkung protokollieren. Bei Fehlschlag nach Runbook zurückrollen und Restore separat messen. Eine konfigurierte Absicht ist noch keine wirksame Abwehr.

Wiederkehrende Prüfung

Ein privates Profil benennt nur erlaubte Logpfade/API-Leser, Techshot-Stand, Assetliste, Lookback, Filter, Zeitplan, Retention und Eskalationsziel. Den vorhandenen Scheduler/Logdienst anbinden statt einen zweiten Daemon zu installieren. Jeder Lauf liest nur den begrenzten Zeitraum und die benannten Quellen, dedupliziert Ereignisse, vergleicht Stackstände über tech-detect und relevante aktuelle Hersteller-/CISA-Hinweise über security-tech-stack-check. Quelle, UTC-Fenster, Parserfehler, fehlende Rechte und Abdeckung in den Receipt; Routineerfolge nicht als Alarm aufblasen. Ein geplanter Lauf ist erst nach einem tatsächlichen Scheduler- und Ergebnis-Readback aktiv.

Für Stackdrift desselben Servers den vorherigen und aktuellen vollständigen Techshot mit unverändertem Slot und Hostnamen über python -X utf8 scripts/techshot.py compare --left <vorher.json> --right <jetzt.json> --output <privat>/vergleich.json vergleichen; den Skriptpfad aus dem tech-detect-Skillverzeichnis auflösen. axis=same-host-time, beide Erfassungszeiten und chronology zurücklesen. version-uncertain, fehlende Coverage oder ein zu alter Stand für die konkrete Entscheidung bleiben offene Befunde; das Vergleichsdatum allein macht keine Messung frisch. Bei fehlender Pflichtprovenienz oder Hostnamenänderung im selben Slot HOLD bis die Assetkontinuität extern belegt ist; keinen Slot zum Umgehen der Prüfung umbenennen.