Praxiswissen für Schweizer KMU

Was ein passiver Domain-Risikocheck wirklich sieht

Öffentliche Registrierungs-, DNS- und Webdaten liefern nützliche Frühindikatoren für Domainlaufzeit, Erreichbarkeit, E-Mail-Schutz und Zertifikatsregeln. Sie zeigen aber nur einen klar begrenzten Ausschnitt der tatsächlichen IT-Sicherheit.

Die klare Grenze

Ein passiver Check liest ausschliesslich öffentlich erreichbare Registrierungs-, DNS-, Zertifikats- und Websignale. Er meldet Konfigurationszustände und Veränderungen, dringt aber nicht in Systeme ein und beweist weder eine Schwachstelle noch vollständige Sicherheit.

Warum öffentliche Signale trotzdem nützlich sind

Domains verbinden Website, E-Mail und Zertifikate mit den öffentlich erreichbaren Diensten eines Unternehmens. Fehlende, doppelte oder unerwartet veränderte DNS-Einträge können deshalb ein sinnvoller Anlass für eine gezielte Prüfung sein.

Das BACS weist darauf hin, dass KMU bei Cyberrisiken oft Zeit, Ressourcen oder Orientierung fehlen. Ein begrenzter Vorcheck kann hier Prioritäten schaffen – er ersetzt aber keinen umfassenden Grundschutz.

Diese öffentlichen Signalgruppen prüft MUITEM passiv

RDAPOb Ablaufdatum, Registrierungsstatus, Registrar, öffentliche Transfersperre und Registry-Nameserver bestätigt werden können.
A und AAAAOb öffentliche IPv4- oder IPv6-Adressen veröffentlicht sind.
MXOb und wohin eingehende E-Mail geroutet wird.
SPFOb eine veröffentlichte Sender-Autorisierung vorhanden und grundsätzlich auswertbar ist.
DMARCOb eine Richtlinie vorhanden ist und ob sie beobachtet, quarantänisiert oder ablehnt.
DNSSECOb die geprüfte DNS-Antwort vom Resolver als kryptografisch authentifiziert markiert wurde.
CAAOb die Domain zulässige Zertifizierungsstellen einschränkt.
HTTPS und WebrichtlinienOb Weiterleitung, HSTS, CSP, Basisschutzheader und security.txt öffentlich erkennbar sind.
ZertifikatsprotokolleWelche zur Domain gehörenden Namen in öffentlichen Certificate-Transparency-Daten erscheinen.

Die Bewertung basiert auf einer Momentaufnahme. DNS-Caches, laufende Änderungen und bewusst nicht genutzte Dienste müssen im Kontext interpretiert werden.

Was dieser Check ausdrücklich nicht tut

  • keine Port- oder Schwachstellen-Scans
  • keine Login-Versuche und keine Passworttests
  • kein Zugriff auf interne Netze, Geräte oder Cloud-Konten
  • keine Aussage darüber, ob Backups funktionieren oder Mitarbeitende Phishing erkennen
  • keine Garantie, dass keine weiteren Risiken bestehen

Vom Signal zur sinnvollen Massnahme

  1. Signal verifizieren.Prüfen, ob der gefundene Zustand beabsichtigt, aktuell und zum eingesetzten Anbieter passend ist.
  2. Auswirkung einordnen.Erreichbarkeit, E-Mail-Missbrauch und Zertifikatskontrolle getrennt bewerten.
  3. Verantwortung zuweisen.Festlegen, wer DNS, Mailanbieter und Zertifikate ändern darf.
  4. Änderung kontrollieren.Konfiguration dokumentieren, testen und nach der DNS-Verbreitung erneut prüfen.
  5. Vorbereitung ergänzen.Technische Signale mit Notfallkontakten, Backups und einem getesteten Reaktionsplan verbinden.

Das BACS-Notfallkonzept ordnet Vorbereitung, Vorfallsbewältigung und Nachbearbeitung als zusammenhängenden Prozess ein. Öffentliche Domain-Signale sind darin nur ein früher Informationsbaustein.

Wann Monitoring mehr Wert hat als ein Einzelcheck

Ein Einzelcheck beantwortet: «Wie sieht die öffentliche Konfiguration jetzt aus?» Monitoring beantwortet zusätzlich: «Was hat sich seit dem letzten bekannten Zustand verändert?» Das ist besonders nützlich nach Anbieterwechseln, DNS-Migrationen oder Änderungen am Mailversand.

Auch Monitoring bleibt begrenzt: Es erkennt nur die beobachteten öffentlichen Signale und muss wichtige Abweichungen zur Prüfung vorlegen, statt automatisch weitreichende Änderungen vorzunehmen.

Nachprüfbar

Quellen und Standards

  1. BACS – KMU im Fokus ↗

    Das Bundesamt für Cybersicherheit beschreibt Phishing, Ransomware und Social Engineering als relevante Themen für KMU und betont wirksamen Grundschutz.

  2. BACS – Notfallkonzept für Cyberresilienz ↗

    Behördenleitfaden zur Vorbereitung, Bewältigung und Nachbearbeitung von Cybervorfällen in Organisationen und KMU.

  3. RFC 7208 – SPF ↗

    Technischer Standard für veröffentlichte Sender-Autorisierungen im DNS.

  4. RFC 8659 – CAA ↗

    Technischer Standard, mit dem Domains zulässige Zertifizierungsstellen im DNS angeben können.

  5. IANA – RDAP-Bootstrap für Domains ↗

    Offizielles Verzeichnis der zuständigen RDAP-Dienste für Domainendungen.

  6. RFC 9083 – RDAP-Registrierungsdaten ↗

    Aktueller Standard für maschinenlesbare Domain-Statuswerte und Registrierungsereignisse wie Ablaufdaten.

  7. ICANN – EPP-Statuswerte ↗

    Offizielle Erläuterung zu Transfer-, Halte-, Lösch- und Erneuerungsstatuswerten.

Weiterlesen

Alle Leitfäden

Nächster Schritt

Öffentliche Domain-Signale verständlich priorisieren.

Prüfen Sie Ihre eigene Domain und erfahren Sie, welche Empfehlungen für Ihr Unternehmen relevant sind.

Kostenlosen Vorcheck starten ↗