Vier agile Werkzeuge für mehr Sicherheit – Anti-Personas

Im Beitrag Vier agile Werkzeuge für mehr Sicherheit – Assets priorisieren mit Bull’s Eye Diagram haben wir gesehen, wie wir die schützenswerten Assets unseres Produkts finden und priorisieren. Im zweiten Teil der Reihe wird es nun um die Angreifer*innen gehen.

Um entscheiden zu können, welche Sicherheitsmaßnahmen wir treffen wollen, ist es notwendig zu wissen, vor wem wir uns überhaupt schützen müssen. Es macht einen großen Unterschied, ob ich Geheimagenten der NSA abwehren will, ein unerfahrenes Scriptkiddie oder ob ich verhindern will, das aus Versehen etwas kaputt gemacht werden kann.

Am Ende des Artikels findet ihr alle Anti-Personas zum Download als PDF. Ich habe sie unter der CC0 in die Public Domain entlassen. Ihr dürft sie also für alles verwenden. Ähnlichkeiten mit real existierenden Personen oder Unternehmen sind rein zufällig. DIe Portraits stammen von 2happy.

Personas

Aus der User Experience Toolbox stammen die Personas. Sie stellen unterschiedliche Nutzergruppen unseres Produktes dar und helfen, es optimal an ihre Bedürfnisse anzupassen.

Durch Vorlieben und Charakterzüge sollen sie im Designprozess helfen, Sympathie mit den Nutzer*innen zu entwickeln und ihre Motivationen nachvollziehen zu lernen. Wenn ich eine Persona habe, die sich mit Computern schwertut, aber mit dem Smartphone ganz gut umgehen kann, hilft das bei vielen Entscheidungen während des Designs. Ein Commandline Interface wäre für die Persona ungeeignet. Eine App würde aber Zuspruch finden.

Wichtig ist, dass es sich nicht einfach um Rollen handelt. Für eine Webanwendung wären eine Persona für Admins und eine für Nutzer*innen wenig hilfreich. Diese Unterteilung ergibt sich ja schon aus dem Code oder dem funktionalen Design und bietet keinen Mehrwert.

Wenn wir Daten aus Befragungen oder anderen Analysen haben, sollten diese Verwendet werden, um die Personas möglichst realitätsnah zu gestalten. Falls man keine Daten hat, kann man auch auf Analysen für Branchen zurückgreifen oder muss notfalls raten. Dann sollte man aber möglichst bald evaluieren, ob die gemachten Annahmen zu den Personas auch der Realität entsprechen.

Wie eine Persona erstellt werden kann, hat unter anderem Adobe beschrieben.

Anti-Personas

Mit Personas haben wir die erwünschten Nutzer*innen unseres Produktes definiert. Doch es gibt auch Personengruppen, die unser Produkt nicht oder nur eingeschränkt nutzen sollen.

Dies kann man an folgendem Beispiel gut sehen. Unsere Firma hat eine innovative Medikamentendose entworfen, bei der besonders auf ältere Menschen geachtet wurde. Die Dose lässt sich auch bei nachlassender Kraft und Geschicklichkeit in den Fingern leicht öffnen. Die Zielgruppe ist begeistert. Doch als eine Mitarbeiterin einen Prototyp mit nach Hause nimmt, spielen ihre Kinder damit und können die Dose ebenfalls leicht öffnen. Da Medikamente oft bunt gestaltet sind, werden sie immer wieder von Kindern gegessen, was tödliche Folgen haben kann. Unsere Firma muss die Medikamentendose kurz vor Produktionsstart nochmal anpassen und einen Kompromiss aus Kindersicherheit und einfachem Öffnen finden. Wären die Kinder bereits zu Beginn der Entwicklung im Fokus gewesen, wären viele Designentscheidungen anders ausgefallen.

Mit einer passenden Anti-Persona können Designentscheidungen vermieden werden, die später zu Problemen führen. Je nach Produkt kann das nachträgliche Lösen diese Probleme kostspielig werden oder im schlimmsten Fall sogar dazu führen, dass das Produkt vom Markt genommen werden muss.

Mehr zu Anti-Personas bei Produkten könnt ihr in einem Beitrag auf Delightful nachlesen.

Anti-Personas für mehr IT-Sicherheit

Wir nutzen Anti-Personas nun im Kontext der IT-Sicherheit. Auch hier geht es um Entscheidungen, die es bestimmten Nutzer*innen unserer Services und Produkte so schwer wie möglich machen sollen.

Um zu verhindern, dass Skriptkiddies mit Brute Force Angeriffen Zugriff auf Accounts erlangen, können mehrere Maßnahmen eingeführt werden. Mindestlängen für Passwörter, Anforderungen an die Komplexitiät, Sperren nach einigen Fehlversuchen. Wenn ich es mit versierteren Angreifer*innen zu tun habe, die vielleicht auch über geziehlte Phishingmails versuchen an Logindaten zu gelangen, reicht das nicht mehr. Dann brauche ich Zwei- oder Multifaktorauthentifizierung.

Wenn ich einen besonders kritischen Dienst im internen Netzt betreibe reicht es scheinbar aus, dass er mit einer sicheren Anmeldung, wie gerade eben beschrieben, versehen wird. Doch wenn ich nicht nur mit Skriptkiddies und Hackern rechne, sondern auch mit Insidern, muss ich mein System an dieser stelle anders entwerfen. Zum Beispiel indem drei von fünf Berechtigten ihre Anmeldedaten eingeben.

Je nachdem, gegen wen wir uns schützen wollen, müssen wir andere Szenarien bedenken und Gegenmaßnahmen implementieren.

Beispiele für Anti-Personas

Skriptkiddies

Auf jeden Fall sollte ein Schutz vor einfachen (automatisierten) Angriffen implementiert werden. Sobald ein System mit dem Internet verbunden wird, dauert es meist keine fünf Minuten, bevor die ersten Angriffe eingehen. Zumindest bei IPv4. Denn dieser wird inzwischen ständig komplett gescannt und angegriffen. Doch auch gezieltere Angriffe mit Tools werden von Skriptkiddies durchgeführt. Ihr technisches Verständnis kann stark variieren. Manche können Programmieren, andere nur Tools herunterladen und Anleitungen befolgen. Oft wird nur kurz versucht, ein System zu knacken. Schließlich gibt es genügend unsichere Alternativziele.

Anti-Persona Skriptkiddie Simon als Steckbrief

Hacker*innen

Hackerinnen haben viel Erfahrung mit Angriffen und der Verwendung von IT-Security Werkzeugen. Sie können auch komplexe Angriffe durchführen und mehrer Lücken kombinieren, um an ihr Ziel zu gelangen. Was alles möglich ist, zeigen verschiedene Teams auf Veranstaltungen wie der Pown2Own. Ob Angriffe über längere Zeit vorbereitet werden, hängt stark von der Motivation ab. Es gibt Sicherheitsforscherinnen, die sich Produkte ansehen und Lücken melden, aber auch organisierte Kriminalität und Ransomware Gangs.

Anti-Persona Hackerin H3x als Steckbrief

Staatliche Akteure

Was Staatliche Akteure haben fast unbegrenzte Resourcen. Sowohl was Geld und Zeit als auch neue Technologien angeht. Spätestens seit den Enthüllungen durch Snowden wird man nicht mehr belächelt, wenn man vor staatlichen Hacker*innen warnt. Neben Angriffen über Computernetze sind auch Agenten vor Ort denkbar, die Manipulationen im Rechenzentrum oder dem Unternehmen durchführen. Angriffe können sich über Monate und Jahre hinziehen und extrem schwer zu entdecken sein.

Anti-Persona NSA Agentin Mrs. Smith als Steckbrief

Insider

Eine besondere Gefahr geht von Insidern aus. Mitarbeiter*innen die sich bereichern wollen, Groll gegen das Unternehmen hegen oder sogar erpresst werden, können in den eigenen Systemen großen Schaden anrichten. Gerade wenn noch auf Perimeter Sicherheit gesetzt wird.

Anti-Persona Insiderin Ina als Steckbrief

Ungeschickte Nutzer*innen

Neben böswilligen Angriffen gibt es auch einfache Versehen, die schlimme folgen haben können. Ein Zahlendreher bei einer großen Übeerweisung. Das Ändern einiger Einstellungen im Produktivsystem. Das Klicken auf eine scheinbar harmlose datei.pdf.exe.

Deshalb sollte bei der Gestaltung von Systemen und Sicherheitsmechanismen auch berücksichtigt werden, dass wichtige oder gefährliche Aktionen eine Bestätigung brauchen oder nach dem Vier-Augen-Prinzip durchgeführt werden.

Anti-Persona des tollpatischen Angestallen Peter als Steckbrief

Downloads

Zusammenfassung

Anti-Personas helfen uns, im Blick zu behalten, vor wem wir uns schützen. Das hilft Maßnahmen so zu gestalten, dass sie verhältnissmäßig und zielführend sind.

Habt ihr schon Personas oder gar Anti-Personas im Einsatz? Welche habt ihr erstellt und wie nutzt ihr sie im Alltag? Schreibt mir gerne eine E-Mail oder auf Twitter.

Bis bald,

seism0saurus