Hafnium Reloaded – Wieder kritische Schwachstellen in Microsoft Exchange

Veröffentlicht 1 KommentarVeröffentlicht in Advisories, Hafnium

Und täglich grüßt das Murmeltier? Nicht ganz. Trotzdem erleben wir aktuell ein Déjà-vu mit Microsoft Exchange: Am 13.04.2021 19 Uhr MESZ wurden vier neue hochkritische Schwachstellen samt dazugehörigem Patch veröffentlicht.

Das BSI warnt bereits vor der Schwachstelle und fordert dazu auf, sehr zeitnah die eigenen Systeme zu patchen. Die Cybersecurity and Infrastructure Security Agency (CISA) des US Department of Homeland Security (DHS) geht sogar noch einen Schritt weiter und wird am Freitag, den 16.04.2021 alle nicht gepatchten Systeme aus dem eigenen Netzwerk ausschließen.

Bei den von der NSA an Microsoft gemeldeten Schwachstelle handelt es sich u. a. wieder um Remote-Code-Execution-Lücken mit einem sehr hohen CVSS Score von 9.8 (auf einer 10er-Skala). Hierbei kann, ähnlich wie bei Hafnium, ein entfernter Angreifer Code auf die Systeme einschleusen und diese ggf. übernehmen. Bei den Schwachstellen handelt es sich um die folgenden CVEs:

  • CVE-2021-28480 Microsoft Server Remote Code Execution Vulnerability
  • CVE-2021-28481 Microsoft Server Remote Code Execution Vulnerability
  • CVE-2021-28482 Microsoft Server Remote Code Execution Vulnerability
  • CVE-2021-28483 Microsoft Server Remote Code Execution Vulnerability

Patches stehen bereits für die folgenden Systeme zur Verfügung:

  • Exchange Server 2013 CU23
  • Exchange Server 2016 CU19 und CU20
  • Exchange Server 2019 CU8 und CU9

Das nicht mehr unterstützte Exchange Server 2010 soll diesmal nicht betroffen sein.

Die Schwachstellen werden aktuell anscheinend noch nicht ausgenutzt. Es dürfte aber nur eine Frage der Zeit sein, bis entsprechende Exploits zur Verfügung stehen . Daher sollten betroffene Exchange-Systeme noch heute gepatcht werden.

Wir empfehlen darüber hinaus weiterhin, Exchange-Umgebungen engmaschig zu kontrollieren.

Blitze-Wolke

HAFNIUM-Schwachstellen: Office 365/Microsoft 365/AD FS indirekt auch bedroht

Veröffentlicht Schreibe einen KommentarVeröffentlicht in Cloud, Hafnium

Von Inés Atug, Markus Drenger und Daniel Jedecke.

Nach der Veröffentlichung des Out-of-Band-Patches für die als HAFNIUM bekannt gewordenen Schwachstellen in Exchange Servern haben viele Admins, die zuvor eine Migration nach Office 365 (jetzt Microsoft 365) durchgeführt hatten, aufgeatmet. Denn Microsoft zufolge ist Exchange Online von Hafnium nicht betroffen. Hiermit meint der Hersteller jedoch das Produkt an sich: Exchange Online ist weiterhin nicht direkt angreifbar. Aber Vorsicht: Es kann je nach Aufbau dennoch möglich sein, dass Angreifer auf den Cloud-Dienst durchgreifen können. 

In vielen Fällen ist in Unternehmen ein hybrider Aufbau etabliert, bei dem ein Exchange-Server weiterhin lokal betrieben wird. Sollte dieser Exchange-Server die HAFNIUM-Schwachstellen aufweisen, könnten Angreifer hierüber Zugriff auf das lokale Netzwerk erhalten (siehe Abbildung Schritt (1)) und sich dann über Lateral Movement im Netz weiterbewegen (Schritt (2)). Mittelbares Ziel des Angriffs ist in der Regel der Zugriff auf ein hochwertiges System wie beispielsweise das Active Directory oder die Active Directory Federation Services (AD FS) zu. Bei Zugriff auf letzteren können die Angreifer unter Umständen den geheimen Schlüssel entwenden (Schritt (3)), sich damit als jeder beliebige legitime Nutzer in der Cloud ausgeben (Schritt (4)) und somit Zugriff (lesen, verändern, löschen) auf alle in der Cloud gespeicherten Daten bekommen (Schritt (5)).

Angriff auf die Cloud/ADFS via HAFNIUM/ProxyLogon

Ob und wie leicht dies möglich ist, hängt stark davon ab, wie der lokale Aufbau umgesetzt ist. Wir erleben im Bereich der Forensik und Beratung hier gute wie auch ungünstige Umsetzungen. Prinzipiell sollte das Ziel immer sein, Lateral Movement in der On-Premise-Umgebung wie auch in der Cloud zu minimieren. Hierfür gibt es bewährte Verfahren, welche sich bei geeigneter Konfiguration dazu eignen, die Bewegungen der Angreifer im Netz zu erschweren:

  • Frühzeitiges Patchen von Sicherheitslücken: Die wichtigste Maßnahme, die auch bei Hafnium eine Kompromittierung mit hoher Wahrscheinlichkeit unterbunden hätte, ist das schnelle Patchen der Systeme. Hier herrscht bisweilen noch der Irrglaube, dass kritische Sicherheitslücken innerhalb von 30 Tagen zu patchen seien. Dies wurde und wird teilweise sogar noch von IT-Sicherheitsstandards vorgeschlagen. Sicherheitslücken, die mittels Fernzugriff automatisiert und unauthentifiziert ausgenutzt werden können, so wie dies bei Hafnium der Fall ist, zeigen jedoch deutlich, dass hier möglichst innerhalb von Stunden anstatt Tagen gepatcht werden sollte.
  • Administrative Trennung von Active Directory und Exchange Server: Eine weitere Maßnahme, die lokal umgesetzt werden sollte, ist die administrative Trennung zwischen Active Directory und Exchange. Oft sind die Systeme über Jahre gewachsen und eng miteinander verbunden. So trennt die Angreifer nach erfolgreicher Kompromittierung oft nur ein Powershell Kommando von der AD-Übernahme. Hier ist es wichtig, die 2017 von Microsoft im Rahmen der Konferenzen Blue Hat und Black Hat vorgestellten Probleme zu mitigieren. Hierfür eignet sich Split-Permissions (https://docs.microsoft.com/en-us/exchange/understanding-split-permissions-exchange-2013-help und https://docs.microsoft.com/de-de/exchange/permissions/split-permissions/configure-exchange-for-split-permissions?view=exchserver-2019). Eine weitere Maßnahme ist die Verwendung der Local Administrator Password Solution (LAPS) von Microsoft. Hierbei wird auf jedem Host ein separates Admin-Passwort gesetzt, um so das Springen nach einem erfolgreichen Angriff (beispielsweise mittels Pass-the-Hash-Angriffsarten) zu erschweren.
  • Umsetzen des Konzepts administrativer Zonen: Da AD FS das Sprungbrett in die Cloud Welt ist, sollte dieser Zugang besonders gesichert werden. Hierzu empfiehlt Microsoft seit längeren einen Aufbau, in dem verschiedene administrative Sicherheitszonen (engl. tiers) voneinander getrennt werden sollten. Ein entsprechend gesicherter Exchange Server würde hier in Zone 1 stehen und ein Active Directory in Zone 0. Ein Sprung zwischen diesen Zonen soll mit den umzusetzenden Maßnahmen stark erschwert werden. Für den AD FS empfiehlt Microsoft ebenfalls den Aufbau in der Zone 0 (https://docs.microsoft.com/de-de/windows-server/identity/ad-fs/design/best-practices-for-secure-planning-and-deployment-of-ad-fs).
  • Multifaktorauthentifizierung: Sowohl in der Cloud als auch in der lokalen IT-Umgebung sollten administrative Zugriffe mittels starker Multifaktorauthentifizierung abgesichert werden.
  • Protokollierung und Monitoring: Damit ein unberechtigter Zugriff möglichst schnell bemerkt wird, sollte ein feinmaschiges Monitoring- und Protokollierungskonzept etabliert sein. Insbesondere in der Cloud-Umgebung gehört das Monitoring neben der Zugriffssteuerung zu den wichtigsten Sicherheitsmaßnahmen. 
  • Datenklassifizierung: Sollte es doch zu einem Einbruch gekommen sein und die Angreifer möchten Daten exportieren, dann sollte mittels der Datenklassifizierung Sicherheitsmaßnahmen greifen, die zumindest die als vertraulich oder streng vertraulich klassifizierten Daten außerhalb der Cloud und des Kundennetzwerks unlesbar darstellen. 
  • Datensicherung: Sollte es zu einem Einbruch gekommen sein und es werden die Daten mittels Ransomware verschlüsselt, dann sollte man auf eine unveränderbare extern gespeicherte Datensicherung zurückgreifen können.

Die obigen Ausführungen zeigen, dass ein ganzheitliches und aktuelles Sicherheitskonzept notwendig ist, um möglichen Sicherheitslücken umfassend entgegenzuwirken. Überprüfen Sie daher regelmäßig Ihre Sicherheitsmaßnahmen und passen Sie diese ggfs. an geänderte Anforderungen an. Insbesondere, wenn Sie lokale Dienste von außen erreichbar konfigurieren oder Cloud-Dienste mit der lokalen IT-Umgebung koppeln, sollten das Sicherheitskonzept überprüft und nachgeschärft werden. Sprechen Sie uns gerne dazu an!  

HiSolutions Research

HiSolutions Discovers New HAFNIUM/ProxyLogon IoCs

Veröffentlicht 1 KommentarVeröffentlicht in Advisories, Hafnium, Incidents

by Daniel Jedecke, David Fuhr und Vincent Rockenfeld

During our work on a large number of forensic analyses of HAFNIUM/ProxyLogon cases, we witnessed several cases where the recommended Microsoft tools (TestProxyLogon script and Safety Scanner/MSERT) do not find anything due to missing traces in the HttpProxy log. In those cases evidence can be found in the ECP Activity log as follow:

Indicators of Compromise (IoCs):

./ECP/Activity/ECPActivity_39844_20210303-1.LOG: 2021-03-03T06:43:32.531Z ,EX01, ,S:FE=EX01.FOOBAR.LOCAL;S:URL=https://ex01.foobar.local:444 /ecp/proxyLogon.ecp (https://owa.foobar.com/ecp/y.js);S:Bld=15.1.2106.2;S:ActID=def0-b0e6-2342-5e2c-23a8ff1962a1;Dbl:WLM.TS=0

./ECP/Activity/ECPActivity_39844_20210303-1.LOG: 2021-03-03T06:43:32.963Z, EX01,Request,S:PSA= administrator@foobar.com ;S:FE=EX01.FOOBAR.LOCAL;S:URL=https://ex01.foobar.local:444 /ecp/proxyLogon.ecp (https://owa.foobar.com/ecp/y.js)

With the following (Linux/UNIX) command logs can be searched for relevant entries:

grep -ir “proxylogon“ ./ECP/Activity | sort -n

For the German version of this post, see here.

HiSolutions Research

HiSolutions entdeckt neue HAFNIUM/ProxyLogon IoCs

Veröffentlicht 1 KommentarVeröffentlicht in Advisories, Hafnium, Incidents

von Daniel Jedecke, David Fuhr und Vincent Rockenfeld

For English version of this advisory, please see here.

Bei der großen Menge an forensischen Untersuchungen zum Thema HAFNIUM/ProxyLogon, die wir aktuell durchführen, haben wir in mehreren Fällen gesehen, dass die Microsoft-Tools (Skripte bzw. Safety Scanner aka MSERT) nichts finden, da im HttpProxy-Log kein ProxyLogon zu sehen war, während der Zugriff im ECP Activity Log nachvollziehbar war.

Hier die Indikatoren für eine Kompromittierung (IoCs):

./ECP/Activity/ECPActivity_39844_20210303-1.LOG: 2021-03-03T06:43:32.531Z ,EX01, ,S:FE=EX01.FOOBAR.LOCAL;S:URL=https://ex01.foobar.local:444 /ecp/proxyLogon.ecp (https://owa.foobar.com/ecp/y.js);S:Bld=15.1.2106.2;S:ActID=def0-b0e6-2342-5e2c-23a8ff1962a1;Dbl:WLM.TS=0

./ECP/Activity/ECPActivity_39844_20210303-1.LOG: 2021-03-03T06:43:32.963Z, EX01,Request,S:PSA= administrator@foobar.com ;S:FE=EX01.FOOBAR.LOCAL;S:URL=https://ex01.foobar.local:444 /ecp/proxyLogon.ecp (https://owa.foobar.com/ecp/y.js)

Mit folgendem (Linux-/UNIX-)Befehl lassen sich die Protokolle auf die interessanten Einträge hin durchkämmen:

grep -ir “proxylogon“ ./ECP/Activity | sort -n

Um den Austausch von Researchern zu fördern und damit sich andere schneller schützen können, haben wir unsere Erkenntnisse auch auf Twitter geteilt. Siehe z. B. https://twitter.com/Jedi_meister/status/1372287075547017218

Bitte beachten Sie weiterhin unsere stetig aktualisierte HAFNIUM/ProxyLogon Selbsthilfe und unsere Empfehlungen zum Monitoring.

HiSolutions Research

Hafnium – Eine Hilfestellung zur Überwachung Ihrer Systeme

Veröffentlicht 5 KommentareVeröffentlicht in Advisories, Hafnium, Incidents

Da die Schwachstellen bereits durch mehrere unterschiedliche Gruppen ausgenutzt wird, reicht es aktuell nicht aus, nur nach einer bestimmten Malware oder Webshell zu suchen. Aus diesem Grund hat das BSI eine Übersicht veröffentlicht, welche weiteren Analysen auf den Systemen durchgeführt werden sollten.

Zur Vereinfachung der Anwendung haben wir uns entschlossen, Ihnen eine Hilfestellung bei der Nutzung des Scanners Thor-Lite zu geben, welcher ebenfalls in der Hilfe des BSI erwähnt wurde. Zudem verweisen wir auf einen guten Artikel zur Überprüfung Ihres Active Directories. Bitte beachten Sie auch die immer die aktualisierte „Selbsthilfe„.

UPDATE vom 24.03.2021: Empfehlung zur Dauer der Überwachung der Systeme nach Kompromittierung durch ProxyLogon ergänzt (12 Monate).

Feedback ist gerne erwünscht. Aufgrund der Kritikalität der Schwachstelle haben wir uns entschlossen, alle Informationen hierzu als TLP-White zu veröffentlichen. Das Dokument ist zudem lizenziert unter einer Creative Commons Namensnennung 4.0 International Lizenz.

HAFNIUM/ProxyLogon bei Microsoft Exchange: Hilfe zur Selbsthilfe

Veröffentlicht 7 KommentareVeröffentlicht in Advisories, Hafnium

UPDATE vom 24.03.2021: Empfehlung zur Dauer der Überwachung der Systeme nach Kompromittierung durch ProxyLogon ergänzt (12 Monate).

English version is here.

Feedback ist gerne erwünscht. Aufgrund der Kritikalität der Schwachstelle haben wir uns entschlossen, alle Informationen hierzu als TLP-WHITE zu veröffentlichen. Das Dokument ist zudem lizenziert unter einer Creative Commons Namensnennung 4.0 International Lizenz.

Für jeweils aktuelle Infos abonnieren Sie auch gerne unseren monatlichen Cybersecurity Digest.

UPDATE vom 17.03.2021: Wir haben die HAFNIUM-Selbsthilfe auf den neusten Stand gebracht und Tool- und Maßnahmenempfehlungen geschärft. Angesichts der zu erwartenden Angriffe über abgeflossene E-Mails und Kontakte haben wir auch unsere Empfehlungen zur Sensibilisierung vor Phishing-Angriffen konkretisiert.

UPDATE vom 14.03.2021: Wir haben am Wochenende parallel zur Incident Response weiteren Research betrieben und uns mit vielen Leuten ausgetauscht. Wir haben erste Erkenntnisse, dass die Angreifer Dateiberechtigungen verändern, um das Installieren von Patchen zu verhindern. Zudem stellen wir vermehrt Ransomware-Angriffe fest.

Auch haben wir ein Update bezüglich des Microsoft Support Emergency Response Tools (MSERT) eingearbeitet. Obwohl MSERT für diesen Anlass angemessen ist, raten wir aktuell zur Vorsicht bei der Nutzung. Das Tool löscht u. U. Shells und kann die vollständige Bereinigung nicht sicherstellen und die Forensik erschweren.

Zudem haben wir nun auch ein Dokument veröffentlich, um mittels Thor Lite die Systeme zu untersuchen und eine grundlegende Überprüfung des Active Directory durchzuführen.


UPDATE vom 12.03.2021 Teil 2: Wir haben die Maßnahmen (auch nach einer möglichen Kompromittierung) umfangreich angepasst. Sobald wir mehr Informationen über die aktuell verteile Ransomware haben werden diese noch nachsteuern. Das BSI hat seine Warnmeldung heute ebenfalls aktualisiert.


UPDATE vom 12.03.2021: Wir haben das Dokument erneut aktualisiert. Feedback gerne wieder an uns. Zudem haben wir einen Verweis auf den Datenschutz eingebaut sowie die Maßnahmen konkretisiert.


UPDATE vom 10.03.2021: Vielen Dank für das viele Feedback und die Anregungen. Wir haben das Dokument überarbeitet und die neusten Empfehlungen des BSI, Erkenntnisse aus der Forensik sowie einige Vereinfachungen im Bereich Monitoring eingearbeitet. Feedback weiterhin gerne an uns oder per Twitter an (@Jedi_meister).


Um unseren Kunden einen ersten Leitfaden zum Umgang mit der HAFNIUM/ProxyLogon-Thematik an die Hand zu geben, haben wir einen Leitfaden „Hilfe zur Selbsthilfe“ herausgebracht. Dieser kombiniert die Empfehlungen des BSI, unsere fachliche Expertise sowie Informationen des Herstellers Microsoft.

Der Leitfaden soll als erster Indikator dienen und eine einfach zu befolgende Checkliste darstellen. Wir aktualisieren das Dokument laufend mit den neusten Erkenntnissen aus unseren Fällen.

Aufgrund der Kritikalität der Schwachstelle verteilen wir den Leitfaden kostenfrei. Sofern Sie Microsoft Exchange nutzen, prüfen Sie bitte, ob Sie bereits alle Schritte durchgeführt haben. Beachten Sie, dass Microsoft am 09.03.2021, dem regulären Patch Tuesday, weitere kritische Lücken in seinen Produkten geschlossen hat!

Weitere Informationen unter:

HAFNIUM/ProxyLogon: Akute Angriffswelle auf Microsoft Exchange

Veröffentlicht 1 KommentarVeröffentlicht in Advisories, Hafnium

Seit in der Nacht zum Mittwoch, 3. März 2021, das Microsoft Threat Intelligence Center (MSTIC) über eine akute Angriffswelle auf Microsoft Exchange Server informiert hat, haben IT-Organisationen weltweit alle Hände voll zu tun, die ausgenutzten Schwachstellen (inkl. ProxyLogon) zu schließen, eine mögliche Kompromittierung abzuchecken und ggf. Aufräumarbeiten durchzuführen.

Auch wenn Microsoft umgehend Out-of-band Updates veröffentlich hat, wurde schnell klar, dass die vier beschriebenen Schwachstellen in Kombination bereits für zielgerichtete Angriffe verwendet wurden und vielerorts die Möglichkeit boten und bieten, Daten abzugreifen oder weitere Schadsoftware zu installieren.

https://blogs.microsoft.com/on-the-issues/2021/03/02/new-nation-state-cyberattacks/

Zu den Sofortmaßnahmen gehört neben dem umgehenden Einspielen der Patches die sofortige Deaktivierung der über HTTPS erreichbaren Dienste (OWA, ECP, UM, VDir, OAB). Eine erste Überprüfung auf Kompromittierung kann mittels eines von Microsoft bereitgestellten Scriptes oder durch Scannen des Microsoft Exchange Server mit dem Microsoft Support Emergency Response Tool (MSERT) erfolgen. Um die Möglichkeit der Angriffsdetektion zu verbessern, sollte außerdem die Protokollierung der Exchange-Server und des Active Directory ausgeweitet werden.

Im Falle der Detektion einer Kompromittierung (z. B. einer Webshell) müssen das System und je nach Berechtigungen ggf. weitere Systeme wie etwa das Active Directory näher untersucht werden. Hier muss darauf geachtet werden, ob es zum besagten Zeitraum zu Kontenerstellung, vermehrten Zugriffen oder ähnlichen Auffälligkeiten gekommen ist.

Unsere Handlungsempfehlungen

Weitere Ressourcen

HiSolutions Research

Umsetzung des § 8a BSIG in der Praxis

Veröffentlicht Veröffentlicht in Kritis

Hilfe für die Bevölkerung oder nur ein Papier-Tiger? Eine Reise zwischen Nachweiserbringungen, Zertifizierungen und dem wirklichen Leben.

Von Daniel Jedecke, Senior Expert, HiSolutions AG.

Kritische Infrastrukturen sind essentiell für unsere Gesellschaft. Daher sollte die Sicherheit der IT ein wichtiges Augenmerk sein. Durch das IT-Sicherheitsgesetz und den § 8a BSIG wurden hierfür die Weichen gestellt. Jedoch ist für viele Unternehmen das Thema IT-Sicherheit neu und die Umsetzung scheitert oft schon am Verständnis für die neuen Anforderungen. Hilft ein schnell eingeführtes ISMS wirklich oder sollte das Thema nachhaltiger angegangen werden?

Oft wurde uns gesagt: „Wir wissen natürlich, wie wir unsere Dienstleistung anbieten müssen, aber IT-Sicherheit? Das ist nicht unser Kernthema“. Das ist vollkommen klar; ein Bäcker wird auch nicht einfach anfangen, Kupplungen zu entwickeln und zu verkaufen.

Zunehmende Digitalisierung

In Zeiten der voranschreitenden Digitalisierung unserer Gesellschaft eröffnen sich auch immer weitere Angriffsflächen. Musste man vor Jahren noch Banken überfallen, um an Geld heranzukommen, so reicht heute der Überfall auf die IT, um sich das Geld bequem am Geldautomaten abzuheben. Dabei lässt sich dann ein sogenannter Cash-Out direkt mit einer manipulierten Chipkarte erzeugen.

Immer neue Cyber-Angriffe führen dazu, dass Angriffe auf Unternehmen nicht mehr als Ausnahme, sondern als Regel gesehen werden. So werden, je nach Studie, etwa 45% der Unternehmen regelmäßig angegriffen. „Von 2013 bis 2017 hat sich die Lage der Cybersicherheit dramatisch verschlechtert. Während die Durchdringung aller Lebensbereiche mit digitaler Technologie immer schneller voranschreitet, ist die Qualität der Technologie in der Fläche nicht besser geworden“[1].

Kritische Infrastrukturen sind essentiell für unsere Gesellschaft. So gibt es europaweite Bestrebungen, diese Infrastrukturen zu schützen. Die EU hat hierzu die Direktive 2008/114/EC herausgegeben, um in einem ersten Schritt die kritischen Infrastrukturen zu definieren und Schutzmaßnahmen einzufordern.

Beispiel Stromversorgung

Am Beispiel der Stromversorgung lässt sich gut feststellen, wie sich diese im Laufe der Zeit angepasst hat. Anfang des 19. Jahrhunderts war die Abwesenheit von Strom noch an der Tagesordnung. Selbst vor 40 Jahren noch gehörten kleinere Stromausfälle zum Alltag und waren von der Gesellschaft akzeptiert. Durch die zunehmende Industrialisierung und die Vernetzung von Systemen entstanden Kopplungen. Eine Kopplung bedeutet, „dass es zwischen zwei miteinander verbundenen Teilen kein Spiel, keine Pufferzone oder Elastizität gibt“[2]. War früher der Ausfall einer Telefonleitung noch vertretbar, so kann dies heutzutage zu einem kritischen Zustand führen, da wichtige Informationen nicht zwischen zwei Standorten übertragen werden können.

Die Bevölkerung verlernt mehr und mehr, den Ausfall von kritischen Infrastrukturen zu kompensieren. „Steigen die Auswirkungen, die durch Stromausfälle hervorgerufen werden, kann dies zweierlei bedeuten: zum einen eine wachsende Abhängigkeit vom Strom, zum anderen eine sich relational verringernde Kompensationskompetenz. Beides scheint in zunehmendem Maße gegeben.“[3]. Die beschriebene Kompensationskompetenz verringert sich durch die Digitalisierung immer weiter. Während bei älteren Bürgern in Deutschland durch die Nachkriegszeit noch Erfahrungen mit Mangelsituationen vorhanden sind, fehlen den meisten Menschen in Deutschland diese Kenntnisse, da sie selten oder nie mit Mangelsituationen infolge kriegerischer Auseinandersetzungen oder Katastrophen in Berührung gekommen sind. So können Jugendliche heutzutage kaum noch ohne ihr Smartphone auskommen. Ausfälle der Infrastruktur erleben sie somit als ernstzunehmende persönliche Bedrohung. Gerade die aktuelle Pandemie mit flächendeckenden Lockdowns zeigt deutlich auf, wie fragil die Gesellschaft in dieser Hinsicht geworden ist.

Angriffe gegen kritische Infrastrukturen

Angriffe gegen die kritischen Infrastrukturen nehmen immer weiter zu. So wurden 2015 weite Teile des ukrainischen Stromnetzes durch einen IT-Angriff abgeschaltet.

Seit 2016 ist ein starker Anstieg der Gefährdung durch Ransomware festzustellen. Weltweite Ransomware wie WannaCry hat 2017 dafür gesorgt, dass viele Unternehmen ihre Produkte und Dienstleistungen nicht mehr oder nur stark vermindert anbieten konnten. Betroffen waren hiervon viele namhafte Firmen wie beispielsweise die Deutsche Bahn, das Kammergericht Berlin, der DFB und die Fresenius. Ebenfalls sorgte ab 2017 eine weitere Malware für Aufsehen. NotPetya verbreitet sich anders als WannaCry nicht nur über Sicherheitslücken, sondern auch intern in Netzwerken. Zu den betroffenen Firmen zählen beispielsweise Maersk, Mondelez, SNCF und Merck. Die Angriffe zeigen deutlich, dass selbst bekannte Angriffswege, in diesem Fall bekannte Schwachstellen, nicht zeitnah innerhalb der Unternehmen behoben werden. Diese Wellen gehen mit den aktuellen Emotet-Kampagnen weiter.

Das BSI weist im Lagebericht 2019 genau 252 Meldungen seit der Einführung der Meldepflicht für kritische Infrastrukturen aus. Die Dunkelziffer dürfte hier weitaus höher sein.

Rechtliche Grundlagen

Da die Sicherheit der Infrastrukturen ein wichtiges Augenmerk sein sollte, wurden durch das IT-Sicherheitsgesetz und den § 8a BSIG hierfür die Weichen gestellt. Das IT-Sicherheitsgesetz ist hierbei die nationale Umsetzung der europäischen Richtlinie 2016/1148 („NIS-Richtlinie“). Durch das BSI Gesetz (BSIG) hat das BSI weitreichende Rechte wie auch Pflichten erhalten, um den Schutz von kritischen Infrastrukturen in Deutschland zu gewährleisten.

Im Rahmen der BSI-Kritisverordnung wurden zwei Körbe definiert, welchen die verschiedenen Sektoren zugeordnet worden sind. Zu den regulierten Sektoren zählen Energie, Telekommunikation, Transport und Verkehr, Gesundheit, Wasser, Ernährung, Finanz- und Versicherungswesen, Staat und Verwaltung sowie Medien und Kultur. Nicht alle Sektoren werden direkt durch das BSI überwacht. Der Bereich Energie wird durch die Bundesnetzagentur (BNetzA) betreut. Die Bereiche Staat und Verwaltung sowie Medien und Kultur fallen nicht direkt unter die KritisV und werden separat betreut.

Am 3. Mai 2016 ist der erste Teil der BSI-Kritisverordnung (§ 10 BSI-Gesetz) in Kraft getreten. Diese behandelt die Sektoren Energie, Wasser, Informationstechnik und Telekommunikation sowie Ernährung. Diese werden auch als „Korb 1“ bezeichnet. Durch die erste Verordnung zur Änderung der BSI-Kritisverordnung, die am 30.06.2017 in Kraft getreten ist, wurden die Sektoren Finanz- und Versicherungswesen, Gesundheit sowie Transport und Verkehr ergänzt. Diese werden auch „Korb 2“ genannt.

Anhand von Schwellwerten werden die betroffenen Unternehmen aus diesen Bereichen eingeteilt. Hierbei wird meist davon ausgegangen, dass eine Anlage 500.000 Bürger versorgt, um zu einer kritischen Dienstleistung zu zählen. Anhand von Berechnungsformeln werden die Schwellwerte berechnet. So ist der in der BSI-Kritisverordnung genannte Schwellwert für Strom unter Annahme eines Durchschnittsverbrauchs von 7.375 kWh pro versorgter Person pro Jahr definiert. Bei 500.000 Bürgern ergibt sich somit ein Schwellwert von 3.700 GWh pro Jahr ( 3.700 GWh/Jahr = 7.375 kWh/Jahr x 500.000).

Von Anfang an gab es jedoch auch Kritik an der Berechnung der Schwellwerte. So Ffllen beispielweise viele Krankenhäuser in einer Großstadt unter diese Regelung, obwohl es in der Stadt meist noch Alternativen gäbe, das kleine Kreiskrankenhaus, welches im Umkreis von 50km alle Patienten betreut, jedoch nicht.

Status-Quo des Umsetzungsstatus bei Unternehmen

Für viele KRITIS-Unternehmen ist das Thema IT-Sicherheit neu und die Umsetzung scheitert oft schon am Verständnis für die neuen Anforderungen. So haben viele Unternehmen mit der Umsetzung der gesetzlichen Anforderungen erst 2018 angefangen, obwohl das Gesetz schon seit zwei Jahren galt. Oft ist das begrenzte Budget Schuld an der mangelhaften Umsetzung neuer IT-Anforderungen.

Im Rahmen unserer beruflichen Tätigkeit als Prüfer, Ausbilder und Teilnehmer an Branchenarbeitskreisen von Betreibern, welche unter die KRITIS-Verordnung fallen, konnte ein breites Wissen darüber aufgebaut werden, inwiefern die Umsetzung der Anforderungen die Sicherheit in den Unternehmen nachhaltig verbessert hat, oder ob es nur das Ziel war, die gesetzlichen Anforderungen mit minimalen Aufwand zu erfüllen.

Hierbei stelle ich die These auf, dass Unternehmen, welche sich bisher noch nicht mit IT-Sicherheit beschäftigt haben, dies trotz des Gesetzes auch in Zukunft nur begrenzt tun werden.

Vielmehr werden diese Unternehmen den Minimalansatz wählen, um die nötigen Nachweise liefern zu können, ohne einen allgemeinen Prozess zur stetigen Verbesserung einzuführen.

Wir würden daher gerne anregen, die folgenden Forschungshypothesen, welche sich aus dem Wissen bei der Betrachtung der bisher durchgeführten Prüfungen wie auch Diskussionen im Rahmen der Branchenarbeitskreise ergeben haben, einmal genauer zu prüfen:

  • Hypothese 1: Die Umsetzung des BSIG führt zu einer besseren Akzeptanz der IT-Sicherheit in den Unternehmen.
  • Hypothese 2: Unternehmen, die sich bereits seit Einführung des Gesetzes mit dem Thema beschäftigen, messen der IT-Sicherheit einen höheren Stellenwert zu.
  • Hypothese 3: Eine (fälschlicherweise oft als Nachweis genutzte) Zertifizierung bringt nicht zwangsläufig Vorteile für den Bereich kritische Infrastrukturen, da gegebenenfalls die falsche Zielsetzung verfolgt wird.
  • Hypothese 4: Unternehmen, die bisher nicht viel für IT-Sicherheit getan haben, werden auch durch das aktuelle IT-Sicherheitsgesetz nicht ermuntert, in Zukunft viel dafür zu tun.

[1] https://www.esmt.org/sites/default/files/dsi_ipr_cybersicherheit_2018-2020_0.pdf

[2] Normale Katastrophen. Die unvermeidbaren Risiken der Großtechnik von Charles Perrow

[3] Kritische Infrastrukturen aus Sicht der Bevölkerung