In dieser Kurseinheit soll die Grundlage für das Verständnis von Sicherheit in Web-basierten Anwendungen aufgebaut werden.

Transkript

1 In dieser Kurseinheit soll die Grundlage für das Verständnis von Sicherheit in Web-basierten Anwendungen aufgebaut werden. (1) Die Thematik wird anhand grundlegender Begriffe der Sicherheitsdomäne eingeführt. Weiterführende Themen werden an Hand eines sicherheitsorientierten Entwicklungsprozesses erläutert. (2) Die Erhebung von Sicherheitsanforderungen ist eine Grundlage, für korrekten Entwurf und Implementierung. In diesem Kapitel wird ein Verfahren zur Erhebung von Sicherheitsanforderungen vorgestellt. Zudem werden Werkzeuge zur Erhebung von Sicherheitsanforderungen auf Basis von Anwendungsfällen gezeigt. (3) Beim Entwurf einer sicheren Anwendung spielen Sicherheitsmuster eine zentrale Rolle. Sicherheitsmuster, die die Autorisation und Authentifizierung betreffen, werden eingeführt und ihr Zusammenhang erklärt. Zudem wird gezeigt, wie Sicherheitsmuster und die erhobenen Sicherheitsanforderungen und Schutzziele zusammenhängen. 1

2 Die Kurseinheit "Sicherheit" betrachtet die bisher präsentierten Kurseinheiten unter dem Aspekt der Sicherheit. Ziel der Lerneinheit soll es sein, ein Verständnis dafür zu entwickeln, wie sich der nichtfunktionale bzw. qualitätsorientierte Aspekt der Sicherheit in einem sicherheitsorientierten Entwicklungsprozess einbauen lässt, um eine möglichst weitgehend abgesicherte Web-Anwendung zu entwickeln. (5. SICHERHEIT) Eingeordnet ist die Sicherheitskurseinheit als Ergänzung zur Kurseinheit Komponenten im Bereich der Architekturen und der Entwicklung von Web-Anwendungen. Gezeigt wird, welche Sicherheitskonzepte einen Entwicklungsprozess ergänzen, so dass eine sichere Web-Anwendung entwickelt werden kann. Insbesondere wird Bezug genommen auf Sicherheitsmuster, die zur Absicherung von Komponenten eingesetzt werden können. 2

3 (1) Schon vor der automatisierten Informationsverarbeitung mittels Rechenmaschinen wurden Mittel zum Schutz von sensiblen Informationen genutzt, um diese vor Einsicht durch nicht-autorisierte Personen zu schützen. Seit dem Betrieb der ersten Mainframes, der Entwicklung des Personal Computers sowie der Entwicklung des Internets wuchsen die Herausforderungen bei der Sicherheitsgewährleistung von verarbeiteten Informationen. (2) Um Gefahren abzuwenden, werden Schutz- bzw. Sicherheitsmaßnahmen errichtet. Diese sind meist mehrschichtig, um alle Gefahren abzuwehren und einen größtmöglichen Schutz zu bieten. Während dies für beliebige Dinge der realen Welt gilt, können für Informationssysteme in Unternehmen physische, persönliche, operationelle, Kommunikations- und Netzwerksicherheit als Beispiele zu solchen Schichten gezählt werden [WM05: 8]. (3) Diese Definition umfasst die vorherigen Beispiele und betrachtet zusätzlich die Verwaltung von Informationssicherheit [WM05: 8]. (4) Die Realisierung von Informationssicherheit erweist sich nicht selten als komplexes Unterfangen, da viele Facetten berücksichtigt werden müssen. Zum einen sind vielfältige Sicherheitsmaßnahmen entstanden, deren Funktionsweise und Anwendungsbereich meist nur von Sicherheitsexperten verstanden werden. Zum anderen müssen alle Ebenen eines Informationssystems berücksichtigt werden. Dies beinhaltet neben der funktionalen Anwendungsschicht auch die darunter liegenden Ausführungsumgebungen und Netzwerke sowie die darüber liegenden Geschäftsprozesse und menschlichen Nutzen. Allerdings dürfen die Sicherheitsmaßnahmen die Benutzbarkeit der Informationssysteme nur nicht wesentlich beeinträchtigen. Auch diese Abwägung erschwert die Einführung von Sicherheitsmaßnahmen. (5) Trotz des Sicherheitsbedürfnisses kommt es häufig dazu, dass aufgrund der Komplexität der Sicherheitsdomäne, Sicherheit oft nur zweitrangig bei der Entwicklung von Informationssystemen betrachtet wird. Meist werden erst nach der erfolgreichen Umsetzung der geschäftlichen Funktionen Sicherheitsprobleme betrachtet und dann oft unzureichende Maßnahmen umgesetzt. [WM05] M. E. Whitman and H. J. Mattord: Principles of Information Security, 2nd ed. Boston: Thomson Course Technology, p. 576,

4 Der hier dargestellte Verlauf ist angelehnt an [FP07] (1-3) Sicherheit hat über die Jahre immer mehr an Relevanz zugenommen. Frühe Software-Systeme mussten nur lokal abgesichert werden, beispielsweise durch lokale Benutzer und geringfügige Absicherung der Daten unter den Benutzern. Mit der Vernetzung der Systeme stieg das Angriffsrisiko nur geringfügig, da die Anzahl der Benutzer und verbundenen Systeme sehr gering war. Erst mit der breiten Einführung von Computersystemen in Firmen und lokalen Software-Systemen auf den Mainframes der Firmen mussten neue Sicherheitslösungen entworfen werden. Daten wurden nicht mehr nur lokal gespeichert, sondern waren auch im Netzwerk für verschiedene Benutzer zugänglich. Hierfür mussten Benutzerverzeichnisse für eine Vielzahl an Benutzern entstehen. Zudem mussten Autorisations- und Zugriffskontrollkonzepte entwickelt werden, die mit den Benutzern von verschiedenen Computersystemen umgehen konnten. Allerdings waren die Benutzer noch bekannt und die Software- Systemen waren i. d. R. in einem isolierten Netzwerk verfügbar. (4) Durch die globale Vernetzung hat das Thema Sicherheit enorm an Relevanz zugenommen. Grund hierfür ist die uneingeschränkte Verfügbarkeit des Software-Systems für alle angeschlossenen Computersysteme. Somit haben auch Angreifer Zugriff auf die Systeme und können Sicherheitslücken ausnutzen. Durch die immer größer werdenden Datenmengen, die Benutzer auf Software-Systemen im Internet speichern, steigt auch das Interesse von Angreifern, auf diese Daten zuzugreifen. Da auch immer mehr sensible Daten gespeichert werden, steigt neben der Attraktivität für Angreifer, auch die Auswirkung bei unbefugtem Zugriff auf Daten. Des Weiteren verändern sich auch die Anforderungen an die Sicherheitslösungen. Um Benutzer für die eigenen Dienste zu gewinnen, müssen diese, neben der Funktionalität, auch einfach benutzbar sein. Aus diesem Grund entstehen Lösungen wie Social Logins. [FP07] Eduardo B. Fernandez and Maria M. Larrondo Petrie: Security patterns and secure systems design using UML, IARIA ICWMC/ICCGI

5 (1) Der Schutzbedarf von Informationsressourcen ist bedingt durch den mit ihnen verbundenen unternehmerischen Wert [Ec09:6f; WH05:9ff]. Dieser Schutzbedarf kann durch drei grundlegende Schutzziele verfolgt werden. Bekannt sind die drei Ziele auch als C.I.A., was für Cofidentiality, Integrity und Availability bzw. Vertraulichkeit, Integrität und Verfügbarkeit steht. (1.1) Vertraulichkeit umfasst den Schutz von Daten vor unautorisiertem Zugriff. Dieses Ziel kann beispielsweise durch Verschlüsselung erreicht werden. Authentifizierung und Autorisierung sind ebenfalls Möglichkeiten die Vertraulichkeit zu gewährleisten. (1.2) Zur Integrität zählt der Schutz vor unerlaubter Manipulation von Daten. Hierzu gehört ebenfalls die Erkennung von Manipulation, beispielsweise wenn ein Schutz nicht möglich ist. Ein weiterer Bestandteil der Integrität ist die Authentizität. Diese muss gewährleistet sein, um zu erkennen, ob eine Manipulation autorisiert ist. (1.3) Ein oft vernachlässigter Aspekt der Sicherheit ist die Verfügbarkeit. Die Sicherstellung der Datenverfügbarkeit und der Schutz vor Verlust, beispielsweise durch Redundanzen, ist das dritte wichtige Schutzziel. (2) Die grundlegenden Schutzziele können je nach Kontext der Anwendung erweitert werden. Zur Bewertung von Software-Systemen sieht der Standard [ISO25010] beispielsweise die zusätzlichen Eigenschaften Authentizität, Nachweisbarkeit und Verantwortlichkeit vor. In Deutschland kann es zudem hilfreich sein, auch Datenschutz als weiteres Ziel zu definieren. Diese Verfeinerung dient auch der Hervorhebung von wichtigen Anforderungen an die Sicherheit der Anwendung. (2.1) Diese erklären sich wie folgt (Authentizität) Feststellung der Identität einer Ressource oder eines Subjekts (Nachweisbarkeit) Das Auftreten von Aktionen und Ereignissen ist nachweisbar (Verantwortlichkeit) Rückverfolgung von Aktionen zum Verursacher (Datenschutz) Die Einhaltung der Datenschutzrichtlinien, bspw. durch Datensparsamkeit. C.I.A. Diskretion (engl. confidentiality), Integrität (engl. integrity), Verfügbarkeit (engl. availability) [Ec09] C. Eckert: IT-Sicherheit, 6th ed. München: Oldenbourg Wissenschaftsverlag, 2009, p [WM05] M. E. Whitman and H. J. Mattord: Principles of Information Security, 2nd ed. Boston: Thomson Course Technology, 2005, p [ISO25010] International Organization for Standardization: Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - System and software quality models. 5

6 Ein wichtiger Aspekt der verfolgten Schutzziele insbesondere die Vertraulichkeit und die Integrität - hat mit der Frage zu tun, WER in einem IT-System WELCHE Ressourcen WIE nutzen darf, womit sich das Identity and Access Management (IAM) beschäftigt. (1) Es ist eine Frage der Anschauung, ob alle IAM-Inhalte (z.b. Verzeichnisse und deren Provisionierung) Teil der IT-Sicherheit sind. (1.1) Die Bereitstellung dieser Sicherheitsfunktionen ist das eigentliche Ziel des IAM. (2) IAM sorgt dafür, dass die richtigen Leute aus dem richtigen Anlass Zugriff auf die richtigen Ressourcen haben und dass sie damit das Richtige tun [Du12]. (3) Grundlegend wichtig für die Aufrechterhaltung der Integrität und Vertraulichkeit ist es, dass nur berechtigte Subjekte Zugriff auf Daten haben. Das IAM setzt sich genau mit dieser Fragestellung und damit verbundenen Themen auseinander. (3.1) Der Teilbereich der Identitäten umfasst auch deren Speicherung und Bekanntmachung über verschiedene Systeme hinweg. Dies ist notwendig, um eine informierte Entscheidung über den Zugriff auf Daten durchführen zu können. (3.2) Des Weiteren ist die Autorisation und somit die Vergabe von Berechtigungen ein wichtiger Teil des IAM. Die Autorisation kann in größeren System sehr komplex werden, weshalb eine Reihe von Lösungen und Sicherheitsmustern hierfür entstanden sind. (3.3) Ein weiterer wichtiger Aspekt ist die Durchsetzung der Berechtigungen. Die Durchsetzung fußt dabei auf der Identitätsfeststellung der vergebenen Rechte und führt mit diesen Informationen eine Zugriffskontrolle durch. (4) Auf Grund der historischen Gegebenheiten kann unterschieden werden zwischen Sicherheitslösungen, die im Unternehmensumfeld (geschlossene Netzwerke, bekannte Benutzergruppen) und im Verbraucherumfeld (unbekannte Benutzer, hohes Angriffsrisiko) eingesetzt werden. IAM Identity and Access Management [Du12] Teodor Dumitrescu: Identity and Access Managment im Kontext der Cloud Trends und Möglichkeiten, ic Consult, C&M-Teamserver > Mitglieder > 3-0.Literatur > Sicherheit_IAM 6

7 (1) Um Sicherheitsmaßnahmen in einem Informationssystem zu implementieren, empfiehlt sich ein sicherheitsorientierter Entwicklungsprozess. Hierzu wird ein bestehender fachlicher Entwicklungsprozess um Aktivitäten ergänzt, so dass Sicherheitsmaßnahmen in einem methodischen Vorgehen entwickelt werden können. Ein solches Vorgehen ist jedoch meist nicht etabliert, was dazu führt, dass Sicherheitsmaßnahmen nach der Implementierung der fachlichen Funktionalität umgesetzt werden. Dieses "penetrate and patch"-vorgehen, d.h. die Sicherheitslücken relativ zufällig entdecken und durch nachträglich eingespielte Aktualisierungen schließen, ist jedoch nicht der Sicherheit einer Anwendung förderlich. Denn wie an der Abbildung zu sehen, erfordert ein nachvollziehbares und qualitätsgesichertes Vorgehen zur Entwicklung sicherer Software vielfältige Methoden undwerkzeuge in allen Entwicklungsphasen. (Anforderungsanalyse, Missbrauchsanwendungsfälle, Szenarien, ) UML-Anwendungsfälle sind ein erprobtes Mittel zur Spezifizierung von Anwendungsfällen und Szenarien, aus welchen funktionale Anforderungen abgeleitet werden. Einen ähnlichen Ansatz nutzen Missbrauchsanwendungsfälle, um die Bedrohungen für Anwendungsfälle zu spezifizieren. Aus den so dargestellten Bedrohungen bzw. Missbrauch von Anwendungsfällen werden im Anschluss Sicherheitsanforderungen abgeleitet. (Entwurf, Sicherheitsmuster, Sicherheitsarchitektur, ) In der Entwurfsphase werden zu den Anforderungen passende Sicherheitsmaßnahmen modelliert. Sicherheitsmuster helfen, aus dem bereits existierenden Sicherheitswissen erprobte Lösungen zu bekannten Sicherheitsproblemen auszuwählen. Ziel des Entwurfs ist es, sowohl die konzeptionelle Architektur der Sicherheitsfunktionalität als auch deren Feinentwurf zu spezifizieren. Sicherheitsrichtlinien spezifizieren dabei die Funktionsweise von einzelnen Sicherheitskomponenten im Detail. (Implementierung, Sicherheitsstandards, Konventionen für sicheren Quellcode,...) Die Umsetzung von Sicherheitsmaßnahmen sollte nur im Ausnahmefall durch eine Eigenimplementierung durchgeführt werden. Stattdessen sollten bestehende Sicherheitsstandards, -produkte oder -rahmenwerke eingesetzt werden, welche eine ausgereifte Implementierung von Sicherheitsmechanismen bereitstellen. Bei der Umsetzung von sicherheitsrelevantem sowie auch fachlichem Quelltext müssen Konventionen eingehalten werden, welche der Einführung von sicherheitskritischen Fehlern (engl. bugs) vorbeugen. Dieser Aspekt wird jedoch in dieser Vorlesung nicht weiter vertieft. (Tests, Penetrationstest, Statische Analyse, ) In der Testphase werden die umgesetzten Software-Artefakte auf Sicherheitslücken überprüft. Mittels Penetrationstests werden bekannte Angriffsszenarien simuliert und die Reaktion der entwickelten Software untersucht. Statische Analyse untersucht den Quelltext der Anwendung auf bekannte Fehler verursachende Quellcodekonstrukte. (Betrieb, Angriffserkennung, Systemerholung,...) Im Betrieb der entwickelten Anwendung müssen neue Angriffsmethoden erkannt und noch unbekannte Verwundbarkeiten analysiert werden. Dementsprechend muss die Sicherheitsfunktionalität der aktuellen Gefährdungslage angepasst werden. Der sicherheitsbasierte Entwicklungsprozess wird dabei erneut durchlaufen. Sollte eine Sicherheitslücke ausgenutzt worden sein, so muss das System in einen funktionsfähigen Zustand zurückgebracht werden. [Mc04] G. McGraw: Software Security, IEEE Security & Privacy, vol. 2, no. 2, pp ,

8 (1) Die drei Schutzziele sind Vertraulichkeit, der Schutz vor unbefugter Gewinnung von Information aus Daten, Integrität, der Schutz vor unautorisiertem Verändern oder Einsehen von Daten, und Verfügbarkeit, der Schutz vor Verlust oder Nicht-Erreichbarkeit von Daten. (2) Wenn für eine Anwendung bestimmte Sicherheitsaspekte hohe Priorität haben und gesondert hervorgehoben werden sollen, so können weitere Schutzziele ergänzt werden. Dies kann beispielsweise bei Online-Shops mit Kreditkartenabrechnung der Fall sein, da hier besondere Datenschutzbestimmungen gelten. (3) Das Software-System war unter Umständen nicht ausreichend vor Fremdzugriff gesichert oder die Authentifikation war zu leicht zu umgehen, was auf das Schutzziel Integrität hindeutet. Zudem hätten die Kreditkartendaten verschlüsselt abgelegt werden können, wodurch das Lesen unmöglich gewesen wäre und das Schutzziel Vertraulichkeit verbessert worden wäre. (4) Je Schutzziele beispielsweise Verschlüsselung der Daten, Zugriffskontrolle und redundante Speicherung. (5) Sicherheit wird nicht erst am Ende als Zusatz betrachtet sondern ist zentraler Bestandteil jeder Phase. (6) Penetrationstests sind umfassende Sicherheitstests, die das Gesamt-Software-System testen und nicht nur einzelne Teile. Das System wird mit den Mitteln eines Angreifers auf Schwachstellen geprüft. Nach dem klassischen Entwicklungsprozess finden Penetrationstests in der Testphase Anwendung. Bei der agilen Entwicklung können solche Tests durchgehend, beispielsweise als Integrationstests, genutzt werden. (7) Wenn Sicherheit nicht von Anfang an einbezogen wird, können unter Umständen nicht alle Sicherheitsanforderungen umgesetzt werden oder ihre Umsetzung ist aufwendig. Zudem fehlt die Gewissheit, alle Sicherheitsprobleme bedacht zu haben. Es wird sich auf die funktionalen Anforderungen konzentriert und Sicherheit erst nach deren Implementierung angegangen. Dies führt zu dem typischen "Identify and Patch"-Verhalten, das heißt, es wird nach Lücken gesucht und diese geschlossen, anstatt sich auf die Absicherung des Gesamtsystems zu konzentrieren. 8

9 (1) Bei der Entwicklung sicherer Web-Anwendungen sollte neben funktionalen Anforderungen auch ein Fokus auf die Sicherheitsanforderungen gelegt werden. (2.1) Sicherheitsanforderungen sollten eine Entwurfsentscheidung nicht vorwegnehmen. In der Anforderungserhebungsphase sind meist noch nicht alle Informationen für eine qualitative Entwurfsentscheidung vorhanden, beispielsweise können vorhandene Systeme, zu verwendende Technologien und andere Einflüsse auf die Architektur noch nicht bekannt sein, weswegen diese Entwurfsentscheidung auch erst in der Entwurfsphase getroffen werden sollte. [TJ+08] (2.2) Sicherheitsanforderungen sind Beschränkungen der funktionalen Anforderung zur Erfüllung von Sicherheitszielen (engl. "constraints on the functions [that]... operationalize one or more security goals") [HL+08]. Als Titel der Anforderung kann ein "nur von" (engl. only to) genutzt werden, um eine Einschränkung auf der funktionalen Anforderung zu definieren und somit einen Bezug zu dieser herzustellen. Diese Formulierung hilft auch bei der Vermeidung der Nennung von Sicherheitsmaßnahmen. [HM+06] (3) Zur Erhebung von Sicherheitsanforderungen wurden zahlreiche Methoden entwickelt. Einen Überblick über verschiedene Techniken bietet [TL+08]. In diesem Artikel stellen die Autoren auch einen eigenen, wie sie schreiben, praxisorientierteren Ansatz vor. Eine der bekannteren und umfassenderen Methoden ist das Security Quality Requirements Engineering (SQUARE), das ein breites Spektrum an wichtigen Aspekten abdeckt, allerdings nur ein Rahmenwerk für den Erhebungsprozess darstellt. Einen weitverbreiteter und modellgetriebener Ansatz ist CORAS, wobei ein Schwerpunkt auf die Analyse gesetzt wird und eine anschließende Formulierung von Anforderungen notwendig ist. (4) Weiterhin sind Sammlungen von Bedrohungen und möglichen Lösungen eine gute Quelle zur Erhebung von Anforderungen und auch für die Formulierung von Maßnahmen in der Entwurfsphase. Eine bekannte Quelle ist in Deutschland der IT-Grundschutz. Dieser wird vom Bundesamt für Sicherheit in der Informationstechnik verwaltet. Der IT-Grundschutz enthält allgemeine Informationen für den Schutz von Anwendungen auf verschiedenen Ebenen, vom Netzwerk bis hin zur Anwendungsebene. Das Open Web Application Security Project (OWASP) ist eine Anlaufstelle für Sicherheitsbelange von Web-Anwendungen, beispielsweise veröffentlich die OWASP die Top 10 Sicherheitslücken von Web-Anwendungen und Maßnahmen zur Absicherung. SQUARE OWASP Security Quality Requirements Engineering Open Web Application Security Project [Me06] Nancy Mead: SQUARE Process, Build Security In, [TL+08] Inger Anne Tondel, Martin Gilje Jaatun, Per Hakon Meland: Security Requirements for the Rest of Us: A Survey, Software, IEEE, Volume:25, Issue: 1. [BD+06] Mass Doldal Lund, Bjornar Solhaug, Ketil Stolen: The CORAS Model-based Method for Security Risk Analysis, SINTEF, Oslo, September [OWASP] Open Web Application Security Project. [HL+08] Charles Haley, Robin Laney, Joathan Moffett, Bashar Nuseibeh: Security Requirements Engineering: A Framework for Representation and Analysis, IEEE Transactions on Software Engineering, Volume 34, Issue 1, January

10 (1-3) Das Security Quality Requirements Engineering (SQUARE) beschreibt Schritte zur ganzheitlichen Analyse von Sicherheitsanforderungen einer Anwendung. SQUARE wurde von Nancy Mead mit dem Ziel entwickelt, einen einheitlichen Rahmen für verschiedene bestehende Werkzeuge zu bieten [Me06]. Für jeden Schritt sind die beteiligten Gruppen und die erwarteten Ergebnisse spezifiziert. (4) Das Ziel des Prozesses sind nicht nur die Sicherheitsanforderungen, die im Verlauf von SQUARE priorisiert und kategorisiert werden, sondern vor allem auch das gemeinsame Verständnis aller beteiligten Parteien. Jeder Akteur (engl. Stakeholder) erhält einen Einblick in die Sicherheitsproblematik, die Bedrohungen auf die Geschäftswerte und die Anwendung als Ganzes. (Kontext festlegen) Im ersten Abschnitt von SQUARE soll der Kontext für den weiteren Prozess festgelegt werden. Alle Beteiligten einigen sich zuerst über das Verständnis der Begrifflichkeiten. Als Nächstes werden die Schutzziele festgelegt und diesen Geschäftswerte (engl. Assets) zugewiesen. Schutzziele beschreiben einen wünschenswerten Zustand in der Zukunft, nicht wie dieser erreicht wird. Abschließend werden Artefakte entwickelt, die für die Sicherheitsanforderungserhebung wichtig sind. Hierzu gehören die zuvor genannten Szenarien und Missbrauchsanwendungsfälle. (Sicherheitsanforderungen sammeln) Nachdem der Kontext festgelegt ist, sollen die Anforderungen aus den Artefakten abgeleitet werden. Hierfür ist zuerst eine Risikoanalyse vorgesehen. Anhand der Risiken können die Anforderungen in folgenden Schritten priorisiert werden und zudem zeigen sie einen ersten Schwerpunkt auf. Im Anschluss wird eine Methode zur konkreten Anforderungserhebung ausgewählt, mit der die Anforderungen anschließend auch identifiziert werden. Die zuvor erstellten Artefakte werden als Grundlage genutzt. (Anforderungen analysieren) Die letzten Schritte dienen dazu, die Auswahl der relevanten Anforderungen zu erleichtern. Zuerst werden die Anforderungen in Kategorien eingeteilt. Zur Kategorisierung können die Anforderungen beispielsweise für die späteren Entwicklungsteams aufgeteilt werden. Eine weitere Möglichkeit ist die Einteilung gemäß Schutzzielen oder typischen Sicherheitsanforderungskategorien [Fi03]. Im Anschluss wird eine Priorisierung der Anforderungen vorgenommen. Als abschließender Schritt werden die Anforderungen auf Korrektheit, Vollständigkeit und Konsistenz überprüft. SQUARE Security Quality Requirements Engineering [Me06] Nancy Mead: SQUARE Process, Build Security In, [Fi03] Donald G. Firesmith: Engineering Security Requirements, Journal of Object Technology, vol. 2, no. 1, January-February

11 (1) Eine wesentliche Voraussetzung zur Umsetzung von Sicherheitsmaßnahmen stellt die Erhebung und Spezifikation von Schutzzielen dar. Durch die Erhebung wird der Schutzbedarf der zu entwickelnden Anwendung festgestellt. Hierdurch wird ermittelt, von welcher Art die umzusetzenden Maßnahmen sind und welchen Umfang sie einnehmen. (2) Zur Ermittlung des Schutzbedarfs kann für jeden Unternehmenswert die Frage nach der Schutzbedürftigkeit jedes Schutzziels gestellt werden. Der Grundschutz des Bundesamts für Sicherheit in der Informationstechnik schlägt hierbei eine Bewertung nach normal, hoch und sehr hoch vor. [BSI2:52]. Wie gut sollte die Vertraulichkeit geschützt werden? Welche Priorität hat die Integrität? Und wie verfügbar muss der Unternehmenswert sein? (3) Schutzziele können weiter verfeinert werden. Zur Konkretisierung der allgemeinen Schutzziele auf abstrakter Ebene, können Schutzziele weiter verfeinert werden und beispielsweise auf Teile des Unternehmenswert genauer eingegangen werden. [BSI2] Bundesamt für Sicherheit in der Informationstechnik, "IT-Gundschutz-Vorgehensweise", BSI-Standard 100-2, Version 2.0,

12 (1, 2) Eine sich an der Erhebung von Anforderungen durch Anwendungsfälle orientierende Methode zur Ermittlung von Sicherheitsanforderungen sind Missbrauchs- [SO05] und Sicherheitsanwendungsfälle [Fi03]. Während Missbrauchsanwendungsfälle zur Beschreibung von Bedrohungen dienen, werden Sicherheitsanwendungsfälle zur Beschreibung von Sicherheitsanforderungen genutzt. Diese Werkzeuge dienen lediglich der grafischen Repräsentation und bieten keine Vorgehensweise zur Erhebung der Bedrohungen und Anforderungen an. (3) Sicherheitsanforderungen werden häufig mit architekturellen Sicherheitsmaßnahmen ausgedrückt. Hierdurch werden jedoch bereits in der Analysephase Entwurfsentscheidungen getroffen, obwohl die fachliche Architektur noch nicht entworfen wurde. Stattdessen beinhalten Sicherheitsanforderungen das zu schützende Objekt und den Grund für den Schutz im Sinne der Sicherstellung eines Schutzzieles. Durch die Relation zu einer fachlichen Ressource bzw. zu einer funktionalen Anforderungen lassen sich die Sicherheitsanforderungen spezifisch genug ausdrücken, so dass im Entwurf auf geeignete Sicherheitsmaßnahmen gesetzt werden kann [TJ+08]. Ausnahmen können hier jedoch Anforderungen des Kunden an das Produkt stellen. Wünscht der Kunde explizit eine spezielle Maßnahme, so sollte diese Information dokumentiert werden. [Fi03] D. G. Firesmith: Security use cases, Journal of Object Technology, vol. 2, May [So05] G. Sindre, A. L. Opdahl: Eliciting Security Requirements with Misuse Cases, Requirements Engineering, vol. 10, no. 1, [TJ+08] I. A. Tøndel, M. G. Jaatun, P. H. Meland: Security requirements for the Rest of Us: A Survey, IEEE Software, vol. 25, no. 1,

13 (1) Nur wenn der Schutzbedarf bekannt ist, können geeignete Gegenmaßnahmen getroffen werden. Zudem ist es dann auch möglich, eine wirtschaftliche Lösung zu entwickeln. Wenn beispielsweise ein niedriger Schutzbedarf erkannt wurde, kann eine schlankere und kostengünstigere Umsetzung gewählt werden. (2) Zur Ermittlung des Schutzbedarfs kann für den Unternehmenswert gefragt werden, wie wichtig ein bestimmtes Schutzziel ist. Wie wichtig ist die Vertraulichkeit für Kreditkartendaten? Wie wichtig ist die Vertraulichkeit für die Auflistung der Standorte eines Unternehmens? (3) Je nach Anwendungsgröße und Unternehmenswert können die Schutzziele zu abstrakt und ungenau sein. Mit den abstrakten Schutzzielen kann ein Entwickler nur schwer arbeiten. Deshalb kann es sinnvoll sein, die Schutzziele zu konkretisieren und auch auf einzelne Teile des Unternehmenswerts zu beziehen. Eventuell sind einzelne Teile des Unternehmenswerts sehr schutzbedürftig im Vergleich zu anderen. Beispielsweise ist das Pseudonym einer Person weniger schützenswert als ihr Geburtsdatum. (4) Erst der Software-Architekt sollte Entwurfsentscheidungen treffen, da erst zur Entwurfszeit alle Anforderungen bekannt sind und somit erst dann eine fundierte Entscheidung getroffen werden kann. (5) "Ein Benutzer kann sich mit seinem Benutzernamen und Passwort authentifizieren". Die Anforderung schreibt so klar vor, mit welchen Daten sich ein Benutzer anmelden kann. Was ist, wenn sehr vertrauliche Daten übertragen werden und eine stärkere Authentifizierung sinnvoll wäre? Bisher hat der Architekt keinen Benutzernamen vorgesehen, wieso soll dieser nun zur Authentifizierung hinzugefügt werden? (6) Zur Unterstützung können Missbrauchs- und Sicherheitsanwendungsfälle genutzt werden, siehe vorherige Folien. 13

14 (1) Sicherheitsmuster beschreiben erprobte Lösungen zu wiederauftretenden Sicherheitsproblemen in einem spezifischen Kontext. Die Lösung besteht aus einer Menge von interagierenden abstrakten Rollen, welche in verschiedene konkrete Entwurfsstrukturen arrangiert werden können [SF+05:31]. Bei der Integration von fachlicher und sicherheitsbasierter Entwicklung ist ein Musteransatz vorteilhaft [SF+05:34]. Sicherheitsmuster sind für verschiedene Phasen des Entwicklungsprozesses verfügbar. (1.1) Muster beschreiben grundlegendes Sicherheitswissen in strukturierter und nachvollziehbarer Form. Die Bestandteile einer solchen Beschreibung entsprechen denen von Entwurfsmustern und umfassen somit unter anderem den Kontext des Problems, eine Beschreibung der Lösung und Konsequenzen durch die Verwendung des Musters. Muster werden bereits in der fachlichen Entwicklung genutzt. Sicherheitsmuster orientieren sich an der für Softwareentwickler und Architekturen gewohnten Beschreibungsform, somit ist die einheitliche Behandlung von fachlichen und Sicherheitsaspekten möglich. (1.3) Sicherheitsmuster können sowohl für die detaillierte Implementierung von Sicherheitsmaßnahmen als auch für die abstrakte logische Strukturierung eingesetzt werden. Hierdurch wird eine iterative musterbasierte Verfeinerung der Sicherheitslösung ermöglicht. (1.4) Obwohl Sicherheitsmuster Lösungen bereitstellen, sollten die zu behandelnden Probleme bzw. Sicherheitsanforderungen nicht außer acht gelassen werden. Ohne ein wohldefiniertes Sicherheitsproblem besteht die Gefahr, dass ein unzureichendes Sicherheitsmuster eingesetzt wird [SF+05:35]. DES Data Encryption Standard [SF+05] M. Schumacher, E. B. Fernandez, D. Hybertson, F. Buschmann, and P. Sommerlad: Security Patterns Integrating Security and Systems Engineering, Chichester, England: John Wiley & Sons Ltd,

15 Im Gebiet des Identitäts- und Zugriffsmanagement gibt es eine Reihe von zentralen Begriffen. Auf dieser Seite sollen die Begriffe in einem Ablauf exemplarisch erklärt werden. (Authentifizierung oder Authentisierung) Im Vergleich zur englischen Sprache bietet die deutsche ein größeres Vokabular und somit genauere Formulierungsmöglichkeiten an. Beispielsweise kann Authentication mit Authentifizierung oder Authentisierung übersetzt werden. Der englische Begriff Authentication kann im deutschen Authentifizieren ist das Zuordnen einer Identität zu einem Subjekt (engl. "Authentication is the binding of an identity to a subject" [Bi03]). Der Prozess der Authentifizierung wird durch (1.1) bis (4) beschrieben. (Autorisierung) Beschreibt den gewährten Zugriff eines Subjekts auf eine Ressource mit einer definierten Aktion ("Bob ist autorisiert seine Adresse zu ändern") [Fe13]. Schritt (1.2) zeigt die Vergabe einer Autorisation und die Schritte (6) bis (10) die Überprüfung der Autorisierung. (Zugriffskontrolle) Ein Mechanismus zur Durchsetzung der Autorisierung. [Fe13] (Referenzmonitor) Ein allgemeines Sicherheitsmuster zur Durchsetzung von Autorisierungsentscheidungen. Es beschreibt, dass Anfragen an geschützte Ressourcen abgefangen und an den Referenzmonitor weitergeleitet werden sollen. Der Referenzmonitor prüft anschließend, ob eine Autorisierung existiert und entscheidet so über den Zugriff oder das Zurückweisen der Anfrage. [SF+05] Der Ablauf zeigt beispielhaft einen Referenzmonitor in einer Web-Anwendung. Eine Anfrage wird abgefangen und die Autorisierung überprüft, bevor der Zugriff durch den Referenzmonitor gewährt oder verweigert wird. [Fe13] Eduardo B. Fernandez: Security Patterns in Practice Designing Secure Architectures using Software Patterns, Wiley, pp. 501, [Bi03] Matt Bishop: Computer Security Art and Science, Addison Wesley, pp. 309, [SF+05] M. Schumacher, E. B. Fernandez, D. Hybertson, F. Buschmann, and P. Sommerlad: Security Patterns Integrating Security and Systems Engineering, Chichester, England: John Wiley & Sons Ltd,