Handlungsleitfaden zur Umsetzung der Anomalieerkennung

Aktuelles

Im Artikel BSIG Kritis-Gesetz und §8a haben wir bereits darüber berichtet, dass mit dem BSI-Gesetz die Pflicht für kritische Unternehmen definiert wurde, angemessene organisatorische und technische Maßnahmen zur Vermeidung von Störungen der Verfügbarkeit, Integrität, Authentizität und Vertraulichkeit ihrer informationstechnischen Systeme, Komponenten oder Prozesse zu treffen. Dahinter verbirgt sich die Anforderung, eine Angriffs- und Anomalie-Erkennung inkl. geeigneter Reaktionen zu implementieren. In diesem Artikel widmen wir uns der Handlungsempfehlung, wie die Implementierung in der Praxis gelingen kann.

Wo?

Grundsätzlich stellt sich die Frage, an welchen Stellen die Detektion stattfinden soll. Im KRITIS Umfeld ist ein neuralgischer Punkt oftmals das Prozessleitsystem, also die Betriebsumgebung zur Durchführung der Leistung, beispielsweise zur Steuerung von Strom- bzw. Gas-Versorgung. Diese Systeme sind häufig gekapselt und ggfs. auch in verschiedene Betriebssäulen wie Produktion und Testbetrieb untergliedert. Das Prozessleitsystem zu überwachen ist grundsätzlich sinnvoll. Jedoch muss dabei beachtet werden, dass die Betriebssicherheit nicht gefährdet wird. Übergänge zwischen Prozessleitsystem und anderen Bereichen bieten sich deshalb für netzwerkbasierte Ansätze durchaus an. Weitere Übergänge wie Netzwerk-Übergänge sind ebenfalls sinnvolle Punkte, für eine solche Überwachung.

Nicht nur auf Netzwerk-Ebene ist eine Überwachung wichtig, auch die Systemebene verdient Aufmerksamkeit. Logdateien liefern beispielsweise wichtige Informationen pro System Preis. Diese zu überwachen sorgt dafür, dass bei unbekannten oder neuen Log-Meldungen direkt eine Beobachtung dieses Systems erfolgt.

Was?

Für einen Überblick über die Systeme und der Verantwortlichkeiten, bietet sich die Verwaltung aller Assets in einer CMDB (Configuration Management Database). Dort können auch die Konfigurationen der Systeme dokumentiert werden, was beim Anlernen der Anomalie-Detektion enorm hilfreich sein kann.

Die Verwaltung aller Assets an einer zentralen Stelle sorgt zudem dafür, dass auch bei verschiedenen Bereichen innerhalb der Kerninfrastruktur ein kompletter Überblick besteht. Das ist nicht nur für die Umsetzung der Anomaliedetektion wertvoll, sondern sorgt auch bei detektierter Schwachstelle dafür, dass alle betroffenen Systeme die wichtigen Patches erhalten.

Womit?

Systeme zur Anomalie-Erkennung gibt es mehrere am Markt. Sie arbeiten in der Regel nach einem ähnlichen Funktionsprinzip, wobei der Datenstrom der Netzwerke durch die Detektions-Gateways geführt wird. Das System lernt somit den kompletten Datenstrom “kennen”. Nach einigen Wochen hat das System den meisten Datenverkehr erlernt, sodass dieser dann an der Appliance als “gewünscht” definiert werden kann.

Bei der Auswahl solcher Systeme sollte extrem darauf geachtet werden, dass die Systeme zur Infrastruktur passen. Werden viele virtuelle Netzwerke verwendet, müssen die Geräte in der Lage sein, diese mitzulesen. Innerhalb des Prozessleitsystems kommen Industrieprotokolle wie das 104rer Protokoll zum Einsatz. Es ist daher wichtig, dass die Systeme zur Anomalieerkennung diese Protokolle kennen, sodass auch eine inhaltliche Anomalie erkannt werden kann. Auf Grund der Funktionsweise, wie die Systeme passiv im Netzwerk arbeiten, muss vor der Implementierung der Netzwerkdurchsatz an den verschiedenen Stellen ermittelt und mit reichlich Puffer für die Systemauswahl berücksichtigt werden. Andernfalls können Systeme zur Abwehr auch ein Flaschenhals für das Netzwerk werden.

Die Daten, die über die Gateways zur Anomalieerkennung gesammelt werden, sollten ebenfalls an einen zentralen Ort geleitet und dort strukturiert aufbereitet werden. Hierfür kommt ein SIEM (Security Information and Event Management) zum Einsatz. Das nimmt die Informationen entgegen und bietet darüber hinaus Funktionen wie Filterung, Alarmierung von Gruppen oder zuständigen Personen und die Bearbeitung der Meldung an.

Wichtig ist, bei der Integration darauf zu achten, dass die Schnittstellen alle so gewählt sind, dass ein zentraler Datenpool möglich ist. Denn nicht nur die Daten aus der Anomalie-Detektion im Netzwerk müssen an einem zentralen Ort zur Verfügung stehen. Auch die Log- und Anmeldedaten von Systemen, soweit diese es zulassen, müssen an zentraler Stelle verarbeitet werden können. Für die Authentifizierung bieten sich Mehr-Faktor-Authentifizierungs-Konzepte an. Für die Datenübertragung ist darauf zu achten, dass die Kommunikation sicher, also verschlüsselt, erfolgt.

Prozess?

Auch wenn wir bisher ausschließlich von Systemen gesprochen haben, sind diese eher als Mittel zum Zweck zu verstehen. Die Anomalie-Detektion und Reaktion auf mögliche Angriffe sind vor allem ein Prozess-Thema. Egal ob der Sicherheits-Prozess komplett inhouse erledigt wird oder durch externe SOC (Security Operation Center) Dienstleistungen ergänzt werden, die Daten müssen zentral, schnell und aggregiert zur Verfügung stehen, damit sich effektiv Rückschlüsse ziehen lassen. Die Verantwortlichkeiten im Regel- und Notfallbetrieb müssen zwingend vorab festgelegt werden. Ein weiterer Punkt ist, Sorge dafür zu tragen, dass der Incident Responce Prozess regelmäßig trainiert wird, um im Notfall sowohl die nötige Ruhe und Routine haben wie auch die erfolgreiche Schnelligkeit bei der Reaktion auf mögliche Bedrohung.

Quelle Pexels.com

Reifegrad?

Sind Prozess und Systeme implementiert, steht der wichtigste Schritt noch aus; die Erhöhung des Reifegrades innerhalb des Incident Responce Prozess‘. Gerade in der Trainingsphase wird es vermehrt zu Fehlalarmen kommen. Das Regelwerk so anzupassen, dass die richtigen Meldungen durchkommen, die falschen Meldungen jedoch verhindert werden, ist eine zeitaufwendige Aufgabe. Der beste Prozess und die besten Systeme nützen nichts, wenn die Mitarbeiter nicht mehr darauf reagieren, weil Sie es ohnehin für einen Fehlalarm halten.

Bereits bei der Beschaffung der Systeme zur Anomalie-Detektion ist also darauf zu achten, dass sich die Systeme feingranular konfigurieren lassen, um sinnvolle Schwellwerte für Meldungen zu finden. Die Anzahl der Falschmeldungen sollte bereits auf Systemebene reduziert werden. Ein weiterer Ansatz ist es, innerhalb des SIEMs die Daten entsprechend so zu verarbeiten, dass auch hier eine Verbesserung der Datenqualität stattfinden kann. Dafür müssen die Rohdaten jedoch alle wichtigen Informationen zuliefern, die es für dieses Regelwerk braucht. Es wird deshalb ein entsprechendes Datenkonzept benötigt, um über das SIEM und dessen Filter die erforderlichen Anpassungen umsetzen zu können.

Automatisches Eingreifen!

Abhängig davon, welche Systeme zum Einsatz kommen, gibt es möglicherweise Automatismen, die sofort greifen, wenn das System einen unbekannten Datenfluss identifiziert. Gerade in der Anlernphase sollten die Reaktionen unter Vorbehalt stehen, sodass das System noch nicht ins Netzwerk-Geschehen durchgreift. Erst wenn der Reifegrad so hoch ist, dass man sich (fast) sicher sein kann, dass es kein gewollter Datenfluss ist, sollten automatisierte Reaktionen freigeschaltet werden. In dem Zusammenhang ist Quality of Service ein spannender Ansatz. Statt bestimmte Datenflüsse direkt zu kappen und den Angreifer damit zu informieren, dass man ihn entdeckt hat, kann die Bandbreite in bestimmten Netzwerkbereichen reduziert werden, um dem Angreifer das Vorankommen zu erschweren.

Faktor Zeit!

Zeit ist in vielerlei Hinsicht ein wichtiges Thema. Die Systeme zur Anomalie-Detektion benötigen eine gewisse Anlernphase. Doch selbst danach wird es immer wieder neue Datenflüsse geben, die gewollt, aber nicht bekannt sind. Ursache dafür ist, dass Systeme nicht immer kommunizieren, sondern ggfs. nur im Fehlerfall. Trat dieser bisher nicht auf, kann auch die Anomalie-Erkennung nur feststellen, dass der Datenfluss unbekannt ist und damit ein potenzielles Problem darstellt.

Damit der Incident Responce Prozess im Notfall gut funktioniert, müssen die Prozesse sinnvoll definiert werden. Das bedeutet auch, Schnittstellen zu den Entscheidern und ggfs. zu Externen zu definieren. Wird im Notfall entschieden, dass ein externer Forensiker oder gar ein externes Incident Responce Team ins Haus kommen soll, müssen die Konzepte für diese Umsetzung bereits fertig sein. Ist der Angreifer erst einmal im Netzwerk, gilt es keine Zeit zu verlieren. Damit das funktioniert, müssen also die Prozesse nicht nur definiert, sondern auch mit allen verantwortlichen Stellen geprobt werden. Bei der Probe stellt sich ggfs. heraus, dass Aspekte wichtig sind, die bisher nicht bekannt oder definiert wurden.

Auch die Kommunikationswege sind in diesem Fall zwingend zu definieren, damit nicht kostbare Zeit nach der Alarmierung ungenutzt verstreicht. Organisatorisch ist in solchen Fällen zu klären, wie eine 24/7 Bereitschaft aussieht bzw. wo eine Meldung erstmalig aufschlagen kann, um dann ggfs. weiter zu informieren.

Fazit!

Die Schritte von der Anforderung zur Einführung einer Anomalie-Erkennung bis hin zu einem funktionierenden und sicheren Incident-Responce-Prozess müssen sorgfältig geplant und mit genügend zeitlichem Vorlauf angegangen werden. Nicht nur, um die Frist für den Stichtag am 01.05.2023 zu halten, sondern vor allem, um sicherzugehen, dass die erarbeiteten Prozesse und die dazugehörigen Systeme sinnvoll und effizient ineinandergreifen.

Vorheriger Beitrag
Die Risikoperspektive wechseln
Nächster Beitrag
Ihr Plan für eine fittere IT-Security

Aktuelles von CYBEResilienz

Hier lesen Sie Aktuelles rund um Themen zu Cyber-Attacken, wie man sich schützen kann und wie CYBEResilienz Ihnen hilft, Ihre Systemlandschaft sicherer zu machen.

Kategorien