Cybersecurity hier und Cybersecurity da – hier wird vor Hackerangriffen gewarnt und dort darum gebeten, sich mehr um die Sicherheit in Unternehmen zu kümmern. Aber wo beginnt eigentlich Cybersecurity und wo endet sie? Ist die IT dafür verantwortlich oder doch die AV-Branche, wenn nicht sogar die Endnutzer:innen? Mit diesen Fragen haben sich die Teilnehmer eines von Atlona veranstalteten Diskussionspanels beschäftigt.
Die dritte Episode der Diskussionsreihe „The Hub“ widmet sich dem Thema Cybersicherheit. Die Teilnehmer des Panels setzen sich aus Herstellern und Integratoren zusammen. Mit dabei: Iftekhar Hossain (Director of Quality bei Panduit), Paul Konikowski (Cyber Security Architect bei Level 3 Audiovisual), Frank Padikkala (Technical Sales Engineer bei Audinate), Mark Okern (Solution Architect bei Yorktel) und Garth Lobban (Director of Marketing bei Atlona), der in dieser Diskussionsrunde als Host fungiert. Gemeinsam diskutieren Sie die Notwendigkeit von Cybersecurity sowie die Merkmale und Spannweite dieser umfangreichen Thematik.
Bevor es um die eigentliche Thematik der Cybersicherheit geht, sollte vorerst eine sprachliche Grundlage geschaffen werden.
Frank Padikkala versucht sich an einer Definition: „Cybersicherheit bezieht sich, wie der Name schon sagt, nicht nur auf cyberbezogene Ereignisse. Es geht um alles, was Sicherheit erfordert. Es ist die neue Terminologie, die alles umfasst – von physischer Sicherheit bis hin zu Cloud Computing, IOT und netzwerkbasierter Sicherheit.“
Dabei lassen sich diese Angelegenheit in drei Komponenten unterteilen: die technologische und die menschliche Komponente sowie die Prozesskomponente. An dieser Definition orientiert sich folgend der Text.
Über die technische Ebene wird in der Branche wahrscheinlich am meisten gesprochen, gefolgt von der Prozessebene – wie kann sichere Technologie hergestellt werden bzw. wie können bestehende Systeme noch sicherer gemacht werden? Welche Prozesse sind bei den Testdurchläufen und bei der Installation der Systeme notwendig? Diese Fragen werden üblicherweise gestellt.
Die menschliche Komponente wird dabei meist außer Acht gelassen. So würden Unternehmen beispielsweise eher Summen für Sicherheitstechnik ausgeben als für eine ordentliche Security-Schulung, die den Mitarbeitenden die nötigen Basics beibringt. Gerade zu Zeiten, in denen das hybride Arbeiten attraktiver denn je scheint, birgen diese Wissenslücken gewisse Gefahren.
Dass das Problem nicht unbedingt die Technik ist, zeigt ein Beispiel, das Mark Okern sinngemäß so beschreibt: „Man nehme an, es gibt einen Hersteller, der Raumsteuerungen, Videosysteme etc. anbietet. Dieser Hersteller nutzt einen Cloud-Service, und die Mitarbeiter fragen sich, warum sie zum Beispiel Phishing-E-Mails bekommen. Das kann daran liegen, dass sie ihre Kontaktdaten beispielsweise auf einem Branchenportal öffentlich ausstellen und sich die Angreifer Personal aussuchen, das nicht unbedingt aus Sicherheitsingenieur:innen besteht – vielleicht sind sie im Bereich der Zusammenarbeit tätig, vielleicht sind sie Vertragsangestellte. Man sende ihnen nun eine E-Mail mit dem Inhalt: ‚Guten Tag, Ihre Anmeldedaten für die XYZ-Cloud scheinen kompromittiert worden zu sein. Können Sie bitte auf diesen Link klicken, um das Problem zu beheben?‘ Die meisten Personen würden den Phishing-Versuch wahrscheinlich erkennen und die Mail ohne weitere Aktion löschen – jedoch reicht eine einzige Person, die eben doch auf den dubiosen Link klickt. Mit diesem Klick erhält der Angreifer bereits die Anmeldedaten für den Cloud-Dienst. Man könnte daraufhin denken, dass der Angreifer mit den Anmeldedaten nicht viel erreichen kann, außer einen Blick in das Portal zu erhaschen. Doch wie groß ist die Wahrscheinlichkeit, dass die Zugangsdaten auch für einen anderen AV-Cloud-Dienst verwendet werden? Vielleicht nutzt diese Person dieselben Zugangsdaten auch für andere Dienste wie Microsoft Azure oder AWS (Amazon Web Services). Spätestens jetzt hätte der Angreifer Zugriff auf die Cloud-Umgebung und könnte damit nicht-geringen Schaden anrichten. Kurz: Es ist nicht nötig, eine Firewall zu hacken oder sich irgendwelche Tools herunterzuladen – das Einzige, worauf sich Angreifende verlassen müssen, ist eine beispielsweise übermüdete Person, die unaufmerksam geworden ist und auf besagten Link klickt.“
Auch das Ausmaß des Schadens, der durch das Einstecken eines USB-Sticks in den Computer angerichtet werden kann, ist nicht zu unterschätzen – es reicht von der Zerstörung des Computers bis hin zur Infizierung und Übernahme des gesamten Systems.
„Die Verbreitung des Stuxnet-Virus ist beängstigend“, so Paul Konikowski. Und doch komme es vor, dass Personen ein ganzes Glas davon auf ihrem Schreibtisch stehen haben und nicht wissen, woher das Virus kommen kann. Auch in diesem Fall ist kein:e geschickte:r Hacker:in erforderlich. Es reicht eine Person, die unbefugt Zutritt zu gewissen Räumlichkeiten erlangt und heimlich einen solchen Stick an einem der Computer anbringt. Natürlich kann mit so einem Stick nicht nur ein gefährlicher Computerwurm verbreitet werden, es können genauso gut Daten gestohlen werden. Der Fehler sei laut Mark Okern in diesem Fall nicht die Software auf dem USB-Stick, sondern die Tatsache, dass sich überhaupt jemand Zugang verschaffen konnte. Man denke immer nur an die elektronische Gefahr und übersehe dabei heutzutage häufig die Sicherheitslücken, die man wortwörtlich vor der Nase liegen hat. „Wir denken, dass es immer Hightech ist, aber man weiß nicht, dass es auch jemand sein könnte, der mit einem Notizblock herumläuft“, so Okern. Wo ordnet man diesen Aufgabenbereich der Sicherheitstechnik ein und wer sollte sich nun womit beschäftigen?
Damit zeigt sich eine weitere Problematik: die Aufgabenteilung der IT- und AV-Branche. Wer ist für was zuständig? Wo beginnen die Arbeitsbereiche der jeweiligen Gruppen – Hersteller, Integrator:innen und Endbenutzer: innen. Für Frank Padikkala ist Sicherheit eine wachsende Landschaft, die dazu zwinge, sich ständig weiterzuentwickeln und daran zu arbeiten. Sicherheitshygiene ist demnach kein einstufiger Prozess. Es handelt sich nicht um etwas, das man in einem einzigen Schritt sicherstellen kann. Wenn ein:e Endbenutzer:in sich beim AV-Integrator/bei der AV-Integratorin oder beim Hersteller meldet, um Sicherheitsauskunft über ein bestimmtes Produkt zu erhalten, passiere nach Padikkala häufig Folgendes: Man legt ihnen ein 60-seitiges White Paper vor, in dem alles drinsteht, anstatt ihnen einfach explizit die Antwort zu geben. Damit sich das ändert, müsse jede:r Teil des Prozesses sein. Nicht jede:r müsse ein:e Hacker:in sein, aber man sollte ein Verständnis für Sicherheit haben. Für Padikkala beginne dies bereits im Verkaufsprozess, also in der Phase der Bedarfsanalyse eines Projekts, denn dort fängt man an, die Sicherheitsfragen zu stellen – nicht erst, wenn das Sicherheitssystem fertig ist. Bei Beschwerden werde die Verantwortung dann häufig vom Hersteller auf den/die Konstrukteur:in geschoben und andersherum. Es ist jedermanns Aufgabe, zu lernen, wie man das eigene Heimbüro und das Familiennetzwerk schützen kann. Die Grundlagen dafür, wie man seine Familie in Sachen Sicherheitshygiene unterrichtet und lernt, wie man das auch im Büro umsetzen kann, gehören von nun an zusammen.
Es ging bis jetzt lediglich um die menschlichen Komponenten der Sicherheitstechnik. Der folgende Punkt lässt sich nicht dort einreihen – er trägt den Namen: Threat Modeling. Dazu teilt Mark Okern seine eigene Erfahrung als Endanwender mit, die er erlebt hat, bevor er auf die Seite der IT gewechselt ist. Eine der Schwierigkeiten bei der Modellierung sei in seinen Augen die Verlagerung in die Cloud. Die Cloud sei kein Rechenzentrum, das unter der eigenen Kontrolle steht – es handle sich um eine „völlig neue Umgebung“.
Man wisse als Integrator:in und als Endanwender:in nicht, was bei den Geräten wortwörtlich unter der Haube steckt. Mark Okern: „Wir verstehen, dass dieses Gerät dies tut und diese Protokolle spricht, mit denen wir in unserem täglichen Leben zu tun haben. Aber verstehen wir auch das zugrundeliegende Betriebssystem?“ Beispiel: Wenn eine Meldung mit dem Text ‚Das ist eine Sicherheitswarnung für die Linux-Variante xy‘ aufploppt, dann sagen einige vielleicht, dass die Meldung für sie irrelevant sei. Allerdings sind sich viele gar nicht dessen bewusst, dass sie in ihrem Konferenzraum nicht vielleicht doch einen Controller haben, auf dem diese Linux-Version läuft. „ Sicherheit durch Unklarheit ist ein altes Sprichwort“, so Okern, „aber es gibt auch eine Bedrohung durch Unklarheit, und diese Unwissenheit ist gefährlich.“
Iftekhar Hossain gibt einen Einblick in das Produktdesign und die Entwicklung von Sicherheitstechnik: „Alle Produkte, die wir jetzt auf den Markt bringen, sind in irgendeiner Weise mit dem Internet verbunden und verfügen über eine Vielzahl von Funktionen wie Firmware und Software.“ Es gebe wortwörtlich viele Türen, die man über diese Geräte öffnen könne, sobald sie mit dem Netzwerk verbunden sind. Wie also kann man ein Produkt entwickeln, das Endkund:innen sicher in ihrer Umgebung einsetzen können?
„Einige der grundlegenden Konzepte bestehen also darin, einen sicheren Softwareentwicklungszyklus […] zu befolgen, bei dem wir mit der Schulung unserer Mitarbeiter in Bezug auf die Bedeutung der Sicherheit für die verschiedenen Personen in dieser Rolle beginnen.“ Dabei nennt Hossain wegweisende Fragen: „Was bedeutet es z.B. für einen Produktmanager, dass er ein Produkt in Bezug auf die Sicherheitsanforderungen entwickeln muss? Was bedeutet es für die Entwicklung eines Produkts? Was sind einige der Bedenken, die wir haben müssen? Und wie können wir sie entschärfen? Wie implementieren und codieren wir richtig?“
Bei der Codierung liege der Schwerpunkt auf dem Schreiben von sicherem Code oder der Durchführung von sicheren Code-Reviews und der Implementierung verschiedener Tools, die bei Vorschau helfen können, wie z.B. statische Analyzer, und dann schließlich die Implementierung. „Unsere Geräte verfügen über einen gesicherten Boot-Vorgang, denn manchmal kann man das Gerät auf eine andere Art und Weise booten lassen, als es eigentlich sein sollte.“ Darüber hinaus gebe es verschiedene Arten von Penetrationstests, die man durchführen könne und die prüfen sollen, ob der gesamte Code für die sichere Codierung nach den Best Practices signiert wurde. Es gilt, herauszufinden, welche Benutzeroberflächen, in die Menschen eindringen können, es sonst noch gibt.
Ein weiterer wichtiger Punkt ist das Threat Modeling. „Wir sehen uns auch das Produkt an und prüfen, welche Einstiegspunkte wir haben: Wie kann ein Angreifer in mein System eindringen und was kann ich tun, um jede einzelne Tür so gut wie möglich zu schließen?“, fasst Hossain zusammen.
Nachdem nun einige der Problematiken, die selten Beachtung finden, näher betrachtet wurden, sollen nun die zehn größten Sicherheitsbedrohungen aus dem Jahr 2022 einmal aufgelistet werden. Die Daten stammen von einer Versicherungsgesellschaft, die sich auf Versicherungspolicen für Cybersicherheitsverbrechen und Cyberkriminalität spezialisiert hat und die von Garth Lobban im Diskussionspanel vorgestellt werden:
Die Auflistung bestätigt, dass auf der menschlichen Ebene aktuell Nachholbedarf notwendig ist, da die ersten beide Plätze des Rankings (größtenteils) nicht aus einer technologischen Grundlage entstammen. Sicherlich kann man auch bei den anderen Platzierungen zwischenmenschliche Aspekte hineininterpretieren, jedoch spielen dort ebenso die technische Komponente sowie die Prozesskomponente mit rein.
Lösungsansätze zur Verbesserung der Sicherheitsstrategien
Paul Konikowski erwähnt im Gespräch §327 des Gesetzbuches, welcher Verträge zu digitalen Produkten behandelt. Dieses Gesetz könnte seiner Einschätzung nach die AV-Branche dahingehend beeinflussen, mehr zu handeln. Damit habe schließlich die Diskussion über AV-Sicherheit wirklich begonnen. Plötzlich reagierten die Hersteller und verlangten entweder ein individuelles Passwort oder ein Passwort, bei dem man aufgefordert wurde, es bei Erstnutzung gleich zu ändern – dies sollte seiner Meinung nach in diesem Gesetz ebenfalls gesetzlich festgehalten werden. Iftekhar Hossain ergänzt hierzu, dass ein nichtstandardmäßiges Passwort tatsächlich auf Herstellerebene eine mögliche Lösung sein könnte. Warum ein standardmäßiges Passwort keine gute Idee sei, beschreibt er wie folgt: „Nehmen wir an, ein Hersteller stellt eine große Anzahl an Geräten her, und sie werden alle mit dem Standard-Login-Passwort ausgeliefert, das mit 123 oder wie auch immer belegt sein kann. Das Problem hierbei: Wenn jemand sich tatsächlich in eines dieser Geräte einhackt, dann kompromittiert er jedes einzelne Gerät, das von diesem Hersteller kommt.“ Sind die Geräte jedoch alle mit einem anderen Startkennwort ausgestattet, so kann ein:e Hacker:in kein weiteres Gerät beschädigen, da sich die Passwörter unterscheiden.
Ein weiterer Lösungsansatz, der in dem Panel vorgestellt wird, ist die Zero-Trust-Methode. Für Cybersicherheitsexpert:innen ist dieser Trend wahrscheinlich nicht neu, aber eventuell für AV-Expert:innen. Um den Begriff zu erläutern, klärt Paul Konikowski vorerst, was der Begriff nicht bedeutet: „Wenn Sie sagen, dass Sie in Ihrer Organisation Zero Trust einführen, bedeutet das nicht, dass Sie Ihren Mitarbeitern nicht vertrauen.“ Vielmehr bedeute dieses Verfahren, dass beim Login immer davon ausgegangen wird, dass es sich nicht um die rechtmäßige Person handelt. „Wir gehen davon aus, dass Ihre Anmeldedaten jeden Tag gestohlen werden, dass jemand im Netzwerk ist oder zumindest Zugang zu einigen Anmeldedaten hat. Wir wollen also sichergehen, dass Sie es sind, und verifizieren, dass Sie es sind, indem wir einen Multifaktor verwenden.“ Hier kommt die Multifaktor-Authentifizierung – kurz MFA – ins Spiel, von der die meisten wahrscheinlich inzwischen gehört haben. Insgesamt teilen sich die Zero-Trust-Prinzipien in drei Gebiete auf:
Annahme des Verstoßes
Explizite Verifizierung (z.B. durch MFA)
Einschränkung des Benutzerzugangs
Die Einschränkung des Benutzerzugangs bedeutet, dass man den Angestellten die Werkzeuge, die sie für ihre Arbeit benötigen, und die Daten, die Sie brauchen, zur Verfügung stellt – und mehr nicht. Dieser Vorgang wird lease privilege genannt.
Paul Konikowski gibt bezüglich des Threat Modelings außerdem den Tipp, sich gelegentlich Case Studies durchzulesen, um auf dem aktuellen Stand zu bleiben und zu erfahren, was draußen vor sich geht. Dabei sollte man versuchen, diese Ereignisse zu verstehen und herauszufinden, welche davon einen am meisten betreffen könnten. Manchmal müsse man einfach die Brille des „Bad Actors“ aufsetzen und die eigene Fantasie nutzen.