Talisman, Fetisch & Co. : Über Aberglauben in der Security – oder: Wie sehr schützen Zertifikate, Richtlinien und hippe Einrichtungen wirklich?
Eigentlich sollte es offenkundig sein: So wie die Flinte überm Kamin nicht vor einem Einbruch schützt, hilft auch die bloße Existenz einer Security-Policy oder des zertifizierten ISMS nur bedingt gegen Cyberattacken. Dennoch beschwört so mancher Manager Security-Buzzwords wie Zauberformeln und sieht in SOCs scheinbar einen Ort für kultische Handlungen, die jedwede Unbill vom Unternehmen fernhalten. Zeit für einen Reality-Check, meint unser Autor.
Von Sebastian Broecker, Bad Soden
Vor Kurzem verkündete der Präsident von Weißrussland, dass sich das Corona-Virus in seinem Land kaum ausbreiten werde: Schließlich verfüge man über wichtige Schutzmaßnahmen – nicht zuletzt würden Sport (vor allem Eissport), häufige Saunagänge, das Trinken von Wodka und landwirtschaftliche Tätigkeiten wie Traktorfahren als Anti-Viren-Medizin wirken [1]. Manchmal erscheint es uns Securityexperten ähnlich abstrus, wenn wir etwa einen Manager verkünden hören, dass seine Firma nun sicher sei, da man ein ISO-27001-Zertifikat erlangt habe – oder eine Cyberversicherung abgeschlossen oder ein SIEM eingerichtet oder eine andere Form von „digitalem Wodka“ zur Hand.
Schutz durch Paperwalls
Oft könnte man glauben, die bloße Existenz von Bescheinigungen, Richtlinien, Vorgaben und ISO-Zertifikaten würde genügen, um „Hacker“ von einem Angriff auf die damit ausgestattete Organisation abzuhalten. So mancher Entscheider glaubt scheinbar, dass eine Kombination aus Regelungen und Nachweisen die Firma quasi mit einem mystischen Schutzschild umgibt: Jede mögliche Handlung ist durch eine Richtlinie oder fachliche Anweisung vorgegeben.
Dabei können solche Vorgaben in Summe durchaus, wie der Autor mal bei einem früheren Arbeitgeber sah, die Dicke mehrerer Harry-Potter-Bände erreichen. Gleichzeitig kommt es aber nicht selten zu der bizarren Situation, dass „normale“ Mitarbeiter keine Ahnung von der Existenz dieses epischen Werks haben, geschweige denn jede einzelne Regelung aus dem Dokument kennen – ja, vielleicht nicht einmal den Namen des Security-Ansprechpartners aus ihrem Bereich wissen. So legten beispielsweise zwei Arbeiter im März 2017 die Produktionsstraße eines Autobauers lahm (und erzeugten dabei einen fünfstelligen Schaden), da sie während der Arbeitszeit Alkohol zu sich nahmen und Joints rauchten [2] – dabei war dies durch die hausinternen Vorgaben sicherlich verboten.
Noch schlimmer wird es bei magischen Buzzwords wie Zertifikaten: Natürlich macht das Einhalten von Prozessen Sinn. Aber dennoch ist es erstaunlich, wie viele Manager glauben, dass eine Zertifizierung echte Sicherheit schafft. Wäre dies der Fall, könnte man überall die teuren und schwer zu findenden Security-Experten entlassen und durch eine Qualitätssicherungsabteilung ersetzen.
Es ist wichtig zu verstehen, dass das Einhalten definierter Schutzmaßnahmen (Standards) das Risiko eines Angriffs senkt – verhindern kann es ihn aber nicht. Typische Beispiele waren im letzten Jahr etwa erfolgreiche Angriffe auf die großen und sicherlich im Bereich Cybersecurity sehr erfahrenen Firmen Airbus [3] und Rheinmetall [4] sowie den Heise-Verlag [5].
Die Moral von der Geschicht‘ …
Betrachtet man „Paperwalls“ auf einer Metaebene, zeigen sich im Prinzip folgende wichtige Aspekte:
- Analyse der zu regelnden Dinge
- Definition der Regelungen in einem Standard in passender Granularität
- Kommunikation des Standards an die betroffenen Mitarbeiter
- Interpretation der Inhalte durch den Leser
- Akzeptanz und Anwendung im Alltag
Jeder dieser Punkte ist eine Herausforderung! Und selbst das Einhalten aller Aspekte bedingt noch nicht automatisch einen daraus resultierenden Schutz. Zudem besitzt jeder der genannten Punkte einen breiten Spielraum: Muss ein Arbeitgeber denn wirklich explizit regeln (vgl. das Beispiel des Automobilkonzerns), dass man während der Arbeitszeit keine Joints rauchen darf? Oder ist das eine Sache des gesunden Menschenverstands? Wie kommuniziert man den Standard? Erreicht eine Meldung im Intranet die Fließbandarbeiter? Und wenn drei Mitarbeiter die Richtlinie lesen, werden sie dann auch dasselbe verstehen?
Und zum Schluss das Wichtigste: Wird die Vorgabe vom Mitarbeiter akzeptiert und umgesetzt? Ein Beispiel wäre hier das offene Tragen eines Firmenausweises: Gibt es Abteilungen, Standorte oder Gruppen von Mitarbeitern, bei denen das eher unüblich ist? Dann kann es in einem großen Unternehmen trotz einer einheitlichen Vorgabe – als Teil der „gelebten“ Securitykultur – durchaus unterschiedlich gehandhabt werden. Das Umsetzen einer Vorgabe (egal ob interne Anweisung oder Anforderung durch die ISO 2700x) ist in der Praxis oft nicht so einfach wie in der Theorie. Und selbst eine sinnvolle Anforderung kann im Ergebnis unsinnig sein, wie der nächste Abschnitt zeigen wird.
Regelkonforme Blei-Enten
Die weit verbreitete ISO-Norm 9001 soll einen hohen und gleichbleibenden Qualitätssicherungsstandard garantieren. Ein wichtiger Aspekt ist dabei die Analyse der Prozesse sowie die Dokumentation der Erfüllung der Prozessschritte bei der Herstellung eines Produkts. Das ist sicherlich sinnvoll. Betrachtet man dies jedoch mit einem gewissen Zynismus, erlaubt die ISO 9001 aber auch die Herstellung nicht schwimmfähiger „Blei-Enten“, die dennoch höchsten internationalen Standards entsprechen, solange der Herstellungsprozess dokumentiert und kontrolliert ist.
Ähnliches gilt für die ISO 2700x, deren generische Anforderungen an Cybersecurity zweifellos „interpretierbar“ sind. So heißt es in der ISO 27002 beispielsweise: „… Equipment should be sited or protected to reduce the risks from environmental threats and hazards, and opportunities for unauthorized access …“ Das klingt nach einer erfüllbaren und selbstverständlichen Anforderung. Aber was ist schon „selbstverständlich“? Im Jahr 1999 füllten Arbeiter einer japanischen Wiederaufbereitungsanlage, um Zeit zu sparen und einen Prozess abzukürzen eine kritische Menge Uranoxyd in einen Behälter und erzeugten so unbeabsichtigt eine Art „Kettenreaktion im Eimer“, die (nach Fukushima) als zweitschwerster Nuklear-Störfall in Japan gilt (siehe etwa [6]). Die Einhaltung der zitierten „selbstverständlichen“ ISO-Anforderung scheiterte schlicht an dem Wunsch der Arbeiter schneller fertig zu werden – ob eine Belehrung hier geholfen hätte, bleibt ungewiss.
Ein anderes Beispiel für eine Interpretation von Sicherheitsvorgaben ist die Aufforderung der Gesundheitsämter, in Zeiten von Corona ausreichend Abstand voneinander zu halten: Obwohl an Supermarktkassen Linien am Boden helfen sollen, die notwendige Distanz zu halten, interpretieren (oder ignorieren) viele Menschen in der Schlange an der Kasse diese Vorgabe. Doch selbst wenn man den Empfehlungen deutscher Behörden folgt und 1,5 m Abstand einhält, gibt es ja immer noch Virologen, die von 2 m, ja sogar von 5 m Mindestabstand sprechen.
Das richtige Maß zu finden, ist hier (und in der Cybersecurity) nicht so einfach. In vielen gesetzlichen Anforderungen zur Cybersicherheit heißt es, dass angemessene Schutzmaßnahmen durch die Firmenleitung zu treffen sind. Die Interpretation des Worts „angemessen“ mag für den Vertriebsbeauftragten eines Security-Produkt-Herstellers dabei aber anders aussehen als für den Einkäufer/Controller in einer beschaffenden Firma, der womöglich eine völlig andere Kosten-Nutzen-Rechnung aufstellt.
Unsinnige Kennzahlen
Im Rahmen von Informationssicherheits-Managementsystemen (ISMS) beschäftigen sich viele Organisationen mit Wahrscheinlichkeiten und Auswirkungen von IT-Angriffen. Manche brechen dabei die Angriffswahrscheinlichkeiten auf einzelne Prozentwerte detailliert herunter (z. B. 2 % vs. 5 %). Bei vorsätzlichen Handlungen (Intentional Acts) ist es aber aus Sicht des Autors unseriös, solche Wahrscheinlichkeiten anzugeben: Wie bestimmt man denn, ob eine Wahrscheinlichkeit von 2, 5 oder 17 Prozent vorliegt, dass ein Hackerangriff die eigene Produktionsstraße lahmlegt? Wird der Schaden 100.000 e, 200.000 e oder nur 10.000 e betragen? Bewirkt der damit verbundene Reputationsverlust einen Kundenrückgang von 3 %, 6 % oder 28 %? Als vor einigen Jahren die Reederei Maersk von der Malware Not_Petaya getroffen wurde, hat vorher wohl kein Risikoexperte vorhergesagt, dass der real eintretende Schaden hunderte Millionen Euro betragen würde [7].
Ähnliches gilt auch für andere Security-Kennzahlen, etwa aus dem Gebiet Awareness: Angenommen 10 % der Mitarbeiter einer großen Firma klicken nach einer Awareness-Schulung immer noch auf einen „giftigen Link“ in einer E-Mail. Ist das nun gut, weil es vor der Schulung noch 30 % waren? Oder ist es schlecht, weil immer noch sehr viele Mitarbeiter das Firmennetzwerk gefährden? Die ISO 2700x sagt hier nur sinngemäß: „Lieber CEO, sieh zu, dass die Mitarbeiter geschult werden und mit den aktuellen IT-Gefahren umgehen können.“ – nicht mehr und nicht weniger. Diese ISO-Anforderung ist also erfüllt, wenn alle Mitarbeiter geschult wurden. Dennoch reicht danach ein einzelner (vielleicht nur abgelenkter) unachtsamer Mitarbeiter aus, um das Firmennetzwerk mit einem Mausklick auf einen virushaltigen Link zu korrumpieren – der sehr gute öffentliche Umgang des Heise-Verlags mit einer Malwareinfektion hat das 2019 noch einmal eindrücklich belegt [5].
Coole Schlagworte vs. Realität
Neben dem Erfüllen von ISO-Standards gibt es weitere von Managern geschätzte Buzzwords: etwa SOC (Security Operations Center) und SIEM (Security Information and Event Management). In Kombination mit dem „Schutz“ durch die angesprochenen Paperwalls sind die aktiven Mechanismen SOC und SIEM in den Augen vieler Manager sehr beliebte – und dennoch fast mystisch anmutende – Schutzmaßnahmen.
Doch auch hier sollte man stets bedenken, dass eine „digitale Feuerwache“ nur wirken kann, wenn das Gesamtpaket stimmig ist: Das beginnt bei der personellen Besetzung (Mitarbeiteranzahl, Auswahl der Qualifikationen) und geht über Aufgabenverteilung und kontinuierliche (teure) Schulung der Mitarbeiter bis hin zur Firmenkultur: Wie geht man mit Incidents um?
Diese Punkte sind sehr wichtig: Als es 1986 zu einem atomaren GAU in Tschernobyl kam, dementierte die Sowjetunion lange Zeit den Vorfall – bis die radioaktive Wolke Schweden erreichte und der Vorfall nicht mehr zu leugnen war. Als 2012 ein Hacker einen digitalen GAU bei der Plattform LinkedIn auslöste, sprach die Firma anfangs von einzelnen (!) betroffenen Accounts, später wurde die Zahl durch Analysen Dritter zunächst auf 6 Millionen betroffene Nutzer erhöht, dann sprach man sogar von mehr als 100 Millionen gestohlenen Nutzerdaten [8]. Ein solcher Umgang mit einem schweren Incident wirkt nicht professionell und vertrauensbildend.
Und sicherlich gibt es auch heute noch viele Firmen, bei denen aus welchen Gründen auch immer (z. B. Aufgrund der Firmenkultur oder nicht funktionierender Prozesse) Security-Incidents nicht schnell und zielstrebig aufgeklärt werden. So soll der Anbieter eines Ticketsystems eine Datenschutzpanne erst nach neun Tagen statt unverzüglich dem Landesdatenschutzbeauftragten gemeldet haben, um dann sogar noch drei Wochen später die Zusammenarbeit mit der zur Aufklärung eingeschalteten IT-Firma zu verweigern [9].
Doch die Firmenkultur zeigt sich auch in der Schulung der SOC- und Cybersecurity-Mitarbeiter: Eigentlich sollten regelmäßige Weiterbildungen zu Sicherheitsthemen durch international angesehene Organisationen wie das SANS Institute selbstverständlich sein – doch diese sind kostspielig, zeitintensiv und finden zudem nicht selten im Ausland statt. Das führt bei Weiterbildungsverantwortlichen oder sonstigen verantwortlichen Führungskräften oft dazu, weniger geeignete Alternativen in Betracht zu ziehen oder Schulungen ganz zu streichen.
Aus Sicht des Autors ist die aufs Jahr betrachtete Zahl von SANS-Schulungstagen pro Security-Mitarbeiter ein wichtiger Key-Performance-Indicator (KPI) für den Stellenwert und die grundlegende Funktionsfähigkeit eines SOC im Unternehmen. Sicherheit zu postulieren, weil man ja ein SOC in der Firma habe, entspricht eher dem Protzen mit einem Maserati in der Garage, der jedoch aufgrund fehlender Wartung und TÜV-Abnahme nicht verkehrstauglich ist.
Ähnliches gilt auch für ein SIEM: Vor einiger Zeit wurde der Autor von einem Externen gefragt, wie er die Effektivität eines solchen Managementsystems messen würde – die Antwort: „Ich rede mit den SIEM-Leuten, ob diese genug Zeit haben, um die Ergebnisse des SIEM zu analysieren, ihrem Bauchgefühl nachzugehen und auch exotische Dinge zu untersuchen.“ Das ist wichtiger als irgendwelche „gemessenen“ KPIs zur Security!
Daher sei an dieser Stelle nochmals ausdrücklich erwähnt, dass das Vorhandensein von Buzzword-Institutionen, -Technikern und -Prozessen in einem Unternehmen an sich noch keine Sicherheit schafft, sondern nur deren gute Anwendung! Eine Insulinspritze im Haus zu haben, nützt einem Diabetiker wenig, wenn er sie nicht regelmäßig mit dem entsprechenden Fachwissen anwendet.
Zertifikate vs. Realität
„Der Unterschied zwischen Theorie und Praxis ist in der Praxis oft größer als in der Theorie“, heißt es in einem Postkartenspruch. Wie wahr! Ein Unternehmen mag sich sicher fühlen, weil es eine ISO-Zertifizierung hat (und diese vielleicht sogar prunkvoll in der Öffentlichkeit darstellt), ein SIEM und ein SOC noch dazu. In der Produktionsstraße oder Gebäudesteuerung wird aber vielleicht noch Windows XP eingesetzt, in manchen Büros noch Windows 7 und zu Coronazeiten im Homeoffice dann Zoom als Kommunikationsplattform. Hierzu sei kurz erwähnt, dass Zoom in der letzten Zeit durch verschiedene Sicherheits- und Datenschutzprobleme auffiel [10], sodass sogar Google den Einsatz dieses Tools innerhalb der Firma verboten hat. Trotz der schweren Sicherheitsbedenken (inkl. Installation eines kaum mehr zu deinstallierenden Webservers) wurde Zoom in den letzten Monaten weltweit 200 Millionen mal heruntergeladen. Hier trifft also eine reale Ist-Situation in einer bestimmten Abteilung auf eine festgestellte ISO-Konformität in anderen Bereichen des Unternehmens. Einem Angreifer ist das aber egal – er stürzt sich auf jede gefundene Schwachstelle.
Zwei weitere erschreckende Beispiele, wie Sicherheit manchmal in der Realität aussieht: 2015 kam es am Pariser Flughafen Orly zu einer schweren Störung im Betriebsablauf, da ein wichtiges System dort mit Windows 3.11 (von 1992) gesteuert wurde und Probleme erzeugte [11]. Und angesichts der Bekämpfung des Corona-Viruses in den USA geriet die Auszahlung von durch die Pandemie ausgelösten Sonderzahlungen der Arbeitslosenhilfe ins Stocken, weil Cobol-Programmierer fehlten [12] – Cobol, die aus den 1950er-Jahren stammende Programmiersprache, für die bereits angesichts des drohenden Jahr-2000-Problems Programmierer aus dem Ruhestand zurückgeholt wurden [13]!
Fazit
Security hat zwei wichtige Aspekte: die real existierende und die gefühlte Sicherheit eines Systems. Sicherlich sind bestimmte Schutzmaßnahmen sinnvoll: Ein ISO-Zertifikat zeigt, dass ein Unternehmen, das es erlangt hat, eine grundlegende Norm erfüllt – vergleichbar einem Touristen, der nicht mit Geldscheinen in der Hand nachts durch unbeleuchtete Straßen wandelt, sondern diese eher bei Tageslicht in einem Brustbeutel mit sich führt. Das sollte eigentlich normal sein – und unabhängig davon, ob dieser Brustbeutel eine Empfehlung von Stiftung Warentest besitzt oder einen Stempel, der besagt, dass er wasserdicht ist.
Auch das Einhalten von Standards, das Herausgeben von Regelungen und fachlichen Anweisungen sowie die Implementierung bestimmter Prozesse und Einrichtungen (z. B. eines SOC) erzeugen nicht automatisch und allein durch ihre Existenz Sicherheit. Diese Maßnahmen erzeugen bei Entscheidern oft eher ein – teils trügerisches – Sicherheits-Gefühl. Ein trauriges Beispiel für „gefühlte Sicherheit“ findet sich in einem Zitat von Präsident Trump am 15. März zur Corona-Krise: „Es ist ein hochansteckendes Virus. Unglaublich. Aber wir haben eine ungeheure Kontrolle darüber.“
Dr. Sebastian Broecker ist Referent Security bei der Deutschen Flugsicherung und nebenberuflich als freier Autor/Journalist tätig.
Literatur
[1] Johannes Aumüller, Wodka gegen das Virus, Süddeutsche Zeitung, 30. März 2020, www.sueddeutsche.de/sport/coronavirus-sport-weissrussland-lukaschenko-1.4862619
[2] dpa, Industrie: Betrunken und bekifft – BMW-Arbeiter legen Fließband lahm, Focus online, 20. März 2017,
www.focus.de/panorama/welt/industrie-betrunken-undbekifft-bmw-arbeiter-legen-fliessband-lahm_id_6811408.html
[3] Gerhard Hegmann, Hacker-Angriff auf Airbus-Daten, Welt online, 31. Januar 2019, www.welt.de/wirtschaft/article188002815/Flugzeugbauer-Hacker-Angriff-aufAirbus-Daten.html
[4] Susanne Khammar, Malware: Rüstungskonzern Rheinmetall in Amerika betroffen, eRecht 24, 13. Oktober 2019,
www.e-recht24.de/news/it-sicherheit/11656-rheinmetallusa-von-malware-betroffen.html
[5] Jürgen Schmidt, Trojaner-Befall: Emotet bei Heise, c‘t 13/2019, S. 36, Juni 2019, online auf https://heise.de/-4437807
[6] Wikipedia, Nuklearunfall von Tokaimura 1999, letztes Update Februar 2020, https://de.wikipedia.org/wiki/Nuklearunfall_von_T%C5%8Dkaimura_1999
[7] juh/AP/Reuters, Hackerangriff kostet Reederei Hunderte Millionen, Spiegel Netzwelt, 16. August 2017, www.spiegel.de/netzwelt/netzpolitik/moller-m-rsk-cyberangriff-kostet-reederei-hunderte-millionen-a-1163111.html
[8] Jürgen Schmidt, LinkedIn-Passwort-Leck hat desaströse Ausmaße, heise online, Mai 2016, https://heise.de/-3210793
[9] Patrick Ruppelt, Datenpanne bei Zendesk, Blogbeitrag, Oktober 2019, www.itk-security.de/datenpanne-beizendesk/
[10] Stephan Scheuer, Neue Datenschutz-Vorwürfe gegen Videodienst Zoom, Handelsblatt online, 31. März 2020,
www.handelsblatt.com/25700760.html
[11] Morgane Tual, Une panne informatique à l’aéroport d’Orly liée à… Windows 3.1, Le Monde, 11. November 2015, www.lemonde.fr/pixels/article/2015/11/11/une-panne-informatique-a-l-aeroport-d-orly-liee-a-windows-3-1_4807479_4408996.html
[12] Christian Kahle, Cobol-Programmierer werden im Anti-Corona-Kampf dringend gesucht, WinFuture, April 2020, https://winfuture.de/news,115127.html
[13] Anna Irrera/Reuters, US-Banken holen IT-Kräfte aus Ruhestand zurück – Programmierer mit 70 Jahren oder älter dringend gesucht, manager magazin, April 2017, www.manager-magazin.de/unternehmen/artikel/us-bankenbrauchen-it-kraefte-manager-holen-cobol-veteranenzurueck-a-1143632.html