+DET.4 Überwachung von Aktivitäten
---+DET.4.1 Überwachung der Protokollierung
---+DET.4.2 Automatische Angriffserkennung
---+DET.4.3 Überwachung der Angriffserkennung
---+DET.4.4 Änderungen an Sicherheitsrichtlinien
---+DET.4.5 Unerwünschte Datenabflüsse
---+DET.4.6 Anomale Nutzung der Anwendung
------+DET.4.6.1 Verhaltensanalyse von Zugangskonten
---+DET.4.7 Auslaufen von Domains
---+DET.4.8 Ausstellung neuer HTTPS-Zertifikate
---+DET.4.9 Manipulations-Checkup
---+DET.4.10 Host-basierte Köder
---+DET.4.11 Anomalien in Netzen und am Perimeter
------+DET.4.11.1 Authentifizierungsversuche an externen Schnittstellen
------+DET.4.11.2 Netzwerk-Honeypots
------+DET.4.11.3 Netzverkehrsfluss
---+DET.4.12 Monitoring der Netzverfügbarkeit
------+DET.4.12.1 Auslastung des Netzes
---+DET.4.13 Verfügbarkeit des Hostsystems
---+DET.4.14 Verfügbarkeit der Anwendung
---+DET.4.15 Ressourcenauslastung von Hostsystemen
---+DET.4.16 Ressourcenauslastung der Server-Dienste
---+DET.4.17 Anwendungsbasiertes Kapazitätsmanagement
---+DET.4.18 Öffentliche Blocklisten
---+DET.4.19 Unautorisierte Sendeanlagen
|
DET.4 Überwachung von Aktivitäten
1. Resumen
| Título |
Estándar |
|
DET.4.1 Überwachung der Protokollierung
|
Detektion SOLLTE die Funktionsfähigkeit der Protokollierung überwachen. Erläuterung Zu den Kriterien kann beispielsweise die Aktivierung oder Deaktkvierung des Loggings auf Systemen, sowie die Datenmenge eingehender Logs in einem bestimmten Zeitraum gehören.
|
|
DET.4.2 Automatische Angriffserkennung
|
Detektion für IT-Systeme SOLLTE diese auf Anzeichen für Angriffe durch [einen automatisierten Mechanismus] überwachen. Erläuterung Wenn professionelle Tätergruppen Zugriff auf Systeme und Daten erhalten, nutzen sie diese zunehmend schneller für ihre Zwecke aus, z.B. um Daten abfließen zu lassen oder Ransomware zu verteilen. Zur Umsetzung können sowohl netz- als auch hostbasierte Erkennungssysteme (NIDS und HIDS) verwendet werden. Für die Detektion bei IT-Systemen ohne Installationsmöglichkeit wie Appliances, IoT-Geräte oder OT-Systeme kann ein kombinierter Ansatz aus Netzwerk- und Loganalyse sinnvoll sein. Angriffe können signaturbasiert, sowie durch Verhaltensanalyse und Anomalien erkannt werden. Die Anforderung kann auch mit bereits vorhandenen oder im System integrierten Angriffserkennungsmechanismen erfüllt werden. Zweckmäßig ist es Schwellwerte und Kategorien (Info, Warnung, Alarm) so festzulegen, dass Probleme frühzeitig erkannt werden können, aber beim Betriebspersonal keine Alarmmüdigkeit (alert fatigue) aufkommt. Hierzu ist es hilfreich die Ergebnisse regelmäßig auszuwerten und wenn nötig Korrekturmaßnahmen zu ergreifen.
|
|
DET.4.3 Überwachung der Angriffserkennung
|
Detektion SOLLTE die Funktionsfähigkeit der automatisierten Angriffserkennung überwachen. Erläuterung Hierzu gehört insbesondere die Aktivierung oder Deaktivierung der Angriffserkennung, oder das Stoppen zugehöriger Dienste.
|
|
DET.4.4 Änderungen an Sicherheitsrichtlinien
|
Detektion SOLLTE Änderungen an Sicherheitsrichtlinien einschließlich deren Aktivierung oder Deaktivierung überwachen. Erläuterung Wird die Aktivität von automatisierten Sicherheitswerkzeugen nicht überwacht, so könnten Angreifer diese Schutzmechanismen unbemerkt deaktivieren und die Person so in falscher Sicherheit wiegen. Zudem installieren Angreifer gerne permanente Hintertüren über neue Konten oder Gruppenwechsel. Automatisierte Sicherheitsrichtlinien sind z.B. Ausnahmelisten von Antivirus- oder EDR, über den Verzeichnisdienst hinzugefügte Gruppenzugehörigkeiten zu sicherheitsrelevanten Gruppen (z.B. Admin), NAC oder Firewallregeln.
|
|
DET.4.5 Unerwünschte Datenabflüsse
|
Detektion KANN unerwünschte Datenabflüsse überwachen. Erläuterung Unerwünschte Datenabflüsse beziehen sich hier auf jede unautorisierte Übertragung sensibler Informationen aus internen IT-Systemen oder Anwendungen nach außen (engl. data leakage oder data exfiltration). Darunter fallen sowohl absichtliche als auch unbeabsichtigte Transfers, etwa über Endgeräte, Netzwerkkanäle oder Cloud-Schnittstellen, wobei Data Loss Prevention (DLP) als Sammelbegriff für technische und organisatorische Maßnahmen dient, die solche Abflüsse erkennen oder verhindern können. Die Überwachung kann gewährleisten, dass vertrauliche Inhalte nicht unbemerkt der Kontrolle entzogen werden. Herkunft und Ziel solcher Abflüsse können zusätzlich Indikatoren für kompromittierte Zugangskonten oder Fehlkonfigurationen liefern. Der Zweck der Vorschrift liegt darin, potenzielle Datenabflüsse frühzeitig sichtbar zu machen, sodass aufkommende Risiken wie der Verlust von personenbezogenen Datensätzen oder vertraulichen Forschungsunterlagen erkannt werden können; andernfalls könnte ein Angreifer persistente Kommunikationskanäle nutzen, um über längere Zeit unbemerkt Daten abzuziehen. Eine wirksame Überwachung kann dabei Anomalien identifizieren, die auf Missbrauch, Malware-Aktivität oder Fehlbedienungen hindeuten, und kann die Integrität sowie Vertraulichkeit schützenswerter Informationen erhöhen. Mögliche Varianten der Umsetzung können auf datei- und inhaltsbasierter DLP-Analyse, Netzwerk-DLP über definierte inspection points, Monitoring von Cloud-Workloads mittels API-gestützter DLP-Funktionen oder Endpoint-DLP basierend auf Richtlinien für Kopieren, Drucken oder Übertragungen über Wechselmedien beruhen.
|
|
DET.4.6 Anomale Nutzung der Anwendung
|
Detektion für Anwendungen KANN die Nutzung der Anwendung auf Anomalien überwachen. Erläuterung Beispiele sind massenhafte Downloads von Dateiservern oder Cloud-Diensten, Datenbankabfragen die eine ungewöhnlich hohe Menge von Daten oder Einträgen, die unerreichbar sein sollen, zurückliefern, oder automatische E-Mail-Weiterleitungen an externe Domains.
|
|
DET.4.7 Auslaufen von Domains
|
Detektion für Webserver KANN das Auslaufen von Domains überwachen. Erläuterung Wenn Registrierungsfristen und Verlängerungszeiträume nicht im Blick behalten werden, könnte eine Domain aus Versehen verfallen und damit einhergehend Erreichbarkeitsprobleme, Vertrauensverluste oder gar Sicherheitslücken entstehen. Als Beispiele können Domains dienen, die für Webauftritte, E‑Mail-Systeme oder API-Endpunkte genutzt werden. Ebenso kann es sich um Subdomains handeln, die für interne Tools, Testumgebungen oder automatisierte Monitoringdienste registriert sind. Auch Domains, die nur der Weiterleitung auf Hauptpräsenzen dienen oder die für Zertifikatsverwaltung (z. B. ACME-Challenges) verwendet werden, können unter diese Überwachung fallen. Jede dieser Anwendungsfälle kann potenziell betroffen sein, wenn die Registrierung unbemerkt abläuft. Hilfreich ist hierfür ein zentrales Inventar aller genutzten Domains in dem Registrierungsdaten (Ablaufdatum, Registrar, Kontaktemail) erfasst werden. Automatisierte Scripts oder Aufgabentickets können eingerichtet werden, die in festgelegten Abständen (z. B. 60, 30 und 7 Tage vor Ablauf) eine Benachrichtigung auslösen. Auch Monitoring-Plattformen mit DNS-Plugins können verwendet werden, um Fristen zu prüfen und Erinnerungen zu generieren. Zusätzlich kann eine Prozessbeschreibung definiert werden, in der Verantwortlichkeiten und Eskalationswege bei nahendem Domainablauf festgehalten sind, um schnelle Entscheidungen und Verlängerungen zu ermöglichen.
|
|
DET.4.8 Ausstellung neuer HTTPS-Zertifikate
|
Detektion für Webserver KANN die rechtzeitige Ausstellung neuer HTTPS-Zertifikate für Hostsysteme, die im Internet erreichbar sind, überwachen. Erläuterung „Rechtzeitige Ausstellung neuer HTTPS-Zertifikate“ meint hier, dass überwacht wird, ob vor Ablauf eines bestehenden TLS-/HTTPS-Zertifikats ein neues, gültiges und zur jeweiligen Webserver-Identität passendes Zertifikat aktiviert wird (certificate expiry monitoring, certificate renewal). „HTTPS-Zertifikate“ sind hier X.509-Zertifikate für TLS-gesicherte Webverbindungen, die insbesondere Servernamen, Gültigkeitszeitraum, ausstellende Zertifizierungsstelle und kryptografische Bindung an einen Schlüssel enthalten. „Server, die im Internet erreichbar sind“ bezeichnet Webserver mit öffentlich erreichbarer Adresse oder öffentlich auflösbarem Namen, etwa Webportale, APIs, Kundenportale oder Administrationsoberflächen, sofern sie aus dem Internet angesprochen werden können. Die Vorschrift zielt darauf ab, ablaufende oder nicht rechtzeitig erneuerte Zertifikate frühzeitig sichtbar zu machen: Ein versäumter Austausch könnte zu Browserwarnungen, Dienstunterbrechungen, fehlgeschlagenen API-Verbindungen, Vertrauensverlust bei Nutzenden oder improvisierten Notfallmaßnahmen führen. Eine entsprechende Detektion kann die Verfügbarkeit und Vertrauenswürdigkeit öffentlich erreichbarer Webdienste unterstützen und kann zugleich Hinweise auf Fehlkonfigurationen, unvollständige Automatisierung oder unerwartete Änderungen im Zertifikatsbestand liefern. Hierbei ist es sinnvoll nicht nur die Restlaufzeit mit Schwellwerten zu überwachen, sondern auch die tatsächliche Bereitstellung des neuen Zertifikates. Dazu können ein Monitoring der Zertifikatsdaten direkt am Webendpunkt, sowie Auswertungen aus Load-Balancern oder Reverse-Proxys gehören.
|
|
DET.4.9 Manipulations-Checkup
|
Detektion für IT-Systeme KANN das System auf Manipulationsversuche [regelmäßig] überprüfen. Erläuterung Falls Systeme einem erhöhten Manipulationsrisiko ausgesetzt sind (z.B. wegen öffentlicher Aufstellung), die Vertraulichkeit oder Integrität des Systems oder damit verbundener Daten oder Netze jedoch nicht vernachlässigenswert ist, so ist eine regelmäßige Überprüfung auf Manipulationen empfehlenswert. Hierfür können Gerätesiegel verwendet werden. Maßnahmen bei Feststellung einer Manipulation können z.B. das Zurücksetzen auf den Werkszustand oder die Aussonderung sein.
|
|
DET.4.10 Host-basierte Köder
|
Detektion für IT-Systeme KANN Host-basierte Köder installieren. Erläuterung Köder sind Anwendungen, Dateien oder Datensätze auf dem IT-System, welche die Aufmerksamkeit von Angreifern auf sich ziehen, um diese zu entdecken, nachzuverfolgen oder von echten Zielen abzulenken. Sie werden auch als Canaries oder Tripwire bezeichnet. Beispielsweise kann das Sicherheitsteam eine gefälschte, aber verlockende Datei (z. B. „IBAN-Kontodaten.xlsx“) im System platzieren und eine Überwachung einrichten, die sie benachrichtigt, wenn die Datei berührt wird - da legitime Benutzer nicht darauf zugreifen können, signalisiert jede Interaktion potenziell unbefugte Aktivitäten. Ein weiteres Beispiel ist eine Datei „unattended.xml“, da sie für Angreifer nützliche Anmeldedaten für automatische Installationen enthalten könnte. Indem Sie eine gefälschte Version mit harmlosen Daten erstellen und den Zugriff auf die Datei oder Anmeldeversuche mit diesen Zugangsdaten überwachen, erhalten Sie eine frühzeitige Warnung, wenn jemand Ihr System auf der Suche nach einfachen Möglichkeiten zur Erlangung von Administratorrechten durchforstet, so dass Sie reagieren können, bevor es zu einem schwerwiegenderen Verstoß kommt. Allerdings kann es hierbei zu falsch-positiv Vorfallsmeldungen kommen, insbesondere wenn die Köder dort platziert werden wo sie für legitime Nutzende leicht zugänglich sind.
|
|
DET.4.11 Anomalien in Netzen und am Perimeter
|
Detektion für Netze SOLLTE den Netzwerkverkehr auf Anomalien überwachen. Erläuterung Beispiele sind ausgehende Netzverbindungen zu als bösartig bekannten oder gänzlich unbekannten DNS-Domains oder IP-Adressen, Anzeichen für DNS-Tunneling (ungewöhnlich lange Subdomains oder Spitzenwerte für TXT-Mengen), ungewöhnlich hohes Datenvolumen zu Cloud-Speicherlösungen, sowie unautorisierte Portscans oder Brute Force Angriffe auf Fernwartungsschnittstellen wie RDP oder SSH sein. Hierdurch können Verbindungen zu Angreiferservern (C2 Beacons), die Ausbreitung von Angriffen über das Netz, oder Datenabflüsse erkannt werden.
|
|
DET.4.12 Monitoring der Netzverfügbarkeit
|
Detektion für Netze SOLLTE die Verfügbarkeit des Netzes anhand von [Schwellwerten] überwachen. Erläuterung Die Verfügbarkeit von Netzen, insbesondere des Internetanschlusses, sowie im Kern- und Verteilernetz, ist von zentraler Bedeutung für die Verfügbarkeit von IT-Infrastrukturen. Ein Monitoring ermöglicht es dem Betriebspersonal, bei Netzproblemen reagieren zu können, bevor Beschwerden von Nutzenden aufkommen. Kann durch Hello-Packete von Netzkomponenten oder die Erreichbarkeit von Diensten über das Netz umgesetzt werden.
|
|
DET.4.13 Verfügbarkeit des Hostsystems
|
Detektion für Hostsysteme SOLLTE die Netzerreichbarkeit anhand von [Schwellwerten] überwachen. Erläuterung Schwellwerte (engl. thresholds) sind hier Grenzwerte, die als Maßstab für die normale oder erwartete Netzerreichbarkeit des Hostsystems dienen. Diese Schwellwerte könnten beispielsweise eine bestimmte Anzahl an Fehlversuchen zur Erreichbarkeit in einem definierten Zeitfenster oder eine überdurchschnittlich hohe Anzahl an Verbindungsanfragen sein, die auf ungewöhnliche Netzwerkaktivität hindeuten. Ein Server könnte beispielsweise aufgrund eines Denial-of-Service-Angriffs (DoS) nicht mehr erreichbar sein, wodurch Dienste für Nutzende ausfallen. Ebenso könnte eine unerwartete Nichterreichbarkeit auf einen Hardwaredefekt, einen Konfigurationsfehler oder einen internen Angriff hindeuten, bei dem der Server vom Netz getrennt wurde, um Spuren zu verwischen. Die Überwachung anhand von Schwellwerten kann der Institution dabei helfen, solche Vorfälle frühzeitig zu erkennen und zu reagieren, bevor sie größeren Schaden anrichten. Die Überwachung kann über ein internes Monitoring-System umgesetzt werden, das kontinuierlich die Erreichbarkeit der Server mittels sogenannter Health-Checks oder Probes prüft. Dabei kann beispielsweise ein automatisches Ping-Verfahren eingesetzt werden, das in regelmäßigen Abständen die Antwortzeit des Servers misst. Die festgelegten Schwellwerte könnten zum Beispiel die maximal erlaubte Anzahl an aufeinanderfolgenden fehlgeschlagenen Ping-Antworten oder die durchschnittliche Antwortzeit sein.
|
|
DET.4.14 Verfügbarkeit der Anwendung
|
Detektion für Anwendungen SOLLTE die Netzerreichbarkeit anhand von [Schwellwerten] überwachen. Erläuterung Dabei wird die Erreichbarkeit des Dienstes der Anwendung selbst, z.B. auf den bereitstellenden Servern, nicht nur die Erreichbarkeit des Systems überwacht.
|
|
DET.4.15 Ressourcenauslastung von Hostsystemen
|
Detektion für Hostsysteme SOLLTE die Ressourcenauslastung anhand von [Schwellwerten] überwachen. Erläuterung Hierzu zählt z.B. die Auslastung der CPU, des Arbeitsspeichers, des Festspeichers. Dazu ist es sinnvoll vorab Schwellwerte zu ermitteln (KPI Baselining). Mögliche Reaktionsmaßnahmen bei zu hoher Auslastung sind z.B. die Lastverteilung auf mehrere Host-Rechner oder die Beschränkung der Ressourcennutzung pro Client.
|
|
DET.4.16 Ressourcenauslastung der Server-Dienste
|
Detektion für Anwendungen KANN die Ressourcenauslastung der für die Anwendung verwendeten Server-Dienste anhand von [Schwellwerten] überwachen. Erläuterung Hierzu zählt z.B. die Auslastung der CPU, des Arbeitsspeichers, des Festspeichers und Anzahl der verbundenen Clients. Dazu ist es sinnvoll vorab Schwellwerte zu ermitteln (KPI Baselining). Mögliche Reaktionsmaßnahmen bei zu hoher Auslastung sind z.B. die Lastverteilung auf mehrere Host-Rechner oder die Beschränkung der Ressourcennutzung pro Client.
|
|
DET.4.17 Anwendungsbasiertes Kapazitätsmanagement
|
Detektion für Anwendungen KANN die Ressourcenauslastung systemübergreifend anhand von [Schwellwerten] überwachen. Erläuterung Hierbei kann nicht nur die aktuelle Auslastung einzelner Server, sondern die Auslastung der Anwendung insgesamt, auch über einen längeren Zeitverlauf inklusive Lastspitzen und Durchschnittswerten, betrachtet werden.
|
|
DET.4.18 Öffentliche Blocklisten
|
Detektion für E-Mail KANN öffentliche Blocklisten auf Einträge für eigene E-Mail-Server [regelmäßig] überprüfen. Erläuterung Die Überprüfung von E-Mail-Blocklisteneinträgen ist entscheidend, um sicherzustellen, dass Nachrichten zuverlässig zugestellt und nicht als Spam klassifiziert werden. Dazu kann zunächst mit Tools wie MXToolbox oder MultiRBL geprüft werden, ob und auf welchen Listen der Server geführt wird, um anschließend die genauen Ursachen zu ermitteln – häufig spielen kompromittierte Konten, unzureichende Authentifizierungsmethoden oder veraltete E-Mail-Listen eine Rolle. Nach der Identifikation können Admins die grundlegenden Probleme beheben, beispielsweise durch Implementierung von SPF-, DKIM- und DMARC-Protokollen, Bereinigung von E-Mail-Listen oder Beseitigung technischer Schwachstellen, bevor bei den jeweiligen Blocklistenbetreibern ein Antrag auf Entfernung gestellt werden kann, wobei in der Regel Nachweise für die durchgeführten Verbesserungen erforderlich sind; zur langfristigen Prävention kann eine regelmäßige Überwachung der Senderreputation, sowie die Einhaltung bewährter E-Mail-Praktiken beitragen, oder die Nutzung eines seriösen E-Mail-Dienstleisters in Betracht gezogen werden.
|
|
DET.4.19 Unautorisierte Sendeanlagen
|
Detektion für Räume KANN diesen nach unautorisierten Sendeanlagen durch [einen automatisierten Mechanismus] überwachen. Erläuterung Bleiben unautorisierte Sendeanlagen unbemerkt, so könnten hierüber Abhörversuche stattfinden oder Störungen legitimer Sender und Empfänger auftreten. Bedenklich sind beispielsweise versteckte Wanzen in Büromöbeln, manipulierte Peripheriegeräte mit eingebauten Sendern, ohne Erlaubnis mitgebrachte Access Points, modifizierte Smartphones mit verdeckten Fernzugriffsfunktionen oder getarnte IoT-Geräte mit Netzwerkverbindung, die sensible Informationen abgreifen und nach außen übertragen könnten. Zum Aufspüren können Wireless Intrusion Detection Systems (WIDS) genutzt werden, welche Sendeanagen auffinden und unbekannte Sender melden. Um unautorisierte Sender effektiv zu erkennen sind auch begleitende Maßnahmen sinnvoll: Die Implementierung von Zugangsbeschränkungen und Mitnahmeverboten für nicht geprüfte elektronische Geräte; die Schulung des Personals zur Erkennung verdächtiger Objekte; sowie die Dokumentation aller autorisierten Geräte in einem Inventar, um unbekannte Signalquellen schnell identifizieren zu können.
|
1.1 Referencias
1.2 Requisitos identificados
1.3 Regulaciones relacionadas
2. Requisitos identificados
Requisitos
| Fuente |
Requisito |
3. Regulaciones relacionadas
Regulaciones
| Fuente |
Regulación |
|