Grundregel: Sicherheitsrelevante Ereignisse werden zweckgebunden, vollständig genug, zeitlich zuordenbar und gegen Manipulation geschützt protokolliert, ausgewertet und bei Handlungsbedarf fristgerecht behandelt.
Wirksamkeitsgrenze: Ein aktiviertes Log, ein SIEM-Agent, ein Dashboard oder eine Alarmregel belegt allein keine wirksame Überwachung. Erforderlich sind nachgewiesene Quellenabdeckung, Zeitqualität, Integrität, Erkennungslogik, Alarmzustellung, qualifizierte Bewertung und dokumentierte Reaktion.
Datenschutzgrenze: Diese Seite schafft keine eigenständige Rechtsgrundlage für Beschäftigten- oder Verhaltensüberwachung. Zweck, Erforderlichkeit, Transparenz, Verhältnismäßigkeit, Aufbewahrung, Auswertung und gegebenenfalls Mitbestimmung müssen vor der Verarbeitung bestätigt werden.
TISAX-Hinweis: Im Reiter „Informationssicherheit“ der ISA-Selbsteinschätzung sind alle 46 Fragen umzusetzen und zu bewerten. Einzelne Fragen werden nicht wie Controls in einer ISO-27001-SoA als „nicht anwendbar“ ausgeschlossen.
Feld
Wert
Dokumenten-ID
ISMS-MA-04-13
Dokumentenart
Richtlinie und Verfahren für Protokollierung, Überwachung und Zeitsynchronisation
Wiki.js-Pfad
/ISMS/04-Sicherheitsregelungen/Protokollierung-und-Ueberwachung
Verantwortlich
IT-Leitung und Informationssicherheit
Fachlich geprüft durch
IT-/OT-Betrieb, System- und Service Owner, Datenschutz, Personal, Recht/Compliance, Incident Management, BCM und TISAX-Koordination
Freigabe durch
Geschäftsführung
Status
Entwurf – Logquellen, Abdeckung, Aufbewahrung, Alarmregeln, Betrieb und Wirksamkeit nicht bestätigt
Version
0.1
Stand
23.07.2026
Nächste Prüfung
Mindestens jährlich sowie bei wesentlichen System-, Bedrohungs-, Rechts-, Provider- oder Architekturänderungen
Schutzklasse
Intern; Rohlogs, Erkennungslogik und Forensikdaten regelmäßig Vertraulich oder strenger
ISO-Bezug
ISO/IEC 27001:2022, insbesondere Annex A 5.7, 5.24 bis 5.28, 5.31 bis 5.34, 8.2, 8.5, 8.9, 8.15 bis 8.17 und 8.20
VDA-ISA-Bezug
ISA 6.0.3, insbesondere Kapitel 5.2 „Betriebssicherheit“ sowie verbundene Fragen zu Zugriff, Incident Management, Lieferanten und Compliance
Diese Regelung legt fest:
welche Ereignisse und Systeme protokolliert werden,
wie Logquellen, Formate, Zeit, Transport, Speicherung und Integrität gesteuert werden,
wie Sicherheits- und Betriebsaktivitäten überwacht werden,
wie Erkennungsregeln, Alarme, Triage und Eskalationen funktionieren,
wie Datenschutz, Vertraulichkeit und Zugriff auf Protokolle geschützt werden,
wie Logs für Vorfälle, Audits, Nachweise und Verbesserungen genutzt werden,
welche Prüfungen und Kennzahlen erforderlich sind.
Ziel ist, Sicherheitsereignisse rechtzeitig zu erkennen, Sachverhalte nachvollziehbar zu machen und die Wirksamkeit von Kontrollen belastbar zu beurteilen.
Die Regelung gilt im ISMS-Geltungsbereich für:
Identitäts-, Berechtigungs- und Verzeichnisdienste,
Endgeräte, Server, Anwendungen und Datenbanken,
Netzwerk-, Kommunikations- und Sicherheitskomponenten,
Cloud-, SaaS-, Plattform- und Providerdienste,
Produktions-, OT-, IoT- und Gebäudesysteme,
Entwicklungs-, Build-, Test- und Deploymentumgebungen,
Backup-, Wiederherstellungs- und Notfallsysteme,
physische Zutritts-, Alarm- und gegebenenfalls Videosysteme,
administrative, automatisierte und externe Aktivitäten.
Systeme, die technisch nicht ausreichend protokollieren können, werden als Lücke oder Ausnahme behandelt und nicht stillschweigend als abgedeckt ausgewiesen.
Diese Seite regelt Protokollierung und Überwachung. Sie ersetzt nicht:
den Incident Response ,
das Asset-, Identitäts-, Netzwerk-, Schwachstellen- oder Change-Management,
fachliche Leistungs-, Qualitäts- oder Finanzkontrollen,
eine Datenschutz-Folgenabschätzung, Betriebsvereinbarung oder Rechtsprüfung,
die forensische Einzelfallplanung in einem konkreten Vorfall.
Protokollierung, Monitoring, Messung, Audit und Managementkennzahlen sind verbunden, aber nicht identisch.
Begriff
Bedeutung
Logereignis
durch eine Quelle erzeugter Datensatz über Zustand, Aktivität oder Änderung
Logquelle
System, Dienst, Gerät, Anwendung oder Sensor, der Ereignisse erzeugt
Monitoring
laufende Beobachtung technischer oder sicherheitsbezogener Zustände
Alarm
aufgrund einer Regel oder Schwelle erzeugter Handlungsbedarf
Use Case
dokumentierter Erkennungsfall mit Datenquellen, Logik, Schwere und Reaktion
SIEM
Plattform zur Sammlung, Normalisierung, Korrelation und Auswertung von Ereignissen
SOC
organisatorische Funktion für Sicherheitsüberwachung und Reaktion
Baseline
bestätigter Referenzzustand oder erwartbares Verhalten
Triage
erste Bewertung, Priorisierung und Zuweisung eines Alarms
Rohlog
unveränderte ursprüngliche Ereignisaufzeichnung
Normalisierung
Überführung verschiedener Formate in ein einheitliches Schema
Korrelation
Verknüpfung mehrerer Ereignisse zu einem bewertbaren Zusammenhang
Aufbewahrung
festgelegte Dauer, in der Daten verfügbar und geschützt bleiben
Beweiskette
nachvollziehbare Sicherung, Übergabe, Zugriff und Integrität eines Nachweises
Protokollierung benötigt einen bestätigten Zweck und verantwortliche Owner.
Umfang und Detailtiefe richten sich nach Risiko, Kritikalität und Anforderungen.
Sicherheitsrelevante Administrator- und Kontrolländerungen werden besonders nachvollziehbar gemacht.
Ereignisse erhalten ausreichend genaue und verlässliche Zeitbezüge.
Logs werden geschützt übertragen, gespeichert und vor unbemerkter Veränderung bewahrt.
Geheimnisse und unnötige Inhaltsdaten werden nicht in Logs geschrieben.
Zugriff auf Logs erfolgt nach Need-to-know und Funktionstrennung.
Alarmregeln besitzen Owner, Reaktion, Test und regelmäßigen Review.
Ausfall von Logquellen, Sensoren, Zeit oder Alarmwegen wird selbst erkannt.
Datenschutz und Verhältnismäßigkeit werden bereits bei der Loggestaltung berücksichtigt.
Aufbewahrung wird begründet und nicht pauschal unbegrenzt festgelegt.
Unbekannte Abdeckung wird sichtbar als Lücke behandelt.
Rolle
Verantwortung
Geschäftsführung
Zielrahmen, wesentliche Risiken, Ressourcen und Konflikte entscheiden
IT-Leitung
Plattformen, Betrieb, Verfügbarkeit, Kapazität und Verantwortungen sicherstellen
Informationssicherheit/SOC
Use Cases, Triage, Detection, Eskalation, Hunting und Wirksamkeit steuern
System-/Service Owner
Loganforderungen, Kritikalität, Quellfunktion und fachliche Kontakte bestätigen
IT-/OT-Betrieb
Quellen anbinden, konfigurieren, überwachen, sichern und Fehler beheben
Netzwerkverantwortung
Netzwerk-, DNS-, VPN-, Firewall- und Kommunikationslogs bereitstellen
Identitätsverantwortung
Authentisierungs-, Berechtigungs- und privilegierte Ereignisse steuern
Entwicklung/Application Owner
sichere Anwendungslogs, Korrelation und Fehlerbehandlung umsetzen
Incident Management
Alarme übernehmen, Vorfälle koordinieren und Beweise sichern
Datenschutz
Zweck, Datenumfang, Transparenz, Aufbewahrung und Betroffenenrechte prüfen
Personal/Recht/Compliance
Beschäftigtenbezug, Mitbestimmung, Rechts- und Vertragsanforderungen prüfen
Einkauf/Provider-Owner
Providerlogs, SLA, Zugriff, Export, Aufbewahrung und Exit vereinbaren
Audit
Angemessenheit und Wirksamkeit unabhängig prüfen
Alle relevanten Quellen und Überwachungsfälle werden in einem Register geführt.
Feld
Inhalt
Quellen-ID
eindeutige Referenz
Asset/Service
System, Dienst, Gerät oder Plattform
Owner/Betrieb
fachliche und technische Verantwortung
Kritikalität/Schutzbedarf
Bezug zu Asset- und Risikoanalyse
Ereigniskategorien
Authentisierung, Änderung, Zugriff, Fehler, Sicherheitsereignis usw.
Format/Schnittstelle
nativ, Agent, Syslog, API, Cloudexport oder sonstige Methode
Zeitquelle
Synchronisationsweg, Zone und erwartete Genauigkeit
Transport/Schutz
Authentisierung, Verschlüsselung und Integrität
Zielsystem
Sammler, SIEM, Archiv oder Providerplattform
Aufbewahrung
Online-, Such-, Archiv- und Löschfrist
Zugriff
berechtigte Rollen und Funktionstrennung
Use Cases
verknüpfte Regeln, Alarme und Reaktionswege
Abdeckung/Gesundheit
vollständig, teilweise, gestört, nicht angebunden
Review
letzte Prüfung, Test und offene Punkte
Anforderungen werden abgeleitet aus:
Informations- und Asset-Schutzbedarf,
Geschäftsprozesskritikalität und Wiederanlaufzielen,
Risikoregister und Bedrohungsinformationen,
ISO-27001-/SoA-Controls und VDA-ISA-Fragen,
Kunden-, Rechts-, Vertrags- und Datenschutzanforderungen,
Incident-, Forensik- und Beweisbedürfnissen,
Betriebs-, Support-, Qualitäts- und Abrechnungszwecken,
Hersteller- und Providerfähigkeiten,
Lessons Learned aus Vorfällen, Audits und Tests.
Kategorie
typische Ereignisse
Identität
Kontoerstellung, Sperrung, Rollenwechsel, Authentisierung, MFA und Passwortänderung
Berechtigung
Rechtevergabe, Entzug, Gruppenänderung, Privilegienerhöhung
Administration
privilegierte Anmeldung, Konfigurations-, Policy- und Kontrolländerung
Zugriff
Zugriff auf besonders schutzbedürftige Daten, Systeme oder Funktionen
System
Start, Stopp, Fehler, Ressourcenmangel, Dienst- und Prozessstatus
Netzwerk
Verbindung, Regelentscheidung, VPN, DNS, Proxy, Routing und Segmentgrenze
Anwendung
fachliche Transaktion, Sicherheitsentscheidung, Fehler und Schnittstellenaktivität
Daten
Export, Massenabfrage, Löschung, Freigabe, Übertragung und Integritätsänderung
Sicherheit
Malware, Schwachstelle, EDR, IDS/IPS, DLP, Filter und Quarantäne
Entwicklung
Repository, Pipeline, Build, Release, Secret- und Artefaktaktivität
Physisch
Zutritt, Alarm, Türzustand und Besuchsvorgang nach bestätigtem Zweck
Verfügbarkeit
Ausfall, Backup, Restore, Failover, Kapazität und Überwachungsausfall
Soweit technisch und fachlich sinnvoll enthält ein Ereignis:
eindeutige Quellen- und Assetreferenz,
Datum, Uhrzeit, Zeitzone und Zeitqualität,
Ereignistyp und Ergebnis,
handelnde Identität, Rolle oder technische Instanz,
Quell- und Zielbezug,
betroffene Ressource oder Funktion,
eindeutige Session-, Transaktions-, Request- oder Korrelations-ID,
Sicherheits-, Fehler- oder Schwereinformation,
Integritäts- und Herkunftsbezug,
Anwendungsversion oder Konfigurationsstand, soweit für Auswertung nötig.
Passwörter, vollständige Tokens, private Schlüssel und unnötige Inhaltsdaten gehören nicht in Logs.
Erfasst werden nach Risiko:
erfolgreiche und fehlgeschlagene Anmeldungen,
MFA-Anforderungen, Ablehnungen und Änderungen,
Kontoerstellung, Sperrung, Entsperrung und Löschung,
Passwort-, Schlüssel-, Zertifikats- und Recoveryänderungen,
ungewöhnliche Orte, Geräte, Zeiten oder Anmeldemuster,
Federation-, SSO- und Verzeichnisfehler,
Notfall-, Service- und technische Kontennutzung.
Anmeldedaten werden nicht so protokolliert, dass Geheimnisse offengelegt werden.
Besonders überwacht werden:
Zuweisung und Entzug privilegierter Rollen,
Änderungen kritischer Gruppen und Funktionstrennungen,
Nutzung von Administrator-, Root-, Notfall- und Break-Glass-Konten,
Deaktivierung oder Umgehung von Sicherheitskontrollen,
Änderungen an Logging, Zeit, Backup, EDR, Firewall oder Identität,
Massenaktionen, Exporte und ungewöhnliche administrative Werkzeuge,
Zugriff auf Secrets, Schlüssel, Zertifikate und besonders geschützte Logs.
Endpunktlogs können umfassen:
Betriebssystem-, Anmelde- und Geräteereignisse,
Endpoint-Schutz, Malware, Quarantäne und Isolation,
Softwareinstallation, Dienst- und Prozessänderungen,
Wechseldatenträger und Geräteanschlüsse,
lokale Privilegien- und Sicherheitsrichtlinienänderungen,
Verschlüsselungs-, Firewall- und Managementstatus,
Datenabfluss- oder ungewöhnliche Kommunikationsereignisse.
Abdeckung, Offlinezeiten und lokale Pufferung werden berücksichtigt.
Für Server und zentrale Dienste werden nach Risiko erfasst:
System-, Dienst-, Kernel- und Ressourcenereignisse,
Authentisierung und privilegierte Aktionen,
Konfigurations-, Patch- und Softwareänderungen,
Datei-, Objekt- oder Registryänderungen an kritischen Bereichen,
Backup-, Restore-, Replikations- und Clusterereignisse,
Fehler, Abstürze, Kapazitäts- und Verfügbarkeitszustände,
Sicherheitsagent-, Logsammler- und Zeitquellenstatus.
Anwendungslogs werden so gestaltet, dass:
sicherheitsrelevante fachliche Aktionen nachvollziehbar sind,
Identität, Session und Transaktion korreliert werden können,
Authentisierungs- und Autorisierungsentscheidungen sichtbar sind,
Validierungs-, Integritäts- und Schnittstellenfehler erkennbar sind,
privilegierte Konfigurations- und Stammdatenänderungen nachvollziehbar sind,
Fehler keine Geheimnisse oder unnötigen personenbezogenen Inhalte offenlegen,
Produktionsdiagnose nicht dauerhaft in übermäßig detailliertem Debug-Modus erfolgt.
Nach Risiko werden protokolliert:
privilegierte und direkte Datenbankanmeldungen,
Rollen-, Rechte-, Schema- und Konfigurationsänderungen,
Zugriff auf besonders schutzbedürftige Tabellen oder Sammlungen,
Massenabfragen, Exporte, Löschungen und ungewöhnliche Datenmengen,
Backup, Restore, Replikation und Integritätsfehler,
fehlgeschlagene oder blockierte Zugriffsversuche.
Vollständige Abfrageinhalte werden nur protokolliert, wenn Zweck und Datenschutz dies tragen.
Risikobasiert einbezogen werden:
Firewall-, Proxy-, DNS-, VPN-, WLAN- und NAC-Ereignisse,
Routing-, Switching- und Konfigurationsänderungen,
erlaubte und blockierte Verbindungen an relevanten Grenzen,
Fernwartungs- und Providerzugänge,
ungewöhnliche Ziele, Protokolle, Länder, Mengen und Zeiten,
IDS/IPS-, NDR-, DDoS- und Datenabflusserkenntnisse,
Sensor-, Zeit-, Kapazitäts- und Verfügbarkeitszustände.
Einzelheiten enthält Netzwerke und Kommunikation .
Vor Nutzung werden geprüft:
verfügbare Audit-, Admin-, Zugriffs-, Daten- und Sicherheitslogs,
Mandanten-, Konto-, Subscription- und Regionsabdeckung,
Aktivierung, Lizenz- und Aufbewahrungsbedingungen,
Export, API, Normalisierung und Verzögerung,
Providerzugriff, Unterauftragnehmer und Supportereignisse,
unveränderbare oder unabhängige Sicherung kritischer Logs,
Abschaltung, Kontosperre, Export und Exit.
Provider-Dashboards ohne kontrollierten Export oder Zugriff können im Vorfall unzureichend sein.
Je nach Risiko werden erfasst:
Versand, Zustellung, Weiterleitung und administrative Änderungen,
Phishing-, Malware-, Spam- und Quarantäneentscheidungen,
externe Freigaben, Gastkonten, Links und Berechtigungsänderungen,
Webfilter-, Download-, Upload- und Proxyereignisse,
Regeländerungen und Freigaben aus Quarantäne,
ungewöhnliche Massenaktivität, Weiterleitung oder Anmeldeorte.
Inhaltsprotokollierung wird besonders auf Erforderlichkeit und Datenschutz geprüft.
Einbezogen werden nach Risiko:
Repository-, Branch-, Merge- und Rechteänderungen,
Build-, Pipeline-, Artefakt- und Signaturereignisse,
Secret-, Komponenten- und Schwachstellenfunde,
Freigaben, Releases, Rollbacks und Deploymentziele,
Änderungen an CI/CD, Runnern, Variablen und Schutzregeln,
direkte Produktivänderungen und Notfallreleases.
OT-Protokollierung berücksichtigt:
Verfügbarkeit und Anlagenrisiko,
eingeschränkte Speicher- und Exportfähigkeiten,
Steuerungs-, Parameter-, Rezept- und Firmwareänderungen,
Benutzer-, Wartungs- und Fernzugriffe,
Sicherheits-, Prozess- und Kommunikationsanomalien,
Zeitsynchronisation und proprietäre Formate,
passive Erfassung, wenn aktive Maßnahmen den Betrieb gefährden könnten.
Fehlende technische Fähigkeiten werden durch Segmentierung, Gateways, externe Sensorik oder organisatorische Nachweise kompensiert.
Erfasst werden:
Sicherungsstart, -ende, Umfang und Ergebnis,
Fehler, Auslassungen und ungewöhnliche Änderungen,
Löschung, Aufbewahrung und Unveränderbarkeitsstatus,
Restore, Test, Ergebnis und Datenkonsistenz,
privilegierte Zugriffe und Konfigurationsänderungen,
Replikation, Medienwechsel und externe Transporte,
Ausfall der Überwachung oder Berichtserzeugung.
Zutritts-, Alarm- und gegebenenfalls Videodaten werden nur im bestätigten Umfang verarbeitet.
Zu prüfen sind:
Sicherheitszweck und betroffene Bereiche,
Rollen, Zugriffe und Auswertungsbefugnisse,
Zeitqualität und Korrelation mit anderen Ereignissen,
Transparenz, Kennzeichnung und Betroffenenrechte,
Aufbewahrung, Sperrung und Löschung,
Ermittlungs-, Export- und Beweissicherungsverfahren,
besondere Anforderungen an Beschäftigten- und Besucherbezug.
Debug-Logging ist in Produktion standardmäßig begrenzt und zeitlich kontrolliert.
Stack Traces, Dumps und Traces können Quellcode, Pfade, Identitäten oder Inhalte enthalten und werden geschützt.
Temporär erhöhte Logstufen benötigen Zweck, Owner, Zeitraum und Rücksetzung.
Fehlerdaten werden vor Weitergabe an Hersteller oder Support klassifiziert und minimiert.
Diagnosekopien werden nach Abschluss kontrolliert gelöscht oder aufbewahrt.
Vor Einführung oder Änderung werden geprüft:
konkreter Zweck und erforderliche Datenfelder,
Personen- und Beschäftigtenbezug,
Rechtsgrundlage und gegebenenfalls Mitbestimmung,
Transparenz und Informationspflichten,
Zugriff, Profilbildung und automatisierte Bewertung,
Aufbewahrung, Sperrung, Löschung und Betroffenenrechte,
Übermittlung an Provider oder Drittländer,
mildere und datensparsamere Alternativen.
IP-Adressen, Benutzerkennungen, Gerätebezüge und Verhaltensmuster können personenbezogen sein.
Logs enthalten grundsätzlich nicht:
Klartextpasswörter,
private Schlüssel oder vollständige Recoverycodes,
vollständige Session-, API- oder Zugangstokens,
unnötige Nachrichten-, Dokument- oder Formularinhalte,
vollständige Zahlungs- oder besondere personenbezogene Daten,
produktive Geheimnisse in Stack Traces, URLs oder Kommandozeilen,
unkontrollierte Speicherabbilder.
Wenn solche Daten technisch unvermeidbar sind, werden Maskierung, Zugriff, Verschlüsselung, Aufbewahrung und Fehlerbehebung besonders gesteuert.
Eine dokumentierte Zeithierarchie legt fest:
freigegebene interne und externe Zeitquellen,
primäre und alternative Quellen,
Vertrauens- und Authentisierungsanforderungen,
Netz- und Sicherheitszonen,
zulässige Abweichungen nach Systemklasse,
Zeitzone und Umgang mit Sommerzeit,
Systeme, die nicht ausreichend synchronisiert werden können,
Owner, Monitoring und Störungsbehandlung.
Relevante Systeme synchronisieren regelmäßig mit freigegebenen Quellen.
Änderungen an Zeit, Zone und Quelle werden protokolliert.
Abweichungen, Sprünge und Ausfälle lösen risikobasierte Alarme aus.
Virtuelle, Cloud-, mobile, OT- und isolierte Systeme werden ausdrücklich berücksichtigt.
Ereignisse aus nicht synchronisierten Quellen werden mit Unsicherheit gekennzeichnet.
Forensische und rechtliche Anforderungen an Zeitnachweise werden berücksichtigt.
Quellen:
erzeugen die festgelegten Ereignisse in ausreichender Qualität,
verwenden eindeutige Quellen- und Zeitinformationen,
puffern bei Verbindungsstörung risikobasiert lokal,
verhindern unkontrollierten Speicherverbrauch,
melden Verlust, Rotation, Überlauf oder Deaktivierung,
setzen nach Wiederverbindung kontrolliert fort,
schützen lokale Logs gegen unbefugte Einsicht und Änderung.
Logs werden:
über authentisierte und angemessen verschlüsselte Wege übertragen,
nicht über unnötig öffentliche oder unkontrollierte Netze gesendet,
gegen Spoofing, Wiederholung und Quellenverwechslung geschützt,
bei Unterbrechung gepuffert und kontrolliert nachgeliefert,
auf Vollständigkeit, Sequenz und Fehler überwacht,
ohne Offenlegung von Secrets in Transportkonfigurationen angebunden.
Bei zentraler Sammlung werden:
Quelle und Rohereignis erhalten,
Parser, Schema und Feldzuordnung versioniert,
Zeitzone, Zeichensatz und Format vereinheitlicht,
Fehler, verworfene Ereignisse und unbekannte Felder sichtbar gemacht,
Duplikate und Reihenfolge kontrolliert behandelt,
Normalisierung gegen repräsentative Ereignisse getestet,
Änderungen auf Use Cases und Abfragen bewertet.
Schutzmaßnahmen können umfassen:
eingeschränkte Schreib-, Änderungs- und Löschrechte,
zentrale oder getrennte Speicherung,
unveränderbare oder manipulationsanzeigende Ablage,
Hashes, Signaturen oder Verkettung nach Bedarf,
administrative Funktionstrennung,
Protokollierung des Zugriffs auf Logs,
Konfigurations- und Löschalarme,
unabhängige Sicherung kritischer Nachweise.
Unveränderbarkeit wird praktisch getestet und nicht nur aus einer Produktbezeichnung abgeleitet.
Die Logging-Architektur dokumentiert:
Quellen, Sammler, Broker, SIEM, Data Lake und Archive,
Sicherheitszonen, Mandanten und Vertrauensgrenzen,
Datenflüsse, Verschlüsselung und Schlüssel,
Hochverfügbarkeit, Kapazität und Abhängigkeiten,
Such-, Analyse-, Backup- und Wiederherstellungswege,
Provider- und Administratorzugriffe,
Löschung, Export, Exit und Notbetrieb.
Aufbewahrungsfristen werden je Kategorie begründet aus:
Erkennungs- und Untersuchungsbedarf,
typischer Entdeckungsdauer,
Rechts-, Vertrags-, Kunden- und Auditvorgaben,
Datenschutz und Speicherbegrenzung,
Kritikalität und Beweiswert,
technischer Verfügbarkeit, Kosten und Risiko.
Online-Suche, kostengünstiges Archiv und rechtliche Aufbewahrung können unterschiedliche Zeiträume besitzen. Konkrete Fristen sind vor Freigabe festzulegen.
Logs werden nach Ablauf kontrolliert gelöscht oder anonymisiert.
Löschung berücksichtigt Kopien, Archive, Exporte, Tickets und Providerplattformen.
Beweissicherung oder rechtliche Sperre wird dokumentiert und zeitlich überprüft.
Löschfunktionen und Automatisierungen werden getestet.
Vorzeitige, massenhafte oder ungewöhnliche Löschung wird erkannt.
Außerbetriebnahme einer Quelle schließt die geregelte Behandlung vorhandener Logs ein.
Zugriff auf Logs:
erfolgt nach Rolle, Need-to-know und Zweck,
trennt Administration, Analyse, Audit und Löschung,
verwendet starke Authentisierung für privilegierte Funktionen,
wird regelmäßig überprüft,
wird selbst protokolliert und auf Missbrauch überwacht,
begrenzt Export, Download und Weitergabe,
wird bei Rollenwechsel, Austritt und Providerende entzogen.
Abfragen und Dashboards werden entsprechend Schutzbedarf freigegeben.
Große Exporte oder Rohlogdownloads werden besonders begrenzt.
Exporte erhalten Klassifizierung, Empfänger, Zweck, Aufbewahrung und Löschung.
Analysewerkzeuge, Notebooks, KI- oder Drittanbieterdienste werden vor Nutzung freigegeben.
Suchhistorien und gespeicherte Abfragen können sensible Erkenntnisse enthalten.
Vorfalls- und Auditexporte werden nachvollziehbar referenziert.
Vor produktiver Nutzung werden geprüft:
Mandanten- und Rollenmodell,
Quellabdeckung und Datenqualität,
Erkennungs-, Alarm- und Ticketintegration,
Verschlüsselung, Schlüssel und Providerzugriff,
Kapazität, Kosten, Drosselung und Datenverlust,
Verfügbarkeit, Backup, Restore und Notbetrieb,
Aufbewahrung, Löschung, Export und Exit,
sichere Administration und Änderungen.
Ein beschafftes SIEM gilt erst nach nachgewiesener Anbindung und Betriebsfähigkeit als umgesetzt.
Jeder Use Case enthält:
Feld
Inhalt
Use-Case-ID/Titel
eindeutige Referenz
Ziel/Bedrohung
zu erkennendes Verhalten oder Kontrollversagen
Risiko/Asset
betroffene Risiken, Werte und Kritikalität
Datenquellen
erforderliche Logs, Felder und Abdeckung
Logik
Korrelation, Schwellen, Sequenz und Ausnahmen
Schwere
Einstufung und Begründung
Owner
fachlich, technisch und operativ Verantwortliche
Triage
Prüfschritte und benötigter Kontext
Reaktion
Ticket, Eskalation, Eindämmung und Kommunikation
Test
positive, negative und Grenzfälle
Kennzahlen
Volumen, Qualität, Fehlalarme und Reaktionszeit
Review
letzte Änderung, Wirksamkeit und nächster Termin
Abhängig von Risiko werden Use Cases unter anderem entwickelt für:
Kontoübernahme, Brute Force und MFA-Missbrauch,
Privilegienerhöhung und kritische Rollenänderung,
deaktivierte oder manipulierte Sicherheitskontrollen,
ungewöhnliche Administrator- und Servicekontennutzung,
Malware, Ransomware und laterale Bewegung,
Datenabfluss, Massenexport und unzulässige Freigabe,
ungewöhnliche Fernzugriffe und Lieferantenaktivitäten,
Internetexposition, Scan und Ausnutzung,
Konfigurations-, Firewall-, Backup- und Löschänderungen,
Ausfall von Logquellen, Sensoren oder Zeit,
ungewöhnliche Cloud-, E-Mail-, Web- und OT-Aktivitäten.
Bedrohungsinformationen liefern:
relevante Akteure, Taktiken, Techniken und Verfahren,
Indicators und Suchhypothesen,
betroffene Technologien und Assets,
Prioritäten für Regeln und Hunting,
Hinweise auf Umgehung und Fehlalarme.
Indicators werden nicht ungeprüft dauerhaft blockiert oder alarmiert; Kontext, Qualität, Gültigkeit und Auswirkungen werden bewertet.
Baselines werden:
aus bestätigten Normalzuständen und Geschäftsprozessen abgeleitet,
nach Nutzergruppe, System, Zeit, Standort und Saison differenziert,
gegen neue oder seltene legitime Aktivitäten geprüft,
bei Änderungen kontrolliert aktualisiert,
nicht allein aufgrund selbstlernender Herstellerlogik als korrekt angenommen,
auf Verzerrung, Fehlalarme und blinde Flecken überwacht.
Stufe
Beispielwirkung
erwartete Behandlung
Kritisch
laufender erheblicher Angriff, Datenabfluss oder Ausfall kritischer Kontrolle
sofortige Triage und Eskalation
Hoch
wahrscheinlicher Sicherheitsvorfall mit wesentlichem Risiko
priorisierte Triage innerhalb bestätigter Reaktionszeit
Mittel
verdächtiges Verhalten oder relevante Kontrollabweichung
zeitnahe Analyse und Entscheidung
Niedrig
schwaches Signal oder begrenzte Abweichung
Bündelung, Beobachtung oder geplante Prüfung
Informativ
Kontext ohne unmittelbaren Handlungsbedarf
Aufbewahrung oder Nutzung in Korrelation
Reaktionszeiten und Besetzungsmodelle sind vor Freigabe verbindlich festzulegen.
Alarme werden an bestätigte, überwachte Kanäle zugestellt.
Zustellung, Annahme und Eskalation sind nachvollziehbar.
Tickets erhalten Quelle, Zeit, Schwere, Kontext, Owner und Status.
Kritische Alarme hängen nicht von einer einzelnen Person oder Mailbox ab.
Störungen der Schnittstelle zwischen Monitoring und Ticketing werden erkannt.
Dubletten, Alarmstürme und Abhängigkeiten werden kontrolliert behandelt.
Die Triage prüft mindestens:
Ist der Alarm technisch echt und vollständig?
Welche Quelle, Identität, Assets und Zeiten sind betroffen?
Ist die Aktivität genehmigt, erwartbar oder durch Änderung erklärbar?
Welche Schutzklassen, Kunden, Personen oder Prozesse sind betroffen?
Gibt es weitere korrelierende Ereignisse?
Welche Auswirkung und Dringlichkeit bestehen?
Ist ein Incident zu eröffnen oder eine andere Fachrolle zuständig?
Welche Beweise und Sofortmaßnahmen sind erforderlich?
Ein Alarm wird zum Sicherheitsvorfall, wenn festgelegte Kriterien erfüllt sind oder Unsicherheit und Auswirkung dies erfordern.
Die Übergabe enthält:
Alarm- und Quellenreferenzen,
Zeitlinie und bekannte Fakten,
betroffene Identitäten, Assets und Informationen,
bereits durchgeführte Abfragen und Maßnahmen,
Beweise, Exporte und Integritätsnachweise,
offene Hypothesen, Risiken und empfohlene Schritte,
Datenschutz-, Kunden-, Vertrags- oder Meldebezug.
Automatische Sperrung, Isolation, Blockierung oder Löschung wird nur eingesetzt, wenn:
Zweck und Risiko bestätigt sind,
Fehlalarme und Betriebsauswirkungen bewertet wurden,
Handlung eindeutig, minimal und reversibel ist,
Berechtigung, Protokollierung und Notfallabschaltung bestehen,
Tests positive, negative und Grenzfälle abdecken,
Menschen bei kritischen Auswirkungen angemessen eingebunden werden,
Ausnahmen und Wiederfreigabe geregelt sind.
Für jede relevante Regel werden betrachtet:
False Positives und deren betriebliche Kosten,
False Negatives und bekannte blinde Flecken,
fehlende Quellen, Felder oder Kontextdaten,
verschlüsselte oder nicht einsehbare Aktivitäten,
Umgehungsmöglichkeiten und Angreiferanpassung,
Filter, Allowlisting und unterdrückte Ereignisse,
Auswirkungen von Tuning und Schwellenänderungen.
Tuning darf die gewünschte Erkennung nicht unbemerkt beseitigen.
Erkannt werden insbesondere:
Ausfall oder Verzögerung einer Logquelle,
fehlende erwartete Ereignisse,
Parser-, Normalisierungs- und Indexierungsfehler,
Queue-, Speicher-, Lizenz- oder Kapazitätsgrenzen,
Zeitabweichung und falsche Zeitzone,
deaktivierte Agenten, Sensoren oder Regeln,
unterbrochene Alarm- und Ticketschnittstellen,
fehlgeschlagene Backups, Archive oder Löschjobs.
Überwacht werden:
Ereignisvolumen, Spitzen und Wachstum,
Drosselung, Sampling und verworfene Daten,
Latenz von Quelle bis Suchbarkeit und Alarm,
Parserfehler, Nullwerte und Feldqualität,
Such- und Abfrageleistung,
Speicher-, Lizenz- und Budgetgrenzen,
Abweichung zwischen erwartetem und tatsächlichem Volumen.
Kostenkontrolle darf nicht unbemerkt zur Sicherheitslücke führen.
Änderungen an:
Logumfang und -stufe,
Quellenanbindung und Parsern,
Zeitquellen,
Aufbewahrung und Löschung,
Rollen und Zugriffen,
Alarmregeln, Schwellen und Unterdrückungen,
Dashboards, Tickets und Automatisierungen
folgen IT-Betrieb und Änderungen mit Test, Freigabe, Rückfall und Abschlussprüfung.
Vor Produktivsetzung werden:
Asset, Owner, Kritikalität und Schutzbedarf bestätigt,
Ereigniskategorien und Mindestfelder festgelegt,
Zeit, Format, Transport und Zielsystem konfiguriert,
Datenschutz, Inhalte und Aufbewahrung geprüft,
Use Cases und Alarmwege zugeordnet,
Quellgesundheit, Beispielereignisse und Ausfallverhalten getestet,
Betrieb, Dokumentation und Reviewtermin übergeben.
Bei Änderung oder Außerbetriebnahme:
werden Auswirkungen auf Use Cases und Nachweise geprüft,
wird eine neue Quelle oder Version vor Abschaltung validiert,
werden historische Logs aufbewahrt oder gelöscht,
werden Agenten, Zertifikate, Konten und Schnittstellen entfernt,
werden Register, Architektur, Regeln und Dashboards aktualisiert,
wird geprüft, ob eine ungewollte Überwachungslücke entstand.
Verträge und Betriebsmodelle regeln:
Quellen, Use Cases, Servicezeiten und Reaktionsziele,
Rollen, Zugriffe, Personal und Unterauftragnehmer,
Datenstandorte, Übermittlungen und Datenschutz,
Schutz, Integrität, Aufbewahrung, Export und Löschung,
Alarmübergabe, Incident-Unterstützung und Beweissicherung,
Leistungsnachweise, Änderungen und Auditmöglichkeiten,
Notbetrieb, Portabilität, Exit und Datenrückgabe.
Ein SOC- oder SIEM-Servicevertrag belegt ohne eigene Abdeckungskontrolle keine wirksame Überwachung.
Erweiterte oder personenbezogen ausgerichtete Überwachung benötigt:
dokumentierten Anlass und Zweck,
befugte Entscheidung und klare Grenzen,
Beteiligung von Datenschutz, Personal, Recht und gegebenenfalls Mitbestimmung,
minimale Daten, Systeme, Personen und Dauer,
geschützte Fallakte und eingeschränkten Zugriff,
regelmäßige Verhältnismäßigkeitsprüfung,
Abschluss, Löschung und dokumentierte Aufhebung.
Unbestätigte Verdächtigungen werden nicht unnötig verbreitet.
Bei möglicher Beweisrelevanz werden:
Quelle, Umfang, Zeitpunkt und verantwortliche Person dokumentiert,
Rohdaten möglichst unverändert gesichert,
Integrität durch geeignete technische Nachweise geschützt,
Exporte, Datenträger und Übergaben nachvollziehbar geführt,
Zugriffe und Analysen protokolliert,
Zeitzonen, Zeitabweichungen und bekannte Lücken dokumentiert,
Aufbewahrungs- und Löschsperren befugt entschieden,
rechtliche und datenschutzrechtliche Anforderungen berücksichtigt.
Bei Ausfall der zentralen Überwachung:
werden kritische Quellen und Alarmwege priorisiert,
lokale Logs und Puffer geschützt,
alternative Kontakt- und Eskalationswege aktiviert,
Einschränkungen und blinde Flecken sichtbar dokumentiert,
Änderungen und privilegierte Tätigkeiten besonders kontrolliert,
Wiederanlauf und Nachlieferung überwacht,
Datenlücken, Reihenfolge und Integrität nachträglich bewertet.
Ausnahmen werden nach Ausnahmen und Risikoakzeptanzen behandelt und enthalten:
Quelle, Ereignisse, Zeitraum und Zweck,
technische oder rechtliche Einschränkung,
Risiko und betroffene Use Cases,
kompensierende Kontrollen,
Owner, Genehmigung und Ablaufdatum,
Review und Beendigungsnachweis.
Geeignete Tests umfassen:
Erzeugung repräsentativer positiver und negativer Ereignisse,
Prüfung von Zeit, Feldern, Parser und Korrelation,
Unterbrechung und Wiederanlauf einer Logquelle,
Manipulations-, Lösch- und Zugriffsversuche,
Alarmzustellung, Triage, Eskalation und Ticketabschluss,
Test von Schwellen, Allowlisting und Automatisierung,
Restore historischer Logs und Nachweisexport,
Simulation eines Provider- oder SIEM-Ausfalls.
Geeignete Ende-zu-Ende-Stichproben verfolgen:
ein kritisches Asset bis zu Quelle, Use Case, Alarm und Reaktion,
eine privilegierte Änderung bis zu Freigabe und Auswertung,
eine Kontoübernahme vom Login bis zur Incident-Übergabe,
einen Massenexport bis zu Alarm und fachlicher Bewertung,
einen Provideralarm bis zur internen Übernahme,
eine Zeitabweichung bis zu Korrektur und Auswirkungsanalyse,
eine Ausnahmeregel bis zu Ablauf und tatsächlicher Beendigung.
Kennzahl
Definition
Ziel im Entwurf
erfasste relevante Logquellen
vollständig erfasst / identifiziert
Zielwert festzulegen
aktive Quellen mit aktuellem Gesundheitstest
gesund / relevante aktive Quellen
Zielwert festzulegen
kritische Assets mit definierter Überwachung
abgedeckt / kritische Assets
Zielwert festzulegen
Quellen mit bestätigter Zeitsynchronisation
konform / relevante Quellen
Zielwert festzulegen
verworfene oder verspätete Ereignisse
Anzahl/Anteil nach Quelle
Schwelle festzulegen
Use Cases mit aktuellem Test
fristgerecht getestet / aktive Use Cases
Zielwert festzulegen
kritische Alarme innerhalb Triageziel
fristgerecht / bestätigte kritische Alarme
Zielwert festzulegen
ungeklärte kritische Alarme
Anzahl und Alter
0
False-Positive-Rate
bestätigte Fehlalarme / geprüfte Alarme
risikobasiert optimieren
Quellen-/Sensorlücken
Anzahl, Dauer und Kritikalität
Trend und Schwellen festlegen
überfällige Ausnahmen
Anzahl
0
ISO/IEC-27001:2022-Control
Beitrag dieser Seite
A.5.7 Bedrohungsinformationen
Überführung von Bedrohungen in Use Cases und Hunting
A.5.24 bis A.5.28
Alarmübergabe, Incident-Unterstützung, Lernen und Beweissicherung
A.5.31 bis A.5.34
Rechts-, Aufzeichnungs-, Datenschutz- und Schutzanforderungen
A.8.2/A.8.5
Überwachung privilegierter und sicherer Authentisierung
A.8.9
Protokollierung und Review von Konfigurationsänderungen
A.8.15 Protokollierung
Ereignisse, Felder, Schutz, Aufbewahrung und Zugriff
A.8.16 Überwachung technischer Aktivitäten
Use Cases, Alarme, Triage und Reaktion
A.8.17 Zeitsynchronisation
Zeitquellen, Hierarchie, Qualität und Abweichungen
A.8.20 Netzwerksicherheit
Netzwerklogs, Sensoren und Kommunikationsüberwachung
Die verbindliche Anwendbarkeit und der Umsetzungsstatus werden im Statement of Applicability geführt. Diese Seite allein belegt keinen umgesetzten Control.
Die Regelung unterstützt insbesondere:
Kapitel 1.6 Incident- und Krisenmanagement,
Kapitel 4 Identitäts- und Zugriffsmanagement,
Kapitel 5.2 Betriebssicherheit,
Kapitel 6 Lieferantenbeziehungen,
Kapitel 7 Compliance.
Verbindliche Bewertungsregeln:
Alle 46 Fragen des Reiters „Informationssicherheit“ werden einzeln umgesetzt und bewertet.
Keine dieser Fragen wird wegen einer SoA-Entscheidung pauschal als „nicht anwendbar“ behandelt.
Logs, Dashboards und Alarmregeln sind Soll-/Umsetzungsnachweise, aber erst Tests und reale Bearbeitung belegen Wirksamkeit.
Unbekannte Quellenabdeckung oder nicht bearbeitete Alarme dürfen nicht als hoher Reifegrad dargestellt werden.
Referenz
Zusammenhang
RIS-2026-001
Anmeldung, MFA, Berechtigungen und Zugriff auf Kundenzeichnungen
RIS-2026-002
Ransomware, laterale Bewegung und Kontrollausfall
RIS-2026-003
Cloud-Ausfall, Providerlogs und Notbetrieb
RIS-2026-004
externe Fernwartung und privilegierte Aktivitäten
RIS-2026-005
Fehlversand, Freigaben und Datenabfluss
RIS-2026-006
Backup-, Restore- und Integritätsereignisse
RIS-2026-010
Schwachstellenausnutzung und erreichbare Systeme
RIS-2026-013
Lieferkette, Provider- und Komponentenaktivitäten
RIS-2026-014
Phishing, Kontoübernahme und Schadsoftware
M-002, M-004, M-005, M-010, M-014 und TISAX-M-010 bleiben offen, bis reale Quellen, Erkennungsfälle, Alarmwege und Wirksamkeit nachgewiesen sind.
Prüfaspekt
Status am 23.07.2026
Sollregelung erstellt
Ja, als Entwurf
vollständiges Logquellenregister
Nicht nachgewiesen
kritische Quellenabdeckung
Nicht geprüft
Ereigniskatalog und Mindestfelder
Soll beschrieben; nicht technisch bestätigt
Zeithierarchie und Synchronisation
Nicht nachgewiesen
sichere Sammlung und Integrität
Nicht geprüft
Aufbewahrungs- und Löschfristen
Nicht verbindlich festgelegt
Datenschutz-/Mitbestimmungsprüfung
Ausstehend
SIEM-/Monitoringarchitektur
Nicht bestätigt
aktive Use Cases und Alarmwege
Nicht vollständig nachgewiesen
24/7- oder sonstiges Betriebsmodell
Nicht festgelegt
praktische Ende-zu-Ende-Tests
Nicht durchgeführt/nicht belegt
offene Maßnahmen wirksam abgeschlossen
Nein
fachliche Prüfung
Ausstehend
Geschäftsführungsfreigabe
Ausstehend
46 ISA-Informationssicherheitsfragen bewertet
Nein; 0 von 46
TISAX-M-010 kontrollfragenbezogen mit realen Nachweisen bearbeiten
Prüffrage
Status Entwurf
Sind alle relevanten Logquellen und Owner bekannt?
Nein
Ist die Abdeckung kritischer Assets vollständig?
Nicht geprüft
Sind Ereignisse, Felder, Zeit und Formate technisch bestätigt?
Nein
Werden Geheimnisse und unnötige Inhalte vermieden?
Soll beschrieben; nicht getestet
Sind Integrität, Zugriff, Export und Löschung geschützt?
Nicht nachgewiesen
Sind Aufbewahrungsfristen begründet und freigegeben?
Nein
Sind Datenschutz und Mitbestimmung berücksichtigt?
Ausstehend
Sind Use Cases, Alarme und Triage operationalisiert?
Nicht vollständig
Werden Ausfälle von Quellen, Sensoren und Alarmwegen erkannt?
Nicht getestet
Sind Ende-zu-Ende-Tests und reale Stichproben vorhanden?
Nein
Ist TISAX-M-010 wirksam abgeschlossen?
Nein
Sind alle 46 ISA-Informationssicherheitsfragen bewertet?
Nein; 0 von 46
Liegen fachliche Prüfung und Geschäftsführungsfreigabe vor?
Nein
Version
Datum
Änderung
Erstellt/geändert durch
Freigabe
Freigabedatum
0.1
23.07.2026
Regelung für Logquellen, Zeit, Sammlung, Schutz, SIEM, Use Cases, Alarmierung, Triage und Wirksamkeitsprüfung angelegt
IT / Informationssicherheit
Ausstehend
–
Funktion
Name
Entscheidung
Datum
Informationssicherheit/SOC
–
fachliche Prüfung ausstehend
–
IT-/OT-Betrieb
–
technische Prüfung ausstehend
–
Incident Management/BCM
–
Reaktions- und Notfallprüfung ausstehend
–
Datenschutz/Personal/Recht
–
Zweck-, Transparenz- und Aufbewahrungsprüfung ausstehend
–
Geschäftsführung
–
Freigabe ausstehend
–
Normtexte, VDA-ISA, Rechtsquellen, Kunden- und Providerverträge sowie aktuelle technische Empfehlungen sind in ihrer jeweils gültigen Fassung separat zu prüfen. Diese Seite enthält bewusst keine produktiven Suchabfragen, Schwellen, Zugangsdaten oder internen Erkennungsdetails.