SerNet IT-Grundschutz-Baustein DER.1: Erfahrungsbericht aus der SIEM-Einführung - Dezember 2020

SerNet

IT-Grundschutz-Baustein DER.1:

Erfahrungsbericht aus der
SIEM-Einführung

03. Dezember 2020

Alexander Koderman

SerNet GmbH, Göttingen - Berlin

Basisratenfehler   SerNet

Inhalt                                                         SerNet

     Anforderung: „Erkennung von Sicherheitsereignissen“

     Wo hört „Ereignis“ auf und fängt „Sicherheitsereignis“ an?

     Datenquellen

     Auswertung

     Hindernisse und Lösungen

SerNet GmbH                                                                              SerNet

    gegründet 1996

    Büros in Göttingen und Berlin

    Schwerpunkt Informationssicherheit und Datenschutz

    bevorzugter Einsatz von Open Source Software

    Fachabteilungen:
         ITSEC: technische Sicherheitslösungen für Industrie und öffentl. Hand (Firewalls, VPN und mehr)
         verinice.: Open Source Tool für Informations-Sicherheits-Management
         Samba: Open Source Alternative zu Windows-Servern
         winwerk: Infrastruktur auf Basis von Microsoft-Lösungen

    SerNet ist klassischer Mittelstand, kein Risiko-Kapital, keine Bank-Kredite

    über 2500 Bestandskunden in DE, EU, US und weltweit

IT-Grundschutz: Erkennung von
Sicherheitsvorfällen                                                          SerNet

     DER.1.A5: „Verfügen eingesetzte IT-Systeme oder Anwendungen über Funktionen, mit
      denen sich sicherheitsrelevante Ereignisse detektieren lassen, MÜSSEN diese
      aktiviert und benutzt werden.“

     Auf allen eingesetzten Komponenten MUSS die Protokollierung aktiviert werden
      (siehe OPS.1.1.5 Protokollierung). Liegt ein sicherheitsrelevanter Vorfall vor, MÜSSEN
      die Meldungen der betroffenen IT-Systeme ausgewertet werden. Zusätzlich MÜSSEN
      die protokollierten Ereignisse anderer IT-Systeme überprüft werden.

     Es MUSS geprüft werden, ob zusätzliche Schadcodescanner auf zentralen IT-
      Systemen installiert werden sollen. Ist dies der Fall, MÜSSEN diese es über einen
      zentralen Zugriff ermöglichen, ihre Meldungen und Protokolle auszuwerten.

     DER.1.A2: „Wenn Protokolldaten ausgewertet werden, [...] MÜSSEN die
      Persönlichkeitsrechte bzw. Mitbestimmungsrechte der Mitarbeitervertretungen gewahrt
      werden, wenn Detektionssysteme eingesetzt werden.“

IT-Grundschutz: Standard-Anforderungen                                         SerNet

     DER.1.A6: „Alle Protokolldaten SOLLTEN möglichst permanent aktiv überwacht und
      ausgewertet werden. Es SOLLTEN Mitarbeiter benannt werden, die dafür verantwortlich
      sind.“

     DER.1.A9: „Der Informationsverbund SOLLTE um zusätzliche Detektionssysteme und
      Sensoren ergänzt werden. So SOLLTEN Schadcodedetektionssysteme eingesetzt und
      zentral verwaltet werden. Auch die im Netzplan definierten Übergange zwischen internen
      und externen Netzen SOLLTEN um netzbasierte Intrusion Detection Systeme (NIDS)
      ergänzt werden.“

     DER.1.A11: „Die gesammelten Ereignismeldungen der IT-Systeme und Anwendungen
      SOLLTEN auf einer zentralen Protokollinfrastruktur [...] aufbewahrt werden. Die
      eingelieferten Ereignismeldungen SOLLTEN mithilfe eines Tools zentral gespeichert,
      ausgewertet und abgerufen werden können. Damit die Daten korreliert und abgeglichen
      werden können, SOLLTEN sie alle zeitlich synchronisiert werden. Die gesammelten
      Ereignismeldungen SOLLTEN regelmäßig auf Auffälligkeiten kontrolliert werden.“

IT-Grundschutz: bei erhöhtem Schutzbedarf                               SerNet

     DER.1.A14: „Ein Personenkreis SOLLTE benannt werden, der ausschließlich für
      das Thema Auswertung von Protokolldaten verantwortlich ist, wie z. B. aus dem
      Bereich Forensik.“

     DER.1.A15: „Zentrale automatisierte Analysen mit Softwaremitteln SOLLTEN dazu
      eingesetzt werden, um alle in der Systemumgebung anfallenden Ereignisse
      aufzuzeichnen, in Bezug zueinander zu setzen und sicherheitsrelevante Vorgänge
      sichtbar zu machen. [...] Die Daten SOLLTEN möglichst permanent ausgewertet
      werden. Werden definierte Schwellwerte überschritten, SOLLTE automatisch
      alarmiert werden.“

     DER.1.A17: „SOLLTEN die eingesetzten Detektionssysteme das Ereignis
      automatisch melden und mit geeigneten Schutzmaßnahmen reagieren […] Es
      SOLLTE möglich sein, automatisch in den Datenstrom einzugreifen, um einen
      möglichen Sicherheitsvorfall zu unterbinden.“

Vergleich: Vorgaben im Finanzsektor                                 SerNet

     BaFin BAIT Tz. 17: „Auf Basis der Informationssicherheitsleitlinie sind
      konkretisierende, den Stand der Technik berücksichtigende
      Informationssicherheitsrichtlinien und Informationssicherheitsprozesse mit
      den Teilprozessen Identifizierung, Schutz, Entdeckung, Reaktion und
      Wiederherstellung zu definieren.“

     „Informationssicherheitsrichtlinien werden bspw. für die Bereiche
      Netzwerksicherheit, Kryptografie, Authentisierung und Protokollierung
      erstellt. Informationssicherheitsprozesse dienen in erster Linie zur
      Erreichung der vereinbarten Schutzziele. Dazu gehört u. a.,
      Informationssicherheitsvorfällen vorzubeugen und diese zu
      identifizieren sowie die angemessene Reaktion und Kommunikation im
      weiteren Verlauf.“

Vergleich: Vorgaben im Finanzsektor                                        SerNet

     ECB, Cyber resilience oversight expectations for financial market infrastructures,
      12ff: „The FMI should develop and implement automated mechanisms (e.g. a
      security information and event management (SIEM) system), which
      correlates all the network and system alerts and any other anomalous
      activity across its business units in order to detect multifaceted attacks (e.g.
      simultaneous account takeover or a distributed denial of service (DDoS) attack).“

     „The FMI should have a process to collect, centralise and correlate event
      information from multiple sources and log analysis to continuously monitor
      the IT environment (e.g. databases, servers and end points, etc.) and detect
      anomalous activities and events. This should include information on anomalous
      activity and other network and system alerts across business units. This capability
      could be achieved through a security operations centre (SOC) or equivalent.“

Terminologie                                                  SerNet

     Log Monitoring:
          Sammlung und Auswertung, Benachrichtigung

     Log Management:
          Konfiguration, Homogenität, Sammlung und Speicherung

     SIEM: Security Information and Event Management
          Aggregation, Korrelation von Logfiles und anderen Datenquellen.
           Auswertung und Benachrichtigung

Terminologie                                                      SerNet

     SOC: Security Operating Center
          Einheit in einer Organisation, welche sicherheitskritische
           Infrastruktur überwacht und auf Sicherheitsereignisse
           angemessen reagieren kann.

     CERT: Computer emergency response team
          Einheit in einer Organisation zur Sicherheitsvorfallbehandlung
           und –vorbeugung. Trademark der Carnegie Mellon University.

     CSIRT: Computer Security Incident Response Team
          Markenrechtlich nicht geschützter Oberbegriff für CERTs.

Datenquellen (Beispiel: Splunk)   SerNet
   Throughput:
        3 EPS (Windows
         Server)
        30 EPS
         (Netflow/IPFIX)

   Storage:
        0,2-30GB täglich
         pro Anwendung

   Retention:
        6 Monate:
         36-5400 GB

                                    Quelle: splunk.com

Auswertung: Monitoring   SerNet

Auswertung: Alerting   SerNet

Misserfolgsfaktor 1: Regeln                                 SerNet

     Das Tool bringt ja Auswertungsregeln mit.

     Davon ausgehen, dass die auf die vorhandenen Datenquellen
      passen.

     Kein Konzept für die Use Cases erstellen.

     Die Business Owner müssen wir damit nicht belasten.

     Versionskontrolle auf den Abfragen ist nicht nötig.

Regeln aus Compliance-Vorgaben ableiten!                                         SerNet

                                                                            ITGS: ORP.4.A2, ORP.4.A3,
                                                                          ORP.4.A7, ORP.4.A11, ORP.4.A15,
                                                                              ORP.4.A19, ORP.4.A23

                                                                             ITGS: ORP.4.A6, ORP.4.A7

                                                                            ITGS: ORP.4.A1, ORP.4.A4,
                                                                            OPS.1.1.2.A5, OPS.1.1.2.A6,
                                                                            OPS.1.1.2.A7, OPS.1.1.2.A8,
                                                                           OPS.1.1.2.A11, OPS.1.1.2.A15,
                                                                           OPS.1.1.2.A1, OPS.1.1.2.A17,
                                                                                 OPS.1.1.2.A18,

Quelle: Shoogee GmbH, http://www.shoogee.com/de/it-consulting.html#siem

Erkennug von Angriffen:
MITRE ATT&CK Framework                                                       SerNet

                          Quelle: https://www.microsoft.com/security/blog/2020/04/02/attack-matrix-kubernetes/

Misserfolgsfaktor 2: Log-Management                          SerNet

     Nur Application-Logs (nur OS-Logs / nur DB-Logs / …)

     Unterschiedliche Timestamps

     Unterschiedliches Logformat

     Zu wenig Log-Events

     Zu viele Log-Events

     Nur Logfiles auswerten, Konfigurations-Updates missachten

Misserfolgsfaktor 2: Log-Management                          SerNet

     Nur Application-Logs (nur OS-Logs / nur DB-Logs / …)

     Unterschiedliche Timestamps

     Unterschiedliches Logformat

     Zu wenig Log-Events

     Zu viele Log-Events

     Nur Logfiles auswerten, Konfigurations-Updates missachten

     => Log-Management zuerst / gleichzeitig etablieren!

Misserfolgsfaktor 3: Access Management                        SerNet

     kein Privileged Access Management

     AD-Updates / Logon / Logoff nicht auswerten!

     Kein Session Manager, kein Session Monitor.

     Sende 30.000 “sudo” Aufrufe pro Tag zur Verifikation an den
      Prozesseigentümer!

SIEM für Privileged Access Management                                                          SerNet

              Source: https://security-architect.com/privileged-account-management-pam-is-very-important-but-deploying-it-stinks/

Known Unknowns: Das Anti-Inventory                               SerNet

                               (Michael Collins: Network Security Through Data Analysis, 2nd Edition)

Unsichtbares sichtbar machen                                                           SerNet

     Fumbling
          Misconfiguration, Automation, Scanning
          Lookup Failures
          TCP Fumbling: Failed Sessions

     Volume & Time
          DDoS, Flash Crowd, Cable Cuts
          Beaconing
          File Extraction, File Transfer, Raiding

     Threat Intel
          IoA, IoC, TTP

     Aktive Reaktion: ständige Anpassung der Regeln an beobachtete Angriffe

                                                     (Michael Collins: Network Security Through Data Analysis, 2nd Edition)

Unsichtbares sichtbar machen                                                           SerNet

     Fumbling
          Misconfiguration, Automation, Scanning
          Lookup Failures
          TCP Fumbling: Failed Sessions

     Volume & Time
          DDoS, Flash Crowd, Cable Cuts
          Beaconing
          File Extraction, File Transfer, Raiding

     Threat Intel
          IoA, IoC, TTP

     Aktive Reaktion: ständige Anpassung der Regeln an beobachtete Angriffe

                                                     (Michael Collins: Network Security Through Data Analysis, 2nd Edition)

Misserfolgsfaktor: SIEM-Prozesse nicht mit
Personal ausgestattet                        SerNet

SIEM Prozesse   SerNet

Kontakt                                         SerNet

     Alexander Koderman, AK@sernet.de
     SerNet GmbH
     Bahnhofsallee 1b       Torstraße 6
     37081 Göttingen        10119 Berlin

     tel +49 551 370000-0   +49 30 5 779 779 0
     fax +49 551 370000-9   +49 30 5 779 779 9

     http://www.sernet.de

© 2020, SerNet GmbH                                  27