E.D. Endpoint Profile (EDEP)

Deutsch · English · Projektseite

Offenes Sicherheitsprofil für Windows-Endgeräte: Outbound-Zero-Trust, Telemetrie-Souveränität und deterministische Isolation.

EDEP legt fest, was ein Windows-Rechner technisch erzwingen muss, damit gilt:

• Kein Programm spricht ins Netz, das nicht ausdrücklich dafür zugelassen ist.
• Das Betriebssystem überträgt nur die unvermeidliche Telemetrie, und der Nutzer sieht das.
• Jede Blockade ist lokal protokolliert.
• Bei erkanntem Datenabfluss isoliert sich der Host, deterministisch und nicht auf Modellverdacht.

EDEP ist kein Antivirus. Es ist als Ergänzung zu Microsoft Defender oder einem anderen AV-Produkt gedacht.

Status: Entwurf 0.1.0. Die Spezifikation ist noch nicht versiegelt. Letzter signierter Entwurf: 0.1.0-draft.6 (SIGNING.md). Gemessen ist L1 in Hyper-V-VMs mit Windows 11 Enterprise, Pro und Home; was dabei offen blieb, steht in SPEC.md, Abschnitt 3.6. Eine Unterstützung durch das BSI besteht nicht.

Name: EDEP steht für E.D. Endpoint Profile, „E.D.“ für E.L.L.A. Defence. Die Idee entstand im Umfeld der E.L.L.A.-Projekte des Autors. EDEP ist aber technisch eigenständig: Es braucht keine andere E.L.L.A.-Komponente und ist keine Voraussetzung für eine davon (siehe letzter Absatz der SPEC.md). Das Repository hieß bis 2026-10-11 „E.L.L.A.-Defence-Endpoint“; die alte Adresse leitet weiter.

Kostenloses Audit: Wie offen ist dein Windows?

Windows lässt ausgehenden Verkehr standardmäßig für jedes Programm zu, auch mit Defender. Das Audit zeigt in einer Minute, was davon auf deinem Rechner zutrifft. Es ändert nichts und läuft auch ohne Adminrechte.

# Im Ordner baseline\L1 (für das vollständige Ergebnis als Administrator)
.\Invoke-EdepAudit.ps1 -Open

Ergebnis: eine Punktzahl von 0 bis 100, Kategorien (ausgehender und eingehender Verkehr, Programmkontrolle, Telemetrie, Protokollierung, Angriffsfläche) und für jeden offenen Punkt eine Erklärung mit konkreter Empfehlung, in der Konsole und als HTML-Bericht. Die Sprache richtet sich nach der Windows-Anzeigesprache; -Language de oder -Language en erzwingt sie.

_{Beispielbericht eines ungehärteten Windows Server 2025 (GitHub-Actions-Runner, mit Adminrechten), erzeugt in der CI.}

Nicht glauben, prüfen

Frage	Antwort
Stimmt das, was hier steht?	Jede technische Aussage hat eine Quelle oder einen Messwert: Nachweisregister. Was noch nicht geprüft ist, steht dort offen als ⏳.
Woher stammen die Fakten?	28 verlinkte Quellen, überwiegend Microsoft Learn und MITRE ATT&CK: SPEC, Anhang B
Was kann EDEP nicht?	Restrisiken und acht bekannte Umgehungen, jede mit Test: SPEC 3.3/3.4
Wo weicht EDEP von Microsoft ab, und warum?	DD-12
Wie prüfe ich es selbst?	In 5 Minuten ohne Risiko, in 30 Minuten in einer VM: Selbst prüfen. Eine Messung für uns wiederholen: Wiederholung
Welche Fehler gab es schon?	Errata
Ich habe eine Lücke gefunden.	SECURITY.md

Stufen

Stufe	Umsetzung	Eigener Code
L1 Baseline	Nur Windows-Bordmittel (Firewall, App Control, Richtlinien)	nein, Skripte
L2 Enforced	Agent mit WFP-Filtern, Programmidentität per Signatur/Hash, Boot-Time-Filter	ja, ohne Kernel-Treiber
L3 Isolated	Deterministische Notfall-Isolation, Metadaten-Anomalieerkennung, Modell nur beratend	ja

Schnellstart L1

In einer PowerShell als Administrator im Ordner baseline\L1:

# 0. Nur für diese Sitzung: Skriptausführung erlauben (Windows sperrt sie standardmäßig)
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass

# 1. Nur anzeigen, was passieren würde
.\Install-EdepL1.ps1 -DeployAppControlAudit -WhatIf

# 2. Im Audit-Modus anwenden (ausgehend bleibt noch erlaubt, alles wird protokolliert)
.\Install-EdepL1.ps1 -DeployAppControlAudit

# 3. Prüfen (mit -ProbeUpdates zusätzlich die Update-Erreichbarkeit messen)
.\Test-EdepL1.ps1

# 4. Nach Auswertung des Firewall-Logs: ausgehend standardmäßig blockieren
.\Install-EdepL1.ps1 -Enforce -DeployAppControlAudit -AllowWindowsUpdate `
    -AllowProgram "${env:ProgramFiles(x86)}\Microsoft\Edge\Application\msedge.exe"

# Rückgängig (stellt den Zustand vor der ersten Anwendung her)
.\Restore-EdepL1.ps1

Achtung bei -Enforce: Danach haben nur noch Programme mit Erlaubnisregel Netzzugang: Windows-Kernnetzwerk, die unter -AllowProgram genannten Programme und Programme mit eigenen Windows-Regeln (Store-Apps). PowerShell, curl.exe, certutil und andere Anhang-A-Werkzeuge sind ausgehend gesperrt, auch für Install-Module und winget-Skripte.

Updates unter -Enforce (gemessen, Lauf 1, Lauf 2, Lauf 3): Kurzfassung: Den Enforce-Modus nur einsetzen, wenn die Updates einen eigenen, definierten Weg haben (WSUS, Intune, Proxy; Betriebsmodell in SPEC 3.5). Für Einzelrechner ohne solchen Weg sind Audit-Modus, LOLBin- und Telemetrie-Sperre sowie App Control (Audit) der belegte Kern. Die Option -AllowWindowsUpdate verbessert die Lage, ist aber nicht zuverlässig (siehe unten).

Ohne weitere Maßnahme sind unter -Enforce Windows Update, Defender-Signaturupdates und BITS nicht erreichbar. Die Erlaubnisregeln mit -Service greifen nicht, weil diese Dienste mit dem Token des aufrufenden Benutzers und ohne Dienst-SID verbinden (E-73, E-84). Test-EdepL1 meldet dann EDEP-TEL-04 = FAIL (14/15).

Mit -AllowWindowsUpdate legt der Installer stattdessen Regeln „Programm svchost.exe, TCP 80/443, nur zu den Update-Domains“ an (Dynamic Keywords der Windows-Firewall, Domainliste mit Quelle und Stand in EdepL1.Common.ps1). Gemessen: Auf Pro gelang die Update-Suche ab dem zweiten Versuch (auch nach einem Neustart ohne Cache), svchost.exe erreicht sonst nichts (E-88). Auf Enterprise (Lauf 3) scheiterten im ersten Messblock alle neun Versuche (Suche, BITS, Update-MpSignature), elf Minuten später gelang die Suche ab dem zweiten Versuch; die Ursache ist unbekannt. Es kann also auch ganz ausbleiben. BITS zu Microsoft gelingt ab dem zweiten Versuch, Defender-Signaturupdates nur mit Wiederholungen: Die Firewall lernt die Adressen mit einigen Sekunden Verzögerung aus der DNS-Antwort, ein sofortiger erster Versuch wird abgewiesen (E-12 bis E-14, E-89). Kosten und Grenzen:

• Der Netzwerkschutz von Defender muss laufen; der Installer stellt ihn auf den Audit-Modus, falls er aus war, und Restore stellt ihn zurück. Mit fremdem Virenschutz geht das nicht (ungemessen).
• Die Firewall lernt die Adressen aus beobachteten DNS-Antworten und verwirft sie beim Neustart. Die ersten Verbindungen können scheitern (gemessen: ein BITS-Versuch), spätere gelingen.
• Defender-Signaturupdates sind damit nicht gelöst: Update-MpSignature scheitert weiter, und WdNisSvc und MDCoreSvc werden abgewiesen (E-89). Ungemessen: Installation von Updates, die Suche nach einem Neustart mit leerem Cache, Dauerbetrieb.
• Den Enforce-Modus nur mit einem Wartungsfenster einsetzen und Restore-EdepL1.ps1 bereithalten. Nach einer Wiederherstellung den Zustand mit Test-EdepL1.ps1 prüfen.
• Restore-EdepL1.ps1 ohne -BackupPath nimmt die älteste Sicherung unter C:\ProgramData\EDEP\backup, also den Zustand vor der ersten Anwendung überhaupt. Liegen Sicherungen früherer Anwendungen vor, geht die Rücknahme auf deren Stand zurück, nicht auf den von vor der letzten Anwendung; gemessen unterschied sich dabei die Zahl der erlaubenden Firewallregeln um je eine (E-91). Für einen bestimmten Stand -BackupPath mit dem Ordner der gewünschten Sicherung angeben.

Installer und Restore-EdepL1 fragen vor jedem Schritt nach (Installer: fünf, mit -DeployAppControlAudit sechs, mit -AllowWindowsUpdate eine weitere; Restore: vier plus je eine für App-Control-Richtlinien, Schlüsselwörter und Netzwerkschutz, soweit vorhanden). Bestätigt wird mit dem angezeigten Buchstaben: auf deutschem Windows J (oder A für alle), auf englischem y. Für Skripte: -Confirm:$false.

Die Blocklisten stützen sich zum Teil auf Programmpfade. Wird eine Richtlinie per Gruppenrichtlinie oder Intune verteilt, überschreibt diese die lokalen Einstellungen. Test-EdepL1.ps1 prüft deshalb immer den wirksamen Zustand.

Inhalt

Pfad	Inhalt
SPEC.md	Normative Spezifikation: Bedrohungsmodell, Anforderungen, Stufen
conformance/	Konformitätstests je Anforderung
baseline/L1/	Audit sowie Anwenden, Prüfen und Wiederherstellen für L1 (Modul EDEP)
tools/	Modul bauen, signieren, Richtlinien validieren
schema/edep-policy.schema.json	Richtliniensprache (JSON Schema)
examples/policy.example.yaml	Beispielrichtlinie
docs/DESIGN-DECISIONS.md	Warum EDEP so gebaut ist, und was vom ersten Konzept korrigiert wurde
docs/L2-AGENT-ARCHITECTURE.md	Referenzarchitektur für den L2-Agenten
docs/ROADMAP.md	Meilensteine
docs/archive/	Ursprüngliche Konzeptpapiere (nicht mehr gültig)

Was EDEP nicht leistet

Angreifer mit Administrator- oder Kernel-Rechten, Inhalte verschlüsselter Verbindungen, Missbrauch zugelassener Programme und kompromittierte signierte Software liegen außerhalb des Geltungsbereichs. Details stehen in SPEC.md, Abschnitt 3.3. Diese Grenzen sind Teil der Norm und dürfen in keiner Produktbeschreibung fehlen.

Die Einschränkungen der Referenzimplementierung (was gemessen ist, was nicht, und was ungeklärt bleibt) stehen in SPEC.md, Abschnitt 3.6.

Lizenz

MIT