Die Usability-Architektur eines Systems definiert die Interaktion zwischen Mensch und Maschine und steht in einem engen Zusammenhang mit seiner sicheren und erwartungsgemäßen Nutzung. Sie kann jedoch nicht einfach aus einem unsicheren System ein sicheres machen. Nach einem kurzen Überblick zum Usability-Problem in der Security untersucht dieser Beitrag die Möglichkeiten und Grenzen der Usability-Architektur bei der Abwehr von Angriffen. Lösungsansätze zur Unterstützung von Usability (User Interface Patterns) werden darüber hinaus als abhängig von der jeweiligen Systemarchitektur gezeigt. Im Kontext dieser technischen Überlegungen wird die Verantwortung der Software-Hersteller wie auch der Benutzer diskutiert: Wo beginnt der bewusstseinspflichtige Teil der Sicherheit und wie kann er durch Usability unterstützt werden?
Zwei Sicherheitshemen stehen in der letzten Zeit – wie auch bei der kürzlichen Sicherheitskonferenz des BSI – stark im Blickpunkt der Medien und der Öffentlichkeit. Das erste ist der Umgang mit Malware, also Viren und Trojanern. Das zweite Thema ist die Forderung nach einer besseren Sicherheitsausbildung der Benutzer angesichts zunehmender semantischer Attacken wie Phishing oder der Verbreitung von kollaborativen Web-2.0-Techniken und Plattformen (z. B. myspace.com, mobile.de).
Wo ist hier der Zusammenhang mit Usability? Ka Ping Yee (![[externer Link]](../../../../images/link.gif)
www.zesty.ca), einer der frühen Verfechter von Usability als Voraussetzung von Security, hat einmal Malware als völlig korrekt funktionierende Software bezeichnet, die lediglich die Erwartungen des Users verletzt. Das Treffen der Erwartungen des Benutzers ist aber eines der Hauptkriterien von Usability (vgl. [1]), ausgedrückt beispielsweise im "Principle of least surprise" [2]. Somit haben Systeme, die anfällig für Malware sind, eine klare Schwäche auch in ihrer Benutzbarkeit.
Wie sieht es beim zweiten Thema aus, der Forderung nach mehr Sensibilisierung der Benutzer für Sicherheitsprobleme? Auf den ersten Blick scheint sich die Warnung vor dem Klick auf eine URL in einer E-Mail rein an den Benutzer zu richten. Tatsächlich spielen sich solche Attacken auf der semantischen Ebene ab und kompromittieren nicht das System, das ja völlig ordnungsgemäß funktioniert. Aber heißt das wirklich, dass die Verantwortung hier ganz auf den Benutzer abgeschoben werden kann? Dafür gibt es zu viele Ungereimtheiten in den Systemen: Es beginnt mit HTML, das zwischen dem Link und seinem Link-Text unterscheidet, dem Benutzer in einer E-Mail aber nur den Link-Text anzeigt, der sich völlig vom eigentlichen Ziel des Links unterscheiden kann. HMTL erlaubt dem Browser auch eigenmächtige Zugriffe, zum Beispiel auf eingebettete Bildreferenzen – nicht dass dies sofort gefährlich wäre, jedoch entspricht es nicht der Erwartungshaltung des Benutzers, wenn über diese Technik sein Nutzerverhalten protokolliert wird.
Die Frage nach der "Bewusstseinsrelevanz" von Sicherheit geht noch weiter: Wieso hilft das System dem User nicht bei der Verwaltung von Namen oder E-Mail-Adressen und den dazugehörigen Schlüsseln und warnt, wenn plötzliche Änderungen auftreten? Und wenn das Phishing eine so gefährliche und weit verbreitete Attacke darstellt – wieso greifen die Finanzinstitute nicht zu dem Mittel, das bekanntermaßen dagegen am Besten hilft: Das Signieren von Transaktionen auf Seiten des Benutzers durch eine Smartcard in Verbindung mit einem Class-4-Reader mit eigenem Display sorgt für eine sichere Verbindung zum Partner sowie für unveränderbare Transaktionen. Halten wir daher fest, dass die fehlende Bewusstseinsrelevanz von Sicherheit zwar durchaus ein Problem auf Nutzerseite darstellt, aber gerne auch als Ausrede für fehlende Hilfestellungen von Seiten der Hersteller verwendet wird.
Schwieriger noch wird das Problem der Usability im Zusammenhang mit Sicherheit bei den momentan so populären kollaborativen Seiten wie myspace.com oder auch mobile.de. Dort stoßen – im Gegensatz zu klassischen B2C-Szenarien – private Nutzer aufeinander und es entstehen mannigfaltige Möglichkeiten technischer, aber auch semantischer Attacken der Benutzer untereinander. Solche Plattformen leben davon, dass die Nutzer einander vertrauen. Wird dieses Vertrauen zu oft durch Angreifer missbraucht, sind diese Plattformen letztlich zum Tod verurteilt.
Auch hier gibt es deshalb Hersteller, die die Gefahren erkannt haben und zum Beispiel durch regelmäßig auftauchende Warnungen vor unsicheren Formen von Finanztransaktionen potenzielle Käufer von Fahrzeugen warnen, vor lauter Freude und Erwartung nicht die Sicherheit der Transaktion völlig zu vergessen. Diese Hersteller definieren die Usability ihrer Systeme in einem umfassenderen Sinne als bislang allgemein üblich, das heißt sie ziehen die konzeptionellen Modelle ihrer Kunden in ihre Bedrohungsmodelle mit ein und versuchen sie durch technische und aufklärende Maßnahmen zu schützen.
Beide Angriffstypen, Angriffe durch Malware wie semantische Attacken, nutzen zum Teil Probleme in der Kommunikation zwischen Mensch und Maschine. Aufgabe der Usability im Sinne einer sicheren Benutzung von Systemen (Sicherheit hier als Safety, also als Schutz vor Bedienfehlern verstanden) ist gerade die sinnvolle Gestaltung dieser Schnittstelle. Hier wurden durch die modernen GUI-Architekturen bemerkenswerte Fortschritte erzielt. Aber gilt das auch für den Einsatz von Usability-Architekturen zur Erhöhung der Security eines Systems (also dem Schutz des Systems vor bewussten Angriffen)? Kann Usability beide Aufgaben bewältigen? Können die gleichen Mittel angewandt werden oder brauchen wir unterschiedliche Mittel für Safety und Security?
Basis zur Unterstützung von Usability ist häufig der Gestaltungsprozess "User centered design", das heißt der Entwurf der Mensch-Computer-Schnittstelle wird vom Benutzer mitbestimmt [3]. Dies ist nicht als plattes "der User hat immer Recht" zu verstehen, denn Safety und Security eines Systems setzen voraus, dass der Benutzer durch das System geschützt wird vor Bedienungsfehlern oder auch Angriffen.
Der erste Einsatz von Usability-Techniken bezog sich auf den Safety-Aspekt von Software: Ziel war die sichere, effektive und effiziente Bedienung von Software und damit die Vermeidung von unbeabsichtigten Schäden an Daten. Daraus entstanden Entwurfsmuster (User Interface Patterns) wie "Shield", bei dem vor einer kritischen Operation, die nicht rückgängig gemacht werden kann, eine zusätzliche Warnung für den Benutzer angezeigt wird. Gut bekannt sein dürfte die Meldung "Wollen Sie wirklich die Datei xyz überschreiben?".
Lässt sich dieses Muster ohne Probleme auch auf den Security-Aspekt übertragen? Betrachten wir eine typisches Szenario aus dem Security-Bereich: Der Nutzer erhält eine Mail mit einem Excel-Sheet im Anhang. Beim Öffnen des Anhangs erhält er die Warnmeldung "Dieses Excel-File enthält Makros, die gefährlich sein können – wollen Sie sie ausführen?". Der Vergleich der beiden Fälle bringt einige interessante Dinge zutage: Im ersten Fall funktioniert "Shield" – der vorsichtige Benutzer kann seine Daten auch unter einem anderen Namen abspeichern und damit weiterarbeiten.
Im zweiten Fall funktioniert "Shield" aber nicht mehr: Der vorsichtige Benutzer führt das Excel-Sheet dann zwar vielleicht nicht aus – aber er kann dann auch nichts mit den darin enthaltenen Daten anfangen. Dem Benutzer wird also in diesem Fall keine sinnvolle Alternative angeboten. Hinzu kommt, dass im Fall der Excel-Makros eine Autorisierung verlangt wird, deren mögliche Konsequenzen eben nicht den Erwartungen der Benutzer entsprechen: Der Benutzer gibt die Autorisierung zum Laden eines Spreadsheets, nicht aber zum Korrumpieren seines Systems. Nichts anderes aber ist die Folge, wenn die bösartigen Makros mit der Autorität des Nutzers ausgeführt werden. Hier klaffen Erwartungshaltung und Systemreaktion weit auseinander – das Principle of Least Surprise wird verletzt. Die Warnmeldung "Wollen Sie die Makros tatsächlich öffnen?" lässt also dem Nutzer nur die Wahl zwischen Skylla (kein sinnvolles Arbeiten möglich) und Charybdis (mögliche Kompromittierung des Systems).
Führen wir den Vergleich der beiden Szenarien noch etwas weiter: Was wäre, wenn im Fall des Abspeicherns von Daten das System über ein automatisches, eingebautes Versionierungssystem verfügen würde? Jede Änderung ergibt dann eine neue Version und nichts geht wirklich verloren. Die Konsequenzen sind drastisch: Die Anwendung des "Shield" User Interface Pattern ist jetzt überflüssig geworden. Auch User Interface Patterns zur Förderung von Usability sind also von ihrer jeweiligen technischen Basis abhängig, genau so wie das für Patterns in der Softwareentwicklung der Fall ist.
Gibt es auch die Möglichkeit, im Fall des verdächtigen Spreadsheet ganz ohne Warnungen auszukommen? Der Idealfall wäre eine automatische, zuverlässige Sicherheitsanalyse der enthaltenen Makros durch das System. Im Fall der Bösartigkeit wird dann der Zugriff mit einer entsprechenden Meldung verweigert. Davon sind wir aber im Moment noch weit entfernt. Die Alternative lautet Schadensbegrenzung: Dazu müsste der Anhang in einer "ungefährlichen" Umgebung mit reduzierten Rechten ausgeführt werden, ähnlich der Sandbox für Java-Applets.
Im Bereich der Systemsicherheit spricht man dann von "Authority Reduction", die im Idealfall dazu führt, dass nur die wirklich benötigten Rechte (Autorität) während der Ausführung einer Aktion zur Verfügung stehen. Nur diese könnten dann auch im Falle eines Missbrauchs Schaden anrichten. Diese Reduktion verhindert, dass die Makros – sollten sie wirklich bösartig sein – alle Daten des Benutzers beziehungsweise das ganze System kompromittieren können. Es gibt bereits solche Systeme, wie Polaris ( www.combex.com), aber auch das neue Windows Vista macht mit seiner Label-basierten Autorisierung einen ersten Schritt in diese Richtung. Das Ziel muss dabei sein, Systeme zu bauen, die Schadensbegrenzung durch Reduktion von Autorität durchführen können.
Wenn die Reduktion der Autorität für jeden Aufruf des Spreadsheets gilt, dann spielt es keine Rolle, ob es ein eigenes Spreadsheet ist oder ein per E-Mail empfangenes. Die Sicherheit wird damit insgesamt einfacher zu verwalten. Sollte nun ein selbst erstelltes Programm einen wirklichen Programmierfehler enthalten, der potenziell alle Daten des Benutzers bedroht (also ein Safety-Problem auftauchen), so ist dieses Problem durch die Authority Reduction ebenfalls entschärft. An dieser Stelle taucht der Verdacht auf, dass es sich bei vielen der Sicherheitsprobleme mit Malware ohnehin in Wirklichkeit um Safety-Probleme handelt, also um eine Systemschwäche, die anschließend zusätzlich auch als Sicherheitsproblem in Erscheinung tritt. Indem die Hersteller von Software in der öffentlichen Wahrnehmung den Fokus jedoch auf den Angriffsaspekt legen, können sie die nötigen Abwehrmaßnahmen eher als bewusstseinsrelevant darstellen und somit auf den Benutzer verlagern.
Somit bleibt für den Zusammenhang zwischen Usability und Systemarchitektur festzuhalten: Es gibt kein nachträgliches Verbessern der Sicherheit durch Usability in einem System, das keine Mittel zur Schadensbegrenzung kennt. Stattdessen werden vom Nutzer hochkomplexe Sicherheitsüberlegungen erwartet (Wo kommen Code oder Daten her? Wie kann dies verifiziert werden? Sind die Quellen vertrauenswürdig?) und Anwender werden mit vielen, letztlich sinnlosen (und unfairen) Warnungen konfrontiert.
Das Ausführen potenziell gefährlicher Software in einer geschützten Umgebung kann im Sinne einer möglichst granularen Rechtevergabe zu vielen Aufforderungen an den Benutzer führen, bestimmte Rechte zu vergeben. Dieses Problem ist aus der Konfiguration von Personal Firewalls bekannt. Vor dem Versuch, diesem Problem durch den Einsatz geeigneter Abstraktionen im Zusammenspiel mit der richtigen Systemarchitektur zu begegnen, sollen jedoch noch einige Grundprinzipien der Usability für sichere Systeme zusammengefasst werden, wie sie Ka Ping Yee in [4] definiert hat. Er unterscheidet grundsätzlich nach Prinzipien, die mit der Autorisierung von Aktionen zusammenhängen, und solchen, welche die Kommunikation des Nutzers mit dem System betreffen.
Die Kommunikationsprinzipien behandeln im Wesentlichen das, was an anderer Stelle auch als "trusted path" bezeichnet wird: Ein sicherer, authentischer Kommunikationsweg zwischen dem Benutzer und einem von ihm verwendeten, vertrauenswürdigen Software-Agenten. Dazu gehört, dass der Benutzer Meldungen des Systems als authentisch erkennen und nicht durch gefälschte getäuscht werden kann. Wesentliches Element ist aber auch die notwendigerweise enge Zusammengehörigkeit zwischen Sicherheits-Policies und den jeweiligen Aufgaben des Benutzers. Heutige Systeme verletzen diese Prinzipien in mehrfacher Hinsicht: So können selbst ganze Browser-Instanzen als Trojanische Pferde wirken und Systemdialoge können von Malware täuschend echt gefälscht oder überlagert werden.
In Bezug auf die Autorisierung von Zugriffen auf Ressourcen gilt, dass diese durch den Benutzer im Rahmen seiner normalen Tätigkeit (z. B. durch Drag and Drop von Files auf Applikationen) ausgesprochen werden sollten. Die Usability-Architektur muss darüber hinaus dem Benutzer Möglichkeiten geben, seine Autorität an andere Benutzer in granularer, aber klar verständlicher Form weiterzugeben. Dies kann dadurch geschehen, dass die Designation einer Ressource (welche Ressource ist gemeint?) und die Autorität zum Zugriff darauf in Form einer so genannten Capability, also einer Referenz auf die freizugebende Ressource zusammengehalten wird. Das klassische Beispiel dazu ist ein geöffnetes File Handle, das einer Komponente übergeben wird anstatt eines bloßen File-Namens, der dann von der Komponente in eine geöffnete Ressource verwandelt werden muss. Der Benutzer muss außerdem über den Stand und die Konsequenzen solcher Delegation informiert werden.
"Why Johnny Can’t Encrypt" [5] ist der Titel eines mittlerweile klassischen Papers zur Usability von PGP. Es scheint so zu sein, dass die Konzepte, die hinter den Schlüsselkonzepten Authentizität, Autorität, Integrität und Vertraulichkeit stehen, den Benutzern zumindest durch die im Moment verwendeten Usability-Mechanismen nicht vermittelt werden können. Das ist einer der Gründe, warum auch heute immer noch die wenigsten Privatnutzer (und auch Firmen) ihre E-Mails nicht wenigstens signieren, geschweige denn verschlüsseln. Die User-Interfaces der entsprechenden Plug-Ins sind schon bei der Installation für den normalen Laien zu kompliziert. Garfinkel führt noch mehrere andere Gründe in seiner PhD-Thesis [2] an:
T. Scheidemann hat dies kürzlich ergänzt durch den Verweis auf Unterschiede in der Risiko-Wahrnehmung der Nutzer, die ebenfalls dazu führen, dass Nutzer zwar Virenschutz und Firewall installieren, sich aber über die Vertraulichkeit ihrer Daten beziehungsweise die ihrer Firmen keine Gedanken machen (s. [6]).
Interessant sind auch die Erkenntnisse, die Garfinkel im Bereich des Privacy-Schutzes der Nutzer auf gängigen Systemen gemacht hat: Hier wird massiv gegen die Erwartungen der Anwender verstoßen. Als Beispiel führt er die Operation "Löschen" an, die genauso wenig wie die Operation "Formatieren" zum erwarteten Ergebnis führt, nämlich dem tatsächlichen Verschwinden von Daten. Ergänzt werden diese Beobachtungen durch die Defizite von Browsern im Umgang mit persistenten Informationen über den Nutzer. Nachdem die meisten Browser begonnen haben, dem Benutzer wenigstens die Verwaltung von Cookies zu ermöglichen, sind bereits neue, unsichtbare Mechanismen zur persistenten Speicherung von Benutzerinformationen in Flash oder Mozillas DOM-Storage-Objekten aufgetaucht (vgl. [7]).
Neben der zentralen Voraussetzung besserer Sicherheit – der Verwendung von Schadensbegrenzung durch Reduktion von Autorität innerhalb der Software – gibt es weitere Möglichkeiten, die Security über die Usability zu verbessern:
Führen diese Maßnahmen nicht einfach nur zu einer anderen Form von GUI, nämlich einer, bei der nicht mehr dauernd gewarnt wird, sondern stattdessen dauernd nach Berechtigungen gefragt wird? Woher sollen Benutzer wissen, welche Rechte ein Programm tatsächlich benötigt? Als Beispiel möge das automatische Update von Applikationssoftware dienen: Dies ist sicherlich ein sinnvoller Mechanismus, der jedoch von den meisten Systemen mit dem Recht auf einen TCP-Kanalzugang gleichgesetzt wird. Deshalb fragen sie den Nutzer: "Wollen Sie xyz den Zugang zum Netzwerk gestatten?". Dabei sollte es doch um "Updates" gehen, nicht um unbeschränkten Netzzugang – dies sind zwei grundverschiedene Dinge. Jeder Benutzer hat ein grobes Konzept von "Update" und versteht darunter wahrscheinlich, dass die Applikation vom Hersteller mit neuen Teilen der Software ausgestattet werden soll. Die auf dieses Konzept passende Frage "Wollen Sie die Applikation updaten?" ist sehr wohl verständlich und auch vom Benutzer beantwortbar.
Das Problem liegt nun auf der Seite des Softwaresystems: Es sollte diese Erlaubnis so umsetzen, dass es der Erwartungshaltung des Benutzers, die der Erlaubnis zugrunde liegt, entspricht. Es sollte also:
Ein solches Update-Verfahren entspricht der Erwartungshaltung des Benutzers und könnte – da harmlos – von diesem durchaus auch als permanentes Recht an die Applikation delegiert werden. Dinge, die vorher ungeheuer kritisch für die Systemsicherheit und mit entsprechenden Warnungsdialogen versehen waren, sind nun wesentlich unkritischer und können dem Benutzer klar kommuniziert werden. Dieser Effekt tritt generell in Systemen auf, die eine Reduktion von Autorität betreiben, wie beispielsweise SELinux, und er hat beträchtlichen Einfluss auf die Usability dieser Systeme.
Leider sind wir im Moment in der Situation, dass wichtige Konzepte der Benutzer wie Update oder eine E-Mail-Adresse auf Seiten des Systems nicht als Konzept repräsentiert sind, sondern zum Beispiel als einfacher String (E-Mail-Adresse) oder – wie gerade diskutiert – als TCP-Verbindung (Update). Damit wird es unmöglich, eine korrekte Autorisierung von Aktionen durchzuführen. In der anderen Richtung ist leider derselbe Effekt zu beobachten: Wichtige Konzepte des Systems (die Rechte des docroot-Verzeichnisses eines Webservers oder Einstellungen in Systemdateien) entsprechen keinem Konzept auf Benutzerebene. Sie werden deshalb leicht falsch behandelt und es entstehen die bekannten Sicherheitslücken. Hier sind kreative Abstraktionen gefragt, die diese Konzepte dem Nutzer näher bringen.
Bleibt noch die Frage zu klären, wie Usability-Fortschritte im Bereich der Sicherheit geprüft werden können: Dies kann über die gleichen Methoden wie generell beim Test von Human-Computer-Interfaces geschehen: Durch die Entwicklung von Testmaterial, mit dem auf Nutzerseite das Verständnis der Begrifflichkeiten wie auch der resultierenden Workflows empirisch geprüft werden kann. So könnte zum Beispiel die sichere Benutzbarkeit von E-Banking-Software durch unabhängige Institute geprüft werden.
Die Autoren danken Prof. Michael Burmester (HDM) für Anregungen und Korrekturen.
www.din.de www.simson.net/thesis www.skyhunter.com/marcs/petnames/IntroPetNames.html
© SecuMedia-Verlags-GmbH, 55205 Ingelheim (DE),
<kes> 2007#3, Seite 33
tag:kes.info,2007:art:2007-3-033
| 