​Die Fragen sind im Rahmen von Webcasts und weiteren Veranstaltungen aufgekommen. Wir haben sie nach bestem Wissen und Gewissen beantwortet und hoffen, dass es nützlich ist. Weitere Fragen immer gerne an info@ausecus.com.

​

• Wieso ist es wichtig, zu wissen woher der Angriff kommt (Attribution?)

  • Um die Reaktion auf den Angriff diesem anzupassen und die richtigen Gegenmaßnahmen treffen zu können. Die Feuerwehr rückt bei Hochwasser mit anderem Werkzeug aus als bei einem Wohnungsbrand im 3. OG.

​

• Wer liefert mir die Regelsätze? Es ist doch sicherlich ein riesige Datenmange.

  • Es gibt viele Experten, die gemeinsam an einer Open Source Datenbank arbeiten und diese zur Verfügung stellen.
    Dazu kann der Betreiber des Angriffserkennungssystems noch spezifische Gegebenheiten des überwachten Netzwerks einbeziehen, beispielsweise die KRITIS Meldungen des BSI. Die Datensätze sind Textdateien und wenige MB groß. Aktuell liegen wir bei 40 MB.

​

• Regelbasiert und Anomaliebasiert schließen sich aber nicht aus ? (Beim Ansatzwerk)

  • Nein, nicht direkt. Viele Systeme nutzen Ansätze aus beiden Methoden. Letztlich ist der Einsatzzweck entscheidend, welcher Ansatz funktioniert.

​

•  Was ist Logging  (im Sinne von Angriffserkennung)?

  • Der Begriff Logging beschreibt ganz grundsätzlich die Protokollierung von bestimmten Ereignissen. Üblicherweise wird damit die Sammlung von Betriebslogs (z.B. syslog, Ereignisanzeige) eines Hosts gemeint. Diese Logs können durch eine Anwendungssoftware (z.B. Webserver), das Betriebssystem oder weitere Quellen (z.B. Firewall-Regeln) erzeugt werden. Daneben können auch die Verbindungsdaten zwischen Systemen geloggt werden, bspw. durch ein Netzwerk Intrusion-Detection System.

  • Angriffserkennung nutzt die gesammelten Log-Daten aus unterschiedlichen Quellen und durchsucht diese nach Angriffen. Die Vor- und Nachteile beim Einsatz der jeweiligen Verfahren in Bezug auf die Angriffserkennung unterscheiden sich je nach Art des Netzwerks, der Endgeräte und deren Konfiguration.

​

• Was unterscheidet (hostbasiertes) Logging von Netzwerk Intrusion Detection (NIDS)?

  • NIDS protokolliert die Verbindungsdaten zwischen Systemen, hostbasiertes Logging protokolliert die Betriebslogs eines Systems. Bestimmte Informationen können in jeweils nur einem der genannten Logs enthalten sein. So befinden sich bspw. aufgerufene URLs bei HTTPS-Verbindungen häufig im Log eines Proxy-Servers, wohingegen ein NIDS diese Information aufgrund der Verschlüsselung nicht erkennen kann. Im Gegenzug dazu kann nicht jedes Gerät Logs gleicher Güte erstellen. So werden bspw. bei bestimmten SPS nur erfolgreiche, nicht jedoch fehlerhafte Logins protokolliert, was mit einem NIDS einfacher erkannt werden kann.

  • Je nach Anwendungsfall kann also die eine oder andere Informationsquelle von höherer Relevanz sein. Als Best-Practice gilt eine sinnvolle Anwendung beider Verfahren unter fachlich fundierter Abwägung und einer Betrachtung der jeweils dafür notwendigen Ressourcen.

​

• Brauche ich im Kraftwerk 2 Systeme, eins für den volatilen Teil und eins für den Statischen (Stationsleittechnik) ?

  • Ein regelbasiertes Angriffserkennungssystem kann auch hervorragend in statischen Netzwerken eingesetzt werden. Nötig für eine sehr gute Erkennung sind auf das Netzwerk abgestimmte Regelsätze und eine passende Konfiguration.

​

• (Über regelbasierte Angriffserkennung. Metapher war "Erkenne jede Person, die mit einer Waffe im Haus unterwegs ist" und der Postbote wird erkannt.)Nachteil: wenn der Postbote auf einmal einen Schnurrbart trägt, wird es wieder schwierig mit dem Phantombild...

  • Wenn der Postbote eine Waffe trägt, wird er trotzdem erkannt. Der Schnurrbart allein wäre ja auch noch nicht kritisch.
    Natürlich hat jedes System seine Grenzen und kann mit genügend hohen Ressourcen immer umgangen werden. Dennoch zeigt die regelbasierte Methode in der Praxis schon sehr spezifische und gute Erkennungsraten.

  • Bei Anomalieerkennung würde der Postbote entweder immer, gar nicht oder mit einem bisher nicht bekannten Gerät in der Hand alarmiert werden. Das Gerät könnte die Waffe, aber auch ein neuer Paket-Scanner etc. sein. Aber auch eine Postbotin würde alarmiert werden. Oder jemand von HERMES, UPS, etc. Sobald halt was anders ist. Man hat damit immer False-Positives. Sucht man hingegen nur nach der Waffe, ist es egal wer sie trägt.

​

• Die Angriffserkennung muss regulatorische Anforderungen erfüllen. Wie sieht der Prozess aus, um dies zu erreichen ? Nach welchen Standard, Prozesse usw. soll die Implementierung erfolgen ?​

  • Es gibt noch keinen offiziell verabschiedeten Leitfaden des BSI zu den Anforderungen an Angriffserkennungssysteme für KRITIS Betreiber. Das Grundprinzip dessen lässt sich aber bereits klar erkennen – letzte Details sind noch zu klären. Wir stehen diesbezüglich im engen Austausch mit dem BSI.
    Die Erfahrungen zeigen jedoch, dass es sinnvoll ist, bereits jetzt zu starten. Dadurch können Erfahrungen im Umgang mit dem System gesammelt werden. Kurz vor dem Nachweis-Datum ohne jede Erfahrung ins kalte Wasser zu springen birgt viele Risiken (Lieferverzögerungen, Personalausfall, kollidierende Projekte, etc.) und verursacht auf jeden Fall Stress auf Seiten des Anwenders.

​

• Wie bekomme ich die Regelsätze ständig in unser Leitsystem wenn es keine Netzwerkverbindung gibt?

  • Auf dem gleichen Weg wie auch sonst Updates in das System eingespielt werden. Es sollte ein DMZ-Konzept ähnlich den Antivirus- bzw. Betriebssystem-Updates etabliert werden.
    Aus Sicherheitssicht ist ein solcher Aufbau unkritisch, da das Angriffserkennungssystem selbst ja nur eine Kopie des Datenverkehrs (Spanning-Port) bekommt und keine Einflussnahme auf die technischen Netzwerke nehmen kann. Die Management-Oberfläche kann in einer gesicherten DMZ liegen, von der aus nur auf die Update-Server zugegriffen werden darf. Verbindungen ins Leitsystem können unterbunden werden.
    Für Air-Gapped Netzwerke kann auch ein manuelles Update der Regelsätze (z.B. via USB, etc.) erfolgen.

​

• Aus Ihrer Erfahrung, welcher Aufwand entsteht in einem Kraftwerk, zur Bewertung der Alarme (Annahme: gute Regelsätze)?

  • Ein Experte, der Vollzeit in der Angriffserkennung arbeitet, benötigt unserer Erfahrung nach mindestens rund 3 Stunden im Monat für eine einigermaßen aussagekräftige Bewertung (kleines, eher statisches Netzwerk). Dazu kommt dann noch der Aufwand für den eigentlichen Systembetrieb, eventuelle Systemanpassungen, Updates von Regelsätzen und Software sowie die Abstimmung mit den Kollegen zu den einzelnen Sicherheitsereignissen.

​

• Wie sieht es bei den Systemen mit Datenschutz aus?

  • Antwort aus Nutzerkreis: Datenschutz sollte in ICS bzw. SCADA Netzwerken keine Rolle spielen, da es sich nicht um Personenbezogene Daten handelt. Die IP-Adressen beziehen sich in der Regel auf Automaten.

  • Die Antwort aus dem Nutzerkreis ist korrekt, sofern das System auch nur dort eingesetzt wird. In Leitsystemen liegen jedoch personenbezogene Daten (z.B. Login-Zeitpunkte, Zugangsdaten, etc.) vor, die entsprechend behandelt werden müssen. Hierzu ist der Datenschutzbeauftragte einzubeziehen.
    Wir behandeln bei unserem System grundsätzlich alle Analysedaten entsprechend datenschutzkonform – einfach um sicherzugehen.

  • Da personenbezogene Daten auf einem solchen Angriffserkennungssystem anfallen und damit ausgewertet und gespeichert werden können, ist die Einbeziehung Ihres DSB erforderlich. Sie benötigen eine Verfahrensbeschreibung, ein TOM Dokument und eine Datenschutz-Folgeabschätzung. Wenn ein Dritter auf diese Daten Zugriff erhält (z.B. Systemwartung) oder einen Teil der Leistungen erbringt (Managed Security Service), dann ist auch ein Vertrag für Auftragsdatenverarbeitung erforderlich. Erfahrene Dienstleister haben diese Dokumente bereits parat.
    Vergessen Sie nicht Ihre Mitarbeitervertretung in die Planung und den Einsatz solcher Systeme einzubeziehen, da sie eine Auswertung des Nutzerverhaltens zulassen. Ggf. ist die Aufnahme in eine bestehende Betriebsvereinbarung von ähnlichen Systemen (z.B. aus der Büro-IT) sinnvoll.

​

• Wie werden bestätigte Anomalien gepflegt? Automatisch?

  • Der Normalzustand („bestätigte Anomalien“) ist manuell nachzupflegen. Eine KI kann unterstützen, muss aber auch kontrolliert werden. Letztendlich sollte das „Mitdenken“ immer von einem erfahrenen Administrator oder Analysten gemacht werden. In regelbasierten Systemen können für bestimmte Regelsatz-SIDs entsprechende Ausnahmen definiert werden. Dies geschieht manuell.

​

• Die Regelsätze können auch nicht als Out of the Box entnommen werden. Studien haben erwiesen dass de Benutzung von Out of the box Regelsätze keinen langfristigen Schutz gewährleisten

  • Aktuelle Regelsätze steigern den Schutz deutlich, da neue Angriffe zeitnah erkannt werden können. Wir raten daher zu einer regelmäßigen und automatischen Aktualisierung, idealerweise täglich und ggf. auch außerplanmäßig.
    Die angesprochenen Open-Source Regelsätze (ET OPEN) werden täglich aktualisiert. Bei gesteigerten Anforderungen kann auf erweiterte Regelwerke diverser Anbieter (ET PRO, Proofpoint, etc.) zurückgegriffen werden.
    Eine direkte Out-of-the-Box Verwendung ist in den seltensten Fällen sinnvoll – wir raten zu einer Anpassung der Regelwerke an die zu überwachenden Netzwerke.

​

• Wie beurteilen Sie den Pflegeaufwand der beiden Systemtypen? / Und den Erstinstallationsaufwand sowie die Kosten (Anschaffung und Pflege) (im Direktvergleich Anomalieerkennung und regelbasierte Erkennung)

  • Regelbasierte Systeme haben zu Beginn einen erhöhten Aufwand, solange bis die Ausnahmen (Normalzustand) oder evtl. spezifischen Regelsätze für einzelne Anwendungsfälle erstellt sind (ca. 1 – 3 Personentage). Im Betrieb ist der Aufwand auf jeden Fall überschaubar, sofern man die notwendige Erfahrung im Umgang mit dem System und effiziente Werkzeuge für die Analyse der Alarme und des Datenverkehrs hat. Nicht jedes System bringt hier gleich gute Werkzeuge standardmäßig mit.

  • Anomaliebasierte Systeme lernen zu Beginn die bestehenden Netzwerkverbindungen. Diese müssen dann sortiert und klassifiziert werden. Das erfordert Aufwand. Im Betrieb sollte dann jede alarmierte Abweichung analysiert werden. Je mehr Änderungen im Netzwerk erfolgen (z.B. Updates, neue Geräte, etc.), desto höher der Aufwand dafür. Auch hier spielen effiziente Werkzeuge für die Analyse eine entscheidende Rolle, um die Abweichungen zu begutachten und einzustufen.

​

• Wird für die Appliance für die Angriffserkennung ein extra Speicher benötigt? Also der Netzwerktraffic muss ja irgendwo gespeichert werden oder erfolgt dies on demand?

  • Die Appliance enthält üblicherweise einen Speicher (SSD) für Betriebssystem und Analysedaten. Die Mitschnitte des Roh-Datenverkehrs (PCAPs) können dort in einer Art Ringspeicher zwischengespeichert werden. Die maximale Speicherdauer hängt von der zur Verfügung stehenden Größe des Datenspeichers ab. Bei bspw. 20 Mbit/s (=2,5 MB/s) durchschnittlichem Datenverkehr reicht ein 1 TB Speicher knapp 5 Tage.
    Die Erfahrung zeigt, dass eine Speicherung der Meta-Daten (Flows, Header, IPs, Ports, Protokolle, erste Bytes der Payload, etc.) häufig eine deutlich größere Aussagekraft haben als die PCAPs. Hier können mit ähnlichen Speichergrößen durchaus Zeiträume bis zu einem Jahr erreicht werden. In jedem Fall gilt neben der Größe insbesondere auch die Performance des Speichers beim Durchsuchen dieser Roh- oder Meta-Daten zu beachten.
    Für die Backups der Analyse-Daten sollte ebenfalls ein geeigneter Speicher (z.B. NAS) eingeplant werden.

​

• Am Anfang muss eine Untersuchung der IT-Infrastruktur der Organisation erfolgen. Wer mach das,  wie werden die Protokollierungsquellen ermittelt und was wenn die Regelsätze nicht alle Anwendungen und IT-Systeme abdecken ?

  • Zu Beginn müssen die Systemanforderungen (IP, DNS, NTP, Platzierung des Systems, Bandbreite, etc.) abgestimmt werden. In den ersten Betriebstagen erfolgt dann die Festlegung des Normalzustands bzw. der Ausnahmen für bestimmte Regelsätze. Eine solche Untersuchung sollte immer vom späteren Betreiber des Angriffserkennungssystems durchgeführt werden. Kenntnisse über das jeweilige Netzwerk und aktuelles Know-How über Angriffserkennung sind eine Grundvoraussetzung dazu.
    Die Erfahrungen aus unseren Systemen zeigen, dass gerade zu Beginn häufig viele falsch-positive Alarme auftreten. Wir bereiten die Erst-Analyse entsprechend vor und gehen die Ergebnisse mit dem Kunden gemeinsam durch. Dieses Vorgehen hat sich bewährt und ist sehr effizient.
    Sollten die Regelsätze nicht ausreichen, können neben den öffentlich verfügbaren Regeln weitere kommerzielle Quellen „abonniert“ werden.