Zugangskontrolle-Log-Auswertung

Das echte Ausmaß des Problems

Zugangskontrollsysteme erzeugen täglich Tausende von Einträgen. Ein Unternehmen mit 150 Mitarbeitenden und zwölf gesicherten Zonen produziert typisch 2.000 bis 5.000 Log-Ereignisse pro Tag. Manuell lässt sich das nicht auswerten, außer in der Retrospektive nach einem Vorfall.

Das Problem: Bis der Vorfall bekannt ist, hat der Täter manchmal Wochen oder Monate Zeit gehabt. Laut dem Verizon Data Breach Investigations Report 2024 dauert es bei Insider-Incidents im Median über 200 Tage, bis ein Unternehmen bemerkt, dass etwas nicht stimmt. Zum Vergleich: Externe Angriffe werden im Schnitt nach 90–100 Tagen entdeckt. Insider kennen die Umgebung. Sie wissen, wann Kameras ausgerichtet sind, wann Schichten wechseln, wie häufig Logs ausgewertet werden.

Die finanziellen Folgen sind erheblich: Der durchschnittliche Schaden einer Insider-Threat-Incident liegt laut dem Ponemon Institute 2023 bei ca. 700.000 US-Dollar, wobei physischer Diebstahl, Datenverlust und Compliance-Schäden eingerechnet sind. Für mittelständische Unternehmen ohne Versicherungsschutz kann ein einziger schwerer Vorfall existenzbedrohend sein.

Die Ursache ist strukturell: Zugangskontrolllogs werden in fast allen Unternehmen reaktiv ausgewertet. Das heißt: Das System ist technisch vorhanden und zeichnet alles auf, aber niemand schaut hin, bis etwas Verdächtiges gemeldet wird. Proaktive Auswertung würde täglich Arbeit bedeuten, die in keinem Stellenplan steht.

Mit vs. ohne KI, ein ehrlicher Vergleich

Die Erkennungszeit-Verbesserung ist real, aber sie hängt direkt davon ab, wie gut die Baselinequalität ist und ob die Alerts ernst genommen werden. Wenn ein System täglich 40 Alerts produziert, von denen 38 Fehlalarme sind, sinkt die Bereitschaft zur Reaktion schnell. Das ist der kritischste Betriebsparameter, und ein häufiger Einstiegsfehler (mehr dazu im entsprechenden Abschnitt weiter unten).

Einschätzung auf einen Blick

Zeitersparnis, niedrig (2/5) Die manuelle Log-Durchsicht entfällt, das spart 30–60 Minuten täglich für eine Person, die diese Aufgabe bisher übernommen hat. Das ist real, aber kein großer Stundeneffekt. Der eigentliche Wert liegt nicht in gesparter Arbeitszeit, sondern in der Qualität der Erkennung: Menschen übersehen systematisch, was UEBA-Systeme zuverlässig markieren. Andere Anwendungsfälle in dieser Kategorie, wie Schichtplanung Sicherheitsdienst oder Vorfallsbericht automatisch erstellen, sparen mehr direkte Arbeitsstunden.

Kosteneinsparung, niedrig (2/5) Es gibt keine direkten Kosteneinsparungen. Der Wert ist präventiv: Verhinderte Incidents, verhinderte Compliance-Strafen, verhinderte Versicherungsregresse. Diese Logik ist real, aber sie ist schwer buchhalterisch zu erfassen, solange kein Incident verhindert wird. Wer als erstes Argument „Kostenersparnis” braucht, wird diesen Use Case nicht erfolgreich pitchen können.

Schnelle Umsetzung, niedrig (2/5) Das Besondere an diesem Anwendungsfall: Die Technik ist oft das Schnellste. Was die Umsetzung verlangsamt, ist das Recht. Ein System, das Mitarbeitende anhand ihres Verhaltens überwacht und bewertet, löst BetrVG § 87 Abs. 1 Nr. 6 aus, das Mitbestimmungsrecht des Betriebsrats bei technischen Überwachungseinrichtungen. Dieser Prozess ist nicht umgehbar und dauert realistisch 4–12 Wochen, bevor der erste Produktivbetrieb aufgenommen werden darf. Dazu kommt eine Baseline-Periode von 60–90 Tagen. Bis zu zuverlässigen Ergebnissen vergehen daher in der Regel 12–16 Wochen ab Projektstart.

ROI-Sicherheit, mittel (3/5) Der ROI existiert, aber er ist nur nachweisbar, wenn etwas verhindert wird. Das ist das Grundproblem der Prävention: Erfolg bedeutet, dass nichts passiert, was schwer zu messen ist. In Branchen mit hohen Compliance-Anforderungen (Pharma, kritische Infrastruktur, Chemie) ist der ROI durch Vermeidung von Bußgeldern messbar. Für alle anderen bleibt er weitgehend qualitativ.

Skalierbarkeit, hoch (4/5) Ein einmal eingerichtetes UEBA-System wächst mit dem Unternehmen: mehr Mitarbeitende, mehr Zonen, mehr Log-Quellen, der Betriebsaufwand steigt kaum. Die Rechenleistung für Machine Learning-Baselines skaliert gut linear. Der einzige echte Skalierungskostenblock ist das Alert-Management: Mehr Nutzer bedeuten mehr potenzielle Anomalien, mehr False Positives, mehr Tuningaufwand.

Richtwerte, stark abhängig von Unternehmensgröße, Anzahl der gesicherten Zonen und vorhandener Systemlandschaft.

Was Zugangskontrolldaten wirklich enthalten

Bevor ein System analysieren kann, muss klar sein, was überhaupt vorhanden ist. Zugangskontrollanlagen, egal ob von Kaba, GEZE, Siemens, Allegion/Schlage oder kleineren Herstellern, erzeugen typisch folgende Datenpunkte:

Was immer vorhanden ist:

• Zeitstempel (Datum + Uhrzeit des Ereignisses, sekundengenau)
• Badge-ID / Transponder-ID (nicht zwingend der Klarnamen, Mapping muss separat gepflegt werden)
• Zonentür / Lesegerät-ID (welche Tür wurde geöffnet oder verweigert)
• Ereignistyp (Zugang gewährt, Zugang verweigert, Ausweis unbekannt, Türöffnung ohne Ausweis)

Was häufig, aber nicht immer vorhanden ist:

• Richtung (Zugang hinein, Zugang hinaus, oder nur eine Richtung)
• Zeitbeschränkungsprofil (welche Zeitfenster sind für diesen Ausweis erlaubt)
• Alarmereignisse (Tür offen zu lang, Tür aufgebrochen)
• Geräusch-/Kamera-Verknüpfung (wenn integrierte Systeme vorhanden sind)

Was fast nie vorhanden ist:

• Biometrische Daten (außer bei explizit biometrisch gesicherten Bereichen)
• Begründung für den Zugang (warum war jemand dort, das weiß das System nicht)
• Kontextdaten (Schichtplan, Urlaubskalender, geplante Wartungsarbeiten)

Die letzte Kategorie ist entscheidend für die Qualität der Anomalieerkennung: Ein System, das keinen Zugriff auf Urlaubskalender oder Schichtpläne hat, wird einen Wochenendbesuch des Sicherheitsbeauftragten genauso als Anomalie markieren wie einen verdächtigen Nachtbesuch. Der Aufwand für die Integration dieser Kontextdaten wird systematisch unterschätzt.

Was das System konkret macht

Das technische Konzept heißt User and Entity Behavior Analytics (UEBA). Das Grundprinzip: Statt feste Regeln zu definieren (“Alert bei Zugang nach 22 Uhr”), lernt das System, was für jeden Mitarbeitenden typisch ist, und markiert nur das, was von dieser persönlichen Baseline deutlich abweicht.

Konkret bedeutet das:

Schritt 1, Datenintegration. Die Logs des Zugangskontrollsystems werden kontinuierlich in das UEBA-System eingespielt. Entweder per Syslog-Stream, REST-API oder CSV-Export (täglicher Batch). Dazu idealerweise Kontextdaten: Personalstamm (wer ist in welcher Abteilung), Schichtpläne (wann ist eine Person üblicherweise im Betrieb), Zonengenehmigungen (für welche Bereiche ist wer berechtigt).

Schritt 2, Baselineaufbau. Über 60–90 Tage lernt das System normale Muster: Angestellter Müller kommt typisch montags bis freitags zwischen 7:30 und 8:15 Uhr an, betritt regelmäßig Bürobereich A und Konferenzraum 2, nie jedoch den Serverraum. Diese Baseline ist individuell, nicht nach Abteilung oder Rolle, sondern nach tatsächlichem Verhalten.

Schritt 3, Anomaliescoring. Für jedes neue Ereignis berechnet das System einen Abweichungswert. Das Serverraum-Ereignis für Müller bekommt einen hohen Score, der Serverraum gehört nicht zu seiner Baseline. Derselbe Serverraum-Zugang für die IT-Administratorin Fischer: normaler Score, sie ist täglich dort.

Schritt 4, Alert-Priorisierung. Nicht jede Abweichung wird sofort als Alert ausgegeben. Gute Systeme akkumulieren Scores: Wenn Müller am selben Tag den Serverraum betritt, einen USB-Stick am Drucker-PC anschließt und 30 Minuten außerhalb seiner üblichen Arbeitszeit anwesend ist, steigt der kombinierte Risikowert. Dieser kumulative Ansatz reduziert False Positives erheblich.

Erkannte Anomalie-Typen bei physischer Zugangskontrolle:

• Impossible Travel: Dieselbe Badge-ID an zwei Standorten innerhalb eines physisch unmöglichen Zeitfensters (zwei Lesegeräte, zehn Minuten Abstand, 80 Kilometer auseinander), klassisches Signal für Badge-Sharing oder Kartenkopie
• Zeitfenster-Abweichung: Zugang außerhalb des üblichen Arbeitszeitrahmens (z.B. ein 9-bis-17-Uhr-Mitarbeitender um 2:30 Uhr morgens)
• Zonenabweichung: Erster Zugang zu einem Bereich, der normalerweise nie betreten wird, insbesondere in Kombination mit anderen Anomalien
• Frequenzanomalie: Plötzlich deutlich häufigeres Betreten eines bestimmten Bereichs (z.B. täglich in den letzten drei Wochen, zuvor nie)
• Abwesenheitsperiode + Zugang: Zugang während offizieller Urlaubszeit (wenn Urlaubskalender integriert ist)

Echter Insider vs. ungewöhnliches Verhalten: eine kritische Unterscheidung

Das ist der Punkt, den Anbieter-Marketing konsequent verwischt, und an dem viele Projekte intern scheitern.

Ein UEBA-System erkennt Abweichung vom Üblichen. Das ist nicht dasselbe wie kriminelles oder gefährliches Verhalten. Ein Mitarbeitender, der erstmals eine Nachtschicht übernimmt, zeigt dieselbe Anomalie wie jemand, der nach Schichtende zurückkommt, um etwas zu stehlen. Das System unterscheidet das nicht.

Die Konsequenz: Jede anomale Aktivität muss untersucht werden, bevor Maßnahmen ergriffen werden. Das klingt selbstverständlich, wird aber in der Praxis unter Zeitdruck falsch gemacht. Die Frage „Hat der Mitarbeitende eine Erklärung für diesen Zugang?” muss immer vor jeder Konsequenz stehen.

Was das für den Betrieb bedeutet:

Etabliere eine klare Eskalationsmatik. Ein Alert aus dem UEBA-System ist kein Beweis für Fehlverhalten, es ist ein Signal für eine Überprüfung. Der Prozess könnte so aussehen:

1. Alert liegt vor (Score über Schwellenwert X)
2. Zuständige Person im Sicherheitsmanagement prüft: Gibt es eine organisatorische Erklärung? (Vertretungsregelung, Wartungsauftrag, Sondererlaubnis)
3. Falls nein: Informationsgespräch mit Führungskraft (nicht mit Mitarbeitendem direkt)
4. Falls keine Erklärung: Eskalation nach Betriebsvereinbarung

Dieser Prozess muss schriftlich in der Betriebsvereinbarung verankert sein, die vor dem Produktivbetrieb mit dem Betriebsrat vereinbart wurde. Ohne diese Grundlage sind alle Konsequenzen arbeitsrechtlich anfechtbar.

Die ehrliche Zahl: Bei guten UEBA-Implementierungen sind ca. 80–90 Prozent der Alerts erklärbar und harmlos (Schätzwert aus Praxisberichten). Nur 10–20 Prozent führen zu Überprüfungen, die wirklich relevant sind. Das ist kein Systemversagen, das ist die Grundstatistik jedes Anomalie-Detektionssystems. Wer das nicht einplant, verbrennt sein Security-Team an irrelevanten Alerts.

BetrVG § 87 Abs. 1 Nr. 6, was vor dem Pilot passieren muss

Das ist der am häufigsten vergessene Projektschritt bei deutschen Unternehmen mit Betriebsrat.

§ 87 Abs. 1 Nr. 6 des Betriebsverfassungsgesetzes gibt dem Betriebsrat ein erzwingbares Mitbestimmungsrecht bei der Einführung und Anwendung von technischen Einrichtungen, die dazu bestimmt sind, das Verhalten oder die Leistung der Arbeitnehmer zu überwachen. Ein UEBA-System auf Zugangsdaten erfüllt dieses Tatbestandsmerkmal eindeutig, die Eignung zur Verhaltensüberwachung ist ausreichend, eine Überwachungsabsicht des Arbeitgebers ist nach Bundesarbeitsgericht-Rechtsprechung nicht erforderlich.

Was das konkret bedeutet:

1. Kein Produktivbetrieb ohne Betriebsvereinbarung. Nicht: „Wir starten mal und regeln das danach.” Wenn du das System in Betrieb nimmst, bevor eine Betriebsvereinbarung vorliegt, kann der Betriebsrat per einstweiliger Verfügung den Betrieb stoppen lassen. Das ist kein theoretisches Risiko, es gibt einschlägige Entscheidungen.

2. Was die Betriebsvereinbarung regeln muss:

   • Zweck der Auswertung (welche Anomalien werden warum gesucht)
   • Welche Daten werden verarbeitet (Badge-ID, Zone, Zeitstempel, aber keine Klarnamen ohne Trennung)
   • Wer hat Zugriff auf Alert-Daten (nur Sicherheitsbeauftragter, nicht Linienvorgesetzte)
   • Eskalationsmatik (wie werden Alerts bearbeitet, wer entscheidet über Maßnahmen)
   • Löschfristen (wann werden Baselines und Rohlog-Daten gelöscht)
   • Was passiert nicht: Leistungsbeurteilung, HR-Entscheidungen auf Basis von UEBA-Daten

3. Gleichzeitig DSGVO: Datenschutz-Folgenabschätzung.
   Ein System, das Verhaltensmuster von identifizierbaren Personen systematisch analysiert, ist nach Art. 35 DSGVO höchstwahrscheinlich DSFA-pflichtig. Das muss vor dem Produktivbetrieb dokumentiert sein.

Der Betriebsratsprozess dauert realistisch 4–12 Wochen, abhängig davon, wie konfliktbeladen das Thema im konkreten Unternehmen ist. Plane diesen Puffer aktiv ein. Unternehmen ohne Betriebsrat (unter 5 Mitarbeitenden in der Regel, oder bei Ablehnung eines Betriebsrats durch die Belegschaft) sind an dieser Stelle schneller, aber die DSGVO-Anforderungen gelten unabhängig.

Konkrete Werkzeuge, was wann passt

Für die UEBA-basierte Zugangskontroll-Auswertung gibt es drei realistische Wege:

Wazuh, wenn On-Premise und kein Budget für Lizenzen Open-Source-SIEM mit ML-basierter Anomalieerkennung. Die physischen Zugangslogs müssen per Custom Parser eingebunden werden (erfordert Linux-Systemwissen), dafür läuft alles im eigenen Rechenzentrum, kein Datentransfer nach außen, keine Lizenzkosten. Der UEBA-Reifegrad ist begrenzt: Wazuh kann regelbasierte und statistische Anomalien erkennen, aber das Verhaltens-Profiling ist weniger differenziert als bei kommerziellen Lösungen. Realistisch für IT-affine Unternehmen mit eigenem Linux-Administrator. Betriebsaufwand: ca. 4–8 Stunden pro Monat.

Microsoft Sentinel, wenn Microsoft-365-Umgebung vorhanden Cloud-native SIEM mit integrierter UEBA. Die Zugangslogs müssen über einen Custom Connector eingebunden werden (kein nativer Konnektor für physische Zugangssysteme), aber sobald die Daten fließen, ist die UEBA-Qualität deutlich besser als bei Wazuh. EU-Hosting in Frankfurt. Kosten für ein mittelständisches Unternehmen: ca. 400–800 Euro pro Monat. Besonders interessant für Unternehmen, die ohnehin in Richtung Azure-native Security gehen.

Exabeam, wenn umfassendes UEBA das Hauptziel ist Spezialisierte UEBA-Plattform mit tiefem Verhaltensprofiling und forensischer Smart Timeline. Sinnvoll für Unternehmen ab ca. 500 Mitarbeitenden, die UEBA als Kernfähigkeit brauchen, nicht als Add-on. Kosten: ab ca. 40.000 Euro Jahresvertrag. Einstieg nur über Vertriebsgespräch. Für KMU in der Regel nicht verhältnismäßig.

Spezialisierte physische Sicherheitsplattformen (Lenel, Software House, Genetec)
Einige große Hersteller physischer Zugangskontrollsysteme bieten mittlerweile eigene Analyse-Module mit eingeschränkten Anomaliefunktionen an. Diese sind oft enger integriert (kein Custom Parser nötig), aber funktional eingeschränkt gegenüber dedizierten UEBA-Lösungen. Wenn ihr bereits ein Genetec- oder Lenel-System betreibt, evaluiere zunächst die eingebauten Analyse-Module, das reduziert den Integrationsaufwand erheblich.

Zusammenfassung:

• Kein Budget, eigener IT-Admin vorhanden → Wazuh
• Microsoft-365-Umgebung, moderate Kosten → Microsoft Sentinel
• Großunternehmen, UEBA als Kernfähigkeit → Exabeam
• Vorhandenes großes physisches Zugangssystem → Erst Hersteller-Analytics evaluieren

Datenschutz und Datenhaltung

Zugangskontrolldaten sind personenbezogene Daten im Sinne der DSGVO, auch dann, wenn Klarnamen nicht direkt in der Log-Datei stehen, solange eine Zuordnung über Badge-IDs möglich ist. Das Mapping von Badge-ID auf Person macht die Daten identifizierbar, und damit gilt der volle DSGVO-Schutz.

Was das operativ bedeutet:

• Auftragsverarbeitungsvertrag (AVV): Bei Cloud-Lösungen (Sentinel, Exabeam Cloud) muss ein AVV nach Art. 28 DSGVO mit dem Anbieter abgeschlossen werden. Bei Wazuh On-Premise entfällt das, die Daten verlassen nie das Unternehmen.

• Datensparsamkeit: Das System braucht Badge-ID, Zeitstempel und Zonen-ID. Klarnamen, Fotos, biometrische Merkmale gehören nicht in den UEBA-Datenstrom, es sei denn, das System ist ausdrücklich für biometrische Auswertung eingerichtet und in der DSFA berücksichtigt.

• Löschfristen: Die DSGVO fordert keine bestimmte Frist, aber die Betriebsvereinbarung sollte klare Fristen festlegen. Üblich: Rohlogs 6–12 Monate; Anomalie-Protokolle (Alerts, Untersuchungsergebnisse) nach Abschluss der Untersuchung. Baseline-Modelle können länger gehalten werden, wenn sie keine personenbezogenen Rohdaten enthalten.

• Zweckbindung: Die Logs dürfen ausschließlich für den in der Betriebsvereinbarung definierten Zweck ausgewertet werden, Sicherheitsanomalien. Nicht für: Anwesenheitserfassung, Leistungsüberwachung, HR-Entscheidungen. Diese Zweckbindung muss technisch durchgesetzt sein (Zugriffsrechte), nicht nur dokumentiert.

• Datenhosting: Wazuh On-Premise = volle Kontrolle. Microsoft Sentinel in EU-Region Frankfurt = DSGVO-konform. Exabeam bietet EU-Datenhosting, aber der Vertrag muss explizit EU-Region konfigurieren.

Was es kostet, realistisch gerechnet

Einmalige Einrichtungskosten

Gesamter Einrichtungsaufwand: realistisch 15.000–30.000 Euro inklusive Rechts- und IT-Kosten, ohne Softwarelizenz.

Laufende Kosten (monatlich)

• Wazuh (Self-Hosted): 0 € Lizenz + ca. 100–300 € Serverkosten + 2–4 Stunden IT-Admin
• Microsoft Sentinel: ca. 400–800 €/Monat für ein mittelständisches Unternehmen (7–15 GB/Tag)
• Exabeam: ab ca. 3.300 €/Monat (40.000 € Jahresvertrag, Richtwert)

Was du dagegenrechnen kannst

Einen konkreten ROI kannst du nur dann benennen, wenn du Incidents verhinderst, die sonst eingetreten wären. Die Versicherungsbranche rechnet mit einem Durchschnittswert von 700.000 US-Dollar pro Insider-Incident (Ponemon 2023), aber das sind große Unternehmen. Für KMU sind Schäden von 50.000–200.000 Euro je Incident realistisch.

Die ehrliche Kalkulation: Wenn dein Unternehmen statistisch mit einem schweren Insider-Incident alle sieben bis zehn Jahre rechnen muss (das ist kein wissenschaftlicher Wert, aber eine konservative Planungsannahme für Unternehmen mit sensiblen Bereichen), dann sind jährliche Kosten von 5.000–10.000 Euro für proaktive Erkennung versicherungsmathematisch sinnvoll. Ohne den Incident ist es nicht messbar.

Typische Einstiegsfehler

1. Zu viele Alerts von Anfang an, und kein Prozess dahinter.
Das passiert fast immer: Das System geht live, und die ersten Wochen produzieren täglich 20–50 Alerts. Das Security-Team schaut sie sich ein paar Tage lang an, findet keinen einzigen echten Vorfall, und beginnt, die Alerts zu ignorieren. Alert Fatigue ist der häufigste Grund, warum UEBA-Projekte sechs Monate nach dem Start de facto tot sind, obwohl das System noch läuft. Lösung: Beginne mit den drei bis fünf kritischsten Szenarien (z.B. nur Impossible Travel und Zone-First-Access für hochsensible Bereiche), und erweitere erst, wenn die Triage-Rate unter 10 Alerts pro Woche liegt.

2. Keine Kontextdaten, und entsprechend viele Fehlalarme.
Ein System ohne Schichtplan-Integration erkennt nicht, dass eine Nachtschicht legitim ist. Ein System ohne Urlaubskalender-Integration markiert den Mitarbeitenden, der im Urlaub ist und trotzdem ins Büro kommt (um z.B. etwas zu holen), als Anomalie. Diese Fehlalarme sind nicht falsch, sie sind korrekte Anomalien. Aber sie sind irrelevant. Wer die Kontextdaten nicht vorab integriert, bekommt ein Alarmsystem, das nach vier Wochen niemand mehr ernst nimmt.

3. Kein Betriebsrat-Prozess, und dann Stopp durch einstweilige Verfügung.
Das ist der teuerste Fehler: ein System einführen, das Verhaltensüberwachung im Sinne von § 87 Abs. 1 Nr. 6 BetrVG ermöglicht, ohne den Betriebsrat einzubinden. Selbst wenn die Absicht harmlos ist, das Recht ist eindeutig. Das System kann bis auf Weiteres abgeschaltet werden.

4. Das System läuft, aber die Baselines werden nicht gepflegt.
Das ist der typische 12-Monats-Fehler. Ein Mitarbeitender wechselt intern in eine andere Rolle und beginnt, neue Bereiche zu betreten. Das System erkennt monatelang Anomalien bei einer Person, die keine mehr hat, weil die Baseline nie aktualisiert wurde. Wer ist zuständig, Baselines nach Stellenwechseln, Schichtänderungen oder Umstrukturierungen neu zu kalibrieren? Diese Frage muss in der Betriebsvereinbarung oder im Betriebskonzept schriftlich beantwortet sein.

Was mit der Einführung wirklich passiert, und was nicht

Die technische Einführung ist geradlinig. Was unterschätzt wird, ist die organisatorische.

Die Unsicherheit der Betriebsräte. In vielen Unternehmen sind Betriebsräte beim Thema Verhaltensüberwachung grundlegend skeptisch, zu Recht. Die Sorge ist berechtigt, dass ein System, das „Sicherheit” verspricht, als Werkzeug für Leistungsüberwachung oder Disziplinarmaßnahmen genutzt wird. Diese Sorge kann nicht wegdiskutiert werden. Sie muss durch eine Betriebsvereinbarung strukturell gelöst werden: Zugriffsrechte eingeschränkt, Zweck klar definiert, Löschfristen festgelegt. Unternehmen, die versuchen, diese Bedenken mit Argumenten zu überwältigen statt sie strukturell zu adressieren, kommen nicht ans Ziel.

Das Security-Team braucht neue Prozesse, nicht nur ein neues Tool. Ein Alert ist wertlos ohne definierten Folgeprozess. Wer bewertet Alerts? Wann? In welchem Zeitfenster? Was wird dokumentiert? Viele Teams haben nach der Einführung schlicht keinen Workflow dafür, die Alerts landen im SIEM, aber niemand ist verantwortlich für die tägliche Sichtung. Das muss vor dem Start mit konkreten Verantwortlichkeiten und Zeiterwartungen geregelt sein.

Was konkret hilft:

• Betriebsrat von Anfang an in die Auswahl einbeziehen (nicht nur informieren, sondern mitentscheiden lassen, welche Szenarien überwacht werden)
• Einen dedizierten Alert-Triage-Slot in den Wochenplan des Sicherheitsbeauftragten einbauen (30 Minuten täglich)
• Die ersten 30 Tage nach Go-live als “Probemodus” definieren: keine Maßnahmen aufgrund von Alerts, nur Dokumentation und Kalibrierung
• Nach 90 Tagen eine strukturierte Retrospektive machen: Wie viele Alerts gab es? Wie viele waren echte Treffer? Was muss am Threshold angepasst werden?

Realistischer Zeitplan mit Risikohinweisen

Realistisches Minimum: 12 Wochen bis zum ersten kontrollierten Pilotbetrieb, nur wenn der Betriebsrat kooperiert und die Log-Integration problemlos klappt.

Häufige Einwände, und was dahintersteckt

„Wir haben schon Alarm-Regeln im Zugangssystem.”
Zugangssystem-Alarmregeln sind statisch: „Alert bei Zugang zwischen 22 und 6 Uhr” oder „Alert bei 5 Fehlversuchen hintereinander.” Das ist hilfreich, aber es erkennt nicht das subtile Muster: ein Mitarbeitender, der immer um 15:30 Uhr geht und plötzlich 19-Uhr-Zutritte hat, ohne den Threshold zu überschreiten. UEBA erkennt genau diese Abweichungen vom persönlichen Normalverhalten, die keine Regel trifft.

„Wir sind zu klein für so etwas.”
Das kommt auf den Maßstab an. Ein Unternehmen mit 50 Mitarbeitenden und einem Serverraum, einem Tresorraum und einem Lager, drei wirklich sensible Zonen, kann mit Wazuh On-Premise ein funktionierendes Grundsystem für null Lizenzkosten betreiben. Das Argument „zu klein” passt eher für Exabeam (ab 500 Mitarbeitende sinnvoll) als für den gesamten Use Case.

„Was, wenn das System falsch liegt und wir einen unschuldigen Mitarbeitenden verdächtigen?”
Das ist keine Schwäche des Systems, die man unterdrücken sollte, es ist der wichtigste Designpunkt. Das System markiert Abweichungen, nicht Schuld. Wer den Prozess so aufbaut, dass ein Alert automatisch zu einer Maßnahme führt, hat den Fehler gemacht, nicht das System. Die Antwort auf diesen Einwand ist: Der Eskalationsprozess, der in der Betriebsvereinbarung steht, schützt genau davor. Kein Alert führt ohne menschliche Überprüfung zu Konsequenzen.

Woran du merkst, dass das zu dir passt

• Ihr habt physische Zugangskontrolle für sensible Zonen, Serverräume, Tresorräume, Produktionsbereiche, Lager mit hochwertigem Inventar, und diese Zonen sind tatsächlich regelmäßig zugänglich (nicht nur bei Spezialanlässen)
• Zugangslogs existieren technisch, werden aber heute ausschließlich reaktiv ausgewertet (nach Vorfällen)
• Ihr habt einen Betriebsrat oder seid bereit, die DSGVO-Anforderungen selbst zu erfüllen, beide Szenarien sind handhabbar, aber sie müssen aktiv verwaltet werden
• Eine Person hat klare Zuständigkeit für Sicherheitsmanagement und könnte täglich 30 Minuten in Alert-Triage investieren
• Ihr betreibt Bereiche mit echtem Risikopotenzial: Chemikalien, Serverinfrastruktur, hochwertige Güter, vertrauliche Informationen in physischer Form

Wann es sich (noch) nicht lohnt, vier harte Ausschlusskriterien:

1. Unter 30 Mitarbeitenden oder unter drei echten Hochrisikozonen. Der Aufwand für Betriebsvereinbarung, DSFA, Log-Integration und laufendes Alert-Management ist bei kleinen Strukturen nicht verhältnismäßig. Eine kluge Kombination aus Schlüsselmanagement, RFID-Protokoll und manuellem Wochenbericht reicht dann völlig.

2. Zugangssystem gibt keine strukturierten Logs aus. Ältere Systeme (vor 2010) speichern Logs teilweise nur lokal und nicht exportierbar, oder nur als proprietäres Format ohne öffentliche Schnittstelle. Ohne exportierbare Logs gibt es keine Datenbasis. In diesem Fall ist der sinnvollste erste Schritt ein Systemupgrade, nicht UEBA.

3. Kein Betriebsrat-Prozess und kein Datenschutzbeauftragter verfügbar. Das Projekt ist nur in Abhängigkeit von einer rechtlich sauberen Grundlage sinnvoll durchführbar. Wer hofft, das „hinterher zu regeln”, riskiert den Stopp durch Gericht oder Betriebsrat.

4. Das Security-Team hat keine Kapazität für Alert-Triage. Ein UEBA-System, das Alerts produziert und niemanden hat, der sie täglich sichtet, ist nach spätestens vier Wochen operativ wertlos. Besser kein System als ein ignoriertes System, letzteres erzeugt das gefährliche Gefühl, geschützt zu sein, ohne es zu sein.

Das kannst du heute noch tun

Bevor du ein Tool evaluierst: Schaue in deinen aktuellen Zugangskontrollanlagen nach, ob ein CSV- oder Syslog-Export der Logs möglich ist. Das ist die technische Grundvoraussetzung für alles Weitere.

Danach: Exportiere eine Woche Logs (ca. 30.000–50.000 Einträge) und lade sie in ein einfaches Analysetool wie Julius AI oder direkt in ChatGPT (wenn keine personenbezogenen Daten im Export enthalten sind, also nur Badge-IDs, keine Klarnamen). Stelle die folgende Frage:

Das gibt dir innerhalb von 30 Minuten ein erstes Bild: Welche Muster liegen in deinen Daten? Wie viele relevante Anomalien gibt es tatsächlich? Das ist nützlich, bevor du irgendein System evaluierst, und komplett kostenlos.

Quellen & Methodik

• Insider Incident Erkennungszeit (200+ Tage Median): Verizon, „Data Breach Investigations Report 2024” (dbir.verizon.com, abgerufen April 2026). Verizon DBIR ist das meistzitierte unabhängige Datenmaterial für Breach-Statistiken.
• Durchschnittlicher Insider-Incident-Schaden (~700.000 USD): Ponemon Institute / DTEX Systems, „2023 Cost of Insider Risks Global Report” (dtexsystems.com/resources, 2023). Ponemon-Studien sind von Hersteller-Sponsoring beeinflusst, die Absolutzahlen sind nach oben verzerrt, die Größenordnung gilt als zuverlässig.
• BetrVG § 87 Abs. 1 Nr. 6: Betriebsverfassungsgesetz in der gültigen Fassung; Tatbestandsmerkmal „Eignung zur Überwachung” ausreichend (BAG-Rechtsprechung). Quellzusammenfassung: jes-beratung.de/mitbestimmungstatbestaende/87-1-6/ (abgerufen April 2026).
• UEBA Baseline-Periode 60–90 Tage: Security Boulevard, allgemeine Praxisempfehlung für UEBA-Implementierungen; bestätigt durch Exabeam-Implementierungsdokumentation (exabeam.com, abgerufen April 2026).
• Alert Fatigue bei UEBA: Exabeam, „Behavior Anomaly Detection: Techniques and Best Practices” (exabeam.com, abgerufen April 2026): „Without proper tuning, SOC teams drown in alerts, causing critical threats to be overlooked.”
• Microsoft Sentinel Preise: Microsoft Security Pricing (microsoft.com/en-us/security/pricing/microsoft-sentinel, abgerufen April 2026). €2,76/GB für Western Europe Pay-as-you-go.
• Art. 35 DSGVO (DSFA-Pflicht bei Verhaltensanalyse): Datenschutz-Grundverordnung in der aktuell gültigen Fassung; Orientierungshilfe der DSK „Muss-Liste” für DSFA-pflichtige Verarbeitungen.

Du willst wissen, ob dein bestehendes Zugangskontrollsystem die nötigen Log-Daten liefert und wie ein Betriebsrat-konformes Konzept aussieht? Meld dich, das besprechen wir in einem kurzen Gespräch.