Security Patterns

Security Patterns weisen eine Struktur auf, die mit herkömmlichen (Design) Patterns vergleichbar sind. Die Bedeutung der Elemente im Hinblick auf den Sicherheitsaspekt wird im Folgenden kurz vorgestellt.

Kontext Der Kontext eines Security Patterns kann mit einem Beispielszenario illustriert werden. Mit Hilfe einer Aufzählung der Annahmen können Aspekte der Umgebung, in der das IT-System benutzt werden soll, beschrieben werden. Oftmals müssen IT-Systeme bestimmten Sicherheitsvorgaben entsprechen. Eine optionale Beschreibung solcher Aussagen erleichtert daher die eindeutige Bestimmung der Schutzziele.

Problem Der Kern von Sicherheitsproblemen bilden Bedrohungen, da ein IT-System grundsätzlich nur dann als sicher gelten kann, wenn Maßnahmen gegen alle bekannten Bedrohungen getroffen werden. Optional können ebenfalls Schutzziele, die ein komplementärer Begriff zu den Bedrohungen sind, formuliert werden. Nur wenn ein bestimmtes Schutzziel gilt, wird eine Bedrohung auch als Gefahr betrachtet.

Anforderungen Verschiedene Anforderungen beeinflussen unmittelbar die Lösung. Dazu gehören Sicherheitsanforderungen sowie andere Anforderungen, die durch die Forderung nach Sicherheit beeinflusst werden, wie z.B. Benutzbarkeit oder Performanz.

Lösung Entsprechend der Anforderungen werden Maßnahmen aufgeführt, die das Problem im jeweiligen Kontext lösen, d.h. die Risiken auf ein Minimum reduzieren. Dabei sollte es mindestens eine Maßnahme für jede Bedrohung bzw. jeden Angriff geben. An dieser Stelle bietet es sich auch an, Vor- und Nachteile der Anwendung eines Security Patterns zu diskutieren.

Verwandte Patterns Da Maßnahmen einerseits den Kontext ändern und andererseits zu neuen Problemen führen können, sind in diesem Fall Abhängigkeiten zu weiteren Security Patterns anzugeben. Da Patterns bewährte Sicherheitslösungen beschreiben, werden sie nicht erfunden, sondern gefunden. Sicherheitsstandards wie etwa der British Standard 7799 oder das IT-Grundschutzhandbuch sind daher wertvolle Orientierungshilfen bei der Dokumentation von Security Patterns. Weitere Ressourcen sind Informationsquellen wie z.B. einschlägige Web-Seiten und Mailing-Listen sowie relevante Artikel oder Bücher. Interne Informationsquellen sind die Mitarbeiter eines Unternehmens, die am besten wissen, - wie es schon immer gemacht worden ist - und dies auch begründen können.

Security Patterns können - im Gegensatz zu den meisten objektorientierten Design Patterns - in verschiedenen Phasen des Lebenszyklus eines IT-Systems angewendet werden. So gibt es neben Security Patterns, die Lösungen für sicherheitsrelevante Programmierprobleme beschreiben (z.B. Zugriffskontrolle auf Objektebene), auch Security Patterns, die als Lösung Konfigurationen oder Betriebskonzepte vorhandener IT-Systeme oder Anwendungen beschreiben.

Kontext Serveranwendungen verwenden Cookies, um Informationen über Klienten abzuspeichern und abzufragen. Ein Server verwendet den HTTP-Header, um ein Cookie dauerhaft bei dem Klienten zu platzieren und so Informationen wie beispielsweise eine eindeutige Benutzerkennung zu hinterlegen. Fragt der Klient eine weitere Seite von dem Server an, wird das Cookie automatisch mit der HTTP-Anfrage versendet.

Problem Zum Schutz der Benutzer wurde vereinbart, dass ein Cookie nur von dem Server gelesen werden kann, der es erzeugt hat. Weiterhin dürfen nur Informationen, die entweder vom Klient oder vom Server erzeugt worden sind, ausgetauscht werden. Diese Konventionen genügen jedoch nicht, um die Privatsphäre des Anwenders zu schützen.

Folgende Bedrohungen können identifiziert werden:

• Dienstanbieter können die Aktivitäten eines Benutzers verfolgen und somit Profile erstellen.
• Benutzerdaten von verschiedenen Anbietern können zusammengeführt werden. Dies geschieht z.B. bei weltweit operierenden Werbungsfirmen wie AdDoubleclick.
• Mit Hilfe von HTML-basierten E-Mail-Nachrichten können Cookies ohne Wissen des Benutzers personalisiert werden.

Anforderungen Folgende Anforderungen müssen berücksichtigt werden:

• Anonymität: Dienstanbietern und andere Benutzern soll es nicht möglich sein, die Identität eines Benutzers aus einer HTTP-Anfrage abzuleiten. Ein Dienst darf weiterhin nicht den richtigen Benutzernamen offen legen.
• Unverknüpfbarkeit: Ein Benutzer sollte mehrere HTTP-Anfragen stellen können, ohne dass diese miteinander in Verbindung gebracht werden.
• Benutzbarkeit: Viele Angebote sind nicht benutzbar, wenn Cookies nicht akzeptiert werden. Außerdem möchten Benutzer oft keine zusätzliche Software kaufen und installieren bzw. Änderungen in der Konfiguration vornehmen.

Lösung Die Verwendung von Cookies muss aufseiten des Benutzers eingeschränkt werden. Nahezu alle Web-Browser erlauben es, Cookies von Fall zu Fall zu aktivieren. Der Benutzer muss dann immer entscheiden, ob er einem Anbieter vertraut oder nicht. Cookies können auch periodisch gelöscht werden, so dass die Erstellung von Profilen nicht mehr möglich ist. Diese Variante wird z.B. von Programmen wie Opera oder Junkbuster unterstützt. Maximaler Schutz ergibt sich, wenn Cookies grundsätzlich deaktiviert werden.

Der Schutz der Privatsphäre ist immer mit Kompromissen verbunden. Je stärker die Verwendung von Cookies eingeschränkt wird, desto stärker wird die Benutzbarkeit eines auf Cookies basierenden WWW-Angebotes beeinträchtigt.

Security Patterns existieren nicht isoliert voneinander. Mehrere zusammenhängende Security Patterns, die gemeinsam ein größeres Problem lösen, werden auch als Security-Pattern-System bezeichnet. Die Patterns des Security-Pattern-Systems von Yoder und Barcalow, bei denen es um Sicherheit in Anwendungen geht, werden im Folgenden kurz einzeln vorgestellt.

Einzelner Zugangsweg Es ist schwierig, ein Anwendung abzusichern, die prinzipiell beliebig viele Zugangspunkte hat. Als Lösung hat sich daher die Beschränkung auf einen einzelnen Zugangsweg bewährt.

Prüfstelle Verschiedene Anwender haben unterschiedliche Sicherheitsanforderungen. Nun tritt das Problem auf, wie diese unabhängig von dem Entwurf der Anwendung realisiert werden können. Als Lösung wird die Kapselung eines entsprechenden Verfahrens, das die Sicherheitsanforderungen eines Unternehmens umsetzt, vorgeschlagen.

Rollen Die Verwaltung von Benutzern, die jeweils unterschiedliche Rechte haben, ist ab einer gewissen Menge nicht mehr handhabbar. Mit Hilfe von Rollen wird daher eine Gruppierung von Benutzern mit vergleichbaren Rechten vorgenommen.

Sitzungen Verschiedene Module einer Anwendung benötigen Zugriff auf sicherheitsrelevante Informationen, wie z.B. die Benutzeridentität. Es hat sich bewährt, solche Informationen global mit Hilfe eines Sitzungskonzeptes zu kapseln und abhängig von den Rechten eines Benutzers lokal zugreifbar zu machen.

Volle Ansicht mit Fehlermeldungen Benutzer dürfen Operationen nur dann aufrufen, wenn sie die entsprechenden Rechte besitzen. Abhängig von diesen Rechten können daher Fehlermeldungen angezeigt werden, sobald versucht wird, - illegale - Operationen aufzurufen.

Limitierte Ansicht Eine alternative Lösung ist es, dem Benutzer entsprechend seiner Rechte lediglich die Operationen anzubieten, die er durchführen darf.

Sichere Zugangsschicht Anwendungen können nur so sicher sein wie ihre Umgebung. Auf Basis von externen Sicherheitsmechanismen - etwa auf Ebene von Betriebssystem, Netzwerk oder Datenbanken - sollte daher eine sichere Zugangsschicht aufgebaut werden, um die Nachrichten von und zu der Anwendung zu schützen.

Ein Vorteil eines solchen Pattern-Systems ist beispielsweise, dass aus der Anwendung eines Patterns umgehend ersichtlich ist, welche weiteren Patterns noch berücksichtigt werden müssen. Ein anderer Vorteil ist, dass erkannt werden kann, welche Auswirkungen ein Fehler in der Implementierung eines Security Patterns haben kann.

Bei den vorangegangenen Beispielen wird dem Leser zunächst verdeutlicht, welche Probleme überhaupt auftreten können. Es wird auch gezeigt, welche Auswirkungen die unterschiedlichen Lösungsvarianten haben. Solche Security Patterns sind ein Hilfsmittel, um Sicherheitsprobleme effizient identifizieren, benennen und diskutieren zu können.

Selbst Laien sollte es so grundsätzlich möglich sein, Probleme strukturiert zu lösen sowie entsprechende Abhängigkeiten und Konsequenzen zu berücksichtigen.

Dem Thema Security Patterns wird von Forschern und Praktikern ein zunehmendes Interesse entgegengebracht. Seit dem ersten Beitrag zum Thema Security Patterns im Jahr 1997 wurden immer wieder Publikationen zu dem Thema veröffentlicht. Heute ist eine ganze Reihe von einzelnen Security Patterns und Pattern-Systemen bekannt. Dennoch bleiben einige Fragen offen, insbesondere um die Verwaltung und Anwendung von Security Patterns verbessern zu können:

• Welche weiteren Eigenschaften zeichnen ein Security Pattern aus? Wo sind die Unterschiede zu herkömmlichen Entwurfsmustern?
• Welche Attribute können zur Klassifizierung von Security Patterns herangezogen werden?
• Um die Integration einzelner Security Patterns zu einem umfangreichen Katalog zu erleichtern, muss die Diskussion über eine einheitliche Struktur fortgeführt werden.
• Es müssen viele weitere Security Patterns identifiziert und dokumentiert werden.

Wenn es einmal eine hinreichend große Menge von Security Patterns gibt, könnte sich solch ein Katalog von Problemen und bewährten Lösungen als nützliches Hilfsmittel erweisen, um die Lücke zwischen theoretischen Sicherheitskonzepten und dem Tagesgeschäft in Unternehmen zu schließen.

1. Security Patterns Community: Security Patterns Homepage.
   http://www.security-patterns.de (2002)
2. Dörner, D.: Die Logistik des Mißlinges - Stragtegisches Denken in komplexen Situa-tion. Reinbek: Rowohlt Tachenbuch Verlag 1999
3. Fernandez, E. B.: Patterns for Secure System Design. 
   http://www.cse.fau.edu/~ed/SecPatterns.pdf (2001)
4. The Open Group: Guide to Security Patterns. 
   http://www.opengroup.org/secu-rity/gsp.htm (2002)
5. Schumacher, M., Rödig, U.: Security Engineering with Patterns. 8th Conference on Pat-tern Language of Programs (PLoP), Monticello/IL, 2001
6. Yoder, J., Barcalow, J.: Architectural Patterns for Enabling Application Security. 4th Conference on Patterns Languages of Programs (PLoP), Monticello/IL, 1997

Hinweis: Die URLs entsprechen dem Stand bei der Veröffentlichung des Artikels und werden nicht aktualisiert.

Markus Schumacher
Technische Universität Darmstadt
Fachbereich Informatik (ITO)
ms@ito.tu-darmstadt.de

© 2002 Informatik Spektrum, Springer-Verlag Berlin Heidelberg