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
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
