IT-Security als psychologischer Prozess

Gestern habe ich mich in einem Blogpost mit dem Umstand befasst, dass viele Sicherheitsprobleme in Organisationen und Unternehmen darin begründet liegen, dass Mitarbeiter nicht richtig geschult sind. Daraus ist eine Diskussion auf Google+ entstanden, in deren Verlauf deutlich wurde, dass ein anderes Problem darin besteht, dass IT-Sicherheit oft nur an technischen Lösungen orientiert ist. Die psychologische Seite, das Verhalten der Beteiligten, wird meist komplett ausgeblendet. In diesem Artikel möchte ich daher darlegen, warum ich der Meinung bin, dass IT-Sicherheit nicht primär ein Problem ist, das auf der technischen Ebene zu lösen ist, sondern ein psychologischer Prozess. Zahlreiche psychologische Faktoren beeinflussen diesen Prozess und entscheiden darüber, ob IT-Security erfolgreich implementiert werden kann oder nicht.

Wissen: Wissen ist einer der zentralen psychologischen Faktoren in diesem Prozess. Die Sicherheit einer eingesetzten Software hängt vom Wissen des Programmierers der Software ab. Die Implementierung und Wartung sicherer Systeme setzt profundes Wissen der zuständigen Administratoren voraus. Und natürlich benötigen auch die Mitarbeiter, die die Systeme tagtäglich benutzen, ein gewisses Maß an Wissen für den sicheren Umgang damit. Darüber hinaus muss dieses Wissen regelmäßig auf den neuesten Stand gebracht und aufgefrischt werden.

Die (Un)fähigkeit von Menschen, komplexe Systeme zu handhaben: Software und IT-Systeme sind oft sehr komplexe Systeme. Das bedeutet, dass sie viele Elemente umfasssen, die miteinander verknüpft sind und sich gegenseitig beeinflussen. Aus psychologischen Untersuchungen weiß man, dass Menschen nicht sonderlich gut darin sind, mit allzu komplexen Systemen umzugehen. Je komplexer ein System ist, umso wahrscheinlicher ist es daher, dass sicherheitsrelevante Fehler bei der Programmierung, Implementierung, Wartung oder Benutzung des Systems passieren oder sicherheitsrelevante Prozesse vereinfacht oder umgangen werden, um Komplexität zu reduzieren. Ein bekanntes Beispiel dafür ist die Wahl schwacher Passwörter oder die Verwendung ein und desselben Passworts für alle Accounts.

Motivation: IT-Security wird insbesondere von Anwendern oft als lästige Pflicht empfunden. Sicherheitsregeln erschweren die Arbeit und gehen zu Lasten der Effektivität. Der Nutzen von Policies bleibt Anwendern dagegen oft verborgen, solange nichts passiert. Sie profitieren nicht direkt von ihrer Einhaltung. Das senkt die Motivation, Regeln zum sicheren Umgang mit IT zu beachten.

Emotionen: Angreifer, die ein IT-System kompromittieren wollen, agieren oft auf der emotionalen Ebene, um sich mittels Social Engineering Zugang zu IT-Systemen zu verschaffen. Ein beliebtes und oft sehr erfolgreiches Angriffsszenario ist beispielsweise, Mitarbeitern ein schlechtes Gewissen zu machen oder Angst vor Konsequenzen zu schüren, wenn sie den Anweisungen des Angreifers nicht folgen. Die Folge sind Stresssituationen, in denen Mitarbeiter nicht mehr rational handeln. Emotionen spielen so regelmäßig eine entscheidende Rolle bei Einbrüchen in IT-Systeme.

Routine und Monotonie als Sicherheitsrisiko: Aus der Arbeitspsychologie wissen wir, dass Routine und Monotonie die Wahrscheinlichkeit von Arbeitsunfällen erheblich erhöhen können. Gleiches gilt für IT-Security. Zwar ist Routine in einem gewissen Maß auch förderlich, um sicherheitskonformes Verhalten zu verinnerlichen. Auf der anderen Seite kann das Wissen, etwas sehr gut zu beherrschen, dazu führen, dass Prozeduren lax gehandhabt, abgekürzt oder gar umgangen werden, was sich negativ auf die Sicherheit auswirken kann.

Die Abstraktheit von Sicherheitsrisiken der Gefahr: Wie bereits angedeutet, besteht ein erhebliches Problem darin, dass Gefahren für die IT-Sicherheit oft als sehr abstrakt empfunden werden. Unter Umständen werden die Auswirkungen eines erfolgreichen Angriffs zunächst gar nicht bemerkt. Darüber hinaus sind auch die positiven Auswirkungen der Beachtung von Sicherheitsmaßnahmen meist nicht sichtbar. Wer sie beachtet, hat kein direktes Erfolgserlebnis. Der Erfolg besteht darin, dass nichts passiert.

Diese Ausführungen sollten deutlich machen, dass es nicht ausreicht, IT-Security als rein technisches Problem zu sehen, das mit der Implementierung bestimmter Technologien gelöst werden kann, wie es leider allzu oft üblich ist. Erfolgreiche IT-Security ist vielmehr von der Entwicklung bis zur Anwendung ein komplexer psychologischer Prozess. Auf allen Ebenen müssen die Akteure ausreichendes Wissen mitbringen, das auf dem neuesten Stand zu halten und regelmäßig aufzufrischen ist. Systeme müssen so wenig komplex wie möglich gestaltet sein, um Sicherheitsmängeln durch eine Überforderung angesichts allzu hoher Komplexität oder durch eigenmächtige Komplexitätsreduktion seitens Administratoren und Anwendern vorzubeugen. Programmierer, Administratoren und Anwender müssen stets aufs Neue motiviert werden, IT-Sicherheit ernst zu nehmen. Sie müssen in Social Engineering geschult werden, um emotionalen Stress, den ein Angreifer erzeugen will, frühzeitig erkennen und Gegenmaßnahmen ergreifen zu können. Routine und Monotonie bei sicherheitsrelevanten Abläufen ist ebenso vorzubeugen wie der Wahrnehmung von Sicherheitsrisiken als vollständig abstrakt. Hier können beispielsweise regelmäßige Übungen helfen, die Mitarbeitern die Konsequenzen ihres Handelns direkt vor Augen führen und so Erfolg bei der Beachtung von Policies, aber auch negative Konsequenzen bei ihrer Missachtung sichtbar machen.

Ich danke Hans-Erik Gaßner für die anregende Diskussion auf Google+ und für die Idee zu diesem Artikel.

4 comments on IT-Security als psychologischer Prozess

  • „Routine und Monotonie als Sicherheitsrisiko“ – das ist mir etwas zu pauschal. Wenn den Mitarbeitern sicherheitsrelevante Vorgänge in Fleisch und Blut übergegangen sind, ist das erstmal positiv (natürlich sollten sie immer noch wissen, warum sie Dinge tun oder nicht tun), weil die Sicherheit dann quasi automatisch gewahrt bleibt.

    Riskant kann dabei nur sein, wenn sicherheitsrelevante Vorgänge einfach nur voraussehbar sein müssen, um geknackt werden zu können, weil es dann genügt, einen Mitarbeiter zu beobachten, um einen Sicherheitsmechanismus zu umgehen. Das ist aber wiederum eine Frage der Sicherheitsarchitektur und/oder ihrer Implementierung. Oder anders, da muß die Psychologie früher ansetzen, nicht erst beim Mitarbeiter.

    Mitarbeiter haben erstmal ein Interesse daran, die ihnen aufgegebenen Arbeiten effizient zu erledigen. Wenn ein Arbeitgeber von seinen Angestellten – explizit oder implizit – verlangt, daß sie Arbeiten (auch) zu Hause zu erledigen haben, dann ist es auch seine Pflicht, sowohl effiziente als auch sichere Verfahren dafür zur Verfügung zu stellen. In diesem Fall wäre ein VPN deutlich sinnvoller gewesen.

    Gerade, wenn Dateien mit nach Hause oder generell (legitim) aus dem Netzwerk des Arbeitgebers heraus genommen werden, stellt sich dann auch noch die Frage, wie sicher der Computer ist, auf dem sie weiterverarbeitet werden. Es hätte ja nicht einmal der USB-Stick sein müssen; bestimmte Dateiformate sind direkt infizierbar.

    Hier muß zunächst der Arbeitgeber und müssen dann auch die Mitarbeiter weiterdenken und sich vorab Gedanken darüber machen, was mit aus dem Netzwerk entnommenen Dateien passiert, insbesondere (aber nicht nur), wenn sie nach Bearbeitung wieder ins Netzwerk zurückgebracht werden.

    Wenn aber schon der Arbeitgeber, hier das Kanzleramt, eine Anforderung stellt, deren sichere Ausführung gar nicht möglich ist, dann kann man der Mitarbeiterin kaum einen Vorwurf machen, daß sie eben einfach versucht, mit den vorhandenen Mitteln ihren Job zu machen.

    • Grundsätzlich richtig, ja. Ob diese Anforderung wirklich gestellt wurde, darf den Berichten nach aber angezweifelt werden. Den dienstlichen USB-Stick mit nach Hause zu nehmen, war offenbar ein Verstoß gegen die Sicherheitsrichtlinien, wie zu lesen ist. Ob es überhaupt erlaubt ist, Dokumente aus diesem Netzwerk woanders zu bearbeiten, wird nirgends diskutiert, oder? Es soll ja auch Mitarbeiter geben, die sich ohne Dienstanweisung Arbeit mit nach Hause nehmen.

      Zu „Wenn den Mitarbeitern sicherheitsrelevante Vorgänge in Fleisch und Blut übergegangen sind, ist das erstmal positiv […], weil die Sicherheit dann quasi automatisch gewahrt bleibt.“. Dieser Automatismus besteht eben bei Routine nicht zwingend, das ist ja das Problem. Routine kann auch dazu führen, dass sich Mitarbeiter zu sicher fühlen und aus ihrer Routine heraus zu wissen meinen, wie sie ein Prozedere vereinfachen können, ohne dass es unsicherer wird. Leider geht sowas immer wieder schief, und zwar nicht nur in der IT, sondern auch in Bereichen, in denen es ganz direkt um Menschenleben geht. Es gab in der Vergangenheit einige Flugzeugabstürze, die ihre Ursache darin hatten, dass Reparatur-„Routinen“ abgekürzt wurden, weil sich die Mechaniker zu sicher in dem fühlten, was sie taten. Das „in Fleisch und Blut übergehen“ ist also durchaus eine Medaille mit zwei Seiten.

      • Du übersiehst da noch dieses kleine Paradoxon, das ich bei diversen Arbeitgebern immer wieder festgestellt habe. Da heißt es zum einen häufig, es darf nichts mit aus der Firma/Behörde mitgenommen werden, aber andererseits stellt man schnell fest, daß man zumindest zeitweise ohne Heimarbeit die auferlegte Arbeit gar nicht in sinnvoller Zeit schaffen kann.

        Das muß vom Arbeitgeber nicht einmal bewußt so gehalten sein, sondern ergibt sich einfach daraus, wenn man prinzipiell zu wenig Personal für die anstehende Arbeit eingestellt hat. Oder in kurz: Auch der hausgemachte Personalmangel gerade (aber nicht nur) bei Behörden kann leicht zum Sicherheitsproblem werden. Darüber denken Arbeitgeber aber nicht so gerne nach.

        • Das ist richtig. Dieses Paradoxon habe ich auch schon erlebt. Kommt auch im öffentlichen Dienst vor. Meistens klopfen da dann aber doch noch die Admins den Chefs auf die Finger. 😉

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.