CRA Logging & Monitoring: Welche Sicherheitsereignisse Produkte erfassen sollten

Der Cyber Resilience Act verlangt, dass Produkte sicherheitsrelevante interne Aktivitäten aufzeichnen und überwachen können. Dazu gehören insbesondere Zugriffe sowie Änderungen an Daten, Diensten oder Funktionen. Logging soll Sicherheitsvorfälle erkennbar machen, darf aber nicht zu unkontrollierter Datensammlung führen.

Einordnung im CRA-Wissen: Dieser Fachartikel gehört zum Themenbereich Technische Produktsicherheit. Dort finden Sie die angrenzenden Anforderungen und eine praktische Reihenfolge für die Umsetzung.

Was verlangt der CRA bei Logging und Monitoring?

Anhang I Teil I Nummer 2 Buchstabe l verlangt, sicherheitsbezogene Informationen bereitzustellen, indem relevante interne Aktivität aufgezeichnet und überwacht wird. Genannt werden ausdrücklich Zugriffe auf oder Änderungen an Daten, Diensten oder Funktionen. Gleichzeitig soll ein Opt-out-Mechanismus für den Nutzer vorgesehen werden.

Die Anforderung ist risikobasiert. Ein einfaches Offlineprodukt benötigt keine identische Telemetrie wie ein cloudverbundenes Administrationssystem. Die CRA-Risikobewertung muss deshalb bestimmen, welche Ereignisse für das konkrete Produkt sicherheitsrelevant sind.

Welche Ereignisse sollten protokolliert werden?

Typisch sind erfolgreiche und fehlgeschlagene Authentisierungen, Änderungen an Berechtigungen, administrative Aktionen, sicherheitsrelevante Konfigurationsänderungen, Updatevorgänge, Integritätsfehler, ungewöhnliche Zugriffsversuche und Änderungen an besonders schützenswerten Daten.

Es ist nicht sinnvoll, jede technische Aktivität dauerhaft zu protokollieren. Zu viele Logs erschweren die Analyse, erhöhen Speicherbedarf und können neue Datenschutz- oder Sicherheitsrisiken erzeugen.

Müssen erfolgreiche Zugriffe ebenfalls geloggt werden?

Bei sicherheitskritischen Funktionen häufig ja. Nur fehlgeschlagene Logins zu erfassen reicht nicht, wenn später geklärt werden muss, welches Konto eine sensible Konfiguration geändert oder Daten exportiert hat. Allerdings muss Umfang und Granularität zum Risiko passen.

Bei normalen Endnutzeraktionen kann eine vollständige Aktivitätschronik unverhältnismäßig sein. Hersteller sollten zwischen Audit-relevanten und rein funktionalen Ereignissen unterscheiden.

Wie schützt man Logs vor Manipulation?

Logs sind nur dann wertvoll, wenn ein Angreifer sie nicht unbemerkt löschen oder verändern kann. Schutzmechanismen können getrennte Berechtigungen, append-only-Speicherung, kryptografische Integritätsmechanismen, externe Logziele oder manipulationsgeschützte Hardware umfassen.

Welche Lösung angemessen ist, hängt von Produkt und Angreifermodell ab. Bei einem kompromittierten lokalen Gerät kann ein entferntes Logziel sinnvoll sein; bei Offlineprodukten braucht es andere Mechanismen.

Dürfen Passwörter oder Tokens in Logs stehen?

Nein, Geheimnisse sollten nicht protokolliert werden. Passwörter, private Schlüssel, vollständige Session-Tokens, API-Secrets oder sensible personenbezogene Inhalte erzeugen in Logs eine zusätzliche Angriffsfläche.

Auch Fehlerausgaben müssen geprüft werden. Entwicklerlogs enthalten häufig Request-Header, Datenbankinhalte oder Stacktraces. Was in einer Testumgebung hilfreich ist, kann im Produktbetrieb ein Sicherheitsproblem darstellen.

Wie passt Logging zur Datenminimierung?

Der CRA verlangt gleichzeitig, nur notwendige Daten zu verarbeiten. Deshalb sollte jedes Logfeld einen Sicherheitszweck haben. Häufig reicht eine pseudonyme Kennung oder interne User-ID statt Klarnamen, vollständiger IP-Historie oder Inhaltsdaten.

Eine Log-Spezifikation sollte festlegen, welche Felder notwendig sind und welche bewusst ausgeschlossen werden. Das unterstützt auch Datenschutzanforderungen außerhalb des CRA.

Was bedeutet der Opt-out-Mechanismus?

Anhang I nennt für Security Logging einen Opt-out-Mechanismus für Nutzer. Hersteller müssen deshalb unterscheiden zwischen technisch zwingenden lokalen Sicherheitsaufzeichnungen und zusätzlicher Übermittlung oder zentralem Monitoring. Die konkrete Umsetzung muss zum Produkt und Risiko passen.

Ein Opt-out darf nicht so gestaltet sein, dass der Nutzer unbeabsichtigt wesentliche Schutzfunktionen zerstört. Die Auswirkungen sollten verständlich erklärt und dokumentiert werden. Bei besonderen B2B-Umgebungen kann außerdem eine vertragliche und technische Abstimmung nötig sein.

Wie lange sollten Logs aufbewahrt werden?

Der CRA gibt keine pauschale Aufbewahrungsdauer für jedes Produktlog vor. Hersteller sollten sie aus Sicherheitszweck, Speicherfähigkeit, Vorfallerkennungszeit, Supportmodell und weiteren Rechtsanforderungen ableiten.

Kurzlebige Debugdaten können Stunden oder Tage genügen, während Auditdaten zu administrativen Änderungen länger benötigt werden können. Wichtig sind dokumentierte Regeln und eine kontrollierte Löschung statt unbegrenzter Speicherung.

Wie funktioniert Monitoring ohne eigenes SOC?

Ein Hersteller braucht nicht automatisch ein 24/7-Security Operations Center. Produkte können lokal relevante Warnungen anzeigen, Ereignisse an ein Kundensystem exportieren oder zentrale Dienste nutzen, sofern dies zur Produktarchitektur passt.

Für KMU ist entscheidend, welche Signale tatsächlich eine Reaktion auslösen. Zehntausende ungeprüfte Alerts schaffen keine Sicherheit. Besser sind wenige, klar priorisierte Ereignisse mit festgelegtem Owner und Eskalationsweg.

Welche Ereignisse sollten Alarme auslösen?

Alarmwürdig können wiederholte Authentisierungsfehler, Rechteausweitungen, unerwartete Änderung sicherheitskritischer Einstellungen, fehlgeschlagene Integritätsprüfungen, manipulierte Updates oder auffällige Ressourcenmuster sein. Der Schwellenwert sollte Fehlalarme und tatsächliche Bedrohung ausbalancieren.

Ein Alarm sollte beantworten können: Was ist passiert? Welches Produkt oder Konto ist betroffen? Wie dringend ist die Prüfung? Welche erste Maßnahme ist möglich?

Wie verbindet man Logs mit dem Schwachstellenmanagement?

Logs können neue Schwachstellen sichtbar machen oder zeigen, dass ein bekannter Fehler tatsächlich ausgenutzt wird. Erkennt das Team Hinweise auf aktive Ausnutzung, muss der Fall in das Schwachstellenmanagement und gegebenenfalls in den gesetzlichen Reporting-Prozess übergeben werden.

Der Übergang sollte dokumentiert sein. Nur ein Alarm im Monitoring-Dashboard genügt nicht, wenn niemand verantwortlich ist, die Relevanz für ein ausgeliefertes Produkt zu bewerten.

Wann können Logs CRA-Meldepflichten unterstützen?

Bei aktiv ausgenutzten Schwachstellen oder schweren Sicherheitsvorfällen sind Zeitpunkt, betroffene Versionen, Auswirkungen und Maßnahmen entscheidend. Gute Logs können diese Fakten schneller liefern und die 24h-/72h-Meldungen unterstützen.

Logs ersetzen keine Bewertung. Ein ungewöhnlicher Login ist nicht automatisch ein CRA-meldepflichtiger Vorfall. Er kann aber die technische Evidenz liefern, um aktive Ausnutzung zu bestätigen.

Wie sollte Zeitstempelung funktionieren?

Für Ereigniskorrelation sind verlässliche Zeitstempel wichtig. Geräte sollten eine geeignete Zeitbasis nutzen und Zeitzonen beziehungsweise UTC nachvollziehbar behandeln. Bei Systemen ohne permanente Zeitsynchronisation muss dokumentiert sein, welche Genauigkeit erreichbar ist.

Fehlerhafte Uhrzeiten können eine Incident-Analyse erheblich erschweren. Deshalb gehört Zeitsynchronisation bei vernetzten Produkten in Architektur und Testplan.

Wie werden Logs aus mehreren Komponenten zusammengeführt?

Moderne Produkte bestehen häufig aus Gerät, App, Backend und Remote-Diensten. Ein Vorfall kann über mehrere Komponenten laufen. Einheitliche Fall- oder Sessionkennungen, Zeitbasis und Ereignisschemata erleichtern die Korrelation.

Dabei sollte vermieden werden, dass jede Komponente ungefiltert alles an einen zentralen Dienst sendet. Datenminimierung und Zweckbindung gelten auch in verteilten Architekturen.

Wie testet man Logging?

Logging sollte Bestandteil des Security-Testplans sein. Tests lösen definierte Ereignisse aus und prüfen, ob diese vollständig, korrekt und ohne Geheimnisse aufgezeichnet werden. Zusätzlich wird getestet, ob unberechtigte Nutzer Logs lesen, löschen oder manipulieren können.

Auch Fehlerfälle gehören dazu: voller Speicher, Netzwerkunterbrechung zum Logserver, falsche Uhrzeit, Neustart und Logrotation. Das Produkt sollte dabei nicht in einen unsicheren Zustand geraten.

Was muss in der technischen Dokumentation stehen?

Die Produktakte sollte erklären, welche sicherheitsrelevanten Ereignisse erfasst werden, wo Logs gespeichert sind, wie Integrität und Zugriff geschützt werden, welche Aufbewahrung gilt und wie Nutzer den vorgesehenen Opt-out nutzen können.

Dazu kommen Testnachweise und der Bezug zur Risikobewertung. Es ist nicht nötig, reale Kundendaten in die technische Dokumentation zu kopieren.

Welche typischen Logging-Fehler treten auf?

• Passwörter, Tokens oder personenbezogene Inhalte werden mitgeloggt.
• Nur Debuglogs existieren, aber keine sicherheitsrelevanten Audit-Events.
• Administratoren können eigene Aktionen spurlos löschen.
• Zeitstempel sind zwischen Komponenten nicht vergleichbar.
• Logs wachsen unbegrenzt und legen den Speicher voll.
• Alerts existieren, aber niemand reagiert.
• Logging wird bei jedem Release verändert, ohne Regressionstest.

Wie kann ein KMU ein sinnvolles Logging-Konzept starten?

Ein guter Start ist eine Eventliste mit drei Prioritäten: Ereignisse, die immer aufgezeichnet werden müssen; Ereignisse, die für Diagnose kurzfristig nützlich sind; und Daten, die bewusst nicht in Logs gehören. Dazu kommen Rollen für Zugriff, Aufbewahrung und Alarmbehandlung.

Für jedes Hochprioritätsereignis sollte ein Test existieren. So wird Logging nicht zum Nebenprodukt der Entwicklung, sondern zu einer überprüfbaren Sicherheitsfunktion.

Wie behandelt man Logexport an Geschäftskunden?

Viele B2B-Nutzer möchten Produktlogs in SIEM- oder Monitoring-Systeme übernehmen. Ein standardisierter Export kann sinnvoll sein, wenn Format, Authentisierung und Transport sicher gestaltet werden. Hersteller sollten dokumentieren, welche Events exportiert und welche Felder pseudonymisiert oder ausgelassen werden.

Der Export darf nicht dazu führen, dass eine zusätzliche ungeschützte Administrationsschnittstelle entsteht. Zugriffsschutz und sichere Übertragung gehören deshalb zum Design.

Welche Rolle spielen Logs bei Support und Forensik?

Support kann mit geeigneten Logs Fehler und Sicherheitsprobleme schneller einordnen. Für forensische Zwecke ist allerdings wichtig, zwischen vertrauenswürdigen Auditdaten und vom Nutzer manipulierbaren lokalen Diagnosedaten zu unterscheiden.

Hersteller sollten in Dokumentation und internen Prozessen klar benennen, welche Daten für welche Aussage belastbar sind. Das verhindert, dass ein einzelner Logeintrag als vollständiger Beweis interpretiert wird.

Wie schützt man zentrale Logsysteme?

Ein zentraler Logdienst enthält häufig sensible Metadaten vieler Produkte und Kunden. Er braucht deshalb starke Authentisierung, getrennte Rollen, Verschlüsselung, Monitoring, Backup und eine eigene Risikobewertung. Besonders privilegierte Such- und Exportfunktionen sind kritisch.

Bei Cloudbestandteilen sollte außerdem geklärt werden, ob sie als notwendige Remote-Datenverarbeitung Teil des Produkts sind. Der geplante Beitrag CRA Remote-Datenverarbeitung ordnet diese Grenze ein.

Wie werden Logging-Änderungen kontrolliert?

Neue Features erzeugen neue sicherheitsrelevante Ereignisse. Deshalb sollte jede Änderung einen kurzen Check enthalten: Muss etwas Neues protokolliert werden? Werden bestehende Felder sensibler? Ändert sich das Volumen oder die Aufbewahrung?

Eine versionierte Event-Spezifikation verhindert, dass Logs zufällig mit dem Code wachsen. Sie hilft auch Integratoren, Ereignisse zuverlässig auszuwerten.

Wie hilft eine Event-Taxonomie bei der Auswertung?

Eine gemeinsame Event-Taxonomie verhindert, dass jedes Produktteam dieselben Sicherheitsereignisse anders benennt. Kategorien wie Authentisierung, Berechtigungsänderung, Konfigurationsänderung, Integritätsfehler, Updateereignis und Recovery lassen sich mit Schweregrad und Produktbezug kombinieren. Dadurch können Support, PSIRT und Kundenmeldungen konsistenter ausgewertet werden.

Die Taxonomie sollte stabil genug für langfristige Auswertung sein, aber neue Ereignistypen aufnehmen können. Änderungen am Format gehören deshalb wie eine API-Version in den Produktlebenszyklus.

Was ist der Unterschied zwischen Audit-Log und Telemetrie?

Audit-Logs dokumentieren sicherheitsrelevante Aktionen und Zustandsänderungen; Telemetrie beschreibt häufig Betriebszustand, Performance oder Nutzung. Beide Datenarten können sich überschneiden, sollten aber nicht unkritisch vermischt werden. Für einen Administratorzugriff ist beispielsweise ein verlässlicher Audit-Eintrag wichtiger als eine aggregierte Nutzungsmetrik.

Diese Trennung hilft auch bei Datenminimierung, Aufbewahrung und Opt-out. Hersteller können genauer erklären, welche Informationen für Produktsicherheit erforderlich sind und welche zusätzlichen Diagnosedaten optional verarbeitet werden.

Wie sollte ein regelmäßiges Logging-Review aussehen?

Mindestens bei größeren Releases und nach Sicherheitsvorfällen sollte geprüft werden, ob die vorhandenen Ereignisse noch zum Risikoprofil passen. Neue administrative Funktionen brauchen häufig neue Audit-Events; nicht mehr benötigte Debugfelder sollten entfernt werden.

Ein Review betrachtet außerdem Aufbewahrung, Speicherverbrauch, Zugriff auf zentrale Logsysteme, Alarmqualität und Datenschutz. So bleibt Logging eine gepflegte Sicherheitsfunktion statt einer historisch gewachsenen Datensammlung.

Wie sollte man Alarmregeln gegen Fehlalarme absichern?

Alarmregeln brauchen eine Rückkopplung aus echten Fällen. Zu empfindliche Regeln erzeugen Alarmmüdigkeit; zu grobe Schwellen übersehen relevante Angriffe. Hersteller sollten deshalb dokumentieren, welche Ereignisse zu einem Alarm führen, wer ihn bewertet und wie Regeln nach False Positives angepasst werden.

Änderungen an Alarmregeln sollten versioniert sein. So lässt sich bei einem späteren Vorfall nachvollziehen, welche Erkennungslogik zu diesem Zeitpunkt aktiv war und warum ein Ereignis gemeldet oder nicht gemeldet wurde.

Wie werden Logs im Ernstfall tatsächlich nutzbar?

Security-Logs entfalten ihren Wert erst, wenn Verantwortliche sie im Vorfall schnell auswerten können. Deshalb sollten Zeitstempel synchronisiert, Ereignisquellen eindeutig benannt und zentrale Such- oder Filtermöglichkeiten vorbereitet sein. Für kritische Produkte lohnt ein kurzer Incident-Test: Ein verdächtiger Zugriff wird simuliert und das Team prüft, ob Ursprung, betroffene Funktion, Nutzerkontext und zeitlicher Ablauf aus den vorhandenen Protokollen nachvollziehbar sind. Fehlende Informationen werden anschließend gezielt ergänzt.

Wo steht die Logging-Anforderung im CRA?

Die ausdrückliche Grundlage findet sich in Anhang I Teil I Nummer 2 Buchstabe l der Verordnung (EU) 2024/2847. Sie nennt Aufzeichnung und Überwachung relevanter interner Aktivität sowie einen Opt-out-Mechanismus für Nutzer.