DNSSecurity.
DNS Security erkennt und blockiert verdächtige Zielnamen, bevor eine Verbindung zum Ziel aufgebaut wird. Sie ist schnell und breit ausrollbar, sieht jedoch weder Inhalt noch jede Kommunikation. Ihre Wirkung hängt an Resolvern, Durchsetzung und einem gepflegten Ausnahmeprozess.
Ein früher Kontrollpunkt.
DNS ist eine natürliche Stelle für Schutz gegen Phishing, Malware-Infrastruktur und Command-and-Control. Der Dienst kann an Endpunkten, Standorten und in Cloud-Netzen greifen. Gute Ergebnisse erfordern Schutz gegen Umgehungen über externe Resolver und verschlüsseltes DNS.
Signal, nicht Vollsicht.
Ein DNS-Treffer belegt eine beabsichtigte Kommunikation nicht. SWG, Firewall und NDR liefern je nach Lage tiefere Kontextdaten. DNS Security ist ein präventiver Control Point und kein Ersatz für Endpoint Detection oder Incident Response.
Port 53 ist sichtbar. Verschlüsseltes DNS braucht eine Regel.
Die klassische Abfrage vom Client zum Resolver läuft über UDP oder TCP Port 53 und ist im lokalen Netz grundsätzlich lesbar. DNS over TLS nutzt üblicherweise TCP 853. DNS over HTTPS transportiert Abfragen über HTTPS, meist Port 443. Beide schützen die Abfrage auf dem Transportweg.
Verschlüsselung ist kein Grund, die Steuerung abzugeben. Wenn Browser oder Endpunkte einen externen DoH- oder DoT-Resolver verwenden, fehlen dem vorgesehenen DNS-Schutz und dem SOC Sichtbarkeit und Durchsetzung. Das Zielbild benennt deshalb den autorisierten Resolver, erlaubt verschlüsseltes DNS dorthin und kontrolliert Umgehungen durch Richtlinie, Endpoint-Konfiguration und Netzwerkregeln.
Die erste Frage zählt.
Fast jede Verbindung beginnt mit einer DNS-Anfrage: Ein Gerät fragt einen rekursiven Resolver, welche IP-Adresse zu einem Namen gehört, und der Resolver sucht die Antwort bei den zuständigen Nameservern. DNS Security setzt genau an diesem Punkt an. Ein Protective DNS ist ein rekursiver Resolver, der die Auflösung von Domains verweigert oder auf eine Warnseite umleitet, wenn sie als schädlich bekannt sind. Weil die Prüfung vor dem Verbindungsaufbau stattfindet, wirkt sie für jedes Protokoll und jedes Gerät, das diesen Resolver nutzt, auch für Drucker, IoT- und OT-Geräte ohne Agent.[1,2]
Es gibt drei Bauformen. Cloud-Resolver erhalten die Anfragen der Standorte, weil der lokale DNS-Server an sie weiterleitet, und die Anfragen mobiler Geräte über einen Client. Sicherheitsfunktionen im eigenen DNS- oder DDI-System prüfen die Anfragen im Rechenzentrum und kennen dank DHCP- und IPAM-Daten das Gerät hinter jeder IP-Adresse. Response Policy Zones (RPZ) schliesslich sind ein offenes Verfahren, mit dem ein eigener Resolver Sperrlisten eines Feeds übernimmt und durchsetzt. Firewalls ergänzen das, indem sie DNS-Verkehr im Durchgang inspizieren.[3,4,5,6]
Die Erkennung arbeitet auf mehreren Ebenen. Sperrlisten enthalten bekannte Phishing-, Malware- und Command-and-Control-Domains. Algorithmisch erzeugte Domains (DGA) erkennt man an ihrer Struktur und an vielen fehlgeschlagenen Auflösungen. DNS-Tunneling versteckt Daten in langen Subdomains oder ungewöhnlichen Antworten und wird über Muster und Mengen pro Gerät sichtbar.[2,7,8]
Klassisches DNS läuft unverschlüsselt über Port 53. DNS over TLS (DoT, Port 853) und DNS over HTTPS (DoH, meist Port 443) verschlüsseln die Anfrage auf dem Weg zum Resolver. Das schützt vor Mitlesen, kann aber den vorgesehenen Schutz umgehen, wenn Browser oder Apps einen fremden DoH-Resolver nutzen. Das Zielbild benennt deshalb einen autorisierten Resolver, erlaubt verschlüsseltes DNS nur dorthin und setzt das über Endpunkt-Richtlinien und Firewall-Regeln durch. Einige Produkte übersetzen unverschlüsselte Anfragen selbst in DoH oder prüfen DoH-Verkehr im Durchgang.[9,10,11]
Typische Probleme
| Problem | Wie man es löst |
|---|---|
| Umgehung über fremde Resolver | Geräte mit fest eingestelltem externem DNS oder Browser mit eigenem DoH-Resolver laufen am Schutz vorbei. Autorisierten Resolver per Richtlinie vorgeben, ausgehendes DNS und bekannte DoH-Ziele an der Firewall sperren, Ausnahmen dokumentieren.[11] |
| Treffer ohne Zuordnung | Leitet ein zentraler DNS-Server weiter, sieht der Cloud-Resolver nur dessen Adresse. Forwarder oder Appliances einsetzen, die interne IP-Adresse oder Identität mitliefern.[13] |
| Lücken bei mobilen Geräten | Ausserhalb des Firmennetzes greift der Standortschutz nicht. Client oder App auf allen mobilen Geräten verteilen und die Abdeckung messen.[14] |
| Fehlalarme ohne Ausnahmeprozess | Neu registrierte oder falsch kategorisierte Domains blockieren legitime Dienste. Freigaben mit Owner, Begründung und Ablaufdatum führen. |
| Treffer ohne Folgearbeit | Ein gesperrter Aufruf eines Command-and-Control-Servers zeigt ein infiziertes Gerät an. DNS-Ereignisse mit Priorität ans SOC geben und das Gerät untersuchen. |
Auswahlfragen
| Frage | Worauf die Antwort hinweisen sollte |
|---|---|
| Wie wird jede Anfrage einem Gerät oder Benutzer zugeordnet? | Die Antwort sollte zeigen, wie interne Adressen, Identitäten und Standorte trotz Weiterleitung sichtbar bleiben. |
| Wie geht das Produkt mit DoH und DoT um? | Gute Antworten nennen eigene verschlüsselte Endpunkte und den Umgang mit fremden DoH-Resolvern. |
| Woher stammen die Bedrohungsdaten, und wie oft werden sie aktualisiert? | Erwartet werden Quellen, Aktualisierungsintervall und ein Verfahren für Fehlalarme. |
| Erkennt das Produkt DNS-Tunneling und DGA ausdrücklich? | Die Antwort sollte Verfahren und Testergebnisse benennen, nicht nur Sperrlisten. |
| Wo werden Anfragen verarbeitet und protokolliert? | Gefragt sind Standorte, Aufbewahrung und Export ins eigene SIEM. |
| Was geschieht bei Ausfall des Resolvers? | Erwartet werden Redundanz, Rückfallverhalten und ein dokumentierter Notbetrieb. |
Betrieb und Verantwortung
Den Resolver und die Richtlinien betreibt meist das Netzwerk- oder Infrastrukturteam, die Auswertung der Treffer liegt beim SOC. Ausnahmen genehmigt die Security, mit Owner und Ablaufdatum. Sinnvolle Kennzahlen sind der Anteil der Geräte, die nachweislich den autorisierten Resolver nutzen, die Zahl der Umgehungsversuche, die Zahl der Treffer auf Command-and-Control-Domains mit abgeschlossener Untersuchung und die Zeit bis zur Freigabe einer fälschlich gesperrten Domain.
Regulatorischer Bezug
ISO/IEC 27001:2022 adressiert das Thema in Annex A über 8.7 «Protection against malware», 8.16 «Monitoring activities», 8.21 «Security of network services» und 8.23 «Web filtering». NIS2 nennt in Art. 21 Abs. 2 lit. b die Bewältigung von Sicherheitsvorfällen und in lit. g grundlegende Verfahren der Cyberhygiene; DORA verlangt in Art. 9 Abs. 3 lit. c IKT-Lösungen, die Verletzungen der Vertraulichkeit und Datenverlust verhindern, und in Abs. 4 lit. b eine solide Struktur für das Netz- und Infrastrukturmanagement.[15,16,17,18,19,20]
Quellen: [1] ncsc.gov.uk · [2] infoblox.com · [3] docs.umbrella.com · [4] efficientip.com · [5] datatracker.ietf.org · [6] switch.ch · [7] akamai.com · [8] efficientip.com · [9] rfc-editor.org · [10] rfc-editor.org · [11] zscaler.com · [12] docs.umbrella.com · [13] docs.umbrella.com · [14] docs.umbrella.com · [15] isms.online · [16] isms.online · [17] isms.online · [18] isms.online · [19] nis-2-directive.com · [20] digital-operational-resilience-act.com
Zwölf Werkzeuge im Vergleich.
DNS Security gibt es in drei Formen: als geschützten rekursiven Resolver in der Cloud, dem Standorte und Geräte ihre Anfragen schicken, als Sicherheitsfunktion im eigenen DNS- und DDI-System oder in der Firewall, die Anfragen im Netz prüft, und als Sperrlisten-Feed (Response Policy Zones), den die Organisation in ihren eigenen Resolver lädt. Die Cloud-Dienste ergänzen den Resolver mit einem Client, der Geräte auch unterwegs schützt, und werden zunehmend als Teil einer SSE-Plattform verkauft. In Europa betreibt Whalebone den EU-kofinanzierten Resolver DNS4EU, die gemeinnützige Quad9 hat ihren Sitz in Zürich, und SWITCH bietet Schweizer Hochschulen und Unternehmen einen DNS Firewall-Feed an. Unterschiede liegen vor allem in der Erkennung von DNS-Tunneling und DGA, in der Zuordnung zu Benutzer und Gerät und in der Frage, ob verschlüsseltes DNS (DoH, DoT) unterstützt oder geprüft wird.
Resolver: geschützter rekursiver Resolver · DoH/DoT: DoH/DoT · Threat Intel: Threat-Intel-Blocklisten · DGA/Tunneling: DGA- oder DNS-Tunneling-Erkennung · Unterwegs: Schutz ausserhalb des Firmennetzes · Reporting: Reporting pro Gerät/Benutzer · On-Prem: On-Prem. ● = auf offizieller Hersteller- oder Projektseite beschrieben, – = nicht belegt (nicht zwingend nicht vorhanden). Auswahl nicht abschliessend, keine Rangliste. Stand: Oktober 2026.
Cisco Umbrella DNS (Cisco Secure Access DNS Defense)
Cisco
DNS-Layer-Security über das globale Netz rekursiver Resolver von Cisco; das Angebot läuft heute auch unter dem Namen Cisco Secure Access DNS Defense.
Netze und Geräte schicken ihre DNS-Anfragen an die Umbrella-Resolver, die bei jeder Auflösung die Sicherheitsrichtlinie anwenden; DoH-Resolver verschlüsseln die Anfragen bis zum Dienst.
Schädliche Ziele sind in Sicherheitskategorien gruppiert und werden je Identität gesperrt; Bedrohungsdaten stammen von Cisco Talos.
Virtual Appliances leiten öffentliche Anfragen als DNS-Forwarder weiter und machen interne IP-Adressen und Active-Directory-Identitäten in den Berichten sichtbar.
Der Activity Search Report zeigt jede DNS-, URL- und IP-Anfrage je Identität; Roaming-Client oder Secure-Client-Modul schützen Geräte ausserhalb des Firmennetzes.
Schneller Grundschutz für Standorte und mobile Geräte, ausbaubar zu SWG und SSE.
Identitätsbezogene Berichte über DNS-, URL- und IP-Anfragen in einer Oberfläche.
Eine ausdrückliche Erkennung von DNS-Tunneling oder DGA ist in den geprüften Seiten nicht beschrieben; Virtual Appliances leiten nur weiter und lösen nicht selbst auf.
Cloudflare Gateway (DNS-Richtlinien)
Cloudflare
DNS-, HTTP- und Netzwerkfilter für Benutzer, Geräte und Standorte, als Teil von Cloudflare One.
Gateway baut auf dem Resolver 1.1.1.1 auf; Organisationen leiten ihren Resolver auf einen IPv6-, DoH- oder DoT-Endpunkt um oder beantragen eine eigene IPv4-Resolveradresse.
Blockiert Malware, Phishing, DNS-Tunneling und Command-and-Control-Verbindungen mit Modellen, die DNS- und HTTP-Telemetrie aus dem gesamten Netz nutzen.
Vordefinierte Kategorien für Richtlinien; zusammen mit DLP-Profilen wirkt Gateway auch als Forward Proxy.
Protokolle und Richtlinien beziehen Benutzer, Geräte-ID und Standort ein.
Schutz von Benutzern unterwegs und von Filialen über denselben Dienst.
DNS-Filter und SWG laufen im selben Dienst mit derselben Richtlinienlogik.
Einen Resolver im eigenen Netz sieht das Modell nicht vor; die Auflösung läuft über das Cloudflare-Netz.
DNSFilter
DNSFilter
Protective DNS, laut Hersteller an den Empfehlungen von NSA und CISA ausgerichtet, mit Kategorie- und Bedrohungsfiltern für Netze und Benutzer.
Auflösung über ein eigenes Anycast-Netz; Richtlinien greifen bei jeder Anfrage.
Machine-Learning-Modelle erkennen neue und Zero-Day-Bedrohungen; Milliarden Domains werden KI-gestützt kategorisiert.
Über 45 Integrationen, etwa ConnectWise, Splunk und Zapier; Anbindung an Active Directory.
Roaming Clients schützen Benutzer in jedem Netz; Insights Reporting zeigt den Zustand des Netzes im Dashboard.
Organisationen und Managed-Service-Provider, die DNS-Filter mit PSA-, SIEM- und Automatisierungswerkzeugen verbinden.
Breite Integration in PSA- und RMM-Werkzeuge von Service-Providern.
DoH/DoT, Erkennung von DNS-Tunneling und Auswertung je Benutzer oder Gerät sind auf der Funktionsseite nicht ausdrücklich beschrieben.
Akamai Secure Internet Access Enterprise
Akamai
Cloud-basierte DNS-Firewall, die DNS-Anfragen prüft, bevor eine Verbindung aufgebaut wird.
Rekursiver DNS-Resolver, der Anfragen an Nameserver weiterleitet und häufige Antworten zwischenspeichert.
Bedrohungsdaten aus der Akamai Connected Cloud, ergänzt um externe Feeds und etwa alle 60 Minuten aktualisiert; blockiert DNS-Exfiltration mit geringem Durchsatz in Echtzeit.
Anbindung über Änderung der DNS-Server-Adresse, eine DNS-Proxy-VM, IPsec-Tunnel, SD-WAN-Integration oder Clients.
Clients für Windows, macOS, iOS, Android und ChromeOS schützen Geräte im und ausserhalb des Netzes; Echtzeit-Analysen und Berichte zu Bedrohungs- und Nutzungsereignissen.
Organisationen, die DNS-Schutz ohne eigene Hardware schnell an vielen Standorten einführen.
Viele Anbindungswege von DNS-Änderung über Tunnel bis Client.
DoH/DoT und eine Auswertung je Benutzer oder Gerät sind auf der Produktseite nicht beschrieben.
Zscaler DNS Security (Teil der Zero Trust Firewall)
Zscaler
Filtert riskante und schädliche Domains als Teil der cloudbasierten Zero Trust Firewall über alle Ports und Protokolle.
Zscaler Trusted Resolvers laufen an über 150 Edge-Standorten nahe am Benutzer; ein DNS-Gateway kann auch an Resolver Dritter weiterleiten.
Inline-Schutz gegen DNS-Tunneling und Datenabfluss; erkennt Angriffe, die sich in DoH verstecken.
Unverschlüsselte DNS-Anfragen lassen sich in DoH übersetzen und an Protective-DNS-Resolver leiten.
Cloud-Dienst innerhalb der Zero Trust Exchange, gemeinsam mit den Web- und Firewall-Richtlinien.
Organisationen mit Zscaler-Plattform, die DNS-Schutz und DoH-Kontrolle in dieselbe Richtlinie aufnehmen.
Prüft auch DoH-Verkehr, der an klassischen Firewalls vorbeiläuft.
Als Teil der Zscaler-Plattform ausgelegt; ein eigenständiger Einsatz und Berichte je Gerät sind auf der Seite nicht beschrieben.
Infoblox Threat Defense
Infoblox
Protective DNS für Geräte im Firmennetz, unterwegs sowie im IoT- und OT-Umfeld, ohne Agent auf dem Gerät.
Als DNS-Resolver sieht Infoblox jede Anfrage jedes Geräts; verdächtige Domains werden vorausschauend gesperrt, bevor sie in Kampagnen genutzt werden.
Verhaltensbasierte Erkennung von DNS-Tunneling, Datenabfluss und DGA sowie Schutz der DNS-Infrastruktur.
Automatisiert Bedrohungsdaten im eigenen Sicherheits-Ökosystem und nutzt Kontext aus DNS, DHCP und IPAM (DDI).
Ordnet Anfragen ohne Client oder Sinkhole Benutzer, Gerät, Quell-IP, Standort, MAC-Adresse und VLAN zu; unternehmensweites Query-Logging.
Organisationen mit Infoblox-DDI, die DNS-Schutz an ihr bestehendes DNS koppeln.
Zuordnung jeder Anfrage zu Gerät und Netzsegment aus DDI-Daten, ohne Agent.
DoH/DoT und die genaue Aufteilung zwischen Cloud und On-Premises-DNS beschreibt die Produktseite nicht.
EfficientIP DNS Guardian
EfficientIP
Eingebaute Sicherheit für Cache-, rekursive und autoritative DNS-Server.
DNS Transaction Inspection analysiert Anfragen, Antworten, Fragmente und Rekursionen direkt im Resolver, statt nur bekannte Muster zu vergleichen.
Erkennt DNS-Tunneling, DGA, Zero-Day-Domains und Datenabfluss; adaptive Gegenmassnahmen stellen verdächtige IP-Adressen unter Quarantäne und schützen den Cache.
Anbindung an SOAR, SIEM und NAC über APIs oder Sicherheitsereignisse; ergänzbar mit DNS-Threat-Intelligence-Feeds.
User Behavioral Analysis und Client Query Filtering werten Anfragen je Client aus; Statistiken und Logging ohne zusätzliche Appliances.
Organisationen und Provider, die DNS-Sicherheit im eigenen DNS-Betrieb und unter eigener Kontrolle führen.
Sicherheit sitzt im eigenen Resolver, nahe an den internen Clients.
Schutz für Geräte ausserhalb des Firmennetzes und DoH/DoT sind auf den geprüften Seiten nicht beschrieben.
Advanced DNS Security
Palo Alto Networks
DNS-Schutz als Abonnement der Firewall der nächsten Generation oder von Prisma Access, ergänzt um einen eigenen Advanced-DNS-Security-Resolver.
Wirkt direkt in der Firewall, ohne Änderung der DNS-Weiterleitung im Netz.
Echtzeitanalyse von Abfragemustern mit Machine Learning gegen Datenabfluss und Command-and-Control über DNS; Analyse der DNS-Antworten gegen DNS-Hijacking.
Automatische Erkennung und Überwachung der eigenen öffentlich erreichbaren Domains.
Bedrohungsdaten werden aus der Kundenbasis zusammengeführt (crowd-sourced).
Organisationen mit Palo-Alto-Firewalls, die DNS-Schutz ohne Umbau der DNS-Architektur ergänzen.
Schutz gegen Tunneling und Hijacking direkt in der bestehenden Firewall.
Setzt Palo-Alto-Firewalls oder Prisma Access voraus; Berichte je Benutzer und DoH-Prüfung sind auf der Seite nicht beschrieben.
FortiGuard DNS Security (DNS Filtering Service)
Fortinet
DNS-Filterdienst für die Fortinet Security Fabric mit Schutz vor Spoofing und Cache Poisoning.
Die DNS-Inspektion auf der FortiGate prüft auch DNS over TLS (DoT) und DNS over HTTPS (DoH).
Weist Anfragen von Staging-Domains über jeden Port und jedes Protokoll ab und hebt ungewöhnliches DNS-Verhalten hervor, um kompromittierte Systeme zu erkennen.
In mehrere Fabric-Lösungen integriert, mit koordinierten Abläufen bis zur Reaktion.
Bedrohungsdaten von FortiGuard Labs aus der weltweiten Installationsbasis.
Fortinet-Umgebungen, die DNS-Schutz als Lizenz an bestehenden FortiGates aktivieren.
DNS-Schutz und DoH/DoT-Inspektion ohne zusätzliche Komponente auf der Firewall.
Ein eigener geschützter Resolver, Roaming-Schutz und Berichte je Benutzer sind auf der Seite nicht beschrieben.
Whalebone Immunity (Betreiber von DNS4EU)
Whalebone
Protective DNS Resolver für Organisationen; Whalebone betreibt zudem den EU-kofinanzierten Resolver DNS4EU.
Speichert und analysiert den DNS-Verkehr und sperrt Domains auch anhand von Abfragefolgen, die eine Einzelprüfung übersieht.
Lokale und regionale Bedrohungsdaten, unter anderem von öffentlichen Stellen und Telekomanbietern aus dem DNS4EU-Umfeld; DNS-Tunneling und DGA werden laut Hersteller über die Analyse von Abfragefolgen und KI erkannt.
Integration mit Active Directory; Konfiguration und Datenabruf vollständig per API, etwa für ein SIEM.
Betrieb vor Ort, in der Cloud oder hybrid; Einblick bis auf einzelne Geräte; Verschlüsselung über DoH und DoT; die App Home Office Security schützt Benutzer in fremden Netzen.
Öffentliche Verwaltungen, Unternehmen und Telekomanbieter in Europa, die DNS-Schutz mit europäischer Infrastruktur wollen.
Wahl zwischen Betrieb vor Ort, Cloud und Hybrid mit europäischen Bedrohungsdaten.
Die Zuordnung bis auf einzelne Geräte setzt laut Seite eine On-Premises- oder Hybrid-Bereitstellung voraus; Prüftiefe und Logformate sind im Pilot zu klären.
Quad9
Quad9 (gemeinnützig, Sitz Zürich)
Offener rekursiver DNS-Dienst mit Sicherheitsfunktionen; DNSSEC-Validierung auf allen Resolver-Adressen.
Unterschiedliche Dienstvarianten über verschiedene IP-Adressen; DNS over HTTPS und DNS over TLS auf Port 853.
Sperrliste aus rund zwanzig kommerziellen und öffentlichen Threat-Intelligence-Quellen; Quad9 verteilt die Daten der Partner und erzeugt keine eigenen Indikatoren.
Partner erhalten nahezu in Echtzeit Rückmeldung, wie oft ihre Einträge gesehen werden.
IP-Adressen der Clients werden nicht gespeichert, nur die ungefähre Herkunft (Stadt, Region, Land); Adresse c/o SWITCH in Zürich.
Datensparsamer Grundschutz ohne Vertrag und Verwaltung, etwa für kleine Umgebungen oder als vorgegebener Resolver für Geräte.
Datensparsamer Dienst mit Sitz in der Schweiz und Sperrliste aus vielen Quellen.
Ohne Richtlinienverwaltung, Ausnahmen und Berichte je Gerät; für Unternehmensanforderungen an Kontrolle, Logging und Vertrag nur bedingt geeignet.
SWITCH DNS Firewall
SWITCH (Stiftung)
Liste schädlicher oder infizierter Domains, die SWITCH an das DNS-System der Kundenorganisation liefert.
Der eigene Resolver muss Response Policy Zones (RPZ) unterstützen und abonniert die gewünschten RPZ-Feeds; der Feed ist nicht an einen DNS-Hersteller gebunden.
Bedrohungsdaten aus der Überwachung von Hochschulnetzen und weiteren Sektoren in der Schweiz, ergänzt um internationale Partner; betrieben vom SWITCH-CERT.
Funktioniert mit allen gängigen DNS-Appliances und -Servern mit RPZ-Unterstützung.
Sicherheitsberichte auf Basis der RPZ-Logdaten, die die Organisation an SWITCH sendet, melden Zugriffsversuche infizierter Systeme.
Hochschulen, Forschung und weitere Organisationen in der Schweiz mit eigenem Resolver.
Schweizer Bedrohungsdaten, durchgesetzt im eigenen, herstellerunabhängigen Resolver.
Die Organisation betreibt Resolver und Durchsetzung selbst; Schutz unterwegs und Berichte je Gerät gehören nicht zum Dienst.
Weitere Anbieter
Kurz eingeordnet, ausserhalb der Vergleichsmatrix.
- BlueCat Edge: DNS-Steuerung und DNS-Sicherheit für Unternehmensnetze von BlueCat
- DNS4EU (öffentlicher Resolver): EU-kofinanzierter, von Whalebone betriebener Resolver für Bürgerinnen und Bürger; unter Whalebone Immunity mitbeschrieben
- ISC BIND 9, Unbound, PowerDNS Recursor mit Response Policy Zones: Open-Source-Resolver, die RPZ-Feeds durchsetzen; Baustein ohne eigene Bedrohungsdaten und Benutzerauswertung
- Microsoft Zero Trust DNS (Windows): Ansatz, Windows-Clients nur noch über autorisierte Resolver auflösen zu lassen
- Check Point DNS Security, Barracuda Content Shield: weitere DNS-Filter in Firewall- und Web-Portfolios
Mit einer kontrollierten Domain.
Der Pilot verbindet eine Testdomain, einen bekannten schädlichen Indikator und eine legitime Ausnahme. Die Organisation muss danach erkennen können, welcher Client welchen Resolver genutzt hat, wer die Ausnahme verantwortet und wie eine blockierte Verbindung weiter untersucht wird.
- Resolver- und Client-Abdeckung nach Standort prüfen
- Umgehung über externe oder verschlüsselte Resolver testen
- Legitime Ausnahme zeitlich befristen und nachvollziehen
- DNS-Event im SOC bis zu einer verifizierten Entscheidung verfolgen
Security Tool Navigator · Gebiet 05
Im Gebiet Network Security einordnen.
Diese Werkzeugklasse gehört zum Gebiet Network Security. Der Gebietshub zeigt, wie die Werkzeugklassen zusammenwirken, wo sie sich abgrenzen und welche Fragen CIO und CISO jeweils klären.