Ransomware, Cloud-Fehlkonfigurationen, Bot-Traffic, Webanwendungsangriffe, Phishing, KI-Risiken und vernetzte Medizingeräte — die Bedrohungslage im Gesundheitswesen hat sich seit der Pandemie grundlegend verändert. 

CSO Online hat die sieben größten Sicherheitsbedrohungen für den Gesundheitssektor zusammengestellt — auf Basis aktueller Studien und Experteneinschätzungen. Wir ordnen ein, was davon für deutsche Kliniken, Praxen und Gesundheitsdienstleister relevant ist.

1. Ransomware: Die existenzielle Bedrohung

Ransomware ist die größte Einzelbedrohung für das Gesundheitswesen. Angreifer haben erkannt, dass Organisationen, die lebensrettende Behandlungen durchführen, erpressbarer sind als Opfer in fast jeder anderen Branche.

Die Zahlen belegen das: Zwischen 2022 und 2023 stieg die Zahl der Ransomware-Opfer im Gesundheitswesen um 81 Prozent (laut US Office of the Director of National Intelligence). 2025 kamen weitere 30 Prozent hinzu — mit einer Verschiebung: Nicht mehr nur Kliniken und Krankenhäuser, sondern zunehmend auch Zulieferer, Softwareanbieter und Abrechnungsdienstleister werden zum Ziel.

Der Change-Healthcare-Angriff im Februar 2024 bleibt das Paradebeispiel: Die Ransomware-Attacke legte die Versicherungsabrechnung, Rezeptausgabe und Finanztransaktionen für Krankenhäuser, Kliniken und Apotheken in den gesamten USA lahm. Im Juni 2024 traf ein Qilin-Angriff auf den NHS-Pathologiedienstleister Synnovis Teile Londons — Bluttests, Diagnostik und Laborleistungen fielen aus, geplante Eingriffe mussten verschoben werden.

Im März 2026 traf es den Medizintechnikhersteller Stryker: Ein Cyberangriff — zunächst als Ransomware vermutet, später der iranischen Gruppe Handala zugeordnet — löschte geschätzt 200.000 Geräte im Rahmen einer breiteren Kampagne gegen US-amerikanische und israelische Ziele.

Besonders kritisch: Wenn elektronische Patientenakten (EPA) durch Ransomware unzugänglich werden, fehlen Behandlungsinformationen, Medikamentendosierungen und Patientenhistorien. Im schlimmsten Fall müssen Patienten in andere Einrichtungen umgeleitet werden.

2. Cloud-Schwachstellen und Fehlkonfigurationen

Die Digitalisierung hat Gesundheitsdaten in die Cloud gebracht — oft über mehrere Anbieter mit unterschiedlichen Sicherheitsstandards. 61 Prozent der Gesundheitsunternehmen gaben in einer Studie von KMS Healthcare an, in den letzten zwölf Monaten einen Cloud-basierten Cyberangriff erlebt zu haben.

Fehlkonfigurationen sind mindestens ebenso gefährlich: Der US-Krankenversicherer Blue Shield of California exponierte drei Jahre lang Mitgliedsdaten — einschließlich geschützter Gesundheitsinformationen — an Googles Werbeplattform, weil Google Analytics falsch konfiguriert war. Im März 2026 erlitt der US-Softwareanbieter CareCloud einen Breach seiner EHR-Umgebung, der 45.000 Anbieter betraf.

3. Webanwendungsangriffe

Angriffe auf Webanwendungen im Gesundheitswesen haben stark zugenommen: Cross-Site Scripting (XSS), SQL-Injection, Protokollmanipulation und Remote Code Execution gehören zu den häufigsten Vektoren. Für unterfinanzierte IT-Abteilungen in Kliniken und Praxen sind diese Angriffe technisch besonders schwer zu managen — insbesondere wenn Drittanbieter-Anwendungen und APIs die Angriffsfläche erweitern.

4. Bot-Traffic

Schadhafter Bot-Traffic macht laut dem Imperva Bad Bot Report 2025 inzwischen 37 Prozent des gesamten Internetverkehrs aus. Das Gesundheitswesen gehört zusammen mit dem Finanzsektor zu den am stärksten betroffenen Branchen. Credential-Stuffing-Angriffe gegen Patientenportale und das automatisierte Abschöpfen sensibler Gesundheitsinformationen sind reale Szenarien. KI verstärkt das Problem: Fortgeschrittene Bots zielen zunehmend auf APIs statt auf Webanwendungen.

5. Phishing

Phishing bleibt der häufigste initiale Angriffsvektor im Gesundheitswesen. Das US Department of Health and Human Services dokumentiert, dass 18 Prozent aller gemeldeten Verstöße gegen geschützte Gesundheitsinformationen zwischen 2009 und 2021 auf Phishing oder kompromittierte E-Mail-Konten zurückgingen. Eine Studie im British Medical Journal ergab, dass rund 3 Prozent aller E-Mails an Krankenhauspersonal als verdächtig eingestuft wurden — Dutzende potenzielle Angriffsvektoren pro Tag.

6. Vernetzte Medizingeräte

Wearables, Implantate und vernetzte Medizintechnik eröffnen neue Angriffsflächen. Die Sicherheitsfirma Pen Test Partners fand, dass sie die Daten eines Insulinpumpen-Trials im öffentlichen Internet manipulieren konnten — theoretisch hätte ein Angreifer tödliche Insulindosen an rund 3.000 Studienteilnehmer verabreichen können. Die US-amerikanische FDA hat mit FD&C 524b (2023) Cybersicherheitsanforderungen für vernetzte Medizingeräte eingeführt. In Europa adressiert der Cyber Resilience Act (CRA) diese Geräteklasse zunehmend.

7. Generative KI

Laut einer Studie von Netskope (2026) entfallen 89 Prozent aller Verstöße gegen Datenrichtlinien im Kontext von KI-Nutzung auf regulierte Daten wie Patientenakten — deutlich über dem branchenübergreifenden Durchschnitt von 31 Prozent. Der Anteil der Gesundheitsmitarbeiter, die organisationsverwaltete KI-Tools nutzen, sprang 2025 von 18 auf 67 Prozent. Die Sicherheitskontrollen halten nicht Schritt: Das klinische KI-Tool Doctronic konnte laut Mindgard kompromittiert werden, um Verschreibungsempfehlungen zu manipulieren.

Was das für deutsche Gesundheitseinrichtungen bedeutet

NIS-2 und KRITIS: Krankenhäuser über der KRITIS-Schwelle müssen bereits Systeme zur Angriffserkennung (SzA) betreiben. NIS-2 erweitert den Kreis der betroffenen Einrichtungen erheblich. Wer Ransomware-Angriffe nicht innerhalb von 24 Stunden meldet, verstößt gegen geltendes Recht.

Telematikinfrastruktur (TI): Die TI verbindet Arztpraxen, Apotheken und Krankenhäuser — und schafft eine Angriffsfläche, die über die einzelne Einrichtung hinausgeht. Jede kompromittierte Praxis kann zum Einstiegspunkt für laterale Bewegung innerhalb der TI werden.

Unterfinanzierung der IT-Sicherheit: Viele Praxen und kleinere Kliniken verfügen nicht über dediziertes IT-Sicherheitspersonal. Die Verantwortung liegt beim Praxisinhaber oder einem IT-Dienstleister, der neben der Sicherheit auch den laufenden Betrieb stemmen muss.

Patientendaten sind Sonderkategorie-Daten: Nach Art. 9 DSGVO sind Gesundheitsdaten besonders schützenswert. Ein Breach zieht nicht nur technische, sondern auch regulatorische Konsequenzen nach sich — Bußgelder und Reputationsschäden können existenzbedrohend sein.

Digitalisierung ohne Sicherheitsbudget: Die Einführung der elektronischen Patientenakte (ePA), von Telemedizin und KI-gestützten Diagnosetools erhöht die Angriffsfläche — oft ohne dass die Sicherheitsarchitektur proportional mitwächst.

Fazit

Das Gesundheitswesen ist nicht einfach „auch betroffen” von Cyberkriminalität. Es ist ein bevorzugtes Ziel — weil die Daten wertvoll sind, die Erpressbarkeit hoch ist und die Verteidigung strukturell unterfinanziert ist. Die sieben Bedrohungen sind keine abstrakten Risiken. Sie sind das, was in der nächsten Klinik, der nächsten Praxis, dem nächsten Gesundheitsdienstleister passieren kann — und bereits passiert.

Eine Milliarde Datensätze. 10.000 Organisationen. Vier Jahre. Und ein Ergebnis, das die Grundannahme der gesamten Branche infrage stellt: Schneller patchen funktioniert nicht mehr. Nicht weil die Teams zu langsam wären. Sondern weil das Modell selbst an eine physikalische Grenze gestoßen ist.

Die Qualys Threat Research Unit (TRU) hat die bislang umfassendste Langzeitanalyse zum Schwachstellenmanagement veröffentlicht: „The Broken Physics of Remediation“. Die Datenbasis — über eine Milliarde Remediation-Datensätze aus dem CISA KEV-Katalog (Known Exploited Vulnerabilities) — zeigt in ernüchternder Klarheit, dass das Wettrennen zwischen Angreifern und Verteidigern bereits entschieden ist. Und zwar nicht zugunsten der Verteidiger.

Die Kernzahlen

Zwischen 2022 und 2025 stieg das Volumen geschlossener Schwachstellen-Events von 73 Millionen auf 473 Millionen — ein Anstieg um 650 Prozent. Organisationen arbeiten also deutlich mehr als noch vor vier Jahren. Trotzdem verschlechtert sich die Lage: Der Anteil kritischer Schwachstellen, die sieben Tage nach Disclosure noch offen sind, stieg im selben Zeitraum von 56 auf 63 Prozent.

Mehr Arbeit, schlechtere Ergebnisse. Qualys nennt das die „human ceiling“ — eine strukturelle Obergrenze, die durch keinen realistischen Zuwachs an Personal, Prozessreife oder Management-Druck durchbrochen werden kann.

Die vielleicht alarmierendste Zahl: Laut Google M-Trends 2026 liegt die durchschnittliche Time-to-Exploit bei minus sieben Tagen. Das bedeutet: Angreifer nutzen die schwerwiegendsten Schwachstellen im Durchschnitt eine Woche aus, bevor ein Patch überhaupt existiert. Das klassische Modell „Patch schneller als der Angreifer exploitet“ ist damit nicht nur schwierig umzusetzen — es ist mathematisch unmöglich.

88 Prozent: Die Verteidiger verlieren das Wettrennen

Qualys hat 52 aktiv ausgenutzte Schwachstellen im Detail analysiert. Das Ergebnis: 88 Prozent der Schwachstellen im Datensatz wurden langsamer gepatcht, als sie ausgenutzt wurden. Bei der Hälfte begann die Ausnutzung vor der öffentlichen Bekanntgabe.

Zum Zeitpunkt der Disclosure waren 85 Prozent der verwundbaren Assets ungepatcht. Nach 21 Tagen waren es noch 33 Prozent. Nach 90 Tagen noch 12 Prozent. Jedes dieser ungepatchten Assets ist ein offenes Fenster für Angreifer — und bei Schwachstellen, die bereits aktiv ausgenutzt werden, kein theoretisches Risiko, sondern ein reales.

Manuelle Prozesse verschlimmern das Problem: Die durchschnittliche Schließungszeit bei manueller Remediation liegt vier- bis fünfmal über dem Median. Die Organisationen, die am längsten brauchen, sind nicht die mit den wenigsten Ressourcen — sondern die mit den meisten manuellen Schritten im Prozess.

Neue Metriken für eine neue Realität

Ein wesentlicher Beitrag der Studie sind zwei neue Metriken, die die Schwächen bisheriger Kennzahlen adressieren:

Average Window of Exposure (AWE): Misst die tatsächliche Zeitspanne von der ersten Exploitation bis zur vollständigen Remediation — nicht ab Disclosure, nicht ab Patch-Verfügbarkeit, sondern ab dem Moment, in dem die Schwachstelle in freier Wildbahn ausgenutzt wird. AWE bildet die reale Gefährdungsdauer für die Mehrheit der Organisationen ab: rund 21 Tage.

Risk Mass: Erfasst die kumulative Exposition einer Organisation, solange eine Schwachstelle offen bleibt. Berechnung: Anzahl verwundbarer Assets multipliziert mit der Anzahl der Tage, die jedes Asset exponiert bleibt. Risk Mass macht sichtbar, was CVSS-Scores und MTTR-Metriken verbergen: dass eine „mittelschwere“ Schwachstelle auf 10.000 Servern über 30 Tage ein größeres Gesamtrisiko darstellen kann als eine kritische Schwachstelle auf drei Systemen, die in zwei Tagen gepatcht wird.

Die Implikation: Das reaktive Modell ist am Ende

Die Qualys-Studie argumentiert nicht für schnelleres Patchen. Sie argumentiert dafür, dass das gesamte Betriebsmodell — Scan, priorisiere, erstelle Ticket, patche, verifiziere, schließe Ticket — an einer mathematischen Grenze angekommen ist, die durch Optimierung nicht überwunden werden kann.

Die Analogie im Report-Titel ist bewusst gewählt: Die „Physik“ der Remediation ist „gebrochen“. Die Geschwindigkeit der Angreifer übersteigt die Reaktionsfähigkeit menschengestützter Prozesse — und der Abstand wird größer, nicht kleiner. Mit Anthropics Mythos Preview, das tausende Zero-Days autonom findet, wird dieses Ungleichgewicht in den kommenden Monaten noch dramatischer werden.

Qualys schlägt stattdessen ein Risk Operations Center (ROC) vor — eine Architektur, die drei Elemente in einem operativen Kreislauf verbindet: eingebettete Intelligenz zur Risikopriorisierung, deterministische Bestätigung der tatsächlichen Ausnutzbarkeit (nicht nur des theoretischen Schweregrads) und autonome Remediation, die ohne menschliche Intervention an jedem Schritt skaliert.

Was das für Unternehmen konkret bedeutet

MTTR als alleinige Metrik ist unzureichend. Wer seine Patch-Performance nur an der Mean Time to Remediate misst, übersieht das eigentliche Risiko. AWE und Risk Mass liefern ein realistischeres Bild — weil sie messen, was den Angreifer interessiert: Wie lange war das Fenster offen, und wie viele Assets waren dahinter?

Automatisierung ist keine Option, sondern Voraussetzung. Die Daten zeigen eindeutig: Manuelle Prozesse sind der stärkste Verzögerungsfaktor. Jede Organisation, die Schwachstellenmanagement noch über manuelle Ticketsysteme und geplante Wartungsfenster abwickelt, operiert in einem Modell, das die Daten als gescheitert ausweisen.

Priorisierung muss exploitability-basiert sein, nicht severity-basiert. Ein CVSS-Score von 9.8 auf einem System, das hinter drei Firewalls steht und nicht aus dem Internet erreichbar ist, hat eine andere Dringlichkeit als ein CVSS 7.5 auf einem exponierten Webserver, für den ein funktionierender Exploit existiert. Qualys nennt das „deterministic confirmation of actual exploitability“ — die Prüfung, ob eine Schwachstelle in der spezifischen Umgebung tatsächlich ausnutzbar ist, nicht nur theoretisch ausnutzbar sein könnte.

Patch-Zyklen müssen dem Risiko folgen, nicht dem Kalender. Monatliche Patch-Zyklen waren für eine Welt konzipiert, in der Time-to-Exploit bei Wochen oder Monaten lag. Bei einer Time-to-Exploit von minus sieben Tagen ist ein monatlicher Zyklus strukturell nicht mehr verteidigungsfähig.

NIS-2 verlangt genau das, was die Daten zeigen. Die Richtlinie fordert technische Maßnahmen zur Angriffserkennung und ein Risikomanagement, das der tatsächlichen Bedrohungslage entspricht. Wer sich auf manuelle Patch-Prozesse mit monatlichen Zyklen beruft, wird es schwer haben, die Angemessenheit dieser Maßnahmen vor einer Behörde zu begründen — insbesondere, wenn die Qualys-Daten zeigen, dass dieses Modell nachweislich nicht funktioniert.

Einordnung

Die Qualys-Studie ist kein Alarmismus und kein Produktmarketing (auch wenn Qualys natürlich Lösungen verkauft). Sie ist eine datengetriebene Analyse, die eine unbequeme Wahrheit belegt: Das operative Modell, auf dem die Mehrheit aller Sicherheitsprogramme aufgebaut ist, funktioniert nicht mehr. Nicht weil die Teams schlecht sind. Sondern weil die Mathematik nicht mehr aufgeht.

Die Konsequenz ist nicht, aufzugeben. Die Konsequenz ist, das Modell zu ändern. Weg von „Scan, priorisiere, patche manuell“ hin zu automatisierter, risikobasierter, kontinuierlicher Remediation. Wer das nicht tut, fällt nicht langsam zurück — er fällt exponentiell zurück, weil das Volumen schneller wächst als jede manuelle Kapazität.

Open Source Intelligence (OSINT) und Digital Forensics werden traditionell als getrennte Disziplinen betrachtet. OSINT sammelt öffentlich verfügbare Informationen, DFIR analysiert digitale Beweise auf kompromittierten Systemen. In der Praxis sind sie komplementäre Werkzeuge im selben Ermittlungsprozess — und die Integration beider beschleunigt Incident Response erheblich.

Was OSINT für DFIR leisten kann

Bei einem Sicherheitsvorfall stehen forensische Analysten vor einer grundlegenden Frage: Was wissen wir über den Angreifer, bevor wir sein Werkzeug analysieren? OSINT liefert Antworten, noch bevor die erste Festplatte gesichert ist:

• Threat Actor Attribution: IOCs (IP-Adressen, Domains, Hashes) gegen öffentliche Threat-Intelligence-Datenbanken abgleichen — VirusTotal, AlienVault OTX, Shodan, Censys. Wurde diese IP in früheren Angriffen gesehen? Welche Gruppe nutzt dieses Tool?
• Infrastruktur-Mapping: Angreifer-Domains über DNS-Historie, WHOIS-Daten, SSL-Zertifikate und Passive-DNS-Daten kartieren. Welche weiteren Domains hängen an derselben Infrastruktur?
• Leak-Monitoring: Wurden Credentials des betroffenen Unternehmens in Datenlecks veröffentlicht? Paste-Sites, Dark-Web-Foren und Telegram-Kanäle liefern Hinweise auf den Angriffsvektor
• Social-Engineering-Kontext: Welche Informationen über das Unternehmen und seine Mitarbeiter sind öffentlich verfügbar? LinkedIn-Profile, Organigramme, Stellenanzeigen — alles Material für Spear-Phishing-Rekonstruktion

Der Intelligence Cycle in der Incident Response

Die Integration von OSINT in DFIR folgt dem klassischen Intelligence Cycle — angepasst auf Incident Response:

1. Direction: Was müssen wir wissen? Wer greift uns an? Welchen Vektor nutzt er? Welche Systeme sind betroffen?
2. Collection: OSINT-Quellen systematisch abfragen — Threat-Intelligence-Feeds, DNS-Daten, Leak-Datenbanken, Social Media. Parallel: Forensische Datensammlung auf betroffenen Systemen
3. Processing: Rohdaten aufbereiten — IOCs extrahieren, Timelines erstellen, Verbindungen zwischen OSINT-Erkenntnissen und forensischen Artefakten herstellen
4. Analysis: Die zentrale Phase: OSINT-Kontext mit forensischen Beweisen korrelieren. Wenn die forensische Analyse eine C2-Domain identifiziert und OSINT zeigt, dass dieselbe Domain in einer APT28-Kampagne genutzt wurde — dann ändert sich die Einschätzung des Vorfalls fundamental
5. Dissemination: Ergebnisse aufbereiten — für das Management (Geschäftsrisiko), für das technische Team (IOCs, Mitigationsmaßnahmen), für Behörden (Meldepflichten)

Praktische OSINT-Werkzeuge für DFIR

Infrastruktur-Analyse

• Shodan / Censys: Exponierte Dienste, Zertifikate und Banner des eigenen Unternehmens und der Angreifer-Infrastruktur identifizieren
• SecurityTrails / PassiveTotal: DNS-Historie und Domain-Verbindungen kartieren
• crt.sh: Certificate Transparency Logs durchsuchen — unautorisiert ausgestellte Zertifikate erkennen

Threat Intelligence

• VirusTotal: Hashes, Domains und IPs gegen eine der größten Malware-Datenbanken prüfen
• AlienVault OTX / MISP: Community-getriebene Threat-Intelligence-Plattformen mit IOC-Sharing
• Abuse.ch (URLhaus, MalwareBazaar): Aktuelle Malware-Samples und C2-Infrastruktur

Leak-Monitoring

• Have I Been Pwned: Kompromittierte E-Mail-Adressen und Passwörter identifizieren
• Intelligence X: Historische Leak-Daten, Paste-Sites und Dark-Web-Inhalte durchsuchen

OSINT als Beschleuniger der forensischen Analyse

Die größte Wirkung entfaltet OSINT, wenn es die forensische Analyse fokussiert. Statt blind alle Systeme zu analysieren, zeigt OSINT, wo man suchen muss:

• Vor der Forensik: OSINT identifiziert den wahrscheinlichen Angriffsvektor. Wenn Leak-Monitoring zeigt, dass Credentials eines VPN-Accounts im Dark Web aufgetaucht sind, beginnt die forensische Analyse am VPN-Gateway — nicht am E-Mail-Server
• Während der Forensik: IOCs aus der forensischen Analyse werden sofort gegen OSINT-Quellen geprüft. Eine unbekannte Domain im DNS-Log wird zur bekannten C2-Infrastruktur — oder zum harmlosen CDN
• Nach der Forensik: OSINT überwacht, ob exfiltrierte Daten im Dark Web auftauchen. Leak-Monitoring nach einem Vorfall ist keine Option, sondern Pflicht

Grenzen und ethische Aspekte

OSINT nutzt öffentlich verfügbare Informationen — aber „öffentlich verfügbar“ bedeutet nicht „uneingeschränkt nutzbar“:

• DSGVO: Die Verarbeitung personenbezogener Daten im Rahmen von OSINT-Ermittlungen muss den Datenschutzanforderungen entsprechen — auch wenn die Daten öffentlich zugänglich sind
• Beweissicherung: OSINT-Erkenntnisse müssen so dokumentiert werden, dass sie als Beweismittel verwertbar sind — mit Zeitstempel, Quelle und Methode der Erhebung
• Scope Creep: OSINT-Ermittlungen können schnell über den definierten Untersuchungsrahmen hinauswachsen. Klare Scope-Definitionen sind essenziell

Handlungsempfehlungen

• OSINT in IR-Playbooks integrieren: Jedes Incident-Response-Playbook sollte einen OSINT-Schritt enthalten — nicht als Optional, sondern als festen Bestandteil der initialen Lagebeurteilung
• Threat-Intelligence-Feeds in SIEM einbinden: IOC-Feeds von AlienVault OTX, Abuse.ch und MISP automatisiert in das SIEM integrieren — so werden OSINT-Erkenntnisse automatisch mit internen Events korreliert
• Leak-Monitoring etablieren: Kontinuierliche Überwachung, ob Unternehmens-Credentials, Dokumente oder Daten in Leaks auftauchen — proaktiv, nicht erst nach einem Vorfall
• DFIR-Team in OSINT schulen: Forensische Analysten sollten OSINT-Werkzeuge kennen und routinemäßig einsetzen — nicht als Spezialdisziplin, sondern als Standardwerkzeug
• Dokumentation und Chain of Custody: OSINT-Erkenntnisse mit derselben Sorgfalt dokumentieren wie forensische Beweise — für Behördenmeldungen, Versicherungsansprüche und juristische Verwertbarkeit

Splunk ist der Platzhirsch im SIEM-Markt. Seit über 20 Jahren das Standardwerkzeug in Enterprise-SOCs, mittlerweile Teil des Cisco-Portfolios, mit einem Ökosystem aus tausenden Apps und Integrationen. Wer über SIEM spricht, spricht oft zuerst über Splunk.

Und trotzdem entscheiden sich immer mehr mittelständische Unternehmen dagegen. Nicht weil Splunk schlecht wäre — sondern weil es für ihre Anforderungen die falsche Lösung ist. Dieser Artikel erklärt, warum XIEM® die bessere Wahl ist — für Unternehmen, die wirksame Sicherheit brauchen, nicht das größte Logo auf dem Chart.

Das Preisproblem: Wenn Log-Volumen zum Geschäftsrisiko wird

Splunks Lizenzmodell basiert auf dem täglichen Ingest-Volumen — gemessen in Gigabyte pro Tag. Das klingt zunächst logisch: Wer mehr Daten einspeist, zahlt mehr. In der Praxis bedeutet es: Jede zusätzliche Log-Quelle, jeder neue Server, jede Cloud-Integration erhöht die Lizenzkosten. Unternehmen beginnen, Entscheidungen über ihre Sicherheitsarchitektur anhand von Lizenzkosten zu treffen statt anhand von Risiken.

Das ist kein theoretisches Problem. In der Branche hat sich der Begriff „Splunk Tax” etabliert — die Praxis, Log-Quellen bewusst nicht anzubinden, weil das Ingest-Budget ausgeschöpft ist. Firewall-Logs werden gedrosselt, Endpoint-Telemetrie gefiltert, Cloud-Audit-Logs gar nicht erst eingebunden. Das Ergebnis: Ein SIEM, das per Design blind ist für die Datenquellen, die es am dringendsten bräuchte.

Die Einstiegskosten für Splunk Enterprise liegen für mittelständische Unternehmen typischerweise im sechsstelligen Bereich pro Jahr — und skalieren schnell in den siebenstelligen Bereich, sobald Log-Volumina wachsen. Seit der Übernahme durch Cisco im März 2024 kommt der Druck hinzu, weitere Cisco-Produkte in den Stack zu integrieren. Hinzu kommen die Personalkosten für den Eigenbetrieb: Mindestens zwei bis drei Vollzeitäquivalente (FTE) für Administration, Detection Engineering und Tuning — Security-Spezialisten, die auf dem Arbeitsmarkt schwer zu finden und teuer zu halten sind. In Summe übersteigen die Personalkosten die Lizenzkosten oft um das Zwei- bis Dreifache.

XIEM® geht einen anderen Weg: Ein Pauschalmodell pro Tier, nicht an das Ingest-Volumen gekoppelt. Sie binden alle relevanten Log-Quellen an — ohne Angst vor der nächsten Rechnung. Sichtbarkeit ist kein Budgetposten, sondern Grundvoraussetzung.

Personal: Die versteckte Kostenfalle

Splunk verkauft Software. Den Betrieb müssen Sie selbst sicherstellen. Das bedeutet in der Praxis: Sie brauchen ein dediziertes Team, das Splunk administriert, Use Cases entwickelt, Detection Rules schreibt, False Positives tuned und die Infrastruktur betreibt. Für ein Unternehmen mit 200 bis 500 Mitarbeitern ist das eine erhebliche Investition — in Menschen, die Sie erst finden, dann halten und deren Wissen Sie vor Abwanderung schützen müssen. Kündigt einer dieser Spezialisten, steht das SOC still.

XIEM® ist ein Managed Service. NEOSEC betreibt das SIEM, entwickelt die Detection-Regeln, tuned die Alerts und liefert Ihnen verwertbare Ergebnisse — nicht Rohdaten, die Sie selbst interpretieren müssen. Sie brauchen kein eigenes SIEM-Team. Sie brauchen einen Ansprechpartner, der Ihnen sagt, was in Ihrem Netz passiert.

Komplexität: Schweizer Taschenmesser vs. scharfes Skalpell

Splunk kann alles. Das ist gleichzeitig seine größte Stärke und seine größte Schwäche. Die Plattform ist als universelle Datenanalysemaschine konzipiert — sie kann SIEM, aber auch Observability, IT-Operations, Business Analytics und Application Performance Monitoring. Diese Flexibilität hat ihren Preis: Die Lernkurve ist steil, die Konfiguration komplex, und die SPL-Abfragesprache (Search Processing Language) ist ein eigenes Fachgebiet.

Für Großkonzerne mit dedizierten Security-Engineering-Teams ist das kein Problem. Für ein mittelständisches Unternehmen, dessen IT-Leiter neben dem SIEM noch Firewall, Endpoint Protection, Backup und Helpdesk verantwortet, ist es eine Überforderung.

XIEM® ist auf Cybersicherheit fokussiert — nicht auf alles. Vier klar definierte Tiers (Sentry, Orchestrate, Control, Control AI) decken den gesamten Reifegrad ab, von der Basis-Überwachung bis zum KI-gestützten SOC-Betrieb. Die Komplexität liegt bei uns, nicht bei Ihnen.

Detection: Out-of-the-Box vs. Build-for-you

Splunk liefert mit der Enterprise Security App ein Framework für Detection — aber die eigentliche Arbeit beginnt danach. Detection Rules müssen geschrieben, getestet, an die eigene Umgebung angepasst und kontinuierlich aktualisiert werden. Ohne diesen Aufwand ist Splunk ein teures Log-Archiv.

XIEM® liefert Detection-Regeln, die auf realen Bedrohungsszenarien basieren und kontinuierlich durch unser SOC-Team weiterentwickelt werden. MITRE ATT&CK Mapping ist integriert, nicht optional. Jeder Alert wurde von einem Analysten bewertet, bevor er Sie erreicht — kein Alert-Rauschen, keine False-Positive-Flut.

NIS-2-Compliance: Nachweis statt Datenbank

NIS-2 verlangt nicht, dass Sie ein SIEM betreiben. NIS-2 verlangt, dass Sie nachweisen können, dass Sie sicherheitsrelevante Ereignisse erkennen, darauf reagieren und dies dokumentieren. Die Meldepflicht — 24 Stunden Erstmeldung, 72 Stunden Detailbericht — setzt voraus, dass Sie überhaupt wissen, dass etwas passiert ist.

Splunk gibt Ihnen die Werkzeuge, diesen Nachweis zu erbauen. XIEM® gibt Ihnen den Nachweis. Unser Reporting ist auf BSI-konforme Dokumentation ausgelegt: MTTD-Metriken, Incident-Timelines, Meldeketten-Protokolle — fertig für die Behörde, nicht erst nach wochenlanger Aufbereitung.

Technologie: Offen statt eingeschlossen

Splunk ist proprietär. Daten, die in Splunk liegen, liegen in Splunks Format. Die Migration weg von Splunk ist aufwändig und teuer — was durchaus beabsichtigt ist. Mit der Cisco-Übernahme verstärkt sich dieser Effekt: Die Plattformstrategie zielt darauf ab, Kunden im Cisco-Ökosystem zu halten.

XIEM® basiert technologisch auf Wazuh — einer Open-Source-SIEM-Plattform mit über 20 Millionen Downloads und einer aktiven Community. Das bedeutet: Keine proprietären Datenformate, keine künstlichen Lock-in-Mechanismen, volle Transparenz über die eingesetzte Technologie. Wenn Sie morgen entscheiden, dass Sie XIEM® nicht mehr brauchen, nehmen Sie Ihre Daten mit. Wir halten Sie nicht durch Abhängigkeit, sondern durch Leistung.

Für wen ist Splunk die richtige Wahl?

Fairerweise: Splunk hat seine Berechtigung. Für Großkonzerne mit dedizierten Security-Engineering-Teams, komplexen Multi-Cloud-Umgebungen und dem Budget für eine siebenstellige SIEM-Investition plus Personalkosten ist Splunk ein mächtiges Werkzeug. Wer bereits ein Team von Splunk-Spezialisten hat und die Plattform produktiv nutzt, hat keinen Grund zu wechseln.

Für alle anderen — für den Mittelstand, für Unternehmen mit 50 bis 2.000 Mitarbeitern, für IT-Leiter, die neben dem SIEM noch zehn andere Baustellen haben, für Geschäftsführer, die NIS-2-Compliance nachweisen müssen, ohne ein eigenes SOC aufzubauen — ist XIEM® die bessere Wahl.

Der Vergleich auf einen Blick

	Splunk Enterprise	XIEM®
Lizenzmodell	Pro GB/Tag Ingest — skaliert mit Log-Volumen	Pauschale pro Tier — planbar und vorhersehbar
Betrieb	Eigenbetrieb (2–3 FTE erforderlich)	Managed Service durch NEOSEC
Kostentreiber	Lizenz + Personal + Infrastruktur	Ein Pauschalpreis, alles inklusive
Detection	Framework — Rules selbst entwickeln	Fertige Rules + kontinuierliche SOC-Analyse
NIS-2-Reporting	Selbst aufbauen	BSI-konform integriert
Technologie	Proprietär (Cisco)	Open Source (Wazuh-basiert)
Lock-in	Hoch — proprietäres Datenformat, Cisco-Ökosystem	Kein Lock-in — offene Standards, Daten gehören Ihnen
KI-Integration	Splunk AI Assistant (kostenpflichtiges Add-on)	XIEM® Control AI (nativ im höchsten Tier)
Zielgruppe	Enterprise mit eigenem Security-Team	Mittelstand ohne dediziertes SOC
Time-to-Value	Monate (Deployment + Tuning + Personalaufbau)	Tage bis Wochen

Laut einem Bericht von Security Insider unterschätzen viele kleine und mittlere Unternehmen (KMU) weiterhin das Risiko gezielter Cyberangriffe. Die Zahlen sprechen eine andere Sprache: Die Mehrheit der Ransomware-Vorfälle trifft inzwischen nicht mehr Konzerne, sondern den Mittelstand.

Warum KMU überproportional betroffen sind

Großunternehmen haben in den letzten Jahren massiv in Sicherheitsinfrastruktur investiert — SOCs, SIEM-Systeme, Red-Team-Übungen, dedizierte Security-Teams. Angreifer weichen daher zunehmend auf Ziele mit geringerem Widerstand aus. KMU bieten dabei ein attraktives Kosten-Nutzen-Verhältnis für Cyberkriminelle:

• Wertvolle Daten: Kundendaten, Geschäftsgeheimnisse, Finanzdaten — auch ein 50-Mitarbeiter-Unternehmen hat Daten, die sich verschlüsseln oder verkaufen lassen
• Geringe Abwehrfähigkeit: Kein eigenes SOC, keine 24/7-Überwachung, oft nicht einmal ein dedizierter IT-Security-Mitarbeiter
• Höhere Zahlungsbereitschaft: Ohne getestete Backups und Incident-Response-Pläne ist die Versuchung größer, Lösegeld zu zahlen, um den Betrieb schnell wiederherzustellen
• Supply-Chain-Zugang: KMU sind oft Zulieferer größerer Unternehmen — ein kompromittierter Zulieferer kann zum Einfallstor für das eigentliche Ziel werden

Was Managed Detection & Response für KMU leistet

Managed Detection & Response (MDR) schließt die Lücke zwischen Enterprise-Sicherheit und KMU-Budget. Statt eigene Infrastruktur und Personal aufzubauen, nutzen Unternehmen den Service eines spezialisierten Anbieters:

• 24/7-Monitoring: Angriffe finden nachts und am Wochenende statt — genau dann, wenn interne IT-Teams nicht besetzt sind. MDR bietet Rund-um-die-Uhr-Überwachung
• Schnellere Erkennung: Laut Branchenberichten können MDR-Dienste Angriffe bis zu 70 Prozent schneller erkennen als Unternehmen ohne kontinuierliches Monitoring
• Geringere Kosten: Ein internes SOC mit 24/7-Besetzung erfordert mindestens 6-8 Analysten. MDR bietet vergleichbare Fähigkeiten zu einem Bruchteil der Kosten
• Expertise on demand: Threat Hunting, Incident Response und forensische Analyse durch spezialisierte Analysten — ohne diese Kompetenzen selbst aufbauen zu müssen

NIS2 macht professionelles Monitoring zur Pflicht

Mit der NIS2-Richtlinie wird IT-Sicherheit für viele KMU erstmals zur gesetzlichen Pflicht. Unternehmen in 18 Sektoren — darunter verarbeitendes Gewerbe, Lebensmittelproduktion, Abfallwirtschaft und digitale Dienste — müssen technische und organisatorische Maßnahmen zur Angriffserkennung nachweisen. Für viele KMU bedeutet das: Ohne SIEM oder MDR ist NIS2-Compliance nicht erreichbar.

Handlungsempfehlungen für KMU

• Sichtbarkeit schaffen: Ein zentrales Log-Management ist die Grundvoraussetzung für jede Angriffserkennung. Ohne Logs keine Erkennung, ohne Erkennung keine Reaktion
• MDR evaluieren: Vergleichen Sie die Kosten eines MDR-Dienstes mit den Kosten eines internen SOC — und mit den Kosten eines unentdeckten Ransomware-Angriffs
• NIS2-Betroffenheit prüfen: Klären Sie, ob Ihr Unternehmen unter die NIS2-Richtlinie fällt — viele KMU wissen es noch nicht
• Incident-Response-Plan erstellen: Auch ohne MDR: Wer wird bei einem Vorfall informiert? Wer entscheidet? Welche externen Partner werden hinzugezogen?
• Backups testen: Vorhandene Backups auf Wiederherstellbarkeit prüfen. Viele Unternehmen entdecken erst im Ernstfall, dass ihre Backups unvollständig oder nicht wiederherstellbar sind

Kürzlich ist ein interessanter Tag in Bezug auf die IT-Sicherheit verstrichen, auf dessen Symbolkraft ich näher eingehen möchte. Im Jahr 2012 wurde der 1. Februar zum Nationalen Tag der Passwortzurücksetzung erklärt. Dieser Tag soll die Menschen an die Bedeutung des Passwortschutzes erinnern. Ist dies noch sinnvoll?

Dieser Tag soll die Menschen dazu ermutigen, alle ihre Passwörter zu ändern, was die Sicherheit erhöhen soll. Aber wenn man so viele Passwörter ändern muss, erstellen die Leute sie in der Regel nach bestimmten Mustern oder, was noch schlimmer ist, sie verwenden überall dasselbe Passwort. Passwörter sollten unterschiedlich und sicher sein und an einem sicheren Ort aufbewahrt werden!

Da es unmöglich ist, sich alle Passwörter zu merken, geschweige denn solche, die sich ständig ändern, bewahren die Menschen sie an unsicheren Orten auf. Zum Beispiel auf einem Blatt Papier unter der Tastatur. Wenn dies auf Sie oder Ihre Kollegen zutrifft, ändern Sie das Passwort sofort und werfen Sie den Zettel weg!

Aber wie bewahren Sie Ihre Passwörter sicher auf?

Sie sollten einen Passwort-Manager wie Bitwarden verwenden und Ihre Passwörter nicht nach einem Kalender ändern. Ja, sie müssen gelegentlich aktualisiert werden, aber nicht unbedingt einmal im Jahr oder noch öfter. Es ist sehr wichtig, Ihr Passwort zu ändern, wenn es möglicherweise durch eine Sicherheitsverletzung kompromittiert wurde oder wenn seine Länge nicht mehr den modernen Standards entspricht. Außerdem sollten Sie nie zweimal dasselbe Passwort verwenden.

Passwortmanager verfügen über gute Passwortgeneratoren, die lange und zufällige Passwörter erstellen, welche Angreifer nicht erraten können. Auch die Verwendung von Passwörtern ist einfach: Sie können das Passwort mit ein paar Klicks kopieren oder eine Browsererweiterung verwenden, die Sie zur Verwendung des Passworts auffordert.

Das einzige Passwort, das Sie sich merken müssen, ist das Master-Passwort. Es sollte sicher aufbewahrt und separat gelagert werden. Mit diesem Passwort erhalten Sie Zugang zum Tresor.

Ein komplexes und nicht kompromittiertes Passwort ist viel besser als ein ständiger Wechsel von einfachen und unsicheren Passwörtern. Verwenden Sie einen Passwort-Manager und bleiben Sie sicher! Für die Einrichtung eines Passwort-Tresors für Organisationen kontaktieren Sie uns.

Im Oktober 2022 veröffentlichte der Twitter-Account der New York Post mehrere beleidigende und gewaltverherrlichende Tweets. Das Unternehmen erklärte zunächst, das Konto sei gehackt worden. Wenig später stellte sich heraus: Ein Mitarbeiter hatte die Tweets verfasst — ein Mitarbeiter, der für seine Rolle keinen Zugriff auf den offiziellen Twitter-Account hätte haben müssen.

Das eigentliche Problem: Unkontrollierte Zugriffsrechte

Der Vorfall war kein Cyberangriff im klassischen Sinne. Aber er illustriert ein Sicherheitsproblem, das in vielen Unternehmen existiert: Mitarbeiter haben Zugriff auf Systeme und Accounts, die sie für ihre tägliche Arbeit nicht benötigen.

Das Prinzip dahinter ist so alt wie die IT-Sicherheit selbst: Least Privilege — jeder Benutzer erhält nur die minimalen Zugriffsrechte, die für seine Aufgabe erforderlich sind. In der Praxis wird dieses Prinzip häufig unterlaufen:

• Berechtigungen werden bei Abteilungswechseln nicht angepasst: Ein Mitarbeiter wechselt von Marketing zu HR, behält aber den Zugriff auf Social-Media-Accounts
• Geteilte Zugangsdaten: Team-Passwörter für Social-Media-Accounts, Admin-Portale oder Cloud-Dienste werden an mehr Personen weitergegeben als nötig
• Fehlende regelmäßige Access Reviews: Berechtigungen werden einmal vergeben und nie überprüft
• Kein Offboarding-Prozess: Ausscheidende Mitarbeiter behalten Zugriff auf Systeme, weil niemand die Deaktivierung anstößt

Insider-Risiko: Nicht nur böswillig

Wenn von Insider-Bedrohungen gesprochen wird, denken viele an bewusste Sabotage. Die Realität ist differenzierter. Laut dem Verizon Data Breach Investigations Report 2023 sind übermäßige Berechtigungen ein wesentlicher Faktor bei Datenschutzverletzungen durch Insider — ob fahrlässig oder absichtlich.

Übermäßige Zugriffsrechte vergrößern den Blast Radius jedes Sicherheitsvorfalls:

• Ein Phishing-Angriff auf einen Mitarbeiter mit zu vielen Rechten kompromittiert mehr Systeme
• Ein gestohlenes Passwort eines Mitarbeiters mit Admin-Zugang öffnet das gesamte Netzwerk
• Ein unzufriedener Mitarbeiter mit unnötig breitem Zugriff kann mehr Schaden anrichten

Privilegierte Accounts: Mehr Schutz, nicht mehr Rechte

Administratoren und Führungskräfte benötigen erweiterte Zugriffsrechte — das ist unvermeidlich. Aber diese Accounts erfordern zusätzliche Schutzmaßnahmen:

• Multi-Faktor-Authentifizierung (MFA) für alle privilegierten Accounts — ohne Ausnahme
• Privileged Access Management (PAM): Zentrale Verwaltung und Überwachung privilegierter Zugänge, zeitlich begrenzte Rechteerweiterung (Just-in-Time Access)
• Separate Admin-Accounts: Tägliche Arbeit mit Standard-Account, Administrative Aufgaben nur über dedizierten Admin-Account
• Session-Monitoring: Protokollierung aller Aktionen mit privilegierten Accounts

Identity Governance als kontinuierlicher Prozess

Zugriffsrechte zu verwalten ist kein einmaliges Projekt, sondern ein kontinuierlicher Prozess. Effektives Identity Governance and Administration (IGA) umfasst:

• Automatisiertes Provisioning und Deprovisioning: Zugriffsrechte werden automatisch vergeben, wenn ein Mitarbeiter eine Rolle antritt, und entzogen, wenn er sie verlässt
• Regelmäßige Access Reviews: Manager bestätigen quartalsweise, dass ihre Teammitglieder nur die Rechte haben, die sie benötigen
• Role-Based Access Control (RBAC): Berechtigungen werden an Rollen gebunden, nicht an Personen — das vereinfacht die Verwaltung erheblich
• Anomalie-Erkennung: Ein SIEM, das ungewöhnliche Zugriffsmuster erkennt — ein Mitarbeiter, der plötzlich auf Systeme zugreift, die er nie zuvor genutzt hat

Was ist Zero-Day?

Eine Zero-Day-Schwachstelle ist eine Software-Schwachstelle, die bereits von Hackern entdeckt wurde. Aber Entwickler und Cybersicherheitsexperten wissen nicht einmal, dass sie existiert. Dementsprechend gibt es kein Update, um die Schwachstelle zu beheben. Das verschafft Angreifern einen deutlichen Vorsprung.

Ein Zero-Day-Exploit ist ein Programm oder eine Methode, mit der Angreifer eine identifizierte Schwachstelle ausnutzen.

Ein Zero-Day-Angriff ist die direkte Ausnutzung eines von Hackern entwickelten Exploits. Manchmal können sie es sofort nach der Entwicklung verwenden und müssen nicht auf den richtigen Moment warten. Häufig wird es angewendet, um Daten zu stehlen oder vorübergehend Zugriff auf Server zu erhalten aber auch um sie zu infizieren und damit Angriffe weiter auszudehnen.

Hacker haben in jedem Fall einen deutlichen Vorsprung, der ihnen die Möglichkeit gibt, Angriffe mit hoher Erfolgswahrscheinlichkeit durchzuführen. Oder sie verkaufen diese Informationen über neu entdeckte Schwachstellen für viel Geld auf dem Schwarzmarkt.

Wie kann man erkennen, dass man Opfer eines Zero-Day-Angriffes ist?

Obwohl Sie die Existenz einer Schwachstelle möglicherweise nicht vermuten, verfügen Sie über das Wissen, wie Ihre IT-Infrastruktur unter normalen Bedingungen funktioniert. Machen Sie sich dazu regelmäßig mit den Systemstatistiken vertraut.

Ungewöhnliches Verhalten und Leistungsindikatoren dieser Systeme zeigen Ihnen, dass etwas nicht stimmt. Denn Viren können nicht völlig unbemerkt im Umlauf sein. Das Problem kann jedoch sein, dass die Änderungen geringfügig sind oder der Virus recht schnell ausgeführt wird.

Ein weiteres nützliches Element sind Antivirenprogramme und Datenbanken mit vorhandenen Viren. Wie wir bereits gesagt haben, werden Viren nicht spurlos ausgeführt. Sie können aber auch nach einem typischen Szenario ausgeführt werden, das von einem Antivirusprogramm erkannt werden sollte. Durch den Vergleich des Verhaltens unbekannter Schadsoftware mit bereits vorhandener soll das Antivirusprogramm deren Betrieb blockieren oder zumindest vor der Bedrohung warnen. Diese Programme arbeiten automatisch und sind in der Lage, die Systemleistung in Echtzeit zu bewerten. Ein solcher Schutz kann Sie effektiv vor einem möglichen Angriff warnen, aber leider ist es unwahrscheinlich, dass er Sie schützen kann.

Wie Sie das Risiko einer 0-Day-Attacke reduzieren können?

Überwachen Sie, wie oben bereits angedeutet, den Betrieb Ihrer Systeme und achten Sie auf ungewöhnliches Verhalten.

Implementieren Sie ein Patch-Management-System. Die neuesten Programmversionen sind in der Regel die sichersten. Selbst wenn Unternehmen ein unsicheres Update veröffentlichen, wird dessen Sicherheit ziemlich schnell gepatcht. Deshalb sollten Sie so schnell wie möglich aktualisieren.

Es ist notwendig, einen Aktionsplan zu haben, falls ein Zero-Day-Angriff auf Sie erfolgreich ist. Hauptsächlich verpflichtet es Sie, regelmäßig Backups aller Daten, Websites usw. anzufertigen. Es ist auch ratsam, im Voraus zu wissen, wie Sie den entspechenden Dienstleister kontaktieren können, sodass Ihre Systeme schnellstmöglich wiederhergestellt werden können.

Verwenden Sie Firewalls und Antivirenprogramme. Damit können Sie im Idealfall sogar neue Angriffe erkennen. Beide sollten dafür vernünftig konfiguriert sein.

Entfernen Sie Anwendungen, die Sie selten oder nicht verwenden, von Ihren Geräten. Sie können zu einem Einstiegspunkt für Angreifer werden. Ebenso sollten Sie alte Anwendungen, welche nicht mehr regelmäßig Sicherheitsupdates erhalten, aus Ihren Systemen ausschließen. Wechseln Sie zu einer neuen Alternative oder geben Sie sie auf. Neue Alternativen werden besser geeignet sein, um vor neuer Malware zu schützen.

Wie Neosec Ihnen helfen kann, sicher zu bleiben?

Die oben genannten Maßnahmen werden Ihre Sicherheit nur geringfügig verbessern oder vor einem möglichen 0-Day-Angriff warnen können. Professionelles Setup, individuelles Schutzdesign und Tracking durch Cybersicherheitsexperten ermöglicht Ihnen, selbst diese Arten von Angriffen zu blockieren und die Wahrscheinlichkeit zu verringern, dass Ihre Systeme solchen Angriffen ausgesetzt sind.

Wir erkennen ungewöhnliche Aktivitäten nicht nur durch automatisierte Methoden, sondern prüfen jede dieser Warnungen auch einzeln. Und dafür verwenden wir komplexere Tools zur tieferen Verifizierung von Systemen.

Wir implementieren ein zentralisiertes automatisches Patch-Management. Alle Ihre Geräte verfügen über die neuesten Versionen der Programme, ganz ohne Ihr mitwirken. Wir können Sie auch darüber beraten, welche Programme Sie vermeiden sollten und welche sichereren Alternativen es gibt.

Wir passen den Zugang Ihrer Mitarbeiter zu IT-Systemen nach ihren Bedürfnissen an. Ein erfolgreicher Angriff auf einen bestimmten Mitarbeiter oder sogar eine ganze Abteilung betrifft also nur deren Systeme und nicht das Unternehmen als Ganzes.

Unsere Erfahrung in der Arbeit mit Firewalls und Antivirenprogrammen ermöglicht es Ihnen, diese richtig zu konfigurieren und die besten für Sie auszuwählen.

Auch im Falle eines erfolgreichen Angriffs haben Sie alles bereit, um die Arbeit schnellstmöglich wieder aufzunehmen. Bei Bedarf kann für Kunden ein vollständig unterbrechungsfreier Betrieb eingerichtet werden.

Was ist, wenn nichts getan wird?

Auf die Produkte großer Konzerne können Sie sich nach wie vor verlassen, in der Hoffnung, dass diese Produkte vollständig geschützt sind. Aber in den letzten drei Jahren sind Apple, Google, Microsoft, Zoom und andere erfolgreich solchen Angriffen erlegen. Ihre Systeme sind sperrig und komplex, was ihren Schutz zu einer äußerst schwierigen Aufgabe macht. Dies verursacht periodische Löcher in der Abwehr. Ihr Schutz hat für sie möglicherweise nicht immer Priorität.

Apple, Mozilla und Let’s Encrypt forderten Ende 2022 gemeinsam die Einführung einer zentralen Sperrliste für kompromittierte SSL/TLS-Zertifikate. Google — dessen Browser Chrome über 60 Prozent Marktanteil hält — hat sich zu dem Vorschlag zunächst nicht geäußert. Die Initiative wirft eine grundlegende Frage auf: Wie kann das Ökosystem der Web-Verschlüsselung mit kompromittierten Zertifikaten umgehen, ohne die Performance und Verfügbarkeit des Internets zu beeinträchtigen?

Was SSL/TLS-Zertifikate leisten — und wo das Problem liegt

SSL/TLS-Zertifikate sind das Fundament der Web-Verschlüsselung. Sie stellen sicher, dass die Verbindung zwischen Browser und Webserver verschlüsselt ist (das Schloss-Symbol in der Adressleiste) und dass die Website tatsächlich dem angegebenen Betreiber gehört. Zertifikate werden von Certificate Authorities (CAs) wie Let’s Encrypt, DigiCert oder Sectigo ausgestellt.

Das Problem entsteht, wenn Zertifikate kompromittiert werden — etwa durch gestohlene Private Keys, fehlkonfigurierte Server oder kompromittierte CAs. In solchen Fällen muss das Zertifikat widerrufen werden. Aber wie erfährt der Browser, dass ein Zertifikat ungültig ist?

CRL und OCSP: Die gescheiterten Ansätze

Historisch gab es zwei Mechanismen:

• Certificate Revocation Lists (CRL): Eine zentrale Liste aller widerrufenen Zertifikate, die Browser regelmäßig herunterladen. In den Anfängen des Web funktionierte das. Mit dem exponentiellen Wachstum der Zertifikatszahlen wurden CRLs zu groß und zu langsam — und wurden von den meisten Browsern aufgegeben
• Online Certificate Status Protocol (OCSP): Der Browser fragt bei jedem Seitenaufruf den OCSP-Server der CA, ob das Zertifikat noch gültig ist. Das erzeugt Latenz, Datenschutzprobleme (die CA erfährt, welche Websites der Nutzer besucht) und funktioniert nicht, wenn der OCSP-Server nicht erreichbar ist. Die meisten Browser implementieren daher Soft-Fail: Wenn der OCSP-Server nicht antwortet, wird das Zertifikat trotzdem akzeptiert

Das Ergebnis: In der Praxis werden widerrufene Zertifikate von vielen Browsern stillschweigend akzeptiert.

Der Vorschlag: CRLite und kompakte Sperrlisten

Der Vorstoß von Apple, Mozilla und Let’s Encrypt zielt auf eine verbesserte Technologie: komprimierte Sperrlisten, die lokal im Browser vorgehalten und regelmäßig aktualisiert werden. Mozilla entwickelt mit CRLite einen Ansatz, der die gesamte Widerrufsinformation des Web-PKI-Ökosystems in eine Datenstruktur von wenigen Megabyte komprimiert. Updates werden inkrementell ausgeliefert — ähnlich wie Virendefinitionen.

Der Vorteil: Kein OCSP-Lookup bei jedem Seitenaufruf, keine Latenz, kein Datenschutzproblem, kein Soft-Fail. Der Browser hat die Information lokal und kann kompromittierte Zertifikate zuverlässig blockieren.

Warum Googles Position entscheidend ist

Chrome hat mit über 60 Prozent den größten Marktanteil unter den Desktop-Browsern. Ohne Chromes Unterstützung bleibt jede Sperrlisten-Initiative lückenhaft. Google verfolgt mit CRLSets einen eigenen Ansatz — eine kuratierte, kleinere Liste besonders kritischer Widerrufe. Kritiker bemängeln, dass CRLSets nur einen Bruchteil der widerrufenen Zertifikate abdecken.

Google hat inzwischen angekündigt, OCSP-Checks in Chrome vollständig abzuschaffen, da sie in der Praxis keinen effektiven Schutz bieten. Ob Chrome auf CRLite oder eine vergleichbare Technologie umschwenkt, ist offen.

Relevanz für Unternehmen

Für Unternehmen hat die Zertifikats-Thematik praktische Konsequenzen:

• Zertifikatsmanagement: Unternehmen müssen ihre eigenen Zertifikate aktiv verwalten — Ablaufdaten überwachen, kompromittierte Zertifikate zeitnah widerrufen und Private Keys sicher speichern
• Certificate Transparency Monitoring: Dienste wie crt.sh ermöglichen es, neu ausgestellte Zertifikate für die eigenen Domains zu überwachen. Unautorisiert ausgestellte Zertifikate können ein Hinweis auf DNS-Hijacking oder CA-Kompromittierung sein
• Phishing-Erkennung: Das Schloss-Symbol allein ist kein Sicherheitsindikator. Auch Phishing-Seiten verwenden gültige SSL-Zertifikate — Let’s Encrypt stellt Zertifikate automatisiert und kostenlos aus. Mitarbeiter müssen wissen, dass HTTPS lediglich die Verschlüsselung der Verbindung garantiert, nicht die Legitimität der Website

Mehr als 600 bekannte Schwachstellen in VPN-Produkten sind in der CVE-Datenbank registriert. Laut dem Zscaler VPN Risk Report 2022 verlassen sich trotzdem 95 Prozent der Unternehmen auf VPN als primären Remote-Access-Mechanismus. Gleichzeitig beobachteten 44 Prozent einen Anstieg von Angriffen auf ihre VPN-Infrastruktur. Das Sicherheitsversprechen von VPN hält der Realität nicht stand.

Was VPN tatsächlich leistet — und was nicht

VPN verschlüsselt den Datenverkehr zwischen dem Endgerät und dem VPN-Gateway und verbirgt die IP-Adresse des Nutzers gegenüber dem Zielserver. Das schützt in unsicheren Netzwerken (öffentliches WLAN, Hotel, Flughafen) vor passivem Mitlesen und bestimmten Man-in-the-Middle-Angriffen.

Was VPN nicht leistet:

• Kein Schutz vor Phishing: VPN verschlüsselt den Transport, nicht den Inhalt. Wer Zugangsdaten auf einer Phishing-Seite eingibt, wird trotz VPN kompromittiert
• Kein Schutz kompromittierter Endgeräte: Ist das Gerät eines Mitarbeiters mit Malware infiziert, tunnelt VPN den Schadverkehr direkt ins Unternehmensnetz
• Kein Identitätsnachweis: VPN authentifiziert die Verbindung, nicht den Nutzer. Gestohlene VPN-Credentials gewähren vollen Netzwerkzugang
• Keine granulare Zugriffskontrolle: Klassische VPNs gewähren nach erfolgreicher Verbindung Zugang zum gesamten Netzwerk — nicht nur zu den Ressourcen, die der Nutzer tatsächlich benötigt

VPN-Schwachstellen als Angriffsvektor

VPN-Appliances selbst sind hochwertige Ziele. Sie stehen per Definition am Netzwerkrand und sind aus dem Internet erreichbar. Kritische Schwachstellen in VPN-Produkten von Fortinet (CVE-2024-21762), Ivanti (CVE-2024-21887), Palo Alto Networks (CVE-2024-3400) und Cisco (CVE-2023-20269) wurden in den letzten Jahren aktiv ausgenutzt — teils als Zero-Days, bevor Patches verfügbar waren.

Die CISA hat mehrfach Notfall-Direktiven zu VPN-Schwachstellen herausgegeben. VPN-Appliances gehören zu den am häufigsten in den KEV-Katalog (Known Exploited Vulnerabilities) aufgenommenen Produktkategorien.

Zuverlässigkeitsprobleme auf mobilen Geräten

Selbst die grundlegende Funktion — Verschlüsselung des gesamten Datenverkehrs — ist nicht garantiert. Mullvad dokumentierte im Oktober 2022, dass Android Connectivity-Check-Traffic am VPN vorbeileitet, selbst wenn die Option „VPN immer aktiv” und „Verbindungen ohne VPN blockieren” aktiviert ist. iOS hat ähnliche Probleme: Mysk-Forscher zeigten, dass Apple-Dienste VPN-Tunnel umgehen.

Für Unternehmen bedeutet das: Selbst bei korrekt konfiguriertem VPN können sensible Metadaten das Gerät unverschlüsselt verlassen.

Zero Trust als Alternative

Der Zero-Trust-Ansatz löst die grundlegenden Architekturprobleme von VPN. Statt dem gesamten Netzwerk nach erfolgreicher VPN-Verbindung zu vertrauen, wird jeder Zugriff einzeln authentifiziert und autorisiert:

• Identity-basierter Zugriff: Nicht das Netzwerk, sondern die Identität des Nutzers bestimmt, welche Ressourcen erreichbar sind
• Device Compliance: Nur verwaltete, konforme Geräte erhalten Zugang — unabhängig vom Standort
• Least Privilege: Zugriff wird granular gewährt — auf Anwendungsebene, nicht auf Netzwerkebene
• Continuous Verification: Die Zugriffsberechtigung wird kontinuierlich überprüft, nicht nur zum Verbindungsaufbau

Microsoft, Google und das NIST (SP 800-207) propagieren Zero Trust als Ablösung des perimeterbasierte Sicherheitsmodells, auf dem VPN basiert. Für Unternehmen, die noch nicht vollständig auf Zero Trust umstellen können, empfiehlt sich als Zwischenschritt: MFA für VPN-Zugänge verpflichtend machen, Netzwerksegmentierung implementieren und VPN-Appliances in das SIEM-Monitoring einbinden.