Home

Methode zur Integration von Sicherheitsanforderungen

1. Business View Gesch ftsprozess Bedrohungs und Modell modell Risikomodell Projektidee Akteure Bedrohungen Projektmission Gesch ftsprozesse Risiken Sicherheitsziel Architektur Ma nahmen Regeln berpr fungsergebnisse Dom nenmodell Glossar Bred Gesch ftsobjekte een Analysemodell Analyseklassenmodell Anwendungsfall Benutzerrechtemodell modell oz le O realisierun Benutzerrechtematrix BE Anwendungsf lle Spezialanforderungen E Anwendungsfall diagramme Analyse Packages A Legende E erweitert Anforderungserg nzung amp angeordnet werveeniics UI Prototyp hinzugef gt Abbildung 8 7 Produktartefakte der Analyse zugriffssicherer Systeme 8 6 Zusammenfassung Ziel der Analyse zugriffssicherer Systeme ist es die durchg ngige und sukzessive Entwik klung von Aspekten der Zugriffssicherheit fortzusetzen und in funktionale Anforderungen zu berf hren Hierzu werden die Struktur der Anwendung in das Klassendiagramm der Analyse verfeinert im Verhalten die Sicherheitsfunktionalit t in Szenarien integriert und die Benutzerrechte verfeinert Innerhalb der Analyse sind die Klassen aus dem Dom nenmodell der Anwendungsfallmodellie rung zur Sicherheit in das Klassendiagramm der Analyse
2. Im Folgenden betrachten wir die genaue Bedeutung der vorgestellten Schutzziele in Akti vit tsdiagrammen Vorab gehen wir noch kurz auf den Zusammenhang zwischen Aktivit ten und Methoden ein 6 2 Spezifikation der Schutzziele in Struktur und Verhalten 105 6 2 2 1 Zusammenhang zwischen Aktivit ten und Methoden Zur Festlegung der Schutzziele in Aktivit tsdiagrammen m ssen wir vorab festlegen wie Ak tivit ten eines Aktivit tsdiagramms mit Methoden zusammenh ngen Dabei gehen wir davon aus dass die im Rahmen der Gesch ftsprozessmodellierung betrachteten Aktivit tsdiagram me derart verfeinert werden k nnen dass in jeder Aktivit t genau eine Methode aufgerufen wird 9 activity m activity m activity activity m v Abbildung 6 12 Verfeinerung der Aktivit tsdiagramme zu den Gesch ftsprozessen In den derart verfeinerten Aktivit tsdiagrammen unterscheiden wir zwei verschiedene Typen von Aktivit ten 1 Der Aktivit t kann eine Datenzugriffsmethode oder ein Systemaufruf zugeordnet wer den Mithilfe der zugeordneten Methode k nnen nur Daten gelesen geschrieben oder erzeugt werden Die Aktivit t wird als unteilbare Aktion betrachtet 2 Der Aktivit t kann eine Vorgehensmethode zugeordnet werden Mit Hilfe dieser zuge ordneten Methode wird ein weiterer Ablauf festgelegt der Datenzugriffe und Vorge hensabl ufe regelt Die Aktivit t i
3. Activity Model I N Create New II Projects ProjectInfo ActivityType 1 1 Administrator 1 Adjustment Project 1 Activity Posting 1 TeamWorker 5 is of ga kind SE oO j Gell Modify Administrator User 1 Accounting Posting Project Manag r m IV sfe Actor ACActor Su ar AC ACOthers passwd Administrator TeamWorker userid ACProject Manager Abbildung 4 5 Erweiterung des Klassendiagramms um Akteurklassen Ausweise beispielsweise in der Form von Smartcards oder gar keine Zugangsdaten falls der Akteur im System anonym bleibt verwendet werden wie beispielsweise beim Akteur ACOthers der TimeTool Fallstudie Formal hat die zustandsbasierte Repr sentierungsfunktion rolerep die Funktionalit t funct rolerep AC Actor Object wobei Object die Superklasse aller Klassen ist wie beispielsweise in der Programmiersprache Java Fla97_ Die Funktion rolerep ist Teil der Akteurklasse AC Actor und kann in dieser Superklasse f r alle Akteurtypen global oder aber auch fiir spezielle Akteurtypen in den einzelnen Subklassen lokal definiert sein Gleichbedeutend kann die Funktion rolerep auch als Anfrageoperation der Funktionalit t rolerep Object verwendet werden Als Beispiele zeigen wir in Abbildung 4 6 die Spezifikation der rolerep Funktionen zu den drei Akteur Subklassen ACTeamWorker ACProjectManager und ACAdministrator der Projekt verwaltungsfalls
4. name String address String email String pswd String userid String name String address String email String pswd String userid String name String address String email String pswd String userid String 1 Accounting CIN SEC accountDate Timestamp requiredHours Real Abbildung 6 9 Kombinierte Schutzziel Stereotypen in TimeTool Geschaftsobjekten 104 Die Gesch ftsprozessmodellierung zugriffssicherer Systeme Beispiel Ein Ausschnitt der Gesch ftsobjekte der Time Tool Fallstudie ist in Abbildung 6 8 dargestellt Die Klasse Activity ist hierbei mit dem Stereotyp Verbindlichkeit annotiert da die grau hin terlegten Attribute accountDate und requiredHours verbindliche Attribute sind Jeder Zugriff auf diese beiden Attribute muss entsprechend protokolliert werden Die Abbildungen 6 6 6 7 und 6 8 zeigen Ausschnitte aus den Schutzziel Stereotypen Vertrau lichkeit Integrit t und Verbindlichkeit in den Time Tool Geschaftsobjekten Wie in Abbildung 6 4 dargestellt wurde k nnen Schutzziel Stereotypen kombiniert werden sodass nicht jedes einzelne Schutzziel in einem eigenen Diagramm modelliert werden muss Abbildung 6 9 zeigt die kombinierten Schutzzielannotationen zu den TimeTool Gesch ftsobjekten 6 2 2 Schutzziele in Abl ufen der Gesch ftsprozessmodellierung Neben den im Abschnitt 6 2 1 vorgestellten S
5. Accounting accountDate Timestamp requiredHours Real Abbildung 6 1 Dom nenmodell der Gesch ftsprozessmodellierung zur TimeTool Fallstudie 6 1 2 Aktivit ten der Gesch ftsprozessmodellierung In der Gesch ftsprozessmodellierung steht die Ermittlung der Kernprozesse und Kernkonzep te im Vordergrund Bei der Erarbeitung dieser zentralen Prozesse und Konzepte sind nach Kru00 DW98 die folgenden Aktivit ten auszuf hren Zu Beginn ist die Organisation bzw die Umgebung zu bewerten in der das zu erstellende System eingebracht werden soll Anforderungsentwickler Auftraggeber Anwender und Auf tragnehmer m ssen sich auf eine einheitliche Terminologie einigen Basierend auf der Bewertung der Organisation bzw Unternehmung ist festzulegen welche Gesch ftsabl ufe im System umgesetzt werden m ssen Anschlie end wird festgelegt wie die Systementwicklung fortgesetzt wird Im Falle einer iterativen Entwicklung sind die Inhalte der einzelnen Iterationen zu definieren In Abh ngigkeit von der geforderten Genauigkeit des Gesch ftsmodells wird das Dom nen modell entwickelt Ein Dom nenmodell enth lt die wichtigsten Typen von Objekten des zu beschreibenden Systems Die Dom nenobjekte repr sentieren die Dinge die im System existieren oder auftauchende Ereignisse vgl JBR99 Falls keine tief greifenden nderungen an den Abl ufen der Organisation bzw Unternehmung durchzuf hren sind k nnen
6. name String name String address String email String pswd String userid String Accounting Logging accountDate Timestamp requiredHours Real annotation String accountDate Timestamp requiredHours Real annotation String state UserState Abbildung 4 7 Das Klassendiagramm zur TimeTool Fallstudie das in den Kapiteln 6 bis 8 erarbeitete Klassendiagramm zur TimeTool Fallstudie als Basis f r die Navigation in der Objektstruktur dargestellt Beispiel la Als erstes Beispiel spezifizieren wir die Berechtigung dass ein Projektmitarbeiter team wor ker alle seine eigenen Buchungen Accountings lesen kann unabh ngig von dem Projekt zu dem die Buchungen geh ren Als Beispiel verwenden wir die Methode getAccountingDate als Stellvertreter f r eine Lesezugriffsmethode Vtw ACTeamWorker Va Accounting a user tw rolerep gt perm Accounting getAccountingDateltw a Der Ausdruck legt fest dass ein User Objekt welches mit dem Accounting Objekt verbunden ist die interne Repr sentation des gegebenen Projektmitarbeiters team worker sein muss Nur wenn dieser Ausdruck zu true ausgewertet wird hat der Projektmitarbeiter Zugriff auf die Methode getAccountingDate der Klasse Accounting Beispiel 1b Als zweites Beispiel betrachten wir die Berechtigung dass ein Projektleiter project manager alle Buchungen zu eigenen Pr
7. Activity ActivityType Administrator name String address String email String pswd String userid String manager mn project plannedStart Timestamp plannedEnd Timestamp realStart Timestamp realEnd Timestamp plannedHours Real state ActivityState User 1 name String name String address String email String pswd String userid String Accounting Logging accountDate Timestamp requiredHours Real annotation String accountDate Timestamp requiredHours Real annotation String state UserState Abbildung 7 2 Dom nenmodell der Anwendungsfallmodellierung e Anwendungsfalldiagramme geben den Zusammenhang zwischen Anwendungsf llen und den involvierten Akteuren sowie die Zusammenh nge zwischen Anwendungsf llen un tereinander wieder e In der Anforderungserg nzung werden nach Anforderungen beschrieben die ber die Anwendungsf lle hinaus gehen Darunter fallen gesetzliche Anforderungen und Regelungen Qualit tsattribute wie zum Beispiel Anwendbarkeit Verf gbarkeit Performance Unterst tzbarkeit Umgebungsanforderungen Betriebssysteme Kompa tibilit t oder Designanforderungen e Im UI Prototyp wird ein Prototyp der Benutzerschnittstelle erstellt Das erweiterte Dom nenmodell ist eine verfeinerte Version
8. IBSSO X SOVIOPOMIG OMAY Op SUNIITTJOpo pun ossezordsyyeyosor oyssedosue UsZUoISUIO4SAG oIp UV SUIONSTUNPUOMUY sop WWeISVIPUSSSe Y SOMI pun soyssedogue U ZUJISU JS P UV XLIEWOIUIILIOZINUIT IU UL aSseZOIdsyEYpsor Jap USYENALISY ne oypoissuniyNjsny Top pun susoyssunpusmuy sop oyyjelqQ ne oyooisyusnz Jop Sunqto1yosog aAIYYIPRId IopO o VULIOJUT uoummeugepy top uesungnadieq Jop pun uoswyeugeyy USH uesunyoipeg Jop Sunqreayosog oplisog opuese punis Hgy Iessopy OMY IOp IIPPOJN Sojoupsoesue yas y9reao y PUN swure13erpsge1arggy 9 1o 19M 19 NOLISYOISSPLISNZ Jop uoyyodsy AN SUIONSTUNPUOMUY Sop WUTEIFEIPUOSSELN 94 10 1OM 19 JOY AOYISsplIsnz Joep usyyodsy A popou 14 Z NUVI T1epouroyxrsry pun ssunyoipogq 1PpowesAjeuy popou ejssunpusomuy 1ppow SSIZOA SYFRUISINY Ppowusugwoq aulayshg IOISYIISSYLIINZ 9sAfeuy auleyskG AOISYIISSYLISNZ Zun otjppowpfeJsgunpusmuy 9W OIS G AOADYIISSYLISNZ sunaI rpopowuss zordsyjgyoso 5 SU9IS S Jo1YIssplisnz uoryeyxyizodsssuntep1ojuy TOP IPLE HLEAMNPpOIq P Joqn JYpIsieqy E efoqey 86 Ein Prozess zur Entwicklung von Anforderungsspezifikationen Geschaftsprozess i a modell Bedrohungs und m va x Risikomodell i Vv a Anwendungsfall BREUER 3 Dom nen i modell modell Benutzerrechte A P4 A modell i ow H 7 Analyse re modell Produkt A
9. Ein Angriff engl attack ist ein nicht autorisierter Zugriff bzw Zugriffsversuch auf das Sy stem Dabei werden aktive und passive Angriffe unterschieden Passive Angriffe betreffen die unautorisierte Informationsgewinnung und zielen auf den Verlust der Vertraulichkeit ab wie beispielsweise das Abh ren von Datenleitungen in vernetzten Systemen Bei aktiven Angrif fen werden unautorisierte Modifikationen an Datenobjekten ausgef hrt wie zum Beispiel das Entfernen von Paketen aus einem Datenstrom Sie richten sich gegen die Datenintegrit t oder Verf gbarkeit eines IT Systems 20 Grundlagen Passiven Angriffen kann durch die Anwendung von kryptografischen Verfahren entgegenge wirkt werden wie beispielsweisedurch die verschl sselte bertragung von Passw rtern Aktive Angriffe k nnen durch eine Beschr nkung der Benutzerrechte zur Durchf hrung von Schreibzugriffen verhindert werden Hierbei hilft der Einsatz von Sicherheitsmodellen die es erlauben von Realisierungsdetails zu abstrahieren und sich auf das Wesentliche konzentrieren hier beispielsweiseauf die Vergabe von Schreibrechten Angriffe durch Viren W rmer trojanische Pferde und mobilem Code Angriffe durch Computerviren W rmer trojanische Pferde und mobilem Code geh ren zu den Bedrohungen die in heutigen Systemen am h ufigsten auftreten Es handelt sich da bei um Programme die im Hintergrund bestimmte Funktionen ausf hren Diese Program me werden auch als Schad
10. AC Actor C T Tn perm m AC Actor My AC Actor C falls my elementare Methode A perm m mi sonst i 1 wobei die m in A perm mz m die n im Ablauf aufgerufenen Submethoden der Methode i l Mg sind 162 Die Anwendungsfallmodellierung zugriffssicherer Systeme Durch die vorgestellte Berechnungsweise wird aus den Berechtigungen zu den elementaren Methoden die Berechtigung der Methode m der Klasse C unter Betrachtung des vorgestellten Ablaufs ermittelt Sind nun in einem Anwendungsfall mehrere genauer 7 Ablaufvarianten spezifiziert so sind zu allen Ablaufvarianten und den dazugeh rigen Ablaufmethoden m die Berechtigungen permc m nach dem oben gezeigten Verfahren zu berechnen Durch die erneute logische UND Verkn pfung der ermittelten Berechtigungen der Abl ufe errechnet sich die Menge der Be rechtigungen die ein Akteur ben tigt sodass er alle Zweige der Methode m ausf hren kann wie folgt j peErMC m VAN permo m p 1 Nach diesem Berechnungsverfahren errechnen wir das Minimum der Berechtigungen die ein Akteur ben tigt um alle Ablaufvarianten eines Anwendungsfalles ausf hren zu k nnen Betrachten wir im Folgenden ein einfaches Beispiel bei dem wir von einem Objekt zur Stun denbuchung Accounting eine Kopie anlegen wollen Der Ablauf hierzu ist in Abbildung 7 111 copy accounting Precondition Project Manager is authenticated c Controller a Accounting a
11. Accounting a accountDate Timestamp requiredHours Real Team Worker name String address String email String pswd String userid String Abbildung 6 8 Schutzziel Verbindlichkeit in TimeTool Geschiaftsobjekten f r einen Lese Schreib oder Create Zugriff ist eine g ltige Zugriffsberechtigung PET MmethIDe _ C P1 Pn true andernfalls erfolgt kein Zugriff und es wird auch kein Historienelement der obigen Form ab gelegt F r alle Zugriffsmethoden die auf ein Attribut zugreifen dessen Zugriff verbindlich sein muss ndern wir die Zugriffsfunktionen dahingehend ab dass nach berechtigter Ausf hrung des Methodenzugriffs ein derartiges Historienelement geschrieben wird Wir nehmen dazu an dass es sich bei der erweiterten Methode um eine unteilbare Methode handelt Somit kann kein Fall eintreten bei dem ein verbindlicher Zugriff ohne Erzeugung eines Historienelements oder die Erzeugung eines Historienelements ohne verbindlichen Zugriff stattfindet Project _1_ 1 ProjectInformation SEC Activity I SEC plannedStart Timestamp plannedEnd Timestamp realStart Timestamp realEnd Timestamp plannedHours Real 1 1 1 Cll TeamWorker as description String name String budget Real Administrator g ProjectManager CI
12. Verfeinerung der Identifikation Identifikation Ermittlung von Modelli Modelle aus der von Sitzungen und Ausarbeitung Bedrohungen odellierung Gesch ftsprozess und Authentifi der Anwendungs Risiken und a modellierung kationen f lle Mabnahmen enutzerrechten Abbildung 7 12 Die Aktivit ten der Anwendungsfallmodellierung zugriffssicherer Systeme 166 Die Anwendungsfallmodellierung zugriffssicherer Systeme Aktivitaten Innerhalb der Anwendungsfallmodellierung zugriffssicherer Systeme sind bei der Prozessaus f hrung die folgenden Aktivit ten nach der in der L sung und in der Struktur skizzierten Vorgehensweise auszuf hren Aus Gr nden der Vollst ndigkeit wurden bei den Aktivit ten auch diejenigen aus der allgemeinen Anwendungsfallmodellierung mit aufgenommen und um rissen vgl Abschnitt 7 1 2 Zu automatisierende Prozesse festlegen In der Gesch ftsprozessmodellierung wurden die Prozesse des Unternehmens bzw der Organisation in Abl ufen modelliert Zu Beginn der Anwendungsfallmodellierung muss nun gemeinsam mit den Auftraggebern festgelegt werden welche Prozesse in dem zu ent wickelnden System umgesetzt werden Im Rahmen einer iterativen Entwicklung k nnen hier auch die Inkremente festgelegt werden Anpassung der Prozesse Bedingt durch die Festlegung der automatisierbaren Prozesse ist das Gesch ftspro zessmodell anzupassen Sowohl gesamte nicht automatisierbare Abl ufe sowie einzelne nicht umzusetzende m
13. ber einzelne oder mehrere Ent wicklungsphasen oder ber den gesamten Prozess m glich Die Erweiterung des vorgestellten Ansatzes um bergreifende Iterationsm glichkeiten ist sinnvoll und notwendig da durch die Umsetzung von Ma nahmen zur Abwehr von Bedrohungen neue Bedrohungen und Risiken geschaffen werden Diese k nnen in einer weiteren Iteration behandelt werden Beispielsweise w re es sinnvoll die Analyse und Modellierungsphase des vorgestellten Ansatzes vergleiche Abbildung 5 1 iterativ durchzuf hren Ein weiterer Nachteil des vorgestellten Prozesses ist dass der vorgestellte Prozess klassisch mit der Entwicklung des Pflichtenheftes beginnt Umwelt und Einsatzgebiet sowie die funk tionalen Anforderungen werden dabei spezifiziert Bei dieser Art der Ermittlung der Anfor derungen werden Sicherheitsaspekte im Pflichtenheft nur sehr oberfl chlich ausgedr ckt zum Beispiel dass die Sicherheit als Produktqualit t mit gut spezifiziert wird vgl Bal96 Eine fr hzeitige Spezifikation von sicherheitsrelevanten Daten und Abl ufen die zumeist bei der Ausarbeitung der funktionalen Anforderungen schon angesprochen werden findet somit nicht statt Stattdessen werden diese Informationen nur zu einem Attribut abstrahiert und m ssen anschlie end erneut erarbeitet werden Auf zu entwickelnde und ben tigte Produktartefakte geht das phasenstrukturierte Modell nur begrenzt ein Es werden das Pflichtenheft die Sicherheitsstrategie un
14. der das System f r eine Sicherheitsanalyse strukturiert Anstelle dieser Strukturierung betrachten wir vor der Bedro hungsanalyse in dem lokal behandelten strukturellen oder funktionalen Teil Schutzziele und analysieren daraus Verletzungen dieser Schutzziele d h inwiefern Verletzungen der Vertrau lichkeit Authentizit t Integrit t und oder Verbindlichkeit m glich sind Aus diesen poten ziellen Angriffsm glichkeiten erarbeiten wir Bedrohungen Risiken und Ma nahmen Nach der Erarbeitung der Ma nahmen f hren wir noch einen Schritt zur berpr fung der Ma nahmen ein wobei die gew hlten Ma nahmen den ermittelten verletzten Sicherheitszielen gegen bergestellt werden Sollte sich formal oder informal zeigen dass die gew hlten Ma nahmen das geforderte Ma an Zugriffssicherheit nicht erf llen so sind wiederholt geeignete Ma nahmen zu suchen und auf ihre Tauglichkeit zu berpr fen Abbildung 5 8 zeigt die Aktivit ten des Sicherheitsmikroprozesses Die grau hinterlegten Ak tivit ten stellen die Basisaktivit ten zur Ermittlung von Bedrohungen Risiken und Ma nah men dar Die wei hinterlegten Aktivit ten zeigen die neu eingef hrten Aktionen zur Analyse zugriffssicherer Systeme Aktivit ten Bei der Prozessausf hrung des Sicherheitsmikroprozesses sind die folgenden Aktivit ten nach der in der L sung und in der Struktur skizzierten Vorgehensweise auszuf hren e Untersuchung der Schutzziele In den verschi
15. e Prozessmuster zum Sicherheitsmikroprozess siehe Abschnitt 15 3 3 5 3 3 Prozessmuster 5 3 Sicherheitsmikroprozess Kurzbeschreibung Innerhalb der Phasen der Anforderungsspezifikation zugriffssicherer Systeme stehen wir ne ben der Erarbeitung des Verhaltens und der Struktur vor der zentralen Aufgabe die An forderungen an die Zugriffssicherheit zu erarbeiten Grunds tzlich sind dabei Bedrohungen und Risiken systematisch zu erarbeiten Ma nahmen zu entwickeln und diese zu berpr fen Da die Modellierung jedoch innerhalb der Phasen der Anforderungsspezifikation verfeinert wird und dadurch die Sicherheit auf unterschiedlichen Detaillierungsstufen zu untersuchen ist f hren wir in diesem Prozessmuster einen Sicherheitsmikroprozess ein der auf allen Ebe nen der Sicherheitsmodellierung innerhalb der Anforderungsspezifikation ausgef hrt werden kann Problem F r die schrittweise Erarbeitung von Aspekten der Zugriffssicherheit gemeinsam mit der Funk tionalit t haben wir im Prozessmuster zur Anforderungsspezifikation zugriffssicherer Systeme im Abschnitt 5 3 2leine dreiteilige Anforderungsspezifikation vorgestellt Innerhalb jedes Pro zessabschnitts der Anforderungsspezifikation ben tigen wir einen Prozess zur Erarbeitung der Anforderungen an die Zugriffssicherheit der innerhalb eines Prozessabschnitts auch mehrfach 80 Ein Prozess zur Entwicklung von Anforderungsspezifikationen ausgef hrt werden kann Eine iterative Entwicklu
16. ndert Da wir in unserem Ansatz sehr wohl Systeme beschreiben wollen die mit einer hohen Anzahl von Benutzern umgehen abstrahieren wir von einzelnen Benutzern zu stellvertretenden Rollen und betrachten im folgenden Abschnitt das hierzu geeignetere Modell der rollenbasierten Zugriffskontrolle 4 2 2 Rollenbasierte Zugriffskontrolle Die rollenbasierte Zugriffskontrolle ist ein Zugriffskontrollmodell welches aufgrund der hohen Flexibilit t bei der Beschreibung und Durchsetzung von unternehmensspezifischen Sicher heitspolitiken vor allem in kommerziellen Informationssystemen eingesetzt wird 1996 wur den rollenbasierte Zugriffsmodelle RBAC engl role based access control von Ravi Sandhu San96 eingef hrt Im RBAC Modell findet eine Abstraktion der Aufgaben von Benutzerebene auf Rollenebene statt d h Aufgaben werden an Rollen gebunden und Benutzer werden Rollen zugeordnet 34 Akteurzentriertes Modell zur Spezifikation von Benutzerrechten Gegen ber den bereits vorgestellten Zugriffsmatrixkontrollstrategien werden hier die Zugriffs rechte aufgabenbezogen vergeben d h Zugriffsrechte werden abh ngig von und zugeschnitten auf die Aufgaben vergeben die Subjekte im System durchf hren Subjekte erhalten dann ber explizit festzulegende Rollenmitgliedschaften Berechtigungen zur Ausf hrung von Aufgaben Rollen sind hier eine Weiterentwicklung des Gruppenkonzepts bei dem Mengen von Benut zern nach verschiedenen Kriterien zusammen
17. Barcelona March 29 31 volume 2984 of LNCS pages 165 179 Springer Verlag 2004 Ruth Breu Objektorientierter Softwareentwurf Integration mit UML Springer Verlag 2001 Ruth Breu An Integrated Approach to Use Case Based Development 2004 To appear Grady Booch James Rumbaugh and Ivar Jacobson The Unified Modeling Lan guage User Guide Addison Wesley Longman Inc first edition 1998 Manfred Broy Informatik Eine grundlegende Einf hrung Band 1 Program mierung und Rechnerstrukturen Springer Verlag second edition 1998 Literaturverzeichnis 201 Bro98b BS199 Bswoi CAB 94 CY91a CY91b Den91 Deu05 DGP 04a DGP 04b Dos01 DW98 DW99 Eck03 EP00 Manfred Broy Informatik Eine grundlegende Einf hrung Band 2 Systemstruk turen und Theoretische Informatik Springer Verlag second edition 1998 BSI Common Criteria for Information Technology Security Evaluation Version 2 1 Technical report Bundesamt fiir Sicherheit in der Informationstechnik August 1999 http www commoncriteria org docs index html Imran Bashir Enrico Serafini and Kevin Wall Securing Network Software Ap plications Communications of the ACM 44 2 29 30 February 2001 Derek Coleman Patrik Arnold Stephanie Bodoff Chris Dollin Helena Gilchri st Fiona Hayes and Paul Jeremaes Object Oriented Development The Fusion Method Prentice Hall 1994 Peter Coad and Edward
18. Da bei sind zur Realisierung der Sicherheitsanforderungen geeignete Protokolle auszuw hlen oder zu konstruieren Innerhalb der Sicherheitsanalyse kommt auch der Sicherheitsmikroprozess zur 197 erneuten Anwendung Werden hier neue Bedrohungen mit nicht minderem Risiko ermittelt so sind die ermittelten Ma nahmen noch innerhalb dieses Prozessabschnitts umzusetzen da die dreistufige Anforderungsanalyse mit der Phase der Sicherheitsanalyse endet Am Ende dieser Phase sind alle Benutzerrechte pr dikativ zu formalisieren Mit dem vorgestellten Prozess zur Sicherheitsanalyse und dessen Eingliederung in den Soft warelebenszyklus werden alle ermittelten Anforderungen an den Prozess erf llt Die vorge stellte Methode unterst tzt in allen Phasen der Anforderungsdefinition eine durchg ngige und sukzessive Entwicklung der Sicherheitsaspekte Sicherheitsaspekte werden innerhalb je des Prozessabschnitts ermittelt und die Modelle werden schrittweise in sich verfeinert oder in neue verfeinerte Modelle berf hrt Bei der Modellierung der funktionalen Anforderungen werden stets die Anforderungen an die Zugriffssicherheit mitbetrachtet Sicherheits und Funktionsanforderungen werden so gemein sam entwickelt Bei der Analyse des Anwendungskerns und der Abl ufe werden die Schutzziele und Benutzerrechte modelliert bei der Modellierung der Anwendungsf lle Sicherheitsanwen dungsf lle eingef gt und dabei die strukturelle Beschreibung erg nzt Das Kl
19. In den Tests muss nachgewiesen werden dass der Evaluierungsgegenstand die geforderten funktionalen Sicherheitsanforderun gen tats chlich erf llt Hierzu ist zu zeigen dass sich die Sicherheitsfunktionen des TOE gem ihrer Spezifikationen verhalten Die Evaluierungsstufe legt den Testumfang die Test tiefe sowie die Abdeckung der funktionalen Anforderungen beim Testen fest Das Benutzer und Systemverwalterhandbuch ist fertig zu stellen der Installationsvorgang ist zu beschreiben und die notwendigen Anlaufdokumente m ssen bereitgestellt werden sodass die Installation in der Abnahme und Einf hrungsphase durchgef hrt und das Abnahmeprotokoll des Systems erstellt werden kann 5 1 Existierende Vorgehensmodelle 63 Bewertung Wie auch in den beiden bereits vorgestellten Vorgehensmodellen zur Entwicklung von Sicher heitsaspekten betrachtet das CC Vorgehen die Sicherheitsaspekte durchgehend im Prozess Ab dem Beginn des CC Vorgehens in der Planungsphase bis hin zur Implementierung mit Abnahme und Einf hrung werden in allen Phasen Arbeitsschritte zur Sicherheitsmodellie rung vorgestellt sodass in keiner Phase Sicherheitsaspekte unbetrachtet bleiben Bei dieser durchg ngigen Betrachtungsweise wird die Sicherheit ebenfalls wie im phasenstrukturierten und im V Modell konformen Vorgehen sukzessive erarbeitet d h die in Phase n erarbeiteten Sicherheitsaspekte werden in der n 1 ten Phase wieder aufgegriffen und weiter verfeinert bzw zur
20. accounting SEC t gt Accounting o b f store accoun CIN ting entry SEC gt Accounting Notification SEC compare with planned time SEC EE OOTA Compare T i Request SEC select accoun PCI ting amp activity SEC i i gt Accounting a F eantas Activi lg ___________ gt Activity en compare Abbildung 6 17 Objektfluss mit Sicherheitsanforderungen 6 3 Berechtigungsmodellierung Die im Abschnitt 6 2 eingef hrte Modellierung von Schutzzielen stellt eine Vorstufe zur Mo dellierung von Benutzerrechten dar Dabei wurden Aktivit ten und Objekte gekennzeichnet die potenzielle Angriffsziele darstellen Neben der Untersuchung der tats chlichen Bedrohun 6 3 Berechtigungsmodellierung 111 gen und Risiken dieser Aktivit ten und Objekte muss f r diese Objekte und Aktivit ten festgelegt werden wer auf diese zugreifen bzw diese ausf hren darf In diesem Abschnitt betrachten wir die Modellierung von Berechtigungen auf Objekten in nerhalb der Gesch ftsprozessmodellierung F r die Modellierung von Berechtigungen wird in Abschnitt 6 3 1 vorab gekl rt welche Akteure in Form von Rollen
21. berwa chung von Projektmitarbeitern oder Mitarbeitern aus anderen Projekten f hren kann Weiterhin k nnen aus den Buchungsdaten von unbefugten Personen Statistiken ber das Projekt angefertigt werden B010 Benutzer des Systems versuchen fremde oder eigene Buchungen zu manipulieren R010 Das Risiko wird als hoch eingestuft da dadurch Kollegen aus ei genen oder fremden Projekten gesch digt werden k nnen sowie die Zeit und Budgetplanung f r Projekte indirekt manipuliert wird Projektmitarbeiter k nnten dadurch zus tzlich Stunden auf bereits berpr fte Aktivit ten zu buchen Fortsetzung auf der n chsten Seite 6 4 Der Prozess der Gesch ftsprozessmodellierung zugriffssicherer Systeme 133 Fortsetzung von Tabelle 6 1 B011 Der Projektmitarbeiter gibt eine Korrekturbuchung fiir eine Pro jektaktivit t nach der Kontrolle durch den Projektmanager ein R011 Das Risiko wird als hoch eingestuft da der Projektmitarbeiter durch diese Korrekturbuchungen zu einer Projektaktivit t zu viel geleistete Stunden verbuchen kann B012 Ein Projektmanager gibt Stundenbuchungen mit negativen Stun den ein R012 Das Risiko wird als hoch eingestuft da der Projektmanager durch negative Stundenbuchungen Budget berschreitungen vertuschen kann B013 Ein Projektmitarbeiter bestreitet dass er an einer Stundenbu chung f r die er die Lese und Schreibberechtungen innehat nderungen durchgef hrt hat R013 Das Risiko wird als hoch ein
22. die innerhalb der Anwendungs fallmodellierung zugriffssicherer Systeme einen stabilen Zustand erreichen sind die anf nglich textuell spezifizierten Benutzerrechten in Hinblick auf eine Codegenerierung Benutzerrechte pr dikativ zu spezifizieren F r diese pr dikativ spezifizierte Benutzerrechte wurde unter Be schr nkung der Allgemeinheit gezeigt wie aus Zugriffsrechten Ausf hrungsrechte berechnet werden k nnen 8 Die Analyse zugriffssicherer Systeme Im vorausgehenden Kapitel haben wir die Anwendungsfallmodellierung zugriffssicherer Syste me untersucht Dabei wurde das Verhalten in Anwendungsf llen verfeinert und das Dom nen modell angepasst Die Gesch ftsabl ufe sind vorab mit Aktivit ten zur Authentifikation er g nzt worden und in den Gesch ftsprozessen spezifizierte Aspekte der Sicherheit sind in die Anwendungsf lle bertragen worden Im Vordergrund stand die isolierte Betrachtung der Anwendungsf lle Zur Beschreibung wurde die Sprache der Anwender und Auftraggeber ver wendet und die Funktionalit t war dabei in den Anwendungsf llen vollst ndig und intuitiv zu spezifizieren vgl JBR99 Bei der Analyse sind die Systemanforderungen in eine f r die Entwickler geeignete Form zu berf hren Im Rahmen der Anwendungsfallmodellierung wurden die Systemanforderungen in Anwendungsf llen spezifiziert F r das weitere Softwaredesign sind diese Anforderungen auf Klassen und Subsysteme abzubilden Diese Transformation wird get
23. e Prozessmuster zur Analyse zugriffssicherer Systeme siehe Abschnitt Weiteres referenziertes Prozessmuster e Prozessmuster zur Anforderungsspezifikation zugriffssicherer Systeme siehe Abschnitt 9 9 2 84 Ein Prozess zur Entwicklung von Anforderungsspezifikationen 5 4 Ubersicht iiber die Produktartefakte In den vorgestellten Prozessmustern wurden bereits die Produktartefakte welche die Ein und Ausgaben zu den Prozessmustern darstellen erl utert Da unser Fokus auf der Anfor derungsspezifikation zugriffssicherer Systeme liegt geben wir im Folgenden einen berblick ber Produktartefakte der Anforderungsspezifikation und zeigen die Zusammenh nge dieser Produktartefakte Im Rahmen der Anforderungsspezifikation zugriffssicherer Systeme sind die folgenden Pro duktartefakte zu erstellen Soweit es sich um keine eigenen Modelle zur Zugriffssicherheit handelt sind diese f r eine Spezifikation von Aspekten der Zugriffssicherheit anzupassen wie detailliert in den Kapiteln 6 bis 8 gezeigt wird Dom nenmodell Die Struktur des Anwendungskerns wird in einem Klassendiagramm mo delliert Dieses Klassendiagramm wird in der Gesch ftsprozessmodellierung und in der Anwendungsfallmodellierung um Datenobjekte erg nzt Da es sich hierbei um ein klas sisches Modell handelt sind Aspekte der Zugriffssicherheit im Klassendiagramm zu erg nzen Gesch ftsprozessmodell Die im Betrieb durchgef hrten Aufgaben werden in Abl ufen d h
24. ec NER ION 25 3 2 1 Systemtiberblick 0 0 a 25 ee ee ee ee es Gee Se ee Re ee 27 3 3 Zusammenfassung 2 2m nn nn 27 4 Akteurzentriertes Modell zur Spezifikation von Benutzerrechten 29 4 1 _ Einf hrung s lt s 2 sa a ac 2 uch sa na nr aan 30 Senay phe Here She neon bs Gr de ten ape 32 4 2 1 Zugriffsmatrixmodell 0 2 0 02 00002000 32 ee ee E re 33 4 3 Der Spezifikationsrahmen P MOS 2 2 2 no nn nn 35 4 3 1 P MOS Ausdr cke 2 2 ee 36 bt oP OGL ota hee Peed Oe eka Phe 6 os 39 err ae 39 4 4 1 Die Funktion rolerep 2 2 2 2 oo nn nn 41 a ape es Geet ee 43 4 4 3 Vererbung von Benutzerberechtigungen 45 li Inhaltsverzeichnis 4 5 Spezifikation von Benutzerrechten in OCL 004 46 uy Wei Soh a a eae ees ge ee ee ee ow 47 4 7 Ausblick auf Codegenerierung 2 2 2 2 m nn nn 49 Er BE Er Er 50 4 9 Zusammenfassung 22 2 2m Hmm nn 51 53 gab ie Be eee Bo ss Ge ee a ae 53 5 1 1 Ein phasenstrukturiertes Vorgehensmodell 54 5 1 2 V Modell und ITSEC 2 2 2 2 En nn 57 aoe amp Gee a Alba here 60 ie we ees Gis ee ee eos 64 eee 67 WP Bde ee eee ee abe Gh eee ee E 67 Errr 71 PA E A aA E e NY de e ok e a ee a ae ae e aes 71 5 3 1 Prozessmuster 5 1 Integration der Anforderungsspezifikation zugriffssi 2 72 5 3 2 Prozessmuster 5 2 Anforderungsspezifikation zugriffssicherer Systeme 75 ae 79 a og a 84 De ee Go ee
25. ge zur Vermeidung von Fehlern oft mals von einer zweiten Person unterzeichnet werden bevor das Dokument die Organisation oder das Unternehmen verlassen darf Dieses so genannte 4 Augen Prinzip verlangt beispiels weise dass in einem Vorgang zwei verschiedene Instanzen einer Rolle an einem Ablauf beteiligt sind Abbildung zeigt ein Beispiel f r einen Ablauf in dem das 4 Augen Prinzip angewen det werden muss Bei dem dargestellten Szenario wird gefordert dass ein Vertrag von zwei unterschiedlichen Projektmitarbeitern unterzeichnet wird 6 3 Berechtigungsmodellierung 121 Team Worker sign contract first sign contract second Abbildung 6 27 Beispiel einer Permissions zur Instanzentrennung In der folgenden Zugriffsmatrix ist das 4 Augen Prinzip zum vorgestellten Szenario textuell spezifiziert dargestellt Im Beispiel wird f r die erste Aktivit t angenommen dass diese von jedem Projektmitarbeiter durchgef hrt werden darf Die zweite Aktivit t darf dann von jedem anderen Vertreter der Rolle ausgef hrt werden mit Ausnahme der Instanz der Rolle der ersten Aktivit t class actor TeamWorker ProjectManager PCSignContractFirst E true E PCSignContractSecond E first and second signer Er have to be different team workers Das 4 Augen Prinzip l sst sich durch das folgende Pr dikat als Permission ausdr cken Vtw ACTeamW orker Vpc PC SignContractFirst V pcg PCSignContractSecond d
26. lle als auch die der Rolle Team Worker ausf hren Im Use Case Diagram ist diese Besonderheit dadurch gekennzeichnet dass der Project Manager mit einer Vererbungs Assoziation mit dem Team Worker verbunden ist Bei der Beschreibung der Anforderungen wurden hier nur sehr offensichtliche Anwendungsf lle zur Gew hrleistung der Zugriffssicherheit mit aufgenommen wie beispielsweise der Anwen dungsfall login oder die Anwendungsf lle freeze und release project sowie activate und deacti vate activity Diese Sicherheitsanwendungsf lle sind in Abbildung 3 2 grau hinterlegt Weitere Anwendungsf lle zur Gew hrleistung der Zugriffssicherheit sind bei der Analyse der Anforde rungen aus dem globalen Sicherheitsziel hohe Sicherheit zu ermitteln In Hinblick auf eine akteurzentrierte Spezifikation der Benutzerrechte wurden die Anwendungsf lle den ausf hren den Rollen zugeteilt 3 3 Zusammenfassung F r ein Vorgehensmodell f r zugriffssichere Systeme sind spezielle Prozessabl ufe erweiterte Beschreibungstechniken Produkte zur Beschreibung der Sicherheitseigenschaften und ein Mo dell zur Spezifikation von Benutzerrechten notwendig F r eine anschauliche Erarbeitung und Einf hrung dieser Themen und deren Zusammenh nge haben wir das Anwendungsbeispiel des Projektverwaltungssystems TimeTool eingef hrt TimeTool realisiert einen Ausschnitt eines Projektmanagementtools insbesondere Teilaufga ben zum Termin und Ressourcenmanagement Das Syste
27. new project a ew projet sine D stale EEN f create rat project vig activity view own iow own acount C Pickup projet gt C Pickup projet gt a S how prejet sinisi how prejet sinisi statistics C tease poset D C tease poset D view ie project into gt ie project into gt tere jst gt tere jst gt modify database entry Catv atv gt Catv atv gt Ss estat activity estat activity Others change project data set planed time for acitivity Check required time for activity initialise project copy accounting confirm adjustment prepare monthly report Abbildung 3 2 berblick ber die Akteure und Anwendungsf lle des TimeTool Systems 3 3 Zusammenfassung 27 Neben diesen fachlichen Anforderungen wird eine gute Benutzbarkeit hohe Zuverl ssigkeit und hohe Sicherheit dem System abverlangt 3 2 2 Anwendungsf lle Die aus den im System berblick dargestellten Produktfunktionen abgeleiteten Anwendungs f lle sind in Abbildung 3 2 in einem UML Anwendungsfalldiagramm engl Use Case Dia gram dargestellt Dabei wurde eine Zuordnung der Akteure welche als Zielgruppe festgelegt wurden zu den Produktfunktionen geschaffen Die Produktanforde rungen wurden gruppiert und einer konkreten Rolle zugeordnet Eine Besonderheit stellt der Akteur Project Manager dar Da er sowohl in der Rolle des Team Workers als auch in der Rolle des Project Managers arbeiten kann kann er sowohl seine rollenspezifischen Anwendungsf
28. r Flussobjekte untersucht F r eine vollst ndige Beschreibung der Abl ufe in den Anwendungsf llen ist es jedoch notwendig die Aktivit ten der Authentifikationen und Autorisierungen zu ermitteln sowie die angewendeten Techniken zur Authentifikation zu be schreiben Abbildung gibt einen berblick ber die Aktivit ten der Anwendungsfallmodellierung zugriffssicherer Systeme Die Aktivit ten zur Modellierung der Zugriffssicherheit sind dabei grau hinterlegt Zur Modellierung von Authentifikation und Autorisierung sind in den Gesch ftsprozessen Sit zungen engl Sessions herauszuarbeiten und daraus Aktivit ten zur Pr fung der Authenti fikation und Autorisierung zu ermitteln Die anzuwendenden Authentifikationstechniken und die damit verbundenen Abl ufe sind in eigenen Sicherheitsanwendungsf llen zu beschreiben Schutzziele Bedrohungen Risiken und Ma nahmen sind f r nderungen am Dom nenmodell sowie f r Anwendungsf lle die nicht 1 1 zu einer Aktivit t zugeordnet werden k nnen neu zu bestimmen Mithilfe des Sicherheitsmikroprozesses aus Abschnitt 5 3 3 sind die Modelle einer erneuten Ermittlung zu unterziehen Die Ergebnisse des Sicherheitsmikroprozesses sind auch f r die Anpassung der Benutzerrechte heranzuziehen Insbesondere m ssen auch f r Anwen dungsf lle die nicht direkt d h nicht 1 1 aus Aktivit ten transformiert werden k nnen die Benutzerrechte spezifiziert und im Benutzerrechtemodell aktualisiert werden
29. ten des Dom nenmodells angewendet werden Einzelheiten zum Sicherheitsmikroprozess sind im Abschnitt und im Prozessmuster zum Sicherheitsmikroprozess in Abschnitt beschieben Modellierung der Ausf hrungsrechte F r alle Anwendungsf lle die nicht direkt d h 1 1 aus Aktivit ten bertragen werden konnten sind die Ausf hrungsrechte zu berpr fen oder gegebenenfalls neu zu spezi fizieren Durch die vorausgehende Ausf hrung des Sicherheitsmikroprozesses wurden in den betreffenden Anwendungsf llen bereits die Schutzziele f r potenzielle Angrif fe spezifiziert Aus diesen Schutzzielen und den ermittelten Risiken Bedrohungen und Ma nahmen sind die Ausf hrungsrechte abzuleiten Die Entwicklung der Benutzerrech te im Rahmen der Anwendungsfallmodellierung ist in Abschnitt 7 4 beschrieben Bei der Entwicklung der Anwendungsf lle wird der interne Ablauf des Anwendungsfalls spezifiziert Liegen zu den im internen Ablauf aufgerufenen Submethoden Benutzerrech te in Form von Zugriffsrechten auf Objekten oder in Form von Ausf hrungsrechten auf Systemfunktionen vor so k nnen die Ausf hrungsrechte der Anwendungsf lle berechnet werden Die Voraussetzungen f r Benutzerrechteberechnung und die eigentliche Berech nung ist in Abschnitt 17 4 2 beschrieben Innerhalb der Gesch ftsprozessmodellierung zugriffssicherer Systeme waren viele Einzel heiten der Abl ufe noch offen sodass die Ausf hrungsrechte vorab gr tenteils textuell spezi
30. ten zur Analyse zugriffssicherer Systeme in Abschnitt haben wir bereits erw hnt dass bei der Realisierung der Anwendungsf lle Vorgangs Fach und Interaktionsklassen bestimmt und die exemplarischen Abl ufe in Szenarien verfeinert werden 8 2 Realisierung der Anwendungsfalle 181 Co Accounting Logging a rd PS modify Accounting Manager 7 7 pre Team Worker pre Web Browser we is authenticated and TimeTool are X authenticated Adjustment Secure VGAdjustment Team Worker PostingUI Connection Posting Key Abbildung 8 2 Szenario zur Korrekturbuchung mit Interaktion der Objekte Bei der Spezifikation der Anwendungsf lle innerhalb der Anwendungsfallmodellierung zugriffs sicherer Systeme haben wir die Funktionalit t und Anforderungen an die Zugriffssicherheit spezifiziert Zur Umsetzung der Aspekte der Zugriffssicherheit sind folgende Erg nzung und Verfeinerung der Szenarien in Abh ngigkeit von den bereits ermittelten Schutzzielen durch zuf hren Vertraulichkeit Informationen sind durch einen eingeschr nkten Benutzerzugriff auf Daten und Vorg ngen sowie durch gesicherte bertragungen vor unerlaubt lesendem Zugriff zu sch tzen Komponenten zur sicheren Daten bertragung sind zum Analysemodell hinzuzuf gen Integrit t Informationen sind durch einen eingeschr nkten Benutzerzugriff auf Daten und Vorg ngen sowie durch gesicherte bertragungen vor unerlaubter Modifikation zu sch t ze
31. um Benutzerrechte ausdr cken zu k nnen Aus diesem Grund f hren wir einen Spezifikationsme chanismus auf der Ebene von Methoden ein Detailliert wird jede Methode m einer Klasse C mit einer Berechtigung engl Permission perm Cm verbunden welche spezifiziert unter welchen Bedingungen ein Akteur Zugang zu einem Me thodenaufruf an einem Objekt zu einer gegebenen Klasse besitzt Im Abschnitt stellen wir einen Mechanismus zur Vereinigung von Berechtigungen vor um eine grob granularere Detailebene zu unterstiitzen In dem skizzierten Rahmenwerk fehlt nun noch eine Verbindung zwischen den Akteuren und ihren internen Klassen Diese Verbindung wird in den F llen ben tigt in denen Berechtigun gen den Akteur selbst referenzieren wie in dem Beispiel bei dem ein Mitarbeiter Leseberech tigungen zu seinen eigenen Buchungen besitzt Um derartige Spezifikationen zu unterst tzen f hren wir eine Funktion rolerep ein die Akteure auf Objekte einer Klasse abbildet Diese Klasse in den meisten F llen eine User Klasse ist die interne Darstellung der Akteure Tats chlich ist diese Repr sentierungs funktion eine Abstraktion der Authentifizierungsprozedur der Implementierung Im Folgenden stellen wir die Repr sentierungsfunktion rolerep vor Abschnitt 14 4 1 gefolgt von dem formalen Mechanismus zur Spezifikation von Berechtigungen auf Methoden Ab schnitt 14 4 2 Die Vererbung von Benutzerberechtigungen ist Gegenstand des Abschnitts 4
32. 1 Prozessmuster 6 1 Gesch ftsprozessmodellierung zugriffssicherer Systeme Kurzbeschreibung Zu Beginn einer Systementwicklung sind die Daten und Abl ufe der Organisation bzw Un ternehmung zu erarbeiten F r eine durchg ngige Entwicklung der Sicherheit m ssen bereits zu diesem Zeitpunkt Aspekte der Zugriffssicherheit betrachtet werden In diesem Prozessmuster zeigen wir die fr hzeitige Modellierung von Aspekten der Zugriffs sicherheit in Struktur und Verhalten Neben der eigentlichen Modellierung von Aspekten der Zugriffssicherheit zeigen wir die Eingliederung dieser T tigkeiten in die allgemeine Gesch fts prozessmodellierung Die Aktivit ten der allgemeinen Gesch ftsprozessmodellierung umrei en wir knapp auf die Aktivit ten zur Modellierung zugriffssicherer Systeme gehen wir n her ein 124 Die Gesch ftsprozessmodellierung zugriffssicherer Systeme Problem Bei der Gesch ftsprozessmodellierung werden die Struktur und das Verhalten der Organi sation bzw Unternehmung analysiert und beschrieben in welche das zu entwickelnde Sy stem eingebettet wird Probleme der Organisation bzw Unternehmung sind herauszuarbei ten und gegebenenfalls sind Verbesserungsm glichkeiten aufzuzeigen Es ist ein gemeinsames Verst ndnis zwischen Anforderungsentwicklern Anwendern Auftragnehmern und Auftragge bern zu erarbeiten und die Systemanforderungen der Zielplattform sind zu kl ren Innerhalb der allgemeinen Gesch ftsprozessmodellierun
33. 7 8 Sektion zur Sicherheit des Anwendungsfalls Korrekturbuchung dass nderungen an Buchungen zur Beweissicherung mitprotokolliert werden m ssen Be drohung B013 Da im Anwendungsfall zur Korrekturbuchung Daten des Objekts Accounting ver ndert werden wird die Anforderung zum Logging A4 hinzugef gt Anpassung der Benutzerrechte Im Benutzerrechtemodell sind bei der Gesch ftsprozessmodellierung zugriffssicherer Syste me die Ausf hrungsrechte auf Aktivit ten festgelegt worden Da jedoch die Aktivit ten in Anwendungsf lle verfeinert wurden sind die Ausf hrungsrechte nun an die Anwendungsf lle anzupassen Da wir die Benutzerrechte in eine Benutzerrechtematrix ausgelagert haben muss diese an die Anwendungsf lle angepasst werden In Abh ngigkeit von der Zuordnung von Aktivit ten zu Anwendungsf llen sind folgende Modifikationen der Benutzerrechtematrix notwendig 1 1 Wenn eine Aktivit t genau einem Anwendungsfall zugeordnet wird muss an der Be nutzerrechtematrix keine Ver nderung durchgef hrt werden Der Anwendungsfall ber nimmt dabei den Bezeichner der Aktivit t 1 n Werden zu einer Aktivit t mehrere Anwendungsf lle eingef gt m ssen Zeilen in die Benutzerrechtematrix aufgenommen werden Die Berechtigungen k nnen dabei von der Aktivit t bernommen werden jedoch ist eine Anpassung zu pr fen m 1 Werden mehrere Aktivit ten durch einen einzigen Anwendungsfall verfeinert so sind in der Benutzerrechtematrix Z
34. A Icreatec 4 Ay createc 4 protect gt H H H I perme createc Au perme createo Au a C Opisto Omp true A T om en Opty V Permo createc A a C 0u 0u false amp createo a a 01 0 L Alle Attribute der Klasse C f r die Schreib oder Create Zugriffe existieren k nnen genau dann von den Akteuren geschrieben oder erzeugt werden wenn die zugeh rige Schreib oder Create Berechtigung fiir den Akteur erfiillt ist Die Schreib Zugriffsmethode weist dem Wert des Attributs A den Wert des Parameters o genau dann zu wenn die Schreibberechtigung auf das Attribut A in der Schreib Zugriffs methode fiir den Akteur a erfiillt ist Die Create Zugriffsmethode erzeugt ein neues Objekt vom Typ 7 des Attributs A und weist die Objekt ID des neuen Objekts dem Wert des Attributs A zu wenn die Create Berechtigung f r das Attribut A beim Ausf hren der zugeh rigen Create Zugriffsmethode f r den Akteur a erf llt ist Die Parameter o Opp der Create Zugriffsmethode werden zur Initialisierung des Objekts 7 ben tigt Ist bei der Ausf hrung einer Schreib oder Create Zugriffsmethode die Berechtigung nicht erf llt so liefert die Schreib bzw Create Zugriffsmethode das spezielle Element L Bottom als Abstraktion einer Fehlermeldung oder Exception zur ck Beispiel In Abbildung sind einige Gesch ftsobjekte der TimeTool Fallstudie mit dem Stereotyp lt Integrity gt annotier
35. A reeze I J SEC project SEC Vv A create project T SEC activities SEC administrate CIN SEC user data SEC eu Vv A release I SEC project SEC ST initialise SEC project SEC A change CI SEC project data SEC IN account CIN account Gil SEC online SEC offline SEC f prepare mon T ad ook edie ana A Monthly ____ i thly report SEC SEC Accounts m backup CI X project SEC Abbildung 7 5 Ablauf des TimeTool Systems mit Authentifikation und Sitzungen Werden innerhalb einer Sitzung mehrere Aktivit ten ausgef hrt f r die eine Authentifizierung notwendig ist kennzeichnen wir zu Beginn der ersten Aktivit t den Beginn der Authentifika tion und nach der letzten Aktivit t das Ende der Authentifikation vgl Abbildung 7 4 c In diesem Fall hat vor der Ausf hrung der Sitzung mit ihren Aktivit ten eine Authentifikation stattzufinden 7 2 Modellierung der Authentifikation 151 Der bereits erw hnte Sonderfall dass innerhalb einer Sitzung f r spezielle Aufgaben eine zus tzliche gesonderte Authentifikation erforderlich wi
36. Accounting Project Manager copy accounting a getDate getHours getAnnotation createAccounting d h a Abbildung 7 11 Funktionsablauf des TimeTool Anwendungsfalls Copy Accounting dargestellt Fiir die elementaren Methoden des Ablaufs sind folgende Zugriffsrechte fiir den Akteur Project Manager spezifiziert vgl Abschnitt 4 4 e F r die Lesezugriffe auf die Felder des zu kopierenden Buchungsobjekts ist folgendes Benutzerrecht gegeben hier am konkreten Beispiel der get AccountingDate Methode Vpm ACProjectManager Val Accounting al activity project projectmanager pm rolerep gt perm Accounting getDate pm al Die Methoden getHours und getDate besitzen dasselbe Zugriffsrecht als die Methode getDate 7 5 Der Prozess der Anwendungsfallmodellierung zugriffssicherer Systeme 163 e Fiir die createAccounting Methode wurde folgendes Benutzerrecht spezifiziert Vpm ACProjectManager Vac Activity Vu User ac project projectmanager pm rolerep gt perm Accounting create PM ac u Aus den Zugriffsrechten zu den Elementarmethoden ergibt sich folgendes Ausf hrungsrecht f r die Methode copyAccounting der Klasse Accounting Vpm ACProjectManager V al Accounting V ac Activity V u User al activity project projectmanager pm rolerep A ac project projectmanager pm rolerep gt perm Accounting copy Accounting PM al ac u Die Parameter ac und
37. David A Basin and Jiirgen Doser SecureUML A UML Based Modeling Language for Model Driven Security In Jean Marc J z quel Heinrich Hussmann and Stephen Cook editors UML 2002 The Unified Mode ling Language Model Engineering Languages Concepts and Tools 5th Inter national Conference Dresden Germany September October 2002 Proceedings volume 2460 of LNCS pages 426 441 Springer Verlag 2002 John A Miller Mei Fan Amit P Sheth and Krys J Kochut Security in Web Based Workflow Management Systems In Proceedings of the International Workshop on Research Directions in Process Technology Nancy France July 1997 John A Miller Mei Fan Shengli Wu Ismailcem B Arpinar Amit P Sheth and Krys J Kochut Security for the METEOR Workflow Management System Technical Report UGA CS LSDIS TR 99 010 University of Georgia June 1999 Alfred J Menezes Paul C van Oorschot and Scott A Vanstone Handbook of Applied Cryptography CRC Press Inc 1996 Literaturverzeichnis 205 Oak01 OHJ 99 OMG03 OW96 Par98 PB96 PBJWO3 Rat00 Rau01 RBP 91 RE99 RNO3 Roy70 RP97 Rup02 San96 Scott Oaks Java Security O Reilly amp Associates Inc second edition 2001 Bernd Oestereich Peter Hruschka Nicolai Josuttis Hartmut Kocher Hartmut Krasemann and Markus Reinhold Erfolgreich mit Objektorientierung Olden bourg Wissenschaftsverlag GmbH 1999 OMG Uni
38. Die Benutzerrechte zu den nicht automa tisierbaren Teilen sind aus der Berechtigungsmatrix zu streichen Zu den Aktivit ten der Gesch ftsprozesse sind die Anwendungsf lle festzulegen Wie in Abschnitt beschrieben ist dabei eine n m Zuordnung m glich In den F llen einer 1 1 oder 1 n Zuordnung k nnen die Benutzerrechte einer Aktivit t auf den einen Anwendungsfall oder die n Anwendungsf lle bernommen werden Die Benutzerrechte m ssen insbesondere bei der m 1 Zuordnung an gepasst werden Werden mehrere Aktivit ten mit verschiedenen Benutzerrechten auf einen einzelnen Anwendungsfall bertragen so sind die Benutzerrechte zu diesem Anwendungsfall erneut zu spezifizieren Die Benutzerrechte sind auch an die Akteure anzupassen Werden bei der Festlegung der An wendungsf lle die Akteure des Systems ver ndert d h neu geordnet oder Akteure werden hinzugef gt oder entfernt so ist die Benutzerrechtematrix anzupassen F r neue Akteure sind eigene Spalten einzuf gen und die Benutzerrechte sind f r die Dom nenobjekte und Anwen dungsf lle zu spezifizieren Die Hinzunahme oder Wegnahme von Akteuren sowie die nde rung der Akteurhierarchie kann auch weitreichende nderungen auf die bereits spezifizierten Benutzerrechte haben da diese an die neue Menge und Hierarchie anzupassen sind Unabh ngig von nderungen an der Klassenstruktur an Abl ufen und an den Akteuren sind die Benutzerrechte im Rahmen der Anwendungsfallmodellierung zugriff
39. Erarbeitung der Funktionalit t herangezogen So flie en zum Beispiel die Sicherheits vorgaben aus der Analysephase in die CC Spezifikation und in die Testvorbereitung w hrend der Designphase mit ein und die CC Entw rfe folgen der Ausarbeitung der CC Spezifikation Die Entwicklung der Sicherheitsaspekte ist in die funktionale Entwicklung integriert sodass gegenseitige Einwirkungen betrachtet werden Die Ergebnisse der funktionalen Betrachtung flie en in die Sicherheitsanalyse ein und umgekehrt Beispielsweise flie en Informationen der Komponentenspezifikation in die CC Spezifikation mit ein Die CC Spezifikation bezieht sich auch auf die ausgearbeiteten Komponenten sodass zum Beispiel erkannt werden kann dass f r eine Teilkomponente Abrechnung eines Warenwirtschaftssystems besondere Bedrohungen zu betrachten sind Sicherheitsaspekte werden jedoch im CC Vorgehen immer als Ganzes betrachtet Im Rahmen der Bearbeitung der Sicherheitsvorgaben sowie bei der CC Spezifikation und Evaluierung wird immer die Gesamtheit aller Sicherheitsaspekte betrachtet Eine Modellierung eines Aus schnitts der Sicherheit mit anschlie ender Integration in das Gesamtsystem die den Vorteil der berschaubarkeit und der fr hzeitigen Reaktionsm glichkeit mit sich bringen w rde fin det in der vorgestellten Vorgehensweise nicht statt In diesem Vorgehensmodell sind neben den Prozessaktivit ten auch Produktartefakte angege ben die w hrend des Sicherheitsprozess
40. Erstellung der Sicherheitsvorgaben engl Security Target ST sowie die Anf nge der Testvorbereitung In den Sicherheitsvorgaben sind die Bedrohungen Annahmen und Si cherheitspolitiken des TOE auszuw hlen Sicherheitszeile und Sicherheitsfunktionen zu for mulieren und die funktionalen Sicherheitsanforderungen zu selektieren Zudem muss bereits in dieser Phase eine vorl ufige Version des Benutzerhandbuchs und des Systemverwalterhand buchs erstellt werden in denen die bereits bekannten Anforderungen zum TOE beschrieben und sp ter in der Designphase erg nzt werden Da Testabl ufe teilweise schon w hrend der Analyse bekannt sind insbesondere die Testabl ufe aus der Sicht des Benutzers werden diese bereits in dieser fr hen Phase in den Testvorbereitungen involviert In der Designphase werden neben der Systemspezifikation f r die Komponenten eine CC Spezifikation und ein CC Entwurf gefordert Ausgehend von den Sicherheitsvorgaben wer den die Sicherheitsfunktionen auf den Ebenen des Grob und Feinentwurfs spezifiziert und Entw rfe erstellt Wie fein granular die Spezifikationen und Entw rfe auszuf hren sind h ngt von der gew hlten Evaluierungsstufe ab die zu Projektbeginn festgesetzt werden muss Eben so sind in der Designphase auch das Benutzer und Systemverwalterhandbuch fortzuschreiben Neben der eigentlichen Implementierung werden in der Implementierungsphase Tests aus gef hrt sowie Installations und Anlaufdokumente erstellt
41. Kontexten erwei tert Im Projekt SECTINO an der Universit t Innsbruck findet der akteurzentrierte Ansatz Anwendung bei der Spezifikation von Workflows zwischen Unternehmen Die Workflows ba sieren dabei auf Web Services Ferner werden Rechte in kombinierten Systemen getestet und analysiert Um den Gewinn der vorgestellten Methode quantifizieren zu k nnen sind Untersuchungen durchzuf hren aus denen die Kostenersparnis der vorgestellten Methode ermittelt werden kann Die Untersuchungen k nnen sowohl an Fallstudien sowie an realen Projekten durch gef hrt werden Die vorgestellte Methode zur Integration von Sicherheitsanforderungen in die Entwicklung zugriffssicherer Systeme wurde im Rahmen des Projekts MEwaDis auf die dienstbasierte Ent wicklung angewendet IDGP 04a Anstelle der Gesch ftsprozesse werden dabei die Dienste mit ihren in Beziehung stehenden Diensten in einer so genannten logischen Ser vicearchitektur dargestellt Da kein globales Datenmodell zur Verf gung steht entf llt die 198 Zusammenfassung und Ausblick Modellierung der Schutzziele am Anwendungskern Bei der Beschreibung der Dienste wird dabei die erweiterte strukturelle Anwendungsfallbeschreibung und die Erstellung von Dienst szenarien verwendet In wird die Verfeinerung der Beziehungen zwischen Diensten untereinander bei der Anforderungsanalyse untersucht In diesem Zusammenhang ist in Zu kunft die durchg ngige und sukzessive Entwicklung von Aspekten der Zugri
42. Nachteile der matrixbasierten Zugriffskontrolle aus dem vor ausgehenden Abschnitt vermeiden da sich die Berechtigungsprofile von Rollen nur selten ndern Auf diese Weise lassen sich Probleme der mangelnden Skalierbarkeit stark reduzie ren RBAC Modelle eignen sich gut f r einen Einsatz in verteilten Systemen Rollen hierarchie Akteur zuordnung Berechtigungs zuordnung CE CD Berechtigungen Akteursitzung Rollensitzung Abbildung 4 2 Schema der rollenbasierten Zugriffskontrolle Die zu vergebenden Zugriffsrechte k nnen mit diesem Modell objektspezifisch oder universell modelliert werden Es werden a priori keine Festlegungen hinsichtlich der Menge der zu ver gebenden Zugriffsrechte getroffen Das Modell erm glicht eine Vergabe der Rechte gem des need to know Prinzips vgl Abschnitt 2 2 3 zu den Sicherheitsprinzipien und unterst tzt eine systematische Aufgabenteilung Die eingef hrte Modellierung einer Rollenhierarchie erlaubt es unmittelbar existierende Organisations und Verwaltungsstrukturen von Unternehmen ab zubilden so dass in diesem Umfeld RBAC Modelle sehr gut bei der Softwareentwicklung eingesetzt werden k nnen Abbildung 4 2 gibt nochmals die Zusammenh nge der eingef hrten Modellierungskonzepte wieder 4 3 Der Spezifikationsrahmen P MOS Als Spezifikationsrahmen verwenden wir die Spezifikationssprache P MOS BreO1 P MOS ist eine Sprache von Ausdr cken und Pr dikaten erster
43. Ordnung vgl RP97 zum Navigieren ber Objekten Zust nden und Objektbez gen Die Ausdr cke und Pr dikate in P MOS beziehen sich auf ein gegebenes Klassendiagramm und sind rein sta tisch Insbesondere liefern Ausdr cke in P MOS einen Wert zur ck sind aber nicht verhal tens ndernd Ausdr cke und Pr dikate beziehen sich auf den Zustand einer implizit gegebenen 36 Akteurzentriertes Modell zur Spezifikation von Benutzerrechten Menge von Objekten zu einem festen Zeitpunkt In P MOS sind die Ausdr cke und Pr dika te getypt Die m glichen Typen st tzen sich dabei auf ein gegebenes Typdefinitionsschema einer funktionalen und algebraischen Sprache ab Komplexe Typausdr cke k nnen sowohl gegebene Grunddatentypen als auch Klassen enthalten Die syntaktischen Grundkonstrukte der Sprache P MOS werden nachfolgend beschrieben Betrachtet man das Verh ltnis der pr dikativen Sprache P MOS und der UML eigenen Spra che OCL Object Constraint Language WK99 so erkennt man dass die beiden Sprachen in ihrem Kern syntaktisch als auch konzeptionell gleich sind vor allem was die Navigation ber Attribute und Assoziationen betrifft vergleiche Bre01 P MOS orientiert sich an algebraischen Ans tzen und deckt mit wenigen Konzepten die volle Ausdrucksst rke der Pr dikatenlogik erster Stufe ab Die OCL orientiert sich mit ihren Konstrukten mehr an Ausf hrbarkeit und Datenbank hnlichem Navigieren in Objektstrukturen Im Gegensatz da zu en
44. Projektmission und Sicherheitsziel 74 Ein Prozess zur Entwicklung von Anforderungsspezifikationen Mit Sicherheitsaspekten erweiterte Dokumente der Anforderungsspezifikation zugriffssi cherer Systeme Dom nenmodell Gesch ftsprozessmodell Anwendungsfallmodell Ana lysemodell Bedrohungs und Risikomodell Benutzerrechtemodell Designdokument mit Nachweis von Sicherheitseigenschaften und Architekturdokument mit sicherheitsspezifischen Komponenten und Packages Implementierungsdokumente mit Implementierung der Subsysteme und der Komponen ten e Dokumentation des Testens mit Testplan Testmodell Testergebnissen Fehlern Test Packages und Klassen Kontext Zur Ausf hrung des vorgestellten Lebenszyklus sind zus tzlich weitere Managementaufgaben auszuf hren da diese im Lebenszyklusmodell nicht betrachtet wurden So sind zum Beispiel Ressourcen und Budgetplanung sowie das Ausarbeiten der Vertr ge kein Bestandteil des vorgestellten Prozesses Struktur In der L sung wurde bereits der Ablauf des Lebenszyklusprozesses angegeben Abbildung 5 5 zeigt eine detaillierte Betrachtung dieses Ablaufs indem es die Standardphasen und die Kernarbeitsschritte des Prozessmusters darstellt Zudem sind auch m gliche Iterationen an gegeben In der Phase der Sicherheitsanalyse sind Iterationen m glich und notwendig wie dies in den Prozessmustern zur Anforderungsspezifikation zugriffssicherer Systeme und zum Sicher heitsmikroprozess gezeigt
45. SW Integration SW Grobentwurf entwerfen externe Schnittstellen spezifizieren entwerfen SES SW Komponente Betriebsmittel und SW Feinentwurf SW Modul Datenbank Zeitbedarf analysieren beschreiben SE6 Selbstpr fung des SW SW Implementierung Moduls der Datenbank durchf hren SE8 Selbstpriifung des Produkt bereitstellen Systemintegration Systems durchfiihren PM1 Projektkriterien und Projektspezifisches Toolset Management Grobplan erstellen Schulung und Projektonitialisierung Entwicklungsstrategie V Modell erstellen durchf hren Einarbeitung festlegen QS1 KM1 QS Initialisierung KM Planung QS2 Pr fungsmethoden und KM2 Pr fungsvorbereitung kriterien festlegen Produkt und Konfi gurationsverwaltung QS3 Produkt inhaltlich KM3 nderung abschlie en Produktpr fung pr fen Anderung management Abbildung 5 2 Aktivit ten bei Anwendung des V Modells und der ITSEC hinterlegten besch ftigen sich mit weiteren Aufgaben die in Zusammenhang mit der Evalu ierung Qualit tssicherung Konfigurationsmanagement oder mit dem Projektmanagement stehen Bewertung Die Sicherheitseigenschaften werden in SEC durchgehend ber die gesamte Systementwicklung und Evaluation betrachtet In allen aufgezeigten Entwicklungsphasen von der Anforderungs analyse bis hin zur Systemintegration werden Sicherheitsaspekte erarbeitet und eingearbeitet Beginnend von einer Bedrohungs und Risikoanalyse wird ein Sicherheitskonzept entw
46. Schutzziele lt Confidentiality gt und lt NonRepudiation gt annotiert F r die Festlegung der Schutzziele einer Aktivit t sind somit immer die Datenzugriffe und Systemaufrufe innerhalb des verfeinerten Ablaufs ausschlaggebend Enth lt der verfeinerte Ablauf eine Aktivit t mit zugeordneter Vorgehensmethode so werden die Schutzziele wiede rum durch die Verfeinerung der Vorgehensmethode ermittelt Diese Verfeinerung wird so lange fortgesetzt bis der verfeinerte Ablauf nur noch aus Datenzugriffen und Systemaufrufen be steht Anschlie end kann das Schutzziel der bergeordneten Aktivit t berechnet und rekursiv zur ckgesetzt werden Die Schutzziele einer Aktivit t errechnen sich somit aus der transitiven H lle der Datenzugriffe in den zugeordneten Methoden der Teilaktivit ten Auf die Bildung der transitiven H lle gehen wir in Zusammenhang mit der Ermittlung von Benutzerrechten in Abschnitt 7 4 2 n her ein Sind in den Abl ufen Verzweigungen in Form von Bedingungen oder parallelen Abl ufen enthalten so werden f r die Ermittlung der Schutzziele stets alle Wege herangezogen Nach dem derartigen Verfahren k nnen die Schutzziele zu Aktivit ten genau dann berech net werden wenn die Teilabl ufe festgelegt und die Schutzziele zu den Datenobjekten und Systemfunktionen festgelegt sind Diese strikte Berechnung kann jedoch bei der Analyse von Abl ufen von zugriffssicheren Systemen nicht immer angewendet werden denn durch eine Kombinat
47. Systems integriert werden Der im Rahmen dieser Arbeit vorgestellte Ansatz zur Verfeinerung der Zugriffssicherheit ba siert auf der m glichen Aufteilung der Anforderungen an die Zugriffssicherheit in die Schutz ziele Vertraulichkeit Integrit t Verbindlichkeit Authentifikation und Verf gbarkeit Da diese Aufteilung als erster Schritt zur Verfeinerung durchzuf hren ist kann der vorge stellte Ansatz nicht auf andere nichtfunktionale Anforderungen wie zum Beispiel Effizienz nderbarkeit oder bertragbarkeit bertragen werden Diese weiteren nichtfunktionalen An forderungen lassen sich nicht in die gegebenen Unteranforderungen aufteilen Mit den Vorgehensprozessen eng verbunden sind Produktartefakte welche die Ein und Aus gaben zu einzelnen Prozessschritten darstellen Neben der Prozessanalyse stehen die Pro duktartefakte zur Spezifikation der Anforderungen an die Zugriffssicherheit ebenfalls im Vor dergrund unserer Betrachtungen Hierzu sind bestehende Produktartefakte aus der objekt orientierten Softwareentwicklung zu erweitern und zus tzliche Produktartefakte zu integrie ren Zur Dokumentation ben tigen wir geeignete Beschreibungstechniken die es uns erlauben Aspekte der Zugriffssicherheit in bestehenden Diagrammen zu annotieren und in eigenen Pro duktartefakten zu beschreiben Da die Unified Modeling Language UML die objektorientierten Softwareentwicklungsmethoden durchdrungen hat und unser Vorgehen auf objektorientierte Vo
48. TaetigkeitenListe x wahlfenster nun g a Mitarbeiter Schlie en TimeTool BEENDEN Mitarbeiter bersicht Gesamtstunden Buchregal wunusi 31 5 2003 Projekt Archiv SWE4 sildot 8 1 2004 Produktionsliste maihal 1 31 2008 Peacemaker stidi 9 9 2009 CDSammlung savgal 12 31 2020 neues Projekt TimeTool Projekt buchen Abbruch TimeTool Projekt TimeTool Tatigkeiten Imnlementieren Datumangeben 30 E N 2003 z Buchen Stunden 4 a T tigkeiten alle al neu Buchung ndern Mitarbeiter alle aufT tigkeiten Basis bis 31 12 2009 Buchungs ID LoginManager O files built Build took 0 seconds Abbildung 3 1 Das Projektverwaltungssystem TimeTool 3 2 Systembeschreibung und Anwendungsf lle 25 3 2 Systembeschreibung und Anwendungsf lle Projektmanagementwerkzeuge unterstiitzen das Wissen und die Erfahrung bei der Planung und Steuerung von Projekten und steigern somit die Effizienz der Projektarbeit Sie un terst tzen eine Projektabwicklung in Bezug auf Termin Ressourcen Kosten Konfigura tions Risiko Dokumentations und Informationsmanagement Aus dieser Vielzahl von Leistungen die in einem Projektmanagementwerkzeug integriert wer den k nnen umfasst unser Projektverwaltungssystem Time Tool nur einen kleinen Ausschnitt der
49. Teil der in anderen SW HW Einheiten verstreut sein kann er stellt werden Innerhalb der Definition der Anforderungen an die Funktionalit t sind die Anforderungen an die Sicherheitsfunktionen und die daf r notwendigen Daten zu erstellen Weiterhin sind die Anforderungen an die Qualit t der SW HW Einheit abh ngig von der Kritikalit tsstufe zu erarbeiten Die Softwarearchitektur ist innerhalb des Softwaregrobentwurfs zu entwerfen Dabei ist die Be drohungs und Risikoanalyse fortzuschreiben und zu untersuchen inwiefern durch die Verfei nerung neue Bedrohungen und Risiken auftreten Abh ngig von der gew hlten Sicherheitsstufe nach ITSEC wird eine textuelle semiformale oder formale Architekturbeschreibung der si cherheitsrelevanten Teile gefordert Weiterhin sind im Grobentwurf die internen und externen Softwareschnittstellen zu entwerfen und die Softwareintegration zu spezifizieren Es sind alle Schnittstellen der sicherheitsspezifischen und sicherheitsrelevanten SW Komponenten SW Prozesse und SW Module mit ihrem Zweck und ihren Parametern zu beschreiben Dabei ist die Separierung des nicht sicherheitsrelevanten Teils zu verdeutlichen und die Schnittstellen sind zu minimieren Im Feinentwurf sind die Komponenten Module und die Datenbank der Software abh ngig von der gew hlten Kritikalit tsstufe informal oder semiformal zu beschreiben und f r Sicher heitsvorgaben sind der Betriebsmittel und Zeitbedarf gegebenenfalls zu ermitteln
50. Umgebungsanforderungen nicht verneint oder nicht als geringf gig eingestuft werden kann m ssen geeignete Ma nahmen gesucht werden und die Ma nahmen sind bez glich ihrer Tauglichkeit zu berpr fen Wie bereits erw hnt verwenden wir die grafische Beschreibungstechnik UML einerseits des halb weil sie sich innerhalb von objektorientierten Vorgehensmodellen zum Modellierungs standard entwickelt hat Ein weiterer entscheidender Vorteil der f r Einsatz der UML propa giert ist die Erweiterbarkeit der UML Durch ihre Erweiterungsf higkeit in Form von Stereo typen Tagged Values und Constraints vgl BRJ98 EPO0 erm glicht sie es die notwendigen Schutzzielannotationen in den hier verwendeten Klassen und Aktivit tsdiagrammen einzu bringen Im Folgenden stellen wir die notwendigen Erweiterungen der UML f r die Spezifikation von Schutzzielen im Dom nenmodell und in den Abl ufen der Gesch ftsprozessmodellierung vor Bei der Ablaufmodellierung zeigen wir auf zwei unterschiedliche Detailstufen die Schutzzielan notation Es k nnen entweder nur die reinen Aktivit tsfolgen betrachtet werden oder in de taillierter Form die zwischen den Aktivit ten ausgetauschten Flussobjekte ebenfalls annotiert werden Die Spezifikation der Schutzziele an Flussobjekten kann als Erweiterung der Akti vit tsfolgen betrachtet werden und ist dann durchzuf hren falls die Gesch ftsprozessmodel lierung die Modellierung auf dieser detaillierten Ebene erford
51. Vererbung von Benutzerberechtigungen Bei den Benutzerberechtigungen gibt es zwei M glichkeiten der Vererbung die sich aus der Vererbung von Klassen im objektorientierten Paradigma und aus der eingefiihrten Speziali sierung von Akteuren ergeben Die erste Vererbungsart bezieht sich auf die Akteurhierarchie siehe hierzu den Quadrant IV von Abbildung 4 5 In unserem Beispiel ist der Projektleiter project manager eine spezielle Art des Projektmitarbeiters team worker Deshalb besitzt ein Projektleiter neben seinen eigenen Berechtigungsaxiomen auch die des Projektmitarbeiters Beispielsweise besitzt der Projektmanager bez glich der Berechtigungen aus den Beispielen 1 und 2 in Abschnitt 14 4 2 den Lesezugriff sowohl zu eigenen Buchungen unabh ngig vom Projekt als auch zu allen Buchungen von eigenen Projekten unabh ngig vom User Die zweite Vererbungsart besch ftigt sich mit der Vererbung im Dom nenmodell dessen Objekte mit den Benutzerberechtigungen zu sch tzen sind Genauso wie oben erben Sub klassen Methoden die Berechtigungen aus ihren Superklassen Zus tzlich erlauben wir dass Berechtigungen in den Superklassen nicht spezifiziert werden und dass dann gegebenenfalls die Berechtigungen in den Subklassen spezifiziert sind 46 Akteurzentriertes Modell zur Spezifikation von Benutzerrechten 4 5 Spezifikation von Benutzerrechten in OCL Im Hinblick auf eine Werkzeugunterstiitzung zur Modellierung von Benutzerrechten und anl s
52. Vorgehens modell Leider stellt nur knapp die Ideen zur Erarbeitung von Sicherheitsrisiken vor eine ausf hrliche Darstellung des Prozesses findet nicht statt Ebenso fehlten Erfahrungsbe richte aus der Praxis die die Anwendung dieses Vorgehens untermauern Security Engineering Management Ross Anderson beschreibt in seinem Buch mit dem Titel Security Engineering Grundlagen f r die Entwicklung von zugriffssicheren Systemen wie beispielsweise Protokolle Kryptografie F lschungssicherheit Abh rm glichkeiten In einem Abschnitt wendet er sich dem Vorgehen f r eine sichere Entwicklung zu und skizziert eine Top Down und eine iterative Vorgehensweise Bei der ersten Vorgehensweise wird die Software zumeist nach dem Wasser fallmodell entwickelt Zur Entwicklung der Sicherheit werden dabei die Gefahren des Systems identifiziert Risiken bewertet und eine Sicherheitsstrategie entwickelt Die Sicherheitsstrate gie wird anschlie end auf die Soft und Hardware bertragen und abschlie end finden Tests statt Nach Anderson eignet sich diese Methode nicht zur Entwicklung von sicheren Systemen da nicht alle potenziellen Sicherheitsl cken gefunden werden Zur Entwicklung von zugriffssicheren Systemen pl diert Anderson f r eine Problemanalyse im Prozess in der alle potenziellen Gefahren systematisch ermittelt werden M gliche Realisie rungen f r eine Problemanalyse sind eine top down orientierte Analyse mit Bedrohungsb u 66 Ein Prozes
53. Zugriffssicherheit beteiligt sind So k nnen auch die gew hnlichen manuellen Vorg nge zur Gew hrleistung der Sicherheit in die Entwicklung der Sicherheitsaspekte des Systems mit aufgenommen werden Beispielsweise k nnen Dokumente die vertraulich behandelt werden m ssen ebenso festge halten werden wie Abl ufe zur Beweissicherung Die Zugriffs und Ausf hrungsrechte f r Akteure sind festzulegen Durch eine hierarchische Anordnung k nnen Gemeinsamkeiten und Besonderheiten in den Rechten fr hzeitig model liert werden Durch die Spezifikation der Benutzerrechte au erhalb des Klassendiagramms bleibt das Klassendiagramm bersichtlich und nderungen im Klassendiagramm k nnen oh ne Betrachtung von Assoziationen zu Klassen f r Benutzerrechte durchgef hrt werden Durch die vorab textuelle Spezifikation der Benutzerrechte m ssen diese vorab noch nicht exakt spe zifiziert werden und bleiben auch f r Endanwender und Auftraggeber verst ndlich Das vorgeschriebene Verfahren bietet eine Vielzahl von Iterationsm glichkeiten Es k nnen Teile der Gesch ftsprozesse und des Dom nenmodells inklusive Betrachtung der Sicherheits aspekte inkrementell entwickelt werden Durch die mehrfache Anwendung des Sicherheitsmi kroprozesses k nnen auch die Bedrohungen Risken und Ma nahmen iterativ entwickelt und verfeinert werden Durch das vorgestellte Verfahren zur Spezifikation der Sicherheit in den Gesch ftsprozessen und im Dom nenmodell werden unt
54. activity 1 process ACActor process ACActor Q activity 2 ha swimlanes ProjectInfo ActivityType Project Activity Administrator User Accounting AC TeamWorker F passwd TeamWorker userid ACActor ACProject A Manager passwd Cc Cc A A ProjectManager userid Administrator TeamWorker AC Omer ACProject Manager Abbildung 6 22 Erweiterung des Klassendiagramms um Vorgangsklassen Akteur Rollen Team Worker und ProjectManager zugeordnet welche die Aktivit ten Activi tyl bzw Activity2 ausf hren Zum internen Klassendiagramm der Time Tool Fallstudie f gen wir die zwei Vorgangsklassen PC Activityl und PCActivity2 hinzu die jeweils eine Methode process enthalten Zu den derart abgeleiteten process Methoden in den Vorgangsklassen k nnen wir nun analog zu Zugriffsmethoden auf Klassenattribute Zugriffsberechtigungen in der in Abschnitt 4 4 2 vorgestellten Art funct perm cm AC Actor C T Im Bool vergeben wobei C eine Klasse und m eine Methode von C der Form m id a1 7T1 2n Thn T ist Die Eigenschaften von Methodenberechtigungen werden dabei durch P MOS Pr di kate spezifiziert die Bedingungen ber der gegebenen Objektstruktur beschreiben Die Spezifikation von Ausf hrungsrechten ist nur deshalb m glich da den Aktivit t
55. aus den Abl ufen die Systemanforderungen abgeleitet werden Bei der Entwicklung eines neuen Gesch ftsbereichs m ssen vorab die Abl ufe erstmalig festgelegt werden 6 1 3 Produktartefakte der Gesch ftsprozessmodellierung Die zentralen Produktartefakte der Gesch ftsprozessmodellierung sind e das Dom nenmodell ein Klassendiagramm in dem die zentralen Typen der Objekte zur Beschreibung der Organisationsstruktur und statischer Konzepte modelliert werden und 6 1 Allgemeine Gesch ftsprozessmodellierung 95 Project Manager Team Worker initialise project change project data xD account online I account offline prepare Dale ae een Monthly k monthly report Accounts Abbildung 6 2 Ein Gesch ftsprozess des TimeTool Projektverwaltungssystems e das Gesch ftsprozessmodell Aktivit tsdiagramme die die Abl ufe der Unternehmung bzw Organisation beschreiben Im Gesch ftsprozessmodell sind neben den Abl ufen als Aktivit tsfolgen noch eine Reihe weiterer Informationen beschrieben die in Zusammenhang mit der Ablaufmodellierung zu erfassen sind e Die Akteure eine Sammlung aller in den Abl ufen involvierten Akteure Zu den Akteu ren geh ren einzelne Personen Gruppen Organisationen Unternehmen sowie Maschi nen die mit dem Gesch ftsbereich interagieren e Die Architektur gibt einen berblick ber die Struktur und Zweck der Unternehmung bzw Organisation Sie dient
56. ce re ae 86 5 6 Zusammenfassung 222222 nn nn 89 b Die Gesch ftsprozessmodellierung zugriffssicherer Systeme 91 6 1 Allgemeine Gesch ftsprozessmodellierung 22 2 22 2 nn 00002 eee 92 la BE Gk ee ee 92 6 1 2 Aktivit ten der Geschaftsprozessmodellierung 94 6 1 3 Produktartefakte der Gesch ftsprozessmodellierung 94 Lethe ea be 22S 96 a 97 6 2 2 Schutzziele in Abl ufen der Geschaftsprozessmodellierung 104 Sake SR i gale ed Eee AOE ner ee lee 107 6 3 Berechtigungsmodellierung 2 2 2 2 2m a 110 6 3 1 Modellierung der Akteure 2 CE CE nn nn 111 6 3 2 Modellierung von Zugriffsrechten auf das Dom nenmodell 113 ae 114 128 6 4 1 Prozessmuster 6 1 Gesch ftsprozessmodellierung zugriffssicherer Systeme123 if ea oes 131 en 137 6 6 Zusammenfassung 2 nn nn 139 7 Die Anwendungsfallmodellierung zugriffssicherer Systeme 141 7 1 Grundlagen der Anwendungsfallmodellierung 22 2 22222220 142 ne ae eae eb eae eh pee a we oe 142 7 1 2 Aktivit ten der Anwendungsfallmodellierung 144 Inhaltsverzeichnis iii 7 1 3 Produktartefakte der Anwendungsfallmodellierung 145 diy See eee ce gc Br ee I a Se Pee ee are 146 ae Gee are Be ts Gt Ge Kane eg ek ge ees A 147 eo GORA Bw Be Re ee Be e E 147 Pa am ae 148 nen ns 151 CG PLE ERLE GPK EE Dee 154 7 3 1 Erweiterung der Anwendungsfalle um Aspekte der Zugriffssicherheit 155 oe eee 157 P igue ee eee de o
57. dabei eine einheitliche Modellbasis verwendet Produkte k nnen flexibel strukturiert und in die Umgebung integriert werden Die objektorientierte Systemsicht unterst tzt insbesondere die Erweiterbarkeit die Wieder verwendbarkeit und die Wartbarkeit von Systemen siehe Die wichtigsten Grund ideen objektorientierten Vorgehens sind die Konzepte der Datenkapselung der Vererbung und 2 1 Vorgehensmodelle 13 der dynamischen Existenz von Objekten Objekte sind die atomaren Strukturierungseinhei ten eines objektorientierten Systems Jedes Objekt hat einen internen Zustand der durch die Auspr gung seiner Attribute bestimmt ist Dieser interne Datenzustand ist gekapselt d h er ist von au en nicht direkt zug nglich sondern nur ber die Ausf hrung von Operationen Sie bilden die Schnittstelle des Objekts Objekte kommunizieren untereinander durch das Senden von Nachrichten Weiterhin sind objektorientierte Systeme hochgradig dynamisch Objekte k nnen zur Laufzeit erzeugt werden und nach Abschluss der Interaktionen h ren sie irgendwann auf zu existie ren Objekte werden zumeist zu Klassen gruppiert Klassen verk rpern das Typkonzept und beschreiben Mengen von Operationen mit hnlicher interner Struktur Schnittstelle und Ver halten Eine weitere Gruppierung hnlicher Objekte wird mit dem Konzept der Vererbung unterst tzt In den 90er Jahren wurden eine Vielzahl von objektorientierten Softwareentwicklungsme thoden entwickelt B
58. der Sicherheitsaspekte und die Integration der Entwicklung von Sicherheitsanforderungen in die funktionalen Anforderungen gezeigt Die Iterationsm glichkeiten der Prozesse insbesondere auch die iterative Anwendung des Sicher heitsmikroprozesses zur Ermittlung von Bedrohungen Risiken und Ma nahmen sowie zur berpr fung der Ma nahmen werden dargestellt Weiterhin wird die Spezifikation der Benut zerrechte auf Basis des vorgestellten Benutzerrechtemodells in den verschiedenen Abschnitten der Anforderungsspezifikation zugriffssicherer Systeme durchgef hrt Neben diesen allgemei nen Aspekten werden in den Prozessabschnitten der Anforderungsspezifikation spezifische Aktivit ten zur Modellierung der Zugriffssicherheit ausgef hrt Bei der Gesch ftsprozessmodellierung zur Sicherheit steht die Spezifikation von Schutzzielen in Struktur und Verhalten im Vordergrund die gemeinsam mit Anwendern Auftraggebern Auftragnehmern und Anforderungsentwicklern erarbeitet wird Die Bedeutung der Schutz ziele im Kontext der Struktur und Verhaltensbeschreibung wird gekl rt und mithilfe des Erweiterungsmechanismus der UML werden Stereotypen f r Schutzziele eingef hrt Bei der Modellierung der Benutzerrechte werden eine Hierarchie von Akteuren erstellt und verschie dene Typen von Ausf hrungsrechten definiert Bei der Anwendungsfallmodellierung zur Sicherheit steht die Modellierung des Schutzziels Authentifikation im Vordergrund F r UML Aktivit tsdiagramm
59. die funktionalen Aspekte von denen der Sicherheit Eine gemeinsame Sicherheitsanalyse und Si cherheitsmodellierung mit Entwicklung und Umsetzung der funktionalen Anforderungen ist im Vorgehensmodell nicht vorgesehen sodass Synergien nicht ausgenutzt werden Bei der Erarbeitung der Funktionalit t k nnen bereits lokale sicherheitsspezifische Aspekte feststellt und herausarbeitet werden Ebenfalls w re es m glich dass bei der Ausarbeitung der Sicher heitsaspekte bereits Sicherheitsgrundfunktionen ermittelt werden und zu den funktionalen Anforderungen hinzugef gt werden So w re es beispielsweise m glich dass bei der Bearbei tung der Sicherheitsstrategie aus Gr nden der Verbindlichkeit ein Mechanismus zur Beweis sicherung ermittelt und zu den Anforderungen hinzugef gt wird Datenobjekte und Abl ufe f r eine Beweissicherung unterliegen ebenfalls Sicherheitsbetrachtungen die durch eine der artige Verzahnung bereits schrittweise erarbeitet werden k nnen W nschenswert w re hier eine strukturierte Erarbeitung von Aspekten der Sicherheit hnlich dem Konzept der Anwen dungsf lle bei der Entwicklung von funktionalen Anforderungen Iterationen sind in dem vorgestellten Vorgehensmodell analog zum Wasserfallmodell nur zwi schen der aktuellen Phase und der vorausgehenden Phase vorgesehen In heutigen objekt orientierten Vorgehensmodellen wie beispielsweise dem Unified Process oder dem Catalysis Approach DW98 werden Iterationsm glichkeiten
60. die Schutzziele die auf diesen Daten spezifiziert sind einzubezie hen Ergeben sich aus den Daten weitere Anforderungen an die Zugriffssicherheit so sind die Schutzziele zur erweiterten Beschreibung des Anwendungsfalls hinzuzunehmen Wurde f r eine Aktivit t das Schutzziel Authentifikation ermittelt und wurde im Abschnitt 7 2 bei der Modellierung der Authentifikation festgelegt dass die Autorisierung zu berpr fen ist so ist im Anwendungsfall hierf r eine Vorbedingung hinzuzuf gen Vorbedingungen in Anwendungsf llen wurden bereits in diskutiert und als Element einer erweiterten Anwendungsfallbeschreibung eingef hrt Beschreibung der Anforderungen der Zugriffssicherheit F r die Beschreibungen von Anforderungen an die Zugriffssicherheit wird die strukturelle Anwendungsfallbeschreibung aus um einen Abschnitt Sicherheit erg nzt Darin werden Schutzziele Vorbedingungen Modifikationen am Ablauf sowie weitere nderungen am Anwendungsfall die aus der Ermittlung der Zugriffssicherheit hervorgehen beschrieben Ergeben sich aus der Ermittlung der Zugriffssicherheit auch Varianten zum Ablauf so sind diese der Beschreibung der Varianten hinzuzuf gen In Abbildung 7 8list die Erweiterung der Anwendungsfallbeschreibung zum Anwendungsfall Korrekturbuchung vgl Abbildung 7 1 aus unserer TimeTool Fallstudie dargestellt Schutz ziele aus der Modellierung der Gesch ftsprozesse sowie aus der Modellierung der Authentifika tion werden al
61. die strukturellen Beschreibungen der Anwendungsf lle mit Betrachtung der Zu griffssicherheit Einen berblick ber die Anwendungsf lle des Systems und die Zuordnung zu den beteiligten Akteuren geben Anwendungsfalldiagramme in die auch die Sicherheits anwendungsf lle zur Beschreibung der Sicherheitsgrundfunktionen mit aufgenommen werden m ssen Zus tzliche Anforderungen wie beispielsweise gesetzliche Regelungen werden in der Anforderungserg nzung beschrieben ein Entwurf der Benutzerschnittstelle im UI Prototyp 7 7 Zusammenfassung 175 7 7 Zusammenfassung Ziel der Anwendungsfallmodellierung zugriffssicherer Systeme ist es die durchg ngige und sukzessive Entwicklung von Aspekten der Zugriffssicherheit die bereits bei der Analyse der Gesch ftsprozesse begonnen wurde fortzusetzen Hierzu werden bei der Entwicklung von Struktur und Verhalten die bereits spezifizierten Anforderungen an die Zugriffssicherheit auf gegriffen und angepasst bzw verfeinert nderungen am Dom nenmodell die sich sowohl aus der Abgrenzung der Systemgrenzen der detaillierten funktionalen Spezifikation sowie als Reaktion auf bereits ermittelte Ma nahmen zur Zugriffssicherheit ergeben sind erneut einer Sicherheitsanalyse zu unterziehen Durch die iterative Anwendung des Sicherheitsmikroprozesses werden f r ge nderte Attribute Klassen und Assoziationen die Schutzziele Bedrohungen und Risiken und Ma nahmen angepasst Die Festlegung der Systemgrenzen
62. eine erneute Ermittlung der Bedrohungen Risiken und Ma nah men sowie f r eine Spezifikation der Benutzerrechte vorzumerken Die Ermittlung der Bedrohungen Risiken und Ma nahmen erfolgt durch die Anwendung des Sicherheits mikroprozesses Erg nzung des Dom nenmodells Bei der Entwicklung der Anwendungsf lle werden die Ein und Ausgaben sowie nde rungen am Anwendungskern spezifiziert Diese nderungen sind in das Dom nenmodell zu bernehmen nderungen am Anwendungskern k nnen etwa Umstrukturierungen das Modifizieren oder Hinzuf gen von Assoziationen und Attributen oder das Hin zuf gen von neuen Klassen sein Durch die nderung von Klassen und Assoziationen sind die Klassen erneut einer Ermittlung der Schutzziele Bedrohungen Risiken und 168 Die Anwendungsfallmodellierung zugriffssicherer Systeme Ma nahmen zu unterziehen siehe Ausf hrung des Sicherheitsmikroprozesses Anschlie Bend sind die Benutzerrechte zu berpr fen Entwurf der UI Prototypen Im Rahmen der Anwendungsfallmodellierung sind Prototypen der Benutzerschnittstelle zu entwickeln Ausf hrung des Sicherheitsmikroprozesses Bei der Ausf hrung des Sicherheitsmikroprozesses sind f r jeden sicherheitskritischen Anwendungsfall f r den die Sicherheitseigenschaften nicht direkt aus der zugeordneten Aktivit t bernommen werden konnte Bedrohungen Risiken und Ma nahmen zu er mitteln Ebenso muss der Sicherheitsmikroprozess auch auf modifizierte Entit
63. erstellt Da jedoch zu diesem Zeitpunkt die Grenzen des Systems noch nicht bestimmt waren sind zu Beginn der Anwendungsfallmodellierung die Grenzen und die Funk tionalit t des zu entwickelnden Systems festzulegen F r die spezifizierten Gesch ftsabl ufe ist festzulegen welche in dem zu entwickelnden System in welchem Umfang behandelt werden Aufbauend auf den zu automatisierenden Gesch ftsprozessen sind die Akteure des Systems abzugrenzen Auch hier wurden bereits im Rahmen der Gesch ftsprozessmodellierung die Akteure in den so genannten Swimlanes den einzelnen Aktivit ten zugeordnet Durch die Festlegung der tats chlichen Systemgrenzen muss aber auch die Menge der Akteure berar beitet werden da durch den Wegfall von Gesch ftsabl ufen diese Menge eingeschr nkt werden kann Da wir neben Personen auch externe Hardware und Softwaresysteme siehe Rat00 mit dem zu erstellenden System interagieren sind im Rahmen der Anwen dungsfallmodellierung die Akteure um derartige externe Systeme und Hardware zu erweitern Da im Rahmen der Gesch ftsprozessmodellierung basierend auf den fehlenden Systemgrenzen die externen Systeme und Hardware noch nicht modelliert werden konnten sind diese bei der Anwendungsfallmodellierung zu ermitteln und als Akteure aufzunehmen F r eine Bestimmung der Anwendungsf lle sind vorab diejenigen Gesch ftsprozesse die mit dem zu erstellenden System automatisiert werden sollen zu berarbeiten Da im Rahmen der
64. keine systemglobalen Eigenschaften festgelegt Da bei der Festlegung der individuellen objektbezogenen Beschr nkungen die Abh ngigkeiten zwischen Objekten wie beispielsweise Benutzungs Kommunikations und Kooperationsabh ngigkeiten nicht be trachtet werden besteht die Gefahr inkonsistente Strategien zu modellieren DAC Modelle werden blicherweise mit Zugriffskontrollmatrizen beschrieben Dabei wird der Schutzzustand eines Systems zum Zeitpunkt t durch eine S x O Matrix M dargestellt Dabei gilt e Die Spalten der Matrix werden durch die Menge O der Objekte und 4 2 Klassische Zugriffskontrollmodelle 33 e die Zeilen der Matrix durch die Menge S der Subjekte zum Zeitpunkt t definiert e Es gilt M S x O 2 wobei R die Menge der Zugriffsrechte festlegt 2 bezeichnet dabei die Potenzmenge der Menge R Ein Eintrag M s 0 r r beschreibt die Menge der Rechte die das Subjekt s zum Zeitpunkt t an dem Objekt o besitzt F r jeden Zeitpunkt t modelliert die Matrix M die in dem betreffenden Zustand g ltigen Zugriffsrechte der Subjekte an den Objekten des Systems M gliche Zugriffsrechte sind zum Beispiel Lesen Schreiben oder Ausf hren von Prozeduren L schen oder Anlegen Die Granularit t der Objekte und Subjekte ist ein wichtiger Parameter bei der Konzeption eines diskreten Zugriffskontrollmodells mit weit reichenden Auswirkungen auf den sp teren Betrieb Alle Objekte haben einen Eigent mer der
65. llen wird die Sicherheit lokal bei der betrachteten Funktionalit t spezifiziert F r die Ausarbeitung der Sicherheit wird kein iteratives Vorgehen explizit angegeben vielmehr wird auf das iterative Vorgehen des bergeordneten Vorgehensmodells verwiesen und dies auch gefordert Eine Gesch ftspro zessanalyse ist nicht Bestandteil dieses Ansatzes Sicherheitsrisiken im Spiralmodell Zur Behandlung von Sicherheitsrisiken im Softwarelebenszyklus wird in VM02 eine Anpas sung des Spiralmodells vorgestellt Das Spiralmodell eignet sich zum Management 5 1 Existierende Vorgehensmodelle 65 von Sicherheitsrisiken nach der Auffassung von Viega und McGraw deshalb sehr gut da die gleichen Entwicklungsaufgaben wieder und wieder durchgefiihrt werden und somit alle Erg nzungen zur Gew hrleistung der Sicherheit einer Sicherheitsanalyse unterzogen werden k nnen Am Ende entsteht ein vollst ndiges und robustes Produkt Besondere Bedeutung liegt in diesem Ansatz auf einer fr hzeitigen Betrachtung von Sicherheit denn bereits bei der Ermittlung der Anforderungen sind Sicherheitsaspekte zu betrachten Bei der Ausf hrung der Risikoanalyse und der Erarbeitung von Strategien sind die in den Anforderungen fest gelegten Sicherheitsaspekte f r eine vollst ndige Sicherheitsanalyse einzubeziehen In diesem Ansatz werden in jeder Iteration alle vorliegenden Produktartefakte verwendet und gegebe nenfalls erweitert Dabei sind beispielsweise die Anforderungsbesc
66. manipuliert werden k nnen B006 Ein Projektmitarbeiter ein Projektleiter oder ein weiterer Benut zer des Systems liest und ver ndert private Daten eines Projekt mitarbeiters R006 Das Risiko wird als hoch eingestuft da das lesen privater At tribute wie z B der Adresse oder Telefonnummer dem Daten schutz widerspricht Z B k nnen diese Daten f r Mobbing ver wendet werden Weiterhin kann durch die Ab nderung etwa der Telefonnummer der Projektleiter im Notfall nicht erreicht werden Administrator B007 Ein Projektmitarbeiter ein Projektmanager oder ein weiterer Be nutzer des Systems versucht das Passwort eines Administrators zu lesen oder zu ver ndern R007 Das Risiko wird als hoch eingesch tzt da mit der Administrator berechtigung im System alle Daten projekt bergreifend gelesen oder manipuliert werden k nnen B008 Ein Projektmitarbeiter ein Projektleiter oder ein weiterer Benut zer des Systems liest und ver ndert private Daten eines Admini strators R008 Das Risiko wird als hoch eingestuft da das lesen privater Attribu te wie der Adresse Telefonnummer etc dem Datenschutz wider spricht Beispielsweise k nnen diese Daten f r Mobbing verwen det werden Weiterhin kann durch die Ab nderung zum Beispiel der Telefonnummer der Administrator im Notfall nicht erreicht werden Accounting B009 Ein Benutzer des Systems versucht fremde Buchungen zu lesen R009 Das Risiko wird als mittel eingestuft da dies zu einer
67. ngig sukzessive und gemeinsam mit der Funktionalit t zu entwickeln sind muss auch mit der Modellierung der Benutzerrechte bereits fr hzeitig begon nen werden wenn also Auftraggeber Anwender Auftragnehmer und Anforderungsentwickler gemeinsam die Eigenschaften des Systems festlegen Eine grob granulare informale Spezifika tion der Benutzerrechte reicht f r weite Teile des Systems sicherlich aus und ist auch der erste Schritt zu einer vollst ndigen Modellierung F r kritische Systemteile sind jedoch genauere fein granularere Benutzerrechte besonders im Hinblick auf eine automatische Transformation in die Implementierung notwendig Zur Modellierung von Zugriffs und Ausf hrungsberechtigungen im Kontext eines objektorien tierten anwendungsfallgetriebenen Entwicklungsprozesses stellen wir in diesem Kapitel einen neuen Ansatz mit einer pr dikativen Spezifikation der Benutzerrechte vor Dazu erweitern wir die Methodenspezifikationen um einen Berechtigungsabschnitt der die Benutzerrechte eines Akteurs zum Aufruf einer Objektmethode beschreibt Nach einer allgemeinen Vorstellung unseres Ansatzes im Abschnitt 4 1 stellen wir in Abschnitt 4 2 klassische Zugriffskontrollmodelle als Basis f r unseren Spezifikationsansatz vor Als syn taktischen und semantischen Rahmen verwenden wir Pr dikatenlogik erster Stufe mit einer integrierten Objekt und Klassenstruktur Diesen mit einer algebraischen Semantik ausgestat teten Spezifikationsrahmen P MOS
68. nnen Im letztge nannten Fall sprechen wir von elementaren Methoden mp Gehen wir davon aus dass zu den elementaren Methoden mp Benutzerrechte spezifiziert sind so k nnen wir aus diesen Benutzerrechten die Benutzerrechte der aufrufenden zerlegbaren Methode mz bestimmen Ermitteln wir alle Benutzerrechte der teilbaren Methodenaufrufe derart so k nnen wir entgegengesetzt der Richtung der Methodenaufrufe die Benutzerrechte der teilbaren Methodenaufrufe und somit auch des gesamten Ablaufs ermitteln Sei M die Menge von Methoden die aufgerufen werden k nnen Die Elemente von M sind Zustandsfunktionen m Mn ber dieser Menge von Methoden f hren wir eine zweistellige Relation R wie folgt ein RPCMxM Mr My RP my liefert Permission fiir Mmg falls es im Ablauf eine Folge von Methodenaufrufen mo m mit n gt 1 gibt und es gilt My Mz Mn My Me Mg ma ma Mn 1 y 7 4 Evolution von Berechtigungen 161 Ein Element mz My ist genau dann in der Relation R enthalten wenn die Methode My f r die Methode m eine Berechtigung liefert Eine Methode liefert genau dann eine Berechtigung wenn sie durch eine Folge von 0 n weiteren Methodenaufrufen aufgerufen wird Die Relation RP liefert uns die transitive H lle Bro98b tiber den Methodenaufrufen zu einer gegebenen Methode m d h in ihr sind alle im Ablauf der Methode m erreichbaren Methodenaufrufe in der Form Methode m ruft Methode m
69. nur die betrachteten Aspekte umfassen Im Requirements Engineering erfolgt eine durchg ngige und sukzessive Entwicklung der Si cherheitseigenschaften denn aus den Bedrohungen und Risiken werden eine Strategie sowie die Umsetzung in ein Sicherheits Target abgeleitet F r eine gemeinsame Entwicklung von 5 2 Prozessanforderungen an die Entwicklung zugriffssicherer Systeme 67 Funktion und Sicherheit pl diert Anderson jedoch fehlt es an detaillierten Arbeitsschritten Produktartefakte und Iterationsm glichkeiten werden im Rahmen des Requirements Engi neerings diskutiert 5 2 Prozessanforderungen an die Entwicklung zugriffssicherer Systeme Nachdem wir in den vorausgegangenen Abschnitten existierende Vorgehensmodelle zur Ent wicklung zugriffssicherer Systeme bez glich ihrer St rken und Schw chen analysiert haben stellen wir im Folgenden Prozessanforderungen zur Entwicklung zugriffssicherer Systeme vor und fassen im Abschnitt 5 2 2 tabellarisch die Anforderungsabdeckung f r die im Abschnitt 5 1l vorgestellten Vorgehensmodelle zusammen 5 2 1 Prozessanforderungen Bei den im Folgenden aufgelisteten Prozessanforderungen zur Entwicklung zugriffssicherer Systeme handelt sich um solche die gr tenteils f r den gesamten Prozess g ltig sind Da wir uns in dieser Arbeit jedoch besonders f r die Phasen der Anforderungsspezifikation inte ressieren heben wir prim r die Prozessanforderungen an die fr hen Phasen zur Entwicklung zugr
70. sein d rfen nicht gekenn zeichnet In sp teren Phasen der Systementwicklung beginnen die Anforderungsentwickler Aspekte der Zugriffssicherheit von Grund auf zu erarbeiten Die Benutzerrechte auf grundlegende Dom nenobjekte und Gesch ftsprozesse werden der zeit innerhalb der fr hen Phasen der Softwareentwicklung nicht modelliert Dies liegt unter anderem daran dass die derzeitigen Ans tze zur Modellierung von Benutzerrechten Rech te zumeist in Form von Klassen im Klassendiagramm modellieren Alt04 Da jedoch das Klassendiagramm zu diesem Zeitpunkt noch instabil ist d h die Struktur des Klassendiagramms oder einzelne Attribute k nnen sich noch ndern bleibt eine Modellierung der Benutzerrechte zu diesem Zeitpunkt au en vor L sung F r die fr hzeitige Behandlung von Aspekten der Zugriffssicherheit innerhalb des Entwick lungsprozesses finden neben den Aktivit ten der allgemeinen Gesch ftsprozessmodellierung aus Aktivit ten zur Modellierung von Schutzzielen sowohl in der Struktur der Do m nenobjekte sowie in den Gesch ftsprozessen statt Akteure werden bez glich der Rechte im System hierarchisch angeordnet sodass Benutzern bez glich ihres Rangs im Unternehmen verschiedene Rechte zugeteilt werden k nnen Basierend auf den ermittelten Schutzzielen in den Aktivit ten der Gesch ftsprozesse und den Objekten des Dom nenmodells sind die 6 4 Der Prozess der Gesch ftsprozessmodellierung zugriffssicherer Systeme 125 Modelli
71. sind auszuarbei ten und zu beschreiben siehe hierzu Abschnitt 7 1 3 Die Daten die im Anwendungsfall ben tigt erstellt und oder manipuliert werden sind zu erfassen und die geeigneten Datenty pen im Dom nenmodell zu erg nzen Der Ablauf mit seinen Varianten wird textuell beschrie ben F r eine iterative Entwicklung k nnen die Anwendungsf lle priorisiert werden d h es wird festgelegt in welchen Ausbaustufen die Anwendungsf lle umgesetzt werden 7 1 Grundlagen der Anwendungsfallmodellierung 145 Anwendungsfall Korrekturbuchung Akteure Team Worker Input AccountingID Modified Accounting Data Output Accounting Data Acknowledgement Modifizierte Klassen des Anwendungskerns Accounting Beschreibung Das System erh lt vom Akteur Team Worker einen Buchungsidentifier z B von einer vorausgehenden Suche Die interne Verwaltungseinheit des Systems f r Buchungen Ac counting Manager sucht die entsprechende Buchung im System und zeigt sie dem Akteur Team Worker an Der Team Worker modifiziert die Daten und das System speichert die Aktualisierungen Am Ende gibt das System eine Best tigung an den Akteur Team Wor ker zur ck Varianten 1 Das System kann die Buchung zum vorgegebenen Buchungsidentifier nicht finden Das System gibt eine negative Best tigung an den Akteur Team Worker zur ck 2 Dem Akteur Team Worker werden die Daten der gesuchten Buchung angezeigt er ver ndert jedoch keine Daten Das System mus
72. sind in so genannten Szena rien zu verfeinern Dazu sind die interagierenden Klassen und die Interaktionen zwischen Objekten der Klassen zu spezifizieren F r jeden Anwendungsfall ist eine Vorgangsklas se zu erstellen in der sp ter der Ablauf des Anwendungsfalls in einer process Methode implementiert wird Alle Vorgangsklassen sowie an den Interaktionen beteiligte Klas sen die noch kein Bestandteil des Klassendiagramms der Analyse sind m ssen dem Klassendiagramm hinzugef gt werden Aspekte der Zugriffssicherheit die in den An wendungsf llen textuell spezifiziert wurden sind in der Ablaufspezifikation d h in den Szenarien zu integrieren Notwendige Klassen zur Realisierung der Sicherheitsfunktio nen sind ebenfalls dem Klassendiagramm hinzuf gen Auf die Aspekte der Zugriffssi cherheit bei der Realisierung der Anwendungsf lle wurde im Abschnitt 8 2leingegangen e Protokollauswahl und modellierung Zur Gew hrleistung der Funktionalit t der Sicherheit sind geeignete Protokolle aus zuw hlen oder zu entwickeln Diese Protokollabl ufe oder der Aufruf von Protokollen sowie die notwendigen Klassen sind den Szenarien und dem Klassendiagramm der Ana lyse hinzuf gen Die Identifikation von Sicherheitsprotokollen wurde in Abschnitt diskutiert e Analyse der Spezialanforderungen Die nichtfunktionale Anforderung der Zugriffssicherheit wurde in der Anforderungs analyse zugriffssicherer Systeme detailliert behandelt Es gibt jedoch eine Re
73. tisierung sind Systemanforderungen abzuleiten Spezifikation der Schutzziele in den Gesch ftsprozessen An den spezifizierten Gesch ftsprozessen sind die Aktivit ten die ein potenzielles An griffsziel darstellen mit Schutzzielen zu annotieren Im Abschnitt 6 2 2 wurden hierzu spezielle Schutzziel Icons f r Aktivit tsdiagramme eingef hrt sodass potenzielle An griffe an einzelnen Aktivit ten dieser Aktivit tsdiagramme annotiert werden k nnen Bei der Spezifikation der Schutzziele in den Gesch ftsprozessen wird jede Aktivit t aus jedem Aktivit tsdiagramm dahingehend untersucht inwiefern bei der Abarbeitung dieser Aktivit t ein unautorisierter Informationsgewinn eine unbemerkte oder unauto risierte Manipulation zu vermeiden ist oder eine Beweissicherung notwendig ist 6 4 Der Prozess der Gesch ftsprozessmodellierung zugriffssicherer Systeme 127 Da der genaue interne Ablauf der Aktivit ten zu diesem Zeitpunkt noch nicht spezifiziert wurde m ssen bei dieser Spezifikation der Schutzziele die Daten oder Systemfunktio nen auf denen die aktuelle Aktivit t operiert in einer ersten Version ermittelt werden Weiterhin sind die potenziellen Angriffsziele auch mit den Auftraggebern und Anwen dern zu diskutieren Schutzziele sind falls m glich aus der manuellen Ausf hrung des Gesch ftsablaufs zu bestimmen Oftmals werden vertrauliche Daten in Schr nken einge sperrt oder nichtabstreitbare Dokumente von beiden Parteien durch i
74. u f r die zugeordnete Aktivit t und den zugeordneten User des Objekts az k nnen bei der Berechnung der Berechtigung aus dem Objekt a entnommen werden Bei der gezeigten Berechnungsvorschrift mittels der transitiven H lle m ssen zur Ermittlung des Benutzerrechts des Ablaufs auch alle Berechtigungen von teilbaren Methodenaufrufen mz bestimmt werden Da die zugeordneten Berechtigungen aber keine zus tzliche Information f r die Ermittlung der Berechtigung des Ablaufs ermitteln kann die Ermittlung der Berechtigung noch vereinfacht und effizienter gestaltet werden Mittels einer Tiefensuche im Ablauf sind alle elementaren Methoden mp zu suchen Die logische UND Verkn pfung der Zugriffsrechte der elementaren Methoden ergibt dann genau die Berechtigung des Ablaufs Auf die detaillierte Berechnung mittels Tiefensuche gehen wir nicht n her ein In unserem Ansatz sind wir bis jetzt immer davon ausgegangen dass die Benutzerrechte basierend auf den Berechtigungen von elementaren Methoden mp berechnen k nnen Es w re jedoch m glich dass f r eine im Ablauf integrierte teilbare Methode mz ein eigenes Ausf hrungsrecht spezifiziert wurde In diesem Fall betrachten wir die urspr nglich teilbare Methode mz wie eine elementare Methode mpg mit zugeordnetem Benutzerrecht Somit wer den bei der Ermittlung des Benutzerrechts des Ablaufs die Submethoden der urspr nglich teilbaren Methode mz nicht mehr zur Berechnung herangezogen sondern durch das vorge ge
75. werden mithilfe von UML Package Diagrammen be schrieben Wie bereits erw hnt muss gegebenenfalls die Ablaufbeschreibung zu einzelnen Anwendungs f llen erg nzt werden falls die Szenarien aus den Abl ufen nicht direkt hervorgehen nderun gen an den Anwendungsfallbeschreibungen werden im Anwendungsfallmodell vorgenommen Adjustment Posting rs Adjustment VGAdjustment Accounting A PostingUI Posting Manager Accounting gt select accounting search accounting get accounting le accounting show accounting modified data update accounting okay Abbildung 8 1 Szenario fiir den Anwendungsfall Korrekturbuchung Abbildung 8 1 zeigt ein Szenario zur Realisierung des Anwendungsfalls Korrekturbuchung auf der Time Tool Fallstudie Der in Abbildung 7 1 beschriebene Ablauf wurde in einem exempla rischen Sequenzdiagramm umgesetzt Zum Szenario wurden die Interaktionsklasse Adjustment Posting UI sowie die Vorgangsklassen VG Adjustment Posting und Accounting Manager er mittelt Die Klasse Accounting ist eine Fachklasse und wurde bei der Transformation des Dom nenmodells in das Klassenmodell der Analyse erstellt Im gezeigten UML Sequenzdiagramm zum Szenario fiir den Anwendungsfall Korrekturbu chung sind auch die Stereotypen aus JBR99 fiir die Einteilung der Klassen in Fach Vorgangs und Interaktionsklassen dargestellt 8 2 Realisierung der Anwendungsf lle In der Beschreibung der Aktivit
76. zeigt die Produktartefakte der Gesch ftsprozessmodellierung zugriffssiche rer Systeme mit ihren Teilprodukten In der Abbildung sind alle durch Sicherheitsaspekte ver nderten oder hinzugef gten Teilprodukte grau hinterlegt In den Teilprodukten ist zu dem auch die Beziehung der Produktartefakte zu den Produktartefakten der allgemeinen Gesch ftsprozessmodellierung gekennzeichnet Die Teilprodukte des Business Vision Modells werden verwendet Bez glich der Modellierung der Zugriffssicherheit werden diese Teilprodukte nicht ver ndert Die Gesch ftsobjekte als Teil des Dom nenmodells werden erweitert Klassen des Dom nen modells werden mit Attributen erweitert die sich aus Ma nahmen zur Abdeckung von Be drohungen ergeben Weiterhin k nnen derartige Ma nahmen auch dazu f hren dass neue Klassen ins Dom nenmodell aufgenommen werden Die Klassen des Dom nenmodells wer den mit Schutzzielen unter der Verwendung von Schutzziel Stereotypen vgl Abschnitt annotiert Im Rahmen der Gesch ftsprozessmodellierung zugriffssicherer Systeme werden innerhalb der Gesch ftsprozessmodellierung die Prozesse ebenfalls mit Schutzziel Stereotypen annotiert und die Abl ufe sind an die ermittelten Ma nahmen zur Abdeckung der Bedrohungen anzupassen Die ermittelten Akteure sind in Hinblick auf eine Spezifikation der Benutzerrechte hierarchisch anzuordnen Im Glossar werden Begriffe hinterlegt die bei der gemeinsamen Erarbeitung von Auftraggebern Auftragn
77. 4 1 Die Funktion rolerep Bereits im letzten Abschnitt haben wir erw hnt dass die Funktion rolerep die Akteure auf ihre interne Darstellung abbildet Um einen homogenen Spezifikationsrahmen innerhalb P MOS bereitzustellen erweitern wir das interne Klassendiagramm um eine Klassenhierarchie zur Darstellung der Akteurrollen Hierzu f hren wir eine Superklasse AC Actor zur Modellierung aller Arten von Akteuren ein Die Subklassen dieser AC Actor Klasse bilden die in dem Gesch ftsprozessmodell bzw Anwen dungsfallmodell definierten Akteure Akteurhierarchien des Anwendungsfallmodells werden in eine entsprechende Klassenhierarchie berf hrt Zu unserer TimeTool Fallstudie erhalten wir auf diese Weise die Subklassen ACAdminstrator ACTeam Worker ACProjectManager und ACOthers wobei ACProjectManager eine Subklasse von ACTeamWorker ist siehe Abbil dung 4 5 In dem Modell k nnen die Akteure auch Attribute besitzen Diese Attribute stellen die Einga ben f r die Authentifizierung der Akteure im System dar wobei Akteure hier Personen oder externe Systeme sein k nnen In den meisten F llen sind diese Attribute die Benutzerken nung engl userid und ein Passwort Stellvertretend k nnen aber auch biometrische Daten 42 Akteurzentriertes Modell zur Spezifikation von Benutzerrechten Use Case Model and or Domain Model
78. 4 4 2 und 4 5 gezeigten Beispiele la und 1b als Beispiel f r die automatische Generierung Allgemeine Berechtigungs berpr fung boolean Accounting getAccountingDatePermission act ACActor Es liegt keine Berechtigung vor False return false Berechtigungs berpr fung f r den Projektmitarbeiter boolean Accounting getAccountingDatePermission act ACTeamWorker Abpr fen der Bedingung ber der Objektstruktur return this user act rolerep Berechtigungs berpr fung f r den Projektleiter boolean Accounting getAccoutingDatePermission act ACProjectManager Abpr fen der Berechtigung f r den Projektmitarbeiter return getAccountingDatePermission ACTeamWorker act Abpr fen der Bedingung ber der Objektstruktur return this activity project projectmanager act rolerep Die Methode getAccountingDate Timestamp Accounting getAccountingDate act ACActor berpr fen der Berechtigung if getAccountingDatePermission act return 0 Berechtigung wird gew hrt return this accountDate Die Berechtigungs berpr fung wurde hier in eigene Methoden ausgelagert die bei der Ab arbeitung der Methode getAccountingDate aufgerufen werden muss Anhand der berlade 50 Akteurzentriertes Modell zur Spezifikation von Benutzerrechten nen Berechtigungsmethoden kann abh ngig vom bergebenen Akteur die geeignete Berech tigungs berpr fung ausgew
79. Administrator des Systems sein denn dadurch w rde er sich im TimeTool System die M glichkeit verschaffen Stundenbuchungen 6 4 Der Prozess der Gesch ftsprozessmodellierung zugriffssicherer Systeme 123 TeamWorker Administrator insert new accounting modify database entries Abbildung 6 29 Szenario zur statischen Aufgabentrennung und andere zu schiitzende Elemente direkt innerhalb der Datenbank zu manipulieren Von weiterfiihrenden Techniken die auch einen Administrator die Manipulation verhindern ab strahieren wir in Zusammenhang mit diesem Beispiel In unserem Modell gehen wir davon aus dass Berechtigungen zur statischen Aufgabentren nung bereits w hrend der Authentifikation berpr ft werden Versto en einzelne Rollenver treter gegen diese globalen Berechtigungen so schl gt die Anmeldung fehl Auf die Authen tifikation gehen wir im Rahmen der Anwendungsfallmodellierung in Kapitel 7 n her ein 6 4 Der Prozess der Gesch ftsprozessmodellierung zugriffssicherer Systeme Nachdem wir uns in den vorausgehenden Abschnitten mit Beschreibungstechniken zur An notation von Schutzzielen und der Darstellung von Benutzerrechten besch ftigt haben stel len wir im Abschnitt 6 4 1 das Prozessmuster zum Ablauf der Gesch ftsprozessmodellierung zugriffssicherer Systeme vor Abschnitt 6 4 2 zeigt die exemplarische Anwendung des Sicher heitsmikroprozesses f r die Modellierung von Bedrohungen und Risiken 6 4
80. Akteurmodell anzu passen Ebenso wie bei der Modellierung der Ausf hrungsrechte erreicht das Dom nenmodell innerhalb der Anforderungsentwicklung mehr und mehr einen stabilen Zustand sodass die anf nglich textuell spezifizierten Zugriffsrechte in Hinblick auf eine automatisierte Codegenerierung pr dikativ zu spezifizieren und zu verfeinern sind Produktartefakte Die folgende Auflistung beschreibt die Eingaben und Ausgaben zum Prozess der Anwendungs fallmodellierung zugriffssicherer Systeme Um Sicherheitsaspekte erweiterte Produktartefakte der allgemeinen Anwendungsfallmodellierung sind gekennzeichnet Eingabe Produktartefakte Business View Modell aus der Startphase Dom nenmodell mit Sicherheitsaspekten erweitert Gesch ftsprozessmodell mit Sicherheitsaspekten erweitert Bedrohungs und Risikomodell Benutzerrechtemodell Ausgabe Produktartefakte Dom nenmodell mit Sicherheitsaspekten erweitert Gesch ftsprozessmodell mit Sicherheitsaspekten erweitert Bedrohungs und Risikomodell erweitert und verfeinert Benutzerrechtemodell erweitert und verfeinert Anwendungsfallmodell mit Sicherheitsaspekten erweitert Kontext Dieses Prozessmuster kann nur im Rahmen einer Anforderungsspezifikation zugriffssicherer Systeme vgl Abschnitt 5 3 2 basierend auf einem objektorientierten Vorgehensmodell aus gef hrt werden F r die Ausf hrung des Prozessmusters werden mit Schutzzielen annotierte Gesch ftsprozesse und Dom neno
81. Die Berechnung der Ausf hrungsrechte ist jedoch nicht immer m glich wie die folgenden Einschr nkungen zeigen e Die Objekt Typen auf denen innerhalb des Anwendungsfalls operiert wird m ssen vorab bekannt sein Werden Objekt Typen auf denen ein Akteur innerhalb eines An wendungsfalls operiert erst zur Laufzeit bestimmt so k nnen auch die Zugriffsrechte erst zur Laufzeit bestimmt werden Somit ist es nicht m glich das Ausf hrungsrecht f r den Anwendungsfall vor Ausf hrung des Anwendungsfalls zu bestimmen da die ser andernfalls schon vorab zur Bestimmung des Ausf hrungsrechts durchlaufen werden m sste Die Einschr nkung der Berechnung der Berechtigung basiert in diesem Fall auf der gew hlten Granularit t des Anwendungsfalls Es w re hier nur m glich den Anwen dungsfall in kleineren Einheiten aufzuteilen und f r diese Einheiten die Benutzerrechte vorab zu bestimmen 160 Die Anwendungsfallmodellierung zugriffssicherer Systeme e M ssen in einem Anwendungsfall spezielle Prinzipien siehe Abschnitt 6 3 3 eingehalten werden wie beispielsweise das Z Eyes Principle so k nnen die Ausf hrungsrechte nicht aus den Zugriffsrechten berechnet werden e Durch die Kombination von Zugriffen innerhalb eines Ablaufs ndert sich der Wert der Information W hrend zum Beispiel einzelne Zugriffe auf einzelne Objekte erlaubt sind l sst ein Zugriff auf alle Objekte einer Klasse Schlussfolgerungen zu Um derartige Schlussfolgerungen zu v
82. F W 99 MvOV96 Ivar Jacobson Object oriented development in an industrial environment In Proceedings of OOPSLA 87 Special issue of SIGPLAN Notices 22 12 pages 183 191 December 1987 Ivar Jacobson Grady Booch and James Rumbaugh The Unified Software De velopment Process Addison Wesley Longman Inc first edition 1999 Ivar Jacobson Magnus Christerson Patrik Jonsson and Gunnar Overgaard Object Oriented Software Engineering A Use Case Driven Approach Reading MA Addison Wesley 1992 Jan J rjens Gerhard Popp and Guido Wimmel Use Case Oriented Develop ment of Security Critical Systems Information Security Bulletion 8 2 55 60 March 2003 Jan J rjens Secure Systems Development with UML Springer Verlag first edition 2004 Jan Jiirjens and Guido Wimmel Security Modelling for Electronic Commerce The Common Electronic Purse Specifications In Proceedings of the First IFIP Conference on E Commerce E Business and E Government I3E 2003 Kluwer 2003 Alfons Kemper and Andr Eickler Datenbanksysteme eine Einf hrung Ol denbourg Verlag 4th edition 2001 Manuel Koch and Francesco Parisi Presicce UML Specification of Access Con trol Policies and their Formal Verification Submitted 2003 Petr Kroha Softwaretechnologie Prentice Hall Verlag GmbH 1997 Philippe Kruchten The Rational Unified Process An Introduction Second Edi tion Addison Wesley Longman Inc 2000 Torsten Lodderstedt
83. Gesch ftsprozesse Risiken Sicherheitsziel Architektur Ma nahmen Regeln berpr fungsergebnisse Glossar Dom nenmodell Erg nzungen Gesch ftsobjekte Anwendungsfall Legende erweitert modell amp angeordnet Benutzerrechtemodell verwendet Anwendungsf lle hinzugef gt Benutzerrechtematrix Anwendungsfall diagramme Anforderungserg nzung UI Prototyp Abbildung 7 14 Produktartefakte der Anwendungsfallmodellierung zugriffssicherer Systeme Die Gesch ftsobjekte des Dom nenmodells m ssen auf die automatisierbaren Gesch ftspro zesse zugeschnitten werden die Klassen Attribute und Assoziationen sind zu optimieren Ein und Ausgabetypen der Anwendungsf lle sowie Klassen f r Schnittstellen zu externen Systemen werden aufgenommen F r so genannte Sicherheitsgrundfunktionen sind Anwen dungsf lle zu erstellen Erfordern diese Sicherheitsanwendungsf lle spezielle Dom nenobjekte sowie Ein und Ausgabeobjekte so m ssen auch diese dem Dom nenmodell hinzugef gt wer den Im Benutzerrechtemodell sowie im Bedrohungs und Risikomodell sind nderungen und Er g nzungen der Berechtigungen sowie neue Bedrohungen Risiken Ma nahmen und Uber pr fungen hinzuzuf gen Im Rahmen der Anwendungsfallmodellierung zugriffssicherer Systeme wird das Anwendungs fallmodell neu erstellt und zu den Produktartefakten hinzugef gt Zentraler Bestandteil dieses Modells sind
84. Gesch ftsprozessmodellierung auch Aktivit ten modelliert wurden die nicht im System umgesetzt werden sollen m ssen in den Gesch ftsprozessen die manuellen Aktivit ten elimi niert werden In trivialen F llen k nnen die manuellen Aktivit ten aus den Abl ufen entfernt werden Andernfalls sind die Prozesse abzu ndern und gegebenenfalls zu erweitern Die einzelnen Aktivit ten der Gesch ftsprozesse k nnen nun den interagierenden Akteuren zugeordnet werden In diesem Schritt werden die Aktivit ten der Gesch ftsprozesse in An wendungsf lle verfeinert und in Anwendungsfalldiagrammen wird der Zusammenhang zwi schen den Anwendungsf llen dargestellt Falls die Aktivit ten keinen zusammenh ngenden und vollst ndigen Ablauf darstellen m ssen die Aktivit ten weiter unterteilt oder zusam mengef gt werden sodass sie in Anwendungsf lle transformiert werden k nnen Durch die Definition der Systemgrenzen k nnen aus dem Dom nenmodell diejenigen Objekte entfernt werden die au erhalb der Systemgrenzen liegen und mit dem System nicht in Ver bindung stehen Dabei ist zu beachten dass f r eine Kommunikation mit externen Systemen Schnittstellen geschaffen werden m ssen und dass hierzu Klassen zum Dom nenmodell hin zuzuf gen sind Weiterhin sind bei der Verfeinerung des Dom nenmodells Gemeinsamkeiten bei den Klassen zu erarbeiten und die Assoziationen anzupassen Die aus den Aktivit ten der Gesch ftsprozesse ermittelten Anwendungsf lle
85. Government oder Wissens management erfordern sowohl einen schrittweisen Analyseansatz als auch ein implementie rungsunabh ngiges Analyseframework Da Benutzerrechte in enger Zusammenarbeit von Auf traggebern Anwendern Auftragnehmern und Entwicklern zu entwickeln sind muss mit der Modellierung der Benutzerrechte in der fr hen Phase der Anforderungsspezifikation begonnen werden Sowohl in der Gesch ftsprozessmodellierung in der Anwendungsfallmodellierung als auch in der Analyse sind die Benutzerrechte zu definieren zu verfeinern und zu formalisieren Abbildung 4 1 zeigt den Zusammenhang der Modellierung der Benutzerrechte und den fr hen Phasen der Anforderungsspezifikation Der im Folgenden vorgestellte statische Ansatz zur Spezifikation von Benutzerrechten basiert insbesondere auf drei Fakten Enterprise Ressource Planing Systems Business to Business Applications 4 1 Einf hrung 31 Erstens betrachten wir die Modellierung von Benutzerrechten als Aktivit t im Kontext einer objektorientierten Entwicklungsmethode wie beispielsweise im Kontext des Rational Unified Processes Kru00 des V Modells oder des Catalysis Ansatzes DW98 Dies bedeutet dass die vorgeschlagene Methode vollst ndig in den Prozessabschnitten der Anforderungsspe zifikation zugriffssicherer Systeme integriert wird Der vorgestellte Ansatz stellt somit einen Ausschnitt aus einem Prozessmodell zum Security Engineering BBH 03 dar Zweitens unterst tzt die vo
86. Innerhalb der Selbstpr fung der SW Module und der Datenbank ist ein Abgleich des Codes mit dem Feinentwurf durchzuf hren und in der Systemintegration ist das Zusammenwirken der Mechanismen zu untersuchen In der Produktbereitstellung muss die korrekte Anwen dung der Sicherheitsfunktionen durch den Sicherheitsverantwortlichen und die Benutzer in Handb chern geeignet dokumentiert werden Abbildung gibt einen berblick ber die Aktivit ten die bei der Entwicklung von si cheren Systemen und deren Evaluierung nach SEC auszuf hren sind Die grau hinterlegten Rechtecke markieren die Aktivit ten die zur Systementwicklung notwendig sind die wei 5 1 Existierende Vorgehensmodelle 59 SEI Ist Aufnahme Analyse Anwendungssystem System fachlich Bedrohungen und System durchf hren beschreiben strukturieren Risiken analysieren Anforderungsanalyse SE2 System technisch Realisierbarkeit Anforderungen Systemintegration Systementwurf entwerfen untersuchen zuordnen spezifizieren SE3 Allg Anforderungen Anf an die externen Anforderungen an die Anforderungen and die Anforderungen an die SW HW aus Sicht der SW HW Schnittstellen der SW Funktionalit t Qualit t der SW HW Entwicklungsumgebung Anforderungsanalyse Einheit definieren HW Einheit pr zisieren definieren Einheit definieren definieren SE4 SW Architektur SW interne und
87. Klassen werden optimiert d h Vererbungen Assoziationen und Attri bute etc werden angepasst Diese nderungen sind bei der Modellierung der Aspekte der Zugriffssicherheit ebenfalls zu betrachten L sung F r eine durchg ngige und sukzessive Entwicklung der Anforderungen an die Zugriffssicher heit sind die bereits erarbeiteten Sicherheitsaspekte aus der Gesch ftsprozessmodellierung zugriffssicherer Systeme in die verfeinerte Struktur und in das verfeinerte Verhalten der An wendungsfallmodellierung zu bertragen erg nzen und verfeinern Durch die Festlegung der Anforderungen des zu entwickelnden Systems sind diejenigen Teile aus den Gesch ftsabl ufen zu entfernen die nicht automatisiert werden Neben den Abl ufen sind auch das Dom nenmodell und die Akteure anzupassen Ver nderte Attribute und As soziationen im Dom nenmodell erfordern eine berpr fung der Schutzziele und die Akteure sind f r eine Rechtespezifikation gegebenenfalls neu hierarchisch anzuordnen Durch die unter schiedliche Zuordnung von Aktivit ten zu Anwendungsf llen k nnen die bereits im Verhalten spezifizierten Schutzziele und Benutzerrechte nicht immer direkt d h 1 1 auf die Anwen dungsf lle bernommen werden Schutzziele Bedrohungen Risiken und Ma nahmen m ssen gegebenenfalls f r die Anwendungsf lle erneut gepr ft und ermittelt werden In der Gesch ftsprozessmodellierung zugriffssicherer Systeme wurde das Schutzziel Authen tifikation nur f
88. ML Klassendiagrammen vor Die Bedeutung der Schutzziele wird im Kontext der Diagramme gegebenenfalls formal eingef hrt 92 Die Gesch ftsprozessmodellierung zugriffssicherer Systeme Als Basis f r eine Beschreibung der Zugriffs und Ausf hrungsrechte sind die an den Prozessen beteiligten Akteure zu ermitteln Hierfiir ist im Rahmen der Geschaftsprozessmodellierung ei ne Modellierung der Organisationsstruktur insbesondere der Bearbeiter durchzufiihren Zu den Bearbeitern lassen sich die Akteure in Form von abstrakten Rollen und deren Hierarchie in Bezug auf die Zugriffs und Ausf hrungsrechte bestimmen Die Zugriffsrechte auf die Daten des Dom nenmodells sowie Ausf hrungsrechte zu Gesch ftsprozessen sowie die Hierarchisie rung der Akteure wird im Abschnitt 6 3 betrachtet Abschnitt 6 4 stellt das Vorgehen bei der Gesch ftsprozessmodellierung zugriffssicherer Sy steme in Form eines Prozessmusters vor Die Anwendung des Sicherheitsmikroprozesses aus Abschnitt die im Rahmen der Gesch ftsprozessmodellierung zugriffssicherer Systeme durchzuf hren ist wird exemplarisch f r unsere TimeTool Fallstudie gezeigt Abschlie end betrachten wir im Abschnitt 6 5ldie Produktartefakte der Gesch ftsprozessmo dellierung zugriffssicherer Systeme Dabei gehen wir auf die Beziehung zu den Produktarte fakten der allgemeinen Gesch ftsprozessmodellierung n her ein 6 1 Allgemeine Gesch ftsprozessmodellierung Bevor wir auf die Besonderheiten
89. Methode zur Integration von Sicherheitsanforderungen in die Entwicklung zugriffssicherer Systeme Gerhard Popp Institut f r Informatik der Technischen Universitat Miinchen Methode zur Integration von Sicherheitsanforderungen in die Entwicklung zugriffssicherer Systeme Gerhard Popp Vollst ndiger Abdruck der von der Fakult t f r Informatik der Technischen Uni versit t M nchen zur Erlangung des akademischen Grades eines Doktors der Naturwissenschaften Dr rer nat genehmigten Dissertation Vorsitzender Univ Prof Dr J rgen Schmidhuber Pr fer der Dissertation 1 Univ Prof Dr Dr h c Manfred Broy 2 Univ Prof Dr Ruth Breu Leopold Franzens Universit t Innsbruck sterreich Die Dissertation wurde am 26 Januar 2005 bei der Technischen Universit t M n chen eingereicht und durch die Fakult t f r Informatik am 04 Juni 2005 ange nommen Kurzfassung Ziel der Entwicklung zugriffssicherer Systeme ist es die dem System anvertrauten Informatio nen vor unautorisiertem Zugriff zu sch tzen Wie Erfahrungen mit der Entwicklung zugriffs sicherer Systeme gezeigt haben reicht es nicht aus Aspekte der Zugriffssicherheit getrennt nach Fertigstellung des Designs zu betrachten da dazu oftmals gro e Teile des Designs ber arbeitet werden m ssen sodass dann Zeit und Kostenpl ne nicht eingehalten werden k nnen Nur zu oft werden die Anforderungen an die Zugriffssicherheit nicht erf llt sodass Systeme mi
90. Modifikationen an Assoziationen Attributen oder Operationen Da f r systemkritische Teile eine textuelle grob granulare Spezifikation von Benutzerrechten nicht ausreicht k nnen wir mit unserem Ansatz die vorab informal spezifizierten Rechte in eine fein granularere pr dikative Rechtespezifikation transformieren die die volle Ausdrucksm chtigkeit der Pr di katenlogik erster Stufe unterst tzt Benutzerrechte k nnen damit in beliebiger Granularit t auf der Basis von Methodenberechtigungen ber einer gegebenen Objektstruktur ausgedr ckt werden Basis f r diese Art von Berechtigungsausdr cken ist die mit einer formalen Semantik ausgestattete algebraische Sprache P MOS Sie erlaubt uns eine Beschreibung von Berechti gungsausdr cken ber Objekten Zust nden und Objektbez gen von einer gegebenen Menge von Objekten zu einem festen Zeitpunkt Besondere Bedeutung kommt bei einer derartigen Benutzerrechtebeschreibung den Akteuren zu Durch eine zugrunde liegende rollenbasierte Rechtemodellierung werden die Benutzerbe rechtigungen nicht einzelnen Personen sondern Rollen zugeordnet Im Grunde werden dann jeder Person eine oder mehrere Rollen zugeordnet und jede Rolle wird mit einer Menge von Berechtigungen verbunden Die Akteure k nnen dann durch eine eigens definierte Repr sen tierungsfunktion auf die innere Struktur der Anwender abgebildet werden F r eine verbesserte Anwendung des Ansatzes haben wir Methodenkategorien eingef hrt 52 Ak
91. Requirements through Misuse Cases In Proceedings of the Norsk Informatikkonferanse NIK 2001 2001 http www nik no 2001 Ian Sommerville Software Engineering Addison Wesley Longman Inc 2000 Jerome H Saltzer and Michael D Schroeder Protection of Information in Com puter Systems In Proceedings of the IEEE volume 63 pages 1278 1308 March 1975 http www cs virginia edu evans cs551 saltzer Josef Staud Gesch ftsprozessanalyse Ereignissgesteuerte Prozessketten und objektorientierte Gesch ftsprozessmodellierung f r Betriebwirtschaftliche Stan dardsoftware Springer Verlag zweite edition 2001 Veronika Thurner Formal fundierte Modellierung von Gesch ftsprozessen Gesch ftsprozesse anschaulich und pr zise dokumentieren Logos Verlag 2004 Monika Vetterling Security Engineering nach den Common Criteria Eine Fallstudie Master s thesis Technische Universit t M nchen August 2001 John Viega and Gary McGraw Building Secure Software How to Avoid Security Problems the Right Way Addison Wesley 2002 David von Oheimb and Volkmar Lotz Formal Security Analysis with Interac ting State Machines In D Gollmann G Karjoth and Waidner M editors Proceedings of the 7th European Symposium on Research in Computer Security ESORICS 2002 number 2502 in Lecture Notes in Computer Science pages 212 228 Springer Verlag 2002 Monika Vetterling Guido Wimmel and Alexander Wi peintner Secure Systems Devel
92. Systeme 8 1 Grundlagen der Analyse Bevor wir auf die Besonderheiten der Analyse zugriffssicherer Systeme eingehen geben wir einen berblick ber Ziele Aktivit ten und Produktartefakte der klassischen Analyse 8 1 1 Motivation In der Analyse werden die Systemanforderungen aus der Anwendungsfallmodellierung verfei nert und strukturiert Ziele der Analyse sind ein genaueres Verst ndnis der Anforderungen zu ermitteln und eine genaue Anforderungsbeschreibung zu erstellen Die Beschreibung muss einfach umzusetzen sein und sie muss die Struktur des gesamten Systems inklusive der Ar chitektur wiedergeben siehe JBR99 Bis jetzt wurden die Systemanforderungen gr tenteils textuell oder in einfachen Klassen und Aktivit tsdiagrammen spezifiziert Bei der Analyse werden diese Beschreibungen in die Sprache der Entwickler umgesetzt und verfeinert Hierbei sind formale oder semiformale Be schreibungen mit mehr Aussagekraft gegen ber textuellen Beschreibungen vorzuziehen Im Analysemodell werden die Anforderungen neu strukturiert sodass diese besser verstan den werden k nnen in Hinblick auf das Design geeigneter dargestellt sind und einfacher ab ge ndert werden k nnen Beispielsweise sind Abl uf nderungen in einem Sequenzdiagramm verst ndlicher und ersichtlicher als nderungen an einer textuellen Ablaufbeschreibung In den Anwendungsf llen werden Daten und Abl ufe teilweise noch redundant spezifiziert zum Beispiel werden in
93. Systeme ausgetauscht werden In diesen F llen sind die eigenen Prozesse mit dem Vorgehen in der Anforderungsspezifikation zugriffssicherer Systeme zu kombinieren der vorgestellte Ansatz ist durch die Anwendung von Prozessmustern jedoch f r derartige Anpassungen offen In Beziehung stehende Prozessmuster Auszuf hrender Teilprozess e Prozessmuster zur Anforderungsspezifikation zugriffssicherer Systeme siehe Abschnitt 5 3 2 5 3 2 Prozessmuster 5 2 Anforderungsspezifikation zugriffssicherer Systeme Kurzbeschreibung Nach der Startphase eines Softwareprojektes in der Projektmission und Sicherheitsziel geklart werden sind die Anforderungen zu definieren d h die Anforderungen sind zu ermitteln festzulegen und zu beschreiben zu analysieren und zu verabschieden vgl Bal96 Wie bereits erl utert wurde ist es f r die Entwicklung zugriffssicherer Systeme unabdingbar Sicherheit in der Entwicklung fr hzeitig bei der Frarbeitung der Anforderungsspezifikation zu betrachten Da sich die Ausarbeitung der Anforderungen ber mehrere Prozessabschnitte erstreckt und Sicherheitsaspekte jeweils in dem Prozessabschnitt behandelt werden m ssen in der sie ermittelt werden ist es notwendig alle Prozessabschnitte der Anforderungsspezifi kation mit Aspekten der Zugriffssicherheit anzureichern In diesem Prozessmuster zur Anforderungsspezifikation zugriffssicherer Systeme stellen wir die Prozessabschnitte der Anforderungsspezifikation zugriff
94. Systeme unterzogen wurden sind hier potenzielle Angriffe m glich Diese Erg nzungen sind bei der Analyse zugriffssicherer Systeme zu betrachten Da die Beschreibungen der Struktur und des Verhaltens ge ndert werden wird die Beschrei bung der Benutzerrechte inkonsistent Die Benutzerrechtespezifikation ist anzupassen L sung F r die durchg ngige und sukzessive Modellierung von Aspekten der Zugriffssicherheit sind die erarbeiteten Sicherheitsanforderungen aus dem Dom nenmodell und aus dem Anwen dungsfallmodell in die verfeinerte Struktur aus Fach Vorgangs und Interaktionsklassen zu transformieren und zu verfeinern Ermittlung von Analyse der Realisierung der en Bedrohungen Modellierung Architektur Anwendungsf lle MRa kann von protokolle en Benutzerrechten Abbildung 8 5 Die Aktivit ten der Analyse zugriffssicherer Systeme Bei der Verfeinerung der Anwendungsf lle sind die Anforderungen an die Zugriffssicherheit in die zu entwickelnden Szenarien zu integrieren F r die spezifizierten Schutzziele sind geeignete Anpassungen und Erg nzungen im Funktionsablauf und im Klassendiagramm durchzuf hren so sind beispielsweise f r eine sichere bertragung Klassen zur Verschl sselung einzuf hren und Methoden zur Verschl sselung der Daten im Ablauf aufzurufen F r die Realisierung der Anwendungsf lle sind Vorgangsklassen im Klassenmodell der Analyse mit aufzunehmen die sp ter den eigentlichen Ablauf in process Methoden beinha
95. Test durchf hren und protokollieren erstellen in CC Entwiirfe erstellen Vv Test vorbereiten a Vorliufiges D Benutzerhandbuch Benutzerhandbuch erg nzen erstellen m D Legende i allgemeine Vorl ufiges N Aktivit ten Systemverwalter i Systemverwalterhandbuch erg nzen ge nderte allgemeine handbuch erstellen P e Aktivit ten durch i Anwendung der CC C neue Aktivit ten aus Installations und Installations und Anwendung der CC Anlaufdokumente Anlaufprozeduren 2 i durchf hren i 1 Abbildung 5 3 Ein zu den Common Criteria konformes Vorgehen Als Grundlage fiir das CC Vorgehen wurde das klassische Wasserfallmodell aus gew hlt da es einfach strukturiert f r kleine Anwendungen geeignet ist und in Projekten angewendet werden kann in denen die Anforderungen zu Beginn der Entwicklung bekannt sind Dieses phasenorientierte Vorgehensmodell wurde mit den sicherheitsspezifischen Akti vit ten angereichert die zur Entwicklung eines sicheren Systems mit anschlie ender Evaluie rung nach den Common Criteria notwendig sind Abbildungl5 3lzeigt das um Sicherheitsaspek te abge nderte und erg nzte auf dem Wasserfallmodell basierte CC Vorgehen Dabei stellen 62 Ein Prozess zur Entwicklung von Anforderungsspezifikationen die wei hinterlegten Aktivit ten diejenigen Arbeitsschritte dar die in einem herk mmlichen Projekt ohn
96. Walker W Royce Managing the Development of Large Software Systems Pro ceedings IEEE WESTCON Los Angeles 14 1 9 August 1970 Reprinted in Pro ceedings of the Ninth International Conference on Software Engineering March 1987 pp 328 338 Peter Rechenberg and Gustav Pomberger editors Informatik Handbuch Carl Hanser Verlag 1997 Josef Rupprecht Datensicherheit im Data Warehousing Technical Report BE HSG CC DW2 06 Universit t St Gallen September 2002 Ravi Sandhu Role Hierarchies and Constraints for Lattice Based Access Con trols In Proceedings of the European Symposium on Research in Security and Privacy 1996 206 Literaturverzeichnis Sch92 Sch99 Schoo Sil04 S001 Som00 S875 Sta01 Thu04 Vet01 VM02 vOL02 vwwo2 WEIOA Wik August Wilhelm Scheer Architektur integrierter Informationssysteme Grund lagen der Unternehmensmodellierung Springer Verlag second edition 1992 August Wilhelm Scheer ARIS Vom Gesch ftsproze zum Anwendungssystem Springer Verlag 1999 Bruce Schneier Secrets and Lies Digital Security in a Networked World John Wiley amp Sons Inc 2000 Silicon de BKA verzeichnet Anstieg der Computerkriminalit t Aufkl rungs quote sinkt Newsletter vom 04 Mai 2004 http www silicon de cpo news itsecurity detail php nr 14478 amp kategorie news itsecurity Guttorm Sindre and Andreas L Opdahl Capturing Security
97. Yourdon Object Oriented Analysis Yourdon Press Englewood Cliffs second edition 1991 Peter Coad and Edward Yourdon Object Oriented Design Yourdon Press Englewood Cliffs 1991 Ernst Denert Software Engineering Springer Verlag 1991 Martin Deubler Dienst orientierte Softwaresysteme Anforderungen und Ent wurf PhD thesis Technische Universitat Miinchen 2005 To appear Martin Deubler Johannes Griinbauer Gerhard Popp Guido Wimmel and Chri stian Salzmann Tool Supported Development of Service Based Systems In Proceedings of the 11th Asia Pacific Software Engineering Conference APSEC 2004 Busan Korea November 30 December 3 pages 99 108 IEEE Computer Society 2004 Martin Deubler Johannes Griinbauer Gerhard Popp Guido Wimmel and Chri stian Salzmann Towards a Model Based and Incremental Development Process for Service Based Systems In M H Hamaza editor Proceedings of the IA STED International Conference on Software Engineering I ASTED SE 2004 Innsbruck Austria Februar 17 19 pages 183 188 2004 Shreyas Doshi Software Engineering and Security Towards Architecting Secure Software Term Paper for ICS 121 University of California 2001 Desmond F D Souza and Alan C Wills Objects Components and Frameworks With UML The Catalysis Approach Addison Wesley Publishing Company 1998 Wolfgang Dr schel and Manuela Wiemers editors Das V Modell 97 Oldenbourg Wissenschaftsverlag GmbH 1999 C
98. Zugriffssi cherheit die Techniken zur Realisierung ausgew hlt Hierbei wurde bereits festgelegt welche Technik anzuwenden ist Authenticate With Chipcard Authenticate A Chipcard Terminal Team Worker ChipcardUI Aa ss gt tCardl putCardIn le getChipNumber CardNumb ardNumber gt le askRandom RandomNumber encrypt key randomTerminal randomChip le encrypt key randomTerminal randomChip Bie ae Enten En EEE EN Abbildung 8 3 Protokoll zur Authentifikation mittels Chipkarte und Terminal 8 3 Integration von Sicherheitsprotokollen 183 Der genaue Ablauf wurde jedoch noch nicht beschrieben Bei der weiteren Verfeinerung zur Realisierung der Anwendungsfalle sind nun die konkreten Protokolle und Techniken aus zuw hlen Dabei sind zwei F lle zu unterscheiden e Es existieren Protokolle die zur Abdeckung der Zugriffssicherheit in das Analysemo dell des zu entwickelnden Systems aufgenommen werden k nnen Gegebenenfalls sind Interaktions Vorgangs und Fachklassen zum Klassenmodell der Analyse hinzuzuneh men Der genaue Protokollablauf muss nicht spezifiziert werden da im Design und in der Implementierung eine fertige Komponente eingesetzt wird Hierbei kann es sich um eine Wiederverwendung aus einem bestehenden Softwareprodukt um freien Code oder um eine Zukaufkomponente handeln F r ein oder mehrere Protokolle k nnen ein oder mehrere Analyse Packages definier
99. a account online A account offline prepare _ E _________ Monthly CT le monthly report SEC Accounts LSEC Abbildung 6 16 TimeTool Gesch ftsprozess mit Schutzzielen im Objektfluss Abbildung zeigt einen TimeTool Gesch ftsprozess mit Objektfluss Stundenbuchungen k nnen offline beispielsweise auf einem Notebook eingetragen werden Vor der bertragung dieser Buchungen auf den Server muss sich das auf dem Notebook ausgef hrte Offline Stun denbuchungssystem beim Server authentifizieren Abbildung zeigt einen weiteren Gesch ftsprozess aus unserer TimeTool Fallstudie mit Betrachtung des Objektflusses In diesem Gesch ftsprozess wurden auch f r manuelle Akti vit ten Schutzziele vergeben zum Beispiel Aktivit t sum up testing time Dieses Beispiel zeigt dass nicht nur automatisierbare Vorg nge mit den vorgestellten Techniken mit Schutz zielen annotiert werden k nnen Bei der Entwicklung von zugriffssicheren Systemen ist zu beachten dass die Integration von Sicherheit in Systemen auch angrenzende Arbeiten und Systeme betreffen muss Was n tzt die beste Sicherung von Daten im System wenn diese au erhalb des Systems offen liegen und ungesch tzt verarbeitet werden 110 Die Gesch ftsprozessmodellierung zugriffssicherer Systeme Team Worker System Project Manager perform E testing SEC sum up 1 testing time SEC a nt insertnew CIN
100. a auf enthalten O ACActor pe PCActivity ol Object 1 02 Object 2 03 Object 3 f process N f a f m y f N f 3539 f E a Abbildung 7 10 Exemplarischer Funktionsablauf Als Beispiel betrachten wir den gegebenen Ablauf aus Abbildung mit den Methoden fo fs In der Relation RP notieren wir alle Methodenaufrufe die erreichbar sind und somit f r die Ermittlung der Berechtigungen herangezogen werden k nnen RP fo fi fo f2 fo fs f3 fa F3 5 fo Fa fo fs Die ersten f nf Elemente sind die im Beispielablauf eingetragenen Methodenaufrufe Durch die Transitivit t sind von der Methode fo auch diejenigen Methoden erreichbar die ber die Methode f3 aufgerufen werden Nachdem wir die Menge der Methodenaufrufe in der Menge RP festgelegt haben ist aus dieser Menge die Berechtigung des Ablaufs der Aktivit t bzw des Anwendungsfalls zu berechnen Wir spezifizieren die Rechte f r eine Methode m welche den Ablauf des Anwendungsfalls und somit der Aktivit t widerspiegelt im Falle einer 1 Zuordnung Da zur Ausf hrung des Anwendungsfalls bzw der Aktivit t die Benutzerrechte von allen im Anwendungsfall aufgerufenen Methoden erf llt sein m ssen k nnen wir die Berechtigung eines Anwendungsfalls mithilfe der logischen UND Verkn pfung berechnen perm om AC Actor C T In N perm Mg My mit Y Mz my E RP permo m
101. all own accountings E from released activities PCConfirmAdjustment E E all accountings of activities of own projects where the project manager is not the team worker who has done the accounting adjustment Die dynamische Aufgabentrennung l sst sich durch das folgende Pr dikat ausdr cken Vpm ACProject Manager Va Accounting Vpc PC AdjustAccounting V pco PCConfirmAdjustment a activity project projectmanager pm rolerep A Jtw ACTeamW orker pc process tw A tw rolerep pm rolerep gt perm PCConfirmAdjustment process pm Pc2 a Die Berechtigung des Projektmitarbeiters zur Aktivit t adjust accounting wurde bereits bei der Objektstruktur Permission eingef hrt Sie ist hier Voraussetzung f r die dynamische Auf gabentrennung Anmerkung zur statischen Aufgabentrennung Neben der dynamischen gibt es auch die statische Aufgabentrennung Hierbei wird die Rollen mitgliedschaft nicht nur f r einen einzelnen Ablauf beschr nkt sondern die hier festgelegte Aufgabentrennung gilt global Bei der statischen Aufgabentrennung wird die gleichzeitige Mitgliedschaft in verschieden Rollen ausgeschlossen Eine Person darf nur dann Mitglied un terschiedlicher Rollen sein wenn sich die den Rollen assoziierten Aufgaben wechselseitig nicht ausschlie en vgl Eck03 Abbildung zeigt ein Szenario zur statischen Aufgabentrennung Wie aus dem Ablaufdia gramm hervorgeht darf ein Projektmitarbeiter kein
102. als Kommunikationsbasis f r Prozessanalysten und Pro jektmitarbeiter e In den Erg nzungen werden wichtige Informationen zum Gesch ftsbereich sowie zum Kontext dokumentiert Im Glossar werden Begrifflichkeiten und die vereinbarte Terminologie festgehalten e Die Regeln beschreiben globale Regeln und Beschr nkungen die bei der Entwicklung des Systems eingehalten werden m ssen Abbildung 6 1 zeigt eine erste Version des Dom nenmodells zu unserer TimeTool Fallstudie Hierbei wurden zentrale Gesch ftsobjekte beispielsweise Project Activity und Accounting sowie Objekte der realen Welt zum Beispiel Administrator Team Worker modelliert und in einem Klassendiagramm dargestellt Abbildung 6 2 zeigt einen exemplarischen Gesch ftsprozess zur TimeTool Fallstudie als Teil des Gesch ftsprozessmodells 96 Die Gesch ftsprozessmodellierung zugriffssicherer Systeme 6 2 Spezifikation der Schutzziele in Struktur und Verhalten Wie wir in Kapitel 5 bereits erl utert und als Anforderung an den Prozess zur Entwicklung von sicheren Systemen definiert haben ist es f r eine durchg ngige und integrierte Entwick lung notwendig dass Sicherheit bereits bei der Erarbeitung der Funktionalit t betrachtet wird Damit die in den fr hen Phasen erarbeiteten Anforderungen an die Sicherheit geeignet dokumentiert werden k nnen ben tigen wir ad quate Beschreibungstechniken f r die Anno tation von Sicherheitsanforderungen im Kontext der grafis
103. als Objektinteraktionsdiagramm Fiir die Anforderung an die Zugriffssicherheit A1 aus der strukturellen Beschreibung des Sicherheitsanwendungsfalls in Abbildung 7 8 wur den Objekte der Vorgangsklasse SecureConnection und der Fachklasse Key in das Szenario aufgenommen Zur Beweissicherung von Anderungen Anforderung A an den Accounting Eintr gen wurde die Fachklasse Logging im Analyseklassendiagramm bestimmt die bereits bei der Ermittlung der Bedrohungen Risiken und Ma nahmen innerhalb der Gesch ftspro zessmodellierung ermittelt wurde In ihr werden vor der nderung von Buchungsdaten die alten Buchungsdaten gespeichert Durch die gerichteten Assoziationen wird der Informations fluss abstrakt beschrieben F r die Anforderungen A2 Projektmitarbeiter muss authentifiziert sein und A3 Web Browser und TimeTool System m ssen gegenseitig authentifiziert sein aus der Beschreibung des Sicherheitsanwendungsfalls sind eigene Szenarien zu entwerfen Sie sind als Vorbedin gung f r das Szenario zur Korrekturbuchung auszuf hren Diese Vorbedingungen werden als Kommentare im Objektinteraktionsdiagramm und im Sequenzdiagramm in Abbildung dargestellt Alle nderungen im Objektdiagramm die sich aus der Verfeinerung der Sicher heitsaspekte aus dem Anwendungsfall Korrekturbuchung ergeben sind in Abbildung 8 2 grau hinterlegt 8 3 Integration von Sicherheitsprotokollen Bei der Realisierung der Anwendungsf lle wurden zu den ermittelten Aspekten der
104. alyse entwickelt wird h ngt von allen anderen Produktartefakten der Anforderungsspezifikation zugriffssicherer Systeme ab ist aber keine zwingende Voraussetzung f r die Erarbeitung der anderen Produktartefakte Die Beziehungen zwischen den Produktartefakten werden bei der Diskussion der Prozessab schnitte der Anforderungsspezifikation zugriffssicherer Systeme in den Kapiteln 6 bis 8 dis kutiert 5 5 Abdeckung der Prozessanforderungen Zu Beginn dieses Kapitels haben wir im Abschnitt existierende Vorgehensmodelle zur Entwicklung sicherer Systeme betrachtet und aus den Bewertungen dieser Vorgehensmodelle Prozessanforderungen zur Entwicklung zugriffssicherer Systeme vgl Abschnitt abgelei tet Nachdem wir im vorausgehenden Abschnitt das Vorgehen f r eine Anforderungsspe zifikation zugriffssicherer Systeme vorgestellt haben untersuchen wir im Folgenden f r den vorgestellten Prozess die Abdeckung der Prozessanforderungen Wie bereits erw hnt sind 5 5 Abdeckung der Prozessanforderungen 87 die vorgestellten Prozessanforderungen fiir einen gesamten Prozess zur Entwicklung sicherer Systeme giiltig Da wir uns im Rahmen dieser Arbeit auf die Phase der Anforderungsspe zifikation zugriffssicherer Systeme beschr nken bewerten wir nur f r diesen Ausschnitt die Abdeckung der Prozessanforderungen Durchg ngige Sicherheitsbetrachtungen SPA1 Ein zentrales Problem bei der Entwicklung von zugriffssicheren Systemen liegt darin dass Sic
105. amkeiten festzustellen Wir k nnen nun zwischen denjenigen Aktivit ten unterscheiden die zur berpr fung der Authentifikation eingef hrt wurden und denjenigen die vorab mit dem Stereotyp Authenticity annotiert wur den Bei allen Aktivit ten die mit dem Schutzziel Authenticity gekennzeichnet wurden muss vor der Ausf hrung berpr ft werden inwiefern der ausf hrende Akteur autorisiert ist die Authentifikation wird jeweils separat ausgef hrt und im Folgenden auch separat spezifiziert Aus den Aktivit ten zur Authentifikation sind im weiteren Verlauf der Anwendungsfallmodel lierung zugriffssicherer Systeme die Anwendungsf lle zur Authentifikation Anwendungsf lle zum Login und Logout auszuarbeiten siehe Abschnitt 7 3 Abbildung 7 7 zeigt die Verfeinerung des in Abbildung dargestellten Ablaufs zur Time Tool Fallstudie Wir beschr nken und dabei auf den Akteur Administrator Die im exemp larischen Ablauf sequenziell ausgef hrten Aktivit ten create new project create project ac tivities backup project und administrate user data k nnen bei der Anwendung in beliebiger Reihenfolge ausgef hrt werden Alle diese Aktivit ten k nnen nur nach einer erfolgreichen Au thentifizierung am System aufgerufen werden bei der Aktivit t administrate user data muss vorab nochmals eine spezielle Authentifikation ausgef hrt werden Die grau hinterlegten Ak tivit ten stellen die Aktivit ten zur Authentifizierung bei den wei hinterlegten A
106. anuelle Aktivit ten sind aus dem Modell zu entfernen Insbeson dere die Entfernung von einzelnen Aktivit ten erfordert die berarbeitung der Abl ufe Anpassung des Dom nenmodells Das Dom nenmodell muss an die im System umzusetzenden Abl ufe angepasst werden Klassen zu Daten die aufgrund der Streichung von Gesch ftsabl ufen und Aktivit ten im Dom nenmodell nicht gespeichert werden m ssen sind zu entfernen Klassen Be ziehungen und Attribute des Dom nenmodells sind nach der Entfernung von unn tigen Elementen anzupassen Anpassung des Akteurmodells Die Festlegung der automatisierbaren Abl ufe erfordert weiterhin eine Anpassung des Akteurmodells Durch das Entfernen von Gesch ftsabl ufen sind gegebenenfalls auch Akteure aus dem Akteurmodell zu entfernen Da innerhalb der Gesch ftsprozessmo dellierung zugriffssicherer Systeme die Akteure in Bezug auf die Spezifikation der Be nutzerrechte hierarchisch angeordnet wurden vgl Abschnitt 6 3 1 ist die Hierarchie anzupassen d h L cken in der Hierarchie sind zu schlie en oder die Hierarchie ist neu anzuordnen Da durch die Festlegung der im System umzusetzenden Funktionalit t auch die Grenzen des Systems sowie externe Softwaresysteme und Hardware definiert werden k nnen sind auch die externen Systeme als Akteure im Akteurmodell aufzunehmen Modellierung von Sitzungen Bei zugriffssicheren Systemen m ssen sich Anwender zumeist nicht vor der Ausf hrung von einzelnen sicherh
107. arauf folgende fachliche Strukturierung mit Umsetzung der Ma nahmen aus dem Sicherheitskonzept Die Sicherheitsaspekte werden einerseits verschr nkt mit der Funktionalit t entwickelt an dererseits wird die Sicherheit nicht lokal bei der Bearbeitung der operationalen Aspekte spe zifiziert Auf Aktivit ten der funktionalen Modellierung folgen Aktivit ten zur Sicherheits modellierung und umgekehrt Aber innerhalb kleiner Bearbeitungsschritte wie beispielsweise der Ausarbeitung einer kleinen funktionalen Einheit werden hierzu nicht sofort die lokal auf tretenden Sicherheitseigenschaften analysiert Sicherheitsaspekte werden bei der Bearbeitung von funktionalen Einheiten spezifiziert Nach diesem Ansatz werden jedoch sicherheitsrele vante Erkenntnisse die sich bei der detaillierten funktionalen Modellierung ergeben vorerst ber Bord geworfen und m ssen anschie end nochmals erarbeitet werden W nschenswert w re hier dass die Erkenntnisse bereits vorab spezifiziert werden und in einem nachfolgenden Schritt bei der Bearbeitung von gr eren funktionalen Einheiten nochmals bez glich Konsis tenz und Vollst ndigkeit berpr ft bzw nachgebessert werden Im Vordergrund bei der Beschreibung von SEC stehen die Aktivit ten die zur Sicherheitsmo dellierung durchgef hrt werden Produktartefakte die w hrend der Sicherheitsmodellierung anzufertigen sind werden nicht angegeben sodass eine durchg ngige Entwicklung von Ar tefakten nic
108. as folgende Pr dikat spezifiziert Vac Accounting V u User inhaber ac u amp ac u accounting Referenziert ein Benutzer User also eine Buchung Accounting dann ist er der Inhaber der Buchung Die Konsistenz dieser Spezifikation ist dadurch gew hrleistet dass jede Buchung von genau einem Benutzer referenziert wird 4 3 2 P MOS Pr dikate Basierend auf der vorab definierten Struktur der P MOS Ausdr cke lassen sich in gewohnter Form Pr dikate bilden Die Struktur der Pr dikate wird in Tabelle 4 1 zusammengefasst Die Quantoren in den Pr dikaten beziehen sich auf alle zum gegebenen Zeitpunkt existierenden Objekte Tabelle 4 1 P MOS Pr dikate P MOS Pr dikat Elementbeschreibung el e2 el e2 P MOS Ausdr cke gleichen Typs P P1IVP2 PINP2 PI gt P2 PI gt P2 P P1 P2 Pr dikate Ve T P 3x T P P Pr dikat x Variable und T Typausdruck Beispiel Die folgende informal angegebene Invariante die global im Time Tool System erf llt sein muss wird durch das unten angegebene Pr dikat formalisiert Invariante Zu allen Buchungen muss der zugeordnete Benutzer Mitglied des bergeordneten Projektes sein Va Accounting a user a activity project user Wenn alle im Pr dikat verwendeten Variablen in Quantoren gebunden sind sprechen wir von geschlossenen Pr dikaten Freie Variablen hei en diejenigen nicht durch Quantoren gebun denen Variablen 4 4 Formale Modellierung von Benutzerrechten D
109. assendiagramm der Analyse wurde zur Umsetzung der Sicherheitsaspekte um Vorgangs und Fachklassen erg nzt und in die Szenarien wurden die Sicherheitsaspekte funktional interpretiert Durch das vorgestellte Verfahren auch die Prozessanforderung der lokalen Spezifikation d h die Spe zifikation von Aspekten der Zugriffssicherheit mit den funktionalen Anforderungen erf llt da die Sicherheitsaspekte in den verschiedenen Abschnitten in kleinen Einheiten ermittelt und dokumentiert werden Es muss also nicht abschlie end ein eigenst ndiger Prozess zur Modellie rung der Sicherheit ablaufen Die iterative Entwicklung wird durch die zahlreich aufgezeigten Iterationsm glichkeiten unterst tzt Anhand der durchg ngigen Fallstudie dem Projektverwaltungssystem TimeTool wurden die erarbeiteten Konzepte illustriert und deren Anwendbarkeit demonstriert Die in dieser Arbeit vorgestellte akteurzentrierte Spezifikation von Benutzerrechten wurde be reits in Fallstudien f r ein Gesundheitsinformationssystem und f r eine E Government L sung erfolgreich angewandt Der Ansatz wird in mehreren Richtungen weiterentwickelt Erstens wird an der Universit t Innsbruck an einer Werkzeugunterst tzung zum vorgestellten Kon zept geforscht sodass Methodenberechtigungen Akteurspezifikationen und Kategorien mit Kategorieberechtigungen innerhalb eines UML Tools zur Verf gung stehen Weiterhin wird der Spezifikationsansatz f r den Einsatz in implementierungsorientierten
110. bene Ausf hrungsrecht ersetzt An der Ermittlung der Berechtigung des Ablaufs m ssen ansonsten keine weiteren nderungen vorgenommen werden Die explizite Angabe eines Ausf hrungsrechts f r einen Teilablauf spielt insbesondere dann eine Rolle wenn im Teilablauf eine Steigerung des Werts der Information erfolgt siehe hierzu Grenzen der Berechenbarkeit von Ausf hrungsrechten weiter oben in diesem Abschnitt Anstelle der zu berechnenden Berechtigung wird die zumeist st rker beschr nkende explizit spezifizierte Berechtigung f r die weitere Ermittlung verwendet 7 5 Der Prozess der Anwendungsfallmodellierung zugriffssicherer Systeme In diesem Kapitel haben wir bereits einzelne Aktivit ten zur Erarbeitung und Verfeinerung von Aspekten der Zugriffssicherheit innerhalb der Anwendungsfallmodellierung zugriffssiche rer Systeme vorgestellt Im Folgenden zeigen wir die Eingliederung dieser Aktivit ten in den Prozess Abschnitt sowie die erneute Anwendung des Sicherheitsmikroprozesses Ab schnitt 7 5 2 164 Die Anwendungsfallmodellierung zugriffssicherer Systeme 7 5 1 Prozessmuster 7 1 Anwendungsfallmodellierung zugriffssicherer Systeme Kurzbeschreibung Kernziele der Anwendungsfallmodellierung sind die Transformation der im System umzuset zenden Gesch ftsprozesse in Anwendungsf lle und die Erweiterung des Dom nenmodells F r eine durchg ngige und sukzessive Entwicklung der Zugriffssicherheit sind die bereits ermittel t
111. beschreibt dabei den Entwicklungsprozess aus funktionaler Sicht und geht nicht auf spezielle Organisationsformen verschiedenster Einrichtungen bzw Firmen ein da es dadurch den Anspruch des universellen Einsatzes gerecht werden will Weiterhin ist esin 4 Submodelle gegliedert die sich mit den Aspekten der Systemerstellung SE der Qualit ts sicherung QS des Konfigurationsmanagements KM und des Projektmanagements PM besch ftigen W hrend sich das Submodell QS verst rkt mit der Evaluierung von Systemen besch ftigt liegt unser Interesse im Submodell SE da hier die Entwicklung beschrieben wird Im Folgenden geben wir deshalb einen Abriss der sicherheitsspezifischen Aspekte aus dem Submodell der Systemerstellung In der System Anforderungsanalyse sind nach SEC eine Ist Aufnahme Ist Analyse durchzu fiihren das Anwendungssystem zu beschreiben die Bedrohungen und Risiken zu analysieren sowie das System fachlich zu strukturieren In einer Ist Aufnahme Ist Analysephase sind falls in einem vorhandenen System bereits Sicherheitsma nahmen existieren diese hinsicht lich eines neu vorgegebenen Sicherheitsziels und einer ver nderten Einsatzumgebung vorab zu analysieren und zu bewerten Bei der Beschreibung des Anwendungssystems ist zus tzlich zu den operationellen Anforderungen an das System das Sicherheitsziel vom Auftraggeber vorzu geben Dieses stellt die Grundlage f r die Entwicklung der Sicherheitsanforderungen dar die in der Phase der B
112. bewirkt eine Anpassung der Gesch ftsabl ufe Sowohl die se nderungen wie auch die berf hrung der Aktivit ten der Gesch ftsprozesse in Anwen dungsf lle erfordern an den spezifizierten Abl ufen eine erneute berpr fung von Aspekten der Zugriffssicherheit Mithilfe des Sicherheitsmikroprozesses k nnen potenzielle Angriffsziele ermittelt und fr hzeitig geeignete Ma nahmen zur Abwehr entwickelt werden Neben der Analyse der Anwendungsf lle ist die Modellierung des Schutzziels Authentifika tion in der Anwendungsfallmodellierung zugriffssicherer Systeme zentral F r die eigentliche berpr fung der Echtheit und Glaubw rdigkeit der Akteure werden Aktivit ten zur Au thentifikation in die Gesch ftsprozesse aufgenommen In Hinblick auf die Autorisierung der Akteure sind Vorbedingungen in die Anwendungsf lle aufzunehmen F r die Modellierung des Schutzziels Authentifikation sind UML Aktivit tsdiagramme um Beschreibungstechniken f r Sitzungen und Authentifikation zu erweitern Zur Beschreibung von Anforderungen der Zugriffssicherheit in Anwendungsf llen wird die strukturelle Beschreibung erweitert f r die Beschreibung von angewendeten Sicherheitsgrundfunktionen wie beispielsweise die verwen deten Authentifikationstechniken sind so genannte Sicherheitsanwendungsf lle zur Anforde rungsspezifikation hinzuzuf gen Durch die Spezifikation von Aspekten der Zugriffssicherheit bei der Entwicklung der An wendungsf lle werden auch die Zi
113. bilit t f r Spezifikationen jeglicher Art von Benutzerbedingungen in allen Phasen der Entwicklung zur Verf gung Jedoch ben tigen wir f r die praktische Anwendung einen Integrationsmechanis mus zur Unterst tzung von grob granulareren Spezifikationen Deshalb f hren wir den Begriff der Methodenkategorie ein Eine Methodenkategorie CAT ist eine Menge von Methoden CAT C METH wobei METH die Menge aller Methoden im System ist Die Methoden sind dabei durch die Klassen sortiert zu denen sie geh ren Kategorien k nnen eine Menge von Methoden einer einzelnen Klasse oder eine Menge von Methoden mehrerer Klassen sein Falls eine Kategorie nur aus Methoden einer einzelnen Klasse besteht verwenden wir den Klassennamen als Index 48 Akteurzentriertes Modell zur Spezifikation von Benutzerrechten der Kategorie Dar ber hinaus k nnen Kategorien auch andere Kategorien mit einschlie en sodass Kategorien hierarchisch strukturiert werden k nnen Wir definieren grob granulare Berechtigungen perm Cato AC Actor C Bool f r jede Kategorie Catc welche Methoden der Klasse C enth lt Kategorieberechtigungen enthalten Methodenberechtigungen in bekannter Weise Va AC Actor o C a Ti an Tn perm Catola 0 gt perm C m a 0 Q1 Qn f r alle Methoden m von Klasse C in der Kategorie Catc Diese Kategorieberechtigungen k nnen nur vom Akteur und dem aktuellen Objekt abh ngen Falls eine Kategorie Cat Methoden von verschiedenen K
114. bjekte vorausgesetzt Weiterhin m ssen die Benutzerrechte in einer Benutzerrechtematrix spezifiziert werden Der Fokus dieser Anwendungsfallmodellie rung zugriffssicherer Systeme liegt auf einer Neuentwicklung eines betrieblichen Informati onssystems Aktivit ten zur Analyse bestehender Systeme sind kein Bestandteil dieses Pro zessmusters Neben den Entwicklungsschritten sind auch projektiibergreifend Managementaufgaben durch zuf hren auf die jedoch im Rahmen dieses Prozessmusters nicht n her eingegangen wird Struktur Innerhalb der L sung wurde bereits der Ablauf der Anwendungsfallmodellierung zugriffssi cherer Systeme skizziert Im Aktivit tsdiagramm in Abbildung 7 13list der verfeinerte Ablauf dargestellt Zudem werden auch geeignete Iterationsm glichkeiten aufgezeigt Bei der Entwicklung der Anwendungsf lle k nnen die Anwendungsf lle in Inkrementen aus gearbeitet werden Die Iterationsm glichkeiten des Ablaufs der Anwendungsfallmodellierung 170 Die Anwendungsfallmodellierung zugriffssicherer Systeme Zu automatisierende Prozesse festlegen Anpassung des Dom nenmodells Anpassung des Akteurmodells Anpassung der Prozesse Analyse von Authentifikation und Autorisierung Modellierung von Sitzungen Analyse der Anwendungsf lle Priorisierung der Anwendungsf lle Erg nzung des Dom nenmodells Entwicklung der Sicherheits anwendungsf l
115. bstraktum das in Form von Daten bzw Datenobjekten repr sentiert wird Die Information die durch ein Datum repr sentiert wird ergibt sich aus einer festgelegten Interpretationsvorschrift Sicherheit Die Funktionssicherheit engl safety ist der Zustand eines Systems frei von unvertretbaren schadenverursachenden Risiken zu sein Das System ist frei von Gefahren die vom Betrieb der Hardware oder Software ausgehen und die der Umwelt drohen DIN EN 61508 4 Anders ausgedr ckt ist die Funktionssicherheit die Sicherheit gegen Fehler und unbeabsich tigte Unf lle Ein Unfall ist dabei ein unerw nschtes und ungeplantes nicht unbedingt un erwartetes Freignis welches einen Grad von Verlusten zur Folge hat Ein Verlust ist eine Zerst rung oder Sch digung von Einrichtungen bzw Systemen oder Verletzung bzw Tod von Lebewesen insbesondere von Menschen Ein Fehler in einem System ist ein Zustand der durch Anregungen aus der Umwelt des Systems zu einem Unfall oder Verlust f hren kann Die Informationssicherheit engl security ist die Eigenschaft eines funktionssicheren Sys tems nur solche Systemzust nde anzunehmen die zu keiner unautorisierten Informations ver nderung oder gewinnung f hren Die Zugriffssicherheit ist die Eigenschaft eines funktionssicheren Systems nur solche Sy stemzust nde anzunehmen die zu keinem unautorisierten Zugriff auf Systemressourcen und Daten f hren Hierbei m ssen die Schutzziele Vertraulichkeit In
116. ch tzenden Attribute bilden eine unechte Teilmenge der Klassenattribute 100 Die Gesch ftsprozessmodellierung zugriffssicherer Systeme Project 1 Activity name String plannedStart Timestamp budget Real plannedEnd Timestamp realStart Timestamp realEnd Timestamp plannedHours Real 1 TeamWorker E 1 Accounting name String accountDate Timestamp address String requiredHours Real L i ai readAccountDate P 8 readRequiredHours userid String readAddress readPswd readUserid Abbildung 6 6 Schutzziel Vertraulichkeit in TimeTool Gesch ftsobjekten 6 2 1 2 Schutzziel Integrit t im Klassendiagramm Seien A T1 An Tn Attribute der Klasse C T ist entweder Klassenname oder ein Basistyp Falls die Klasse C mit dem Schutzziel Stereotyp lt Integrity gt annotiert wird gibt es eine Teilmenge A Ths Aim Tim der Attribute der Klasse C deren schreibender oder erzeugender Zugriff eingeschr nkt ist F r den schreibenden Zugriff f hren wir Schreib Zugriffsmethoden funct writec a a AC Actor oi Ta funct writeo x a AC Actor Oin Tim ein die einen schreibenden Zugriff auf ein Attribut A genau dann erlauben wenn die zu geh rige Schreibberechtigung permc writec Au AC Actor C T f r den Akteur erf llt ist Wir erweitern die Relation protect f r die Zuordnun
117. ch in der funktionalen Modellierung angewen det werden jedoch w ren hierzu einige Ab nderungen am Prozessmuster n tig Da wir uns im Rahmen dieser Arbeit auf objektorientierte Vorgehensweisen und Beschreibungstechniken beschr nken gehen wir auf diese Ab nderungen nicht weiter ein 5 3 Das Vorgehen 83 Schutzziele bereits ermittelt Schutzziele nicht ermittelt Untersuchung der Schutzziele Modellierung der Bedrohungen Bewertung der Risiken Entwurf von berpr fung der Ma nahmen Ma nahmen Ma nahmen unwirksam Ma nahmen geeignet Abbildung 5 9 Der Ablauf des Sicherheitsmikroprozesses Das Anwendungsgebiet des Sicherheitsmikroprozesses ist durch das Prozessmuster zur Anfor derungsspezifikation zugriffssicherer Systeme im Abschnitt 5 3 2 vorgegeben das eine gemein same Entwicklung von Funktionalit t und Sicherheit unterst tzt Der vorgestellte Sicherheits mikroprozess kann somit nicht in einer ganzheitlichen Entwicklung der Sicherheit eingesetzt werden da hierbei eine Aufteilung der Sicherheit des Systems in kleinere handhabbarere Einheiten notwendig w re die vom vorgestellten Prozess nicht unterst tzt wird In Beziehung stehende Prozessmuster bergeordnete Prozesse e Prozessmuster zur Gesch ftsprozessmodellierung zugriffssicherer Systeme siehe Ab schnitt e Prozessmuster zur Anwendungsfallmodellierung zugriffssicherer Systeme siehe hierzu Abschnitt
118. ch wird Betreibern und Anwendern ein mit der Klassifikationsstufe festgelegtes Ma an Sicherheit zugesichert Bewertung Dieses phasenstrukturierte Vorgehensmodell betrachtet Sicherheitsaspekte durchgehend Im Gegensatz zu den blichen Entwicklungspraktiken wird bereits in den fr hen Phasen die Sicherheit systematisch erarbeitet Hierzu sind in dem vorgestellten Prozess explizit Phasen zur Ermittlung von Bedrohungen und Risiken sowie zur Entwicklung einer Sicherheitsstrategie und eines modells eingef hrt worden Aspekte der Sicherheit werden ber allen Phasen strukturiert erarbeitet aus den Bedrohun gen und Risiken wird systematisch eine Sicherheitsstrategie und ein Sicherheitsmodell erar beitet welches in eine Architektur transformiert wird Abschlie ende Tests und eine m gliche Evaluierung folgen dieser strukturierten Erarbeitung Bedrohungsb ume mit Attributierung der Risiken werden zur vollst ndigen Ermittlung der Bedrohungen und Risiken verwendet Zur Abwehr der Bedrohungen sind bei der Entwicklung der Sicherheitsstrategie und des Si cherheitsmodells geeignete Ma nahmen zur Abwehr der Bedrohungen zu ermitteln und im 56 Ein Prozess zur Entwicklung von Anforderungsspezifikationen Entwurf zu integrieren Durch eine derartige strukturierte Entwicklung und Umsetzung der Sicherheitsanforderungen k nnen zugriffssichere Systeme entwickelt werden Dieses phasenorientierte Vorgehen trennt jedoch in den fr hen Phasen der Entwicklung
119. chen Beschreibungssprache UML In diesem Abschnitt f hren wir derartige Beschreibungstechniken in Form von annotierten Schutzzielen zu den zentralen Produkten der Gesch ftsprozessanalyse dem Dom nenmodell und den Gesch ftsprozessen ein Bei der Erarbeitung der Gesch ftsprozesse und Gesch ftsobjekte sind die Ziele festzuhalten die bei einem Angriff verletzt werden k nnen Hierzu annotieren wir die potenziellen An griffsziele auf der Granularit t von Klassen und Aktivit ten mit Schutzzielen Durch diese Annotation modellieren wir die Schutzbed rftigkeit der Objekte und Abl ufe Bei der Analyse der potenziellen Angriffe beschr nken wir uns auf die Verletzung der Schutz ziele Vertraulichkeit Integrit t und Verbindlichkeit Auf das Schutzziel Authentizit t gehen wir im Rahmen der Gesch ftsprozessmodellierung nur kurz ein detailliert wird dieses Schutz ziel innerhalb der Anwendungsfallmodellierung betrachtet vgl Kapitel7 Auf die Schutzzie le Verf gbarkeit und Anonymisierung gehen wir wie bereits zu Beginn der Arbeit erl utert nicht n her ein Mit Schutzzielen annotierte Diagramme stellen die Basis f r die sp ter durchzuf hrenden Modellierungen der Bedrohungen und Risiken dar Jedes potenzielle Angriffsziel welches als solches erkannt und im Diagramm annotiert wird ist nach Bedrohungen zu untersuchen und zu den Bedrohungen sind die Risiken zu abzusch tzen Wenn das Risiko einer Bedrohung unter Betrachtung der System und
120. chen Eigenschaften bereinstimmt Eine Authentifikation wird in herk mmlichen Systemen meist nur f r Benutzer als Subjekte durchgef hrt Die Identifikation basiert auf der Vergabe von eindeutigen Benutzerkennun gen engl account oder Benutzernamen Charakteristische Eigenschaften zum Nachweis der Identit t sind beispielsweise Passworte Chipkarten biometrische Merkmale etc Autorisierung Autorisierung ist die Pr fung der Berechtigung eines Subjekts zum Zugriff auf eine Informa tion beziehungsweise auf ein Objekt Integrit t In einem IT System ist die Integrit t engl integrity gew hrleistet wenn es Subjekten nicht m glich ist die zu sch tzenden Daten unautorisiert und unbemerkt zu manipulieren Die Integrit t erfordert im System eine Rechtefestlegung zur Nutzung von Daten F r die Erkennung unautorisierter Manipulationen m ssen geeignete Techniken eingesetzt werden Der Begriff der Integrit t ist nicht zu verwechseln mit dem Begriff der Datenintegrit t von Datenbanksystemen Im Umfeld von Datenbanksystemen versteht man unter dem Begriff der Datenintegrit t oder kurz Integrit t die Gew hrleistung der Datenkonsistenz im DB System insbesondere die eindeutige Zuordnung von Prim r und Fremdschl sseln referentielle Integ rit t KEO1 18 Grundlagen Vertraulichkeit In einem System ist die Informationsvertraulichkeit oder kurz die Vertraulichkeit engl confidentiality gew hrleistet wenn auf Infor
121. chen Gesch ftsprozessmodellierung werden jedoch Sicherheitsaspek te nicht betrachtet Die Bearbeiter widmen sich der Funktionalit t und den damit zusam menh ngenden Merkmalen Ergebnisse sind Ablauf Dom nen und Organisationsmodelle in Form von Klassen und Aktivit tsdiagrammen Jedoch k nnen im Rahmen der Gesch ftsprozessmodellierung bereits eine Reihe von Sicher heitsaspekten ermittelt werden Aus der manuellen Abarbeitung der Prozesse lassen sich be reits Schutzziele f r Daten und Prozessaktivit ten ermitteln sowie Berechtigungshierarchien festlegen Auf die Vertrauensw rdigkeit von Objekten kann beispielsweise dadurch geschlos sen werden dass Dokumente welche die Objekte repr sentieren im manuellen Ablauf nach Dienstende im Safe versperrt werden Eine Eingangsbest tigung f r ein Dokument stellt zum Beispiel einen Verbindlichkeitsnachweis dar Derartig ermittelte Schutzziele in den Objekten und Abl ufen der Gesch ftsprozessmodellierung sind bei der Modellierung von Zugriffsrech ten auf Daten und Ausf hrungsrechten von Aktivit ten heranzuziehen und m ssen so nicht erst durch eine separate detaillierte Analyse der Daten und Funktionen erarbeitet werden Zur Dokumentation der so erarbeiteten Schutzziele des Dom nenmodells und der Prozesse sind geeignete Beschreibungstechniken notwendig Im Abschnitt stellen wir die Spezifi kation von Schutzzielen in Struktur und Verhalten als Erweiterung von UML Aktivit tsdia grammen und U
122. cherer Systeme ermittelt werden Vor und Nachteile Durch das vorgestellte Prozessmuster wird die fr hzeitige Entwicklung von Sicherheit in nerhalb der Phase der Anforderungsspezifikation zugriffssicherer Systeme weiter unterst tzt Durch die Betrachtung von Sicherheitsaspekten in allen Prozessabschnitten der Anforderungs spezifikation zugriffssicherer Systeme wird eine durchgehende Sicherheitsanalyse erreicht Ins besondere wird durch den vorgestellten Prozess die geforderte sukzessive Entwicklung erreicht da die Ergebnisse aus der Gesch ftsprozessmodellierung zugriffssicherer Systeme in die Mo dellierung der Anwendungsf lle einflie en und dabei verfeinert und erg nzt werden Wie bereits in der Gesch ftsprozessmodellierung zugriffssicherer Systeme begonnen bleibt das Klassendiagramm frei von Benutzerrechten Hierzu werden Zugriffs und Ausf hrungsrechte im Benutzerrechtemodell d h in einer Benutzerrechtematrix spezifiziert In dieser Benut zerrechtematrix k nnen sowohl Zugriffs als auch Ausf hrungsrechte einheitlich dargestellt werden Das Prozessmuster zur Anwendungsfallmodellierung zugriffssicherer Systeme bietet wie be reits erw hnt eine Vielzahl von Iterationsm glichkeiten vgl Struktur des Prozessmusters Besonders f r gro e Systeme spielt die iterative Entwicklung eine bedeutende Rolle Eine entscheidende Rolle spielt dabei die Tatsache dass die Entwicklung von Aspekten der Zu griffssicherheit nicht in den Hint
123. chrittweise verfeinert werden k nnen In einer ersten Phase ist das neue System zu beschreiben und gegen ber existierenden Systemen abzugrenzen Ein Risikomodell und der Entwurf einer Security Policy dokumentieren die Sicherheitsbetrachtungen Die Ergebnisse aus der ersten Phase werden dem Kunden zur berarbeitung vorgelegt und es findet eine interne Bewertung statt Die Entwick ler erweitern ihr Fachwissen durch internes Material und Literaturstudien Als Ergebnis liefert die zweite Phase berarbeitete qualitativ hochwertige Risikomodelle Security Policies und Security Targets In der dritten Phase erfolgt eine Verteilung der Dokumente an einen gr e ren Kreis wie etwa an Senior Manager externe Bewerter oder Evaluatoren Im Rahmen der Entwicklung zugriffssicherer Systeme sind nach Anderson ein Bedrohungsmo dell mit Angreifern und Schwachstellen sowie ein Strategiemodell zu erstellen Das Strategie modell wird in die Beschreibung des Sicherheits Targets vgl BSI99 aufgenommen welches Basis f r die weitere Entwicklung sowie das Testen und gegebenenfalls f r eine Evaluierung ist Die von Ross Anderson vorgestellten Aspekte sind nur Teile eines Vorgehens f r eine Entwick lung sicherer Systeme denn nur im Bereich des Requirements Engineerings geht er ansatzweise auf Einzelheiten ein Ein Vorgehen in anderen Phasen wie beispielsweise in der Analyse oder im Design fehlt vollst ndig Die im Folgenden beschriebene Bewertung kann deshalb
124. chutzzielen in Gesch ftsobjekten des Dom nen modells sind Schutzziele auch in den Gesch ftsprozessen zu identifizieren Innerhalb der Aktivit ten von Prozessabl ufen werden Daten verarbeitet sodass die Daten ebenfalls vor unerlaubt lesendem Zugriff und vor unerlaubter Manipulation zu sch tzen sind Auch die Ausf hrung einer Aktivit t muss bei kritischen Gesch ftsprozessen zu einem sp teren Zeit punkt nachvollzogen werden k nnen Wird im Rahmen der Gesch ftsprozessmodellierung festgestellt dass Aktivit ten derartigen potenziellen Angriffen ausgesetzt sind annotieren wir Aktivit ten mit den in Abbildung 6 10 eingef hrten Schutzzielen lt lt Confidentiality gt gt lt lt Integrity gt gt lt lt NonRepudiation gt gt activity A activity B activity C Z activity A activity B activity C y SEC SEC y SE A Abbildung 6 10 Schutzziele in Aktivit tsdiagrammen Wir verwenden analog zu den eingef hrten Stereotypen f r Klassendiagramme die Schutzziel Icons lt Confidentiality gt lt Integrity gt und lt NonRepudiation gt innerhalb von Aktivit ten eines Aktivit tsdiagramms Da auch Aktivit ten h ufig nicht nur einzelnen Angriffen ausgesetzt sind erlauben wir auch eine Kombination der Schutzziel Icons wie dies in Abbildung 6 11 dargestellt ist eivi D E eivi E N eivi F 2 rivi G 2 Abbildung 6 11 Kombinationen von Schutzzielen in Aktivit tsdiagrammen
125. ct vity SEC activity Abbildung 7 3 Stereotypen zur einfachen und beidseitigen Authentifikation 7 2 Modellierung der Authentifikation 149 Bei der Untersuchung der Abl ufe wird nun jede Aktivit t bez glich des Schutzziels Authenti fikation untersucht Falls der ausf hrende Akteur der durch die Swimlane zugeordnet wurde zur Ausf hrung der Aktivit t einseitig oder gegenseitig am System authentifiziert werden muss wird die Aktivit t mit dem entsprechenden Stereotyp gekennzeichnet O Y AN i activi SEC ty a b activity SEC l SEC activity 1 SFC activity 1 SEC activity 1 activity 1 1 1 1 if 1 A activity 2 A activity 2 activity 2 activity 2 T 1 A l activity 3 activity 3 A activity 3 c d e 6 activity 3 Abbildung 7 4 Authentifikation und Sitzungen in Abl ufen F r aufeinander folgende Aktivit ten ist es zumeist nicht erforderlich und nicht geeignet dass der Akteur oder ein externes System f r jede Aktivit t separat authentifiziert werden muss Aus diesem Grund haben wir im Abschnitt 7 2 2 bereits Sitzungen und verschiedene F lle eingef hrt in denen ein Akteur nur zu unterschiedlichen Aktivit ten einer Sit
126. d k nnen die Ausf hrungsrechte des Anwendungsfalls aus den ben tigten Benutzerrechten im Ablauf errechnet werden Abschnitt 7 5 stellt das Vorgehen in der Anwendungsfallmodellierung zugriffssicherer Syste me in Form eines Prozessmusters vor Dabei kommt erneut der Sicherheitsmikroprozess aus Abschnitt 5 3 3 zur Anwendung Auf die Produktartefakte der Anwendungsfallmodellierung zugriffssicherer Systeme gehen wir in abschlie end Abschnitt 7 6 ein 7 1 Grundlagen der Anwendungsfallmodellierung Bevor wir auf die Besonderheiten der Anwendungsfallmodellierung zugriffssicherer Systeme eingehen geben wir einen kurzen berblick ber Ziele Aktivit ten und Produktartefakte der allgemeinen Anwendungsfallmodellierung ein 7 1 1 Motivation Mit der Entwicklung neuerer Entwurfsmethoden wurde der reine Entwurf von Objekten und Operationen verlassen Es wurden neue Modellierungskonzepte wie beispielsweise System operationen CAB 94 Gesch ftsvorf lle und Anwendungsf lle ein gef hrt bei denen in den fr hen Phasen des Entwurfs zur Modellierung von Struktur und Verhalten ein hybrides Vorgehen unterst tzt wird Bei dem prominentesten Ansatz zu den Anwendungsf llen engl Use Cases wird sowohl eine objektorientierte als auch eine funk tionsorientierte Sicht auf das System eingenommen in der sowohl die Objekte des Anwen dungskerns Dom nenmodell als auch die Dienste die das System unterst tzt beschrieben werden vgl Bre01 Die w
127. d Herrn Guido Wimmel die interessante Impulse f r meine Arbeit lieferten mir sehr viel Freiraum im Projekt einr umten und f r ein angenehmes Arbeitsklima sorgten Des Weiteren danke ich den Innsbrucker Kollegen Frau Joanna Chimiak Opoka Herrn Klaus Burger und Herrn Michael Hafner f r die wertvollen Diskussionen und die gute thematische Zusammenarbeit F r das aufmerksame Durchlesen und die zahlreichen Kommentare zur endg ltigen Fassung meiner Arbeit m chte ich mich bei Herrn Martin Deubler Herrn Johannes Gr nbauer Herrn Thomas Kuhn und Frau Dr Katharina Spies besonders bedanken Nicht zuletzt danke ich meinen Eltern Anna und Robert sowie meiner Freundin Heidi f r die Geduld und R cksicht sowie f r den seelischen und moralischen Beistand Inhaltsverzeichnis 1 1 1 Zielsetzung ies 2 4 ans ak de eA eR dh eek ee GOR ao de A 2 bp eae ee ete aes eres awn oy pene ee eee eee oe os eee a 5 1 3 Aufbau der Arbeitl u 4 4 eo e tom Bow Re en ee Se ee ee Bae 7 eee Be Ek oe oe ee be ie ce ee ee 8 1 ee ee oe ees ee 11 ee 1 Loree te ae ee He a ce RE RR 12 NEN 13 2 1 4 Die grafische Beschreibungssprache UML 15 2 2 Grundlagen zur IT Sicherheit 2 2 2 2 oo nn 15 i a Be a ae Be ae Sale ne le eo ae 16 bE Bee Aa eae Bee ee woe bow gl we hee oy Be 17 De es glee eee Gees Ge es 18 Sates ee ea eee ee Be Ge ee eo 19 Gem Da ee ae Gos Gee Gy 21 23 3 1 Motivation und Hintergrund 000002 ee eee 23
128. d Process RUP Kru00l der Unified Process UP JBR99 oder der Catalysis Approach DW98 sind an passbar und erweiterungsf hig Da sie zumeist sehr allgemein sind m ssen sie vor einer 5 3 Das Vorgehen 73 Sicherheits Konstruktions Auslieferungs Startphase anforderungs BR phase phase definition Abbildung 5 4 bersicht ber das modifizierte Lebenszyklusmodell konkreten Anwendung den Projekt oder Unternehmensbed rfnissen angepasst werden Wir w hlen hiervon den RUP als Vertreter der objektorientierten Vorgehensmodelle aus und in tegrieren die Phase der Anforderungsspezifikation zugriffssicherer Systeme in den Software lebenszyklus Der im RUP vorgestellte Lebenszyklus enth lt eine Startphase engl Inception Phase eine Ausarbeitungsphase engl Elaboration Phase eine Konstruktionsphase engl Construction Phase und eine Auslieferungsphase engl Transition Phase Alle Phasen sind auf eine objektorientierte Modellierung ausgerichtet Iterationen sind ebenfalls in allen Phasen zu finden und Produktmodelle stehen ebenfalls im Vordergrund Da die zu integrierende Phase der Anforderungsspezifikation zugriffssicherer Systeme gr ten teils eine Verfeinerung der Ausarbeitungsphase darstellt ersetzen wir diese Phasen gegenein ander Somit ergibt sich der in Abbildung 5 4 gezeigte Softwarelebenszyklus F r die Integra tion ist eine Modifikation der Startphase durchzuf hren Wir ndern sie dahingehend ab dass ausgehe
129. d das Sicherheitsmodell genannt weitere Spezifikationen wie beispielsweise die Dokumentation der Bedrohungen und Risiken sowie eine Umsetzung dieser zu in funktionalen Anforderungen wird nicht beschrie ben F r einen durchg ngigen und sukzessiven Entwicklungsprozess sicherer Systeme in dem in den Prozessschritten Sicherheitsaspekte erarbeitet werden ist eine Betrachtung der Pro duktartefakte notwendig 5 1 Existierende Vorgehensmodelle 57 5 1 2 V Modell und ITSEC Ein weiteres Vorgehen zur Entwicklung sicherer Systeme existiert als Erweiterung des V Modells 97 Hierzu wird das Vorgehen aus dem V Modell 97 um Aspekte der Entwicklung und Evaluierung sicherer Systeme erweitert Die in beschriebene Anwendung des V Modells 97 und der ITSEC genannt SEC verfolgt das Ziel IT Systeme nach dem V Modell 97 zu entwickeln sowie nach Kriterien des Kriterienkataloges zur Evaluierung sicherer Systeme ITSEC zu bewerten Da unser Fokus im Rahmen dieser Arbeit auf der Entwicklung von sicheren Systemen insbesondere in den fr hen Phasen der Anforderungsspezifikation liegt betrachten wir weniger die Aspekte der Evaluierung und beschr nken uns auf die Ent wicklung des Systems Das V Modell 97 regelt die Gesamtheit aller Aktivit ten und Produkte sowie die Produktzust nde und logischen Abh ngigkeiten zwischen Aktivit ten und Produkten im Systementwicklungsprozess sowie die Instandhaltung und Modifikation von existierenden IT Systemen Das V Modell
130. de zur Entwicklung sicherer Systeme Bei der Entwicklung sicherer Systeme ohne dediziertes Vorgehensmodell wird meist versucht nach der Umsetzung der funktionalen Anforderungen die Systeme gegen ber Angriffen abzu sichern indem Aspekte der Zugriffssicherheit als Erweiterung angef gt werden Da jedoch bei der Entwicklung zugriffssicherer Systeme ein Gro teil der Abl ufe und Daten an die Tech niken zur Gew hrleistung der Sicherheit angepasst werden m ssen ist es nicht m glich die Aspekte der Zugriffssicherheit am Ende der Produktentwicklung anzuf gen Techniken zur Realisierung der Zugriffssicherheit k nnen eben nicht als isolierter Baustein angef gt werden Alle Abl ufe und Daten m ssen auf Sicherheitsaspekte berpr ft und gegebenenfalls ange passt werden Ein gro es Problem stellt dabei das nahende Ende der Entwicklung dar da gegen Ende zumeist Zeit und Budget schon berzogen sind und die Integration der Sicher heitsaspekte somit nicht mehr im erforderlichen Ausma verfolgt werden kann 1 1 Zielsetzung Sicherheit spielt in heutigen Systemen mehr und mehr eine entscheidende Rolle Derzeit fehlt ein methodisches Vorgehen zur Entwicklung zugriffssicherer Systeme Im Rahmen dieser Arbeit wird ein Vorgehen entwickelt welches zeigt wie eine schrittweise Entwicklung der Zugriffssicherheit in den fr hen Phasen der Softwareentwicklung betrieblicher Informationssysteme integriert werden kann Im Vordergrund steht dabei die Entwicklu
131. dell der TimeTool Fallstudie bereits mit den eingef hrten Stereotypen Schutzziele annotiert In Tabelle 6 1 betrachten wir die Aktivit ten Modellierung der Bedrohungen und Bewertung der Risiken zu diesen annotierten Objekten des Dom nenmodells F r jedes Objekt das mindestens mit einem Schutzziel annotiert wur de erfassen wir die Bedrohungen und sch tzen das Risiko ab F r die Risikoabsch tzung verwenden wir nur eine dreistufige Skala gering mittel und hoch Diese Risikoabsch tzung kann auch durch umfangreichere Ermittlungsverfahren ersetzt werden wie beispielsweise in HBO3 Auf Verfahren zur Risikoabsch tzung gehen wir hier nicht n her ein Da Bedrohungen und Risiken innerhalb der weiteren Bearbeitungsschritte wie etwa zur Er mittlung von Gegenma nahmen referenziert werden nummerieren wir die Bedrohungen und Risiken durch Tabelle 6 1 Bedrohungen und Risiken zum Dom nenmodell der TimeTool Fallstudie Klasse Bedrohung und Risiko Projekt B001 Ein Projektmitarbeiter oder ein weiterer Benutzer des Systems ver ndert das Budget des Projekts R001 Das Risiko wird als gering eingesch tzt da das Budget in der Klasse Projekt nur zu Informationszwecken gespeichert wird und keinen weiteren Einfluss auf das System hat Activity B002 Ein Projektmitarbeiter oder ein weiterer Benutzer des Systems ver ndert die Dauer und Start bzw Endzeiten von Projektakti vit ten R002 Das Risiko wird als hoch eingesch tzt da durch
132. den textuellen Ablaufbeschreibungen die Varianten eigenst ndig be schrieben Synergien mit anderen Anwendungsf llen werden zu diesem Zeitpunkt nicht her ausgearbeitet ebenso auch bei der Ermittlung des Dom nenmodells Weiterhin werden bei der Analyse der Anwendungsf lle getrieben durch die eigenst ndige Beschreibung auch In konsistenzen nicht erkannt Im Rahmen der Analyse sind Redundanzen und Inkonsistenten zu erkennen und zu beheben Ein Analysemodell kann als erster Entwurf eines Designmodells betrachtet werden Das Ana lysemodell stellt eine wichtige Vorarbeit zum Design und zur Implementierung dar 8 1 Grundlagen der Analyse 179 8 1 2 Aktivit ten der Analyse Zu Beginn der Analyse ist die Architektur des zu entwickelnden Systems zu untersuchen Die Anwendungsf lle und Entit ten des Dom nenmodells aus der Anwendungsfallmodellierung sind dabei in kleinere handhabbarere Einheiten f r die Analyse aufzuteilen Die so genannten Analyse Packages k nnen beispielsweise nach funktionalen Anforderungen oder nach Aufga benbereichen der Unternehmung bzw Organisation aufgeteilt werden Weitere Unterteilungen der Packages sind in beschrieben Aus dem Dom nenmodell der Anwendungsfallmodellierung sind die Klassen des Anwendungs kerns f r das Analyseklassendiagramm zu erstellen Grunds tzlich werden im Klassendia gramm der Analyse folgende drei Typen von Klassen unterschieden Interaktionsklassen Vor gangsklassen und Fachklassen
133. der Anforderungsspezifikation Dieser Ansatz zur Sicherheitsmodellierung beginnt mit der Erarbeitung von Sicherheitsaspek ten in der Problembeschreibung die entweder als textuelle Beschreibung vom Auftraggeber geliefert oder in gemeinsamen Diskussionen von Entwicklern und Anwendern erarbeitet wird Diese Beschreibung wird in einem ersten Schritt um Sicherheitsanforderungen erg nzt In AWO3b wird hierzu eine Matrix vorgestellt die zu bekannten Sicherheitsanforderungen Si cherheitsma nahmen vorstellt Die so ermittelten Ma nahmen flie en in die Anforderungsspe zifikation mit ein In der Anwendungsfallmodellierung werden die Akteure bestimmt wobei auch Security Patterns als Akteure betrachtet und Zugriffsrechte in Form von Vorbedingun gen neben der blichen Anwendungsfallspezifikation beschrieben werden In Anwendungsfall diagrammen werden die Sicherheitsma nahmen als UML Notes dargestellt in Klassendia grammen als UML Stereotypes wobei die Stereotypes in UML Notes eingetragen sind In der Analyse wird zwischen drei verschiedenen Klassenkategorien zur Sicherheit Entity Boundary und Control unterschieden und es werden Security Patterns zur Integration der Sicherheits ma nahmen angewandt In diesen Ansatz wird Sicherheit in allen Projektphasen beginnend bei der Anforderungsana lyse durchgef hrt und die Sicherheit wird schrittweise im System integriert Sicherheit wird gemeinsam mit der Funktionalit t entwickelt In den Anwendungsf
134. der Gesch ftsprozessmodellierung zugriffssicherer Systeme eingehen geben wir einen kurzen berblick ber Ziele Aktivit ten und Produktartefakte der allgemeinen Gesch ftsprozessmodellierung 6 1 1 Motivation Nach starten viele UML basierte Entwicklungsprozesse mit der Modellierung der An wendungsf lle Durch die Anwendungsf lle k nnen zwar Aufgaben die ein Akteur mithilfe des zu erstellenden Systems l sen will beschrieben werden aber es bleibt offen inwiefern alle oder zumindest die wichtigsten Anwendungsf lle des Systems auf diese Art identifiziert werden Weiterhin wird nicht gekl rt wie unterschiedliche Akteure in Prozessen zusammenar beiten welche Aktivit ten zu ihrem Aufgabenfeld geh ren welche Ziele sie mit ihren Arbeiten verfolgen und welche anderen Bearbeiter Systeme oder Ressourcen dabei involviert sind Mit diesen Aspekten besch ftigt sich die Gesch ftsprozessmodellierung Die Abl ufe und die Aufteilung der Unternehmung bzw Organisation die Ressourcen der Prozesse die globalen Regeln die Ziele sowie die Probleme werden innerhalb der Gesch ftsprozessmodellierung un tersucht Informationen die f r das Unternehmen einen strategischen Wert besitzen sind in einem unvollst ndigen Dom nenmodell siehe Rat00 herauszuarbeiten Ein Gesch ftsprozessmodell kann nach niemals absolut genau und vollst ndig sein Wenn zwei Betrachter ein und dasselbe System beschreiben werden beide eine unterschiedli che Auffass
135. der Phase der Gesch ftsprozessmodellierung betrachtet werden Der vorgestellte Prozess ist in bestehende Vorgehensmodelle integrierbar insbesondere in ob jektorientierte Vorgehensweisen da unter anderem die verwendeten und erg nzten Beschrei 5 3 Das Vorgehen 79 bungstechniken an denen der objektorientierten Vorgehensweisen Kru00 DW98 JBR99 an geglichen sind Das vorgestellte Prozessmuster beschr nkt sich auf eine Neuentwicklung von zugriffssicherer Software F r die Phase der Anforderungsspezifikation bedeutet dies dass die Anforderungen gemeinsam mit der Funktionalit t und aus einer Bedrohungs und Risikoanalyse heraus ent wickelt werden Eine Analyse bestehender Systeme insbesondere von Sicherheitsaspekten ist nicht Bestandteil dieses Prozessmusters Hierzu w re das vorgestellte Prozessmuster mit den zugeh rigen Teilphasen abzu ndern was jedoch nicht Gegenstand der vorliegenden Arbeit ist In Beziehung stehende Prozessmuster Auszuf hrende Teilprozesse e Prozessmuster zur Gesch ftsprozessmodellierung zugriffssicherer Systeme siehe Ab schnitt e Prozessmuster zur Anwendungsfallmodellierung zugriffssicherer Systeme vergleiche Ab schnitt e Prozessmuster zur Analyse zugriffssicherer Systeme siehe Abschnitt bergeordneter Prozess e Prozessmuster zur Integration der Anforderungsspezifikation zugriffssicherer Systeme in den Softwarelebenszyklus siehe Abschnitt 5 3 1 Weiteres referenziertes Prozessmuster
136. des Dom nenmodells aus der Gesch ftsprozessmodellierung Das Dom nenmodell ist an die festgelegten Systemgrenzen an zupassen In den Klassendiagrammen sind Gemeinsamkeiten in den Klassen zu identifizieren und die Assoziationen anzupassen Im Rahmen des Entwurfs des Anwendungskerns sind auch die fachlichen Datentypen wie W hrungen Datumsangaben etc zu identifizieren Abbildung 7 1 zeigt die strukturelle Beschreibung des Anwendungsfalls Korrekturbuchung aus der TimeTool Fallstudie Ein Anwendungsfalldiagramm der Fallstudie ist bei der Einf hrung der Fallstudie TimeTool in Kapitel 3 dargestellte siehe Abbildung 3 2 Das verfeinerte Klassendiagramm des Dom nenmodells aus der Gesch ftsprozessmodellierung ist in Abbildung zu sehen Projektmitarbeiter und Projektleiter k nnen in eine Klasse zusammengefasst werden Gemeinsam mit der in Abschnitt 6 4 2leingef hrten Klasse Logging ergibt sich das in Abbildung 7 2 dargestellte Klassendiagramm 7 2 Modellierung der Authentifikation Bisher haben wir im Rahmen der Autorisierung den berechtigten Zugriff auf Daten und Ak tivit ten betrachtet Im Folgenden gehen wir auf die eng mit der Autorisierung verbundene Authentifikation ein bei der die ausf hrende Entit t eines Zugriffs anhand ihrer charakteri stischen Eigenschaften oder anhand einer eindeutigen Identit t vorab berpr ft werden muss 7 2 Modellierung der Authentifikation 147 Nach der Authentifikation stehen der ausf hrend
137. die Akteure welche die Gesch ftsprozesse ausf hren Weitere Anwendungsgebiete der Gesch ftsprozessmodellierung sind Business Process Reengi neering Unterst tzung bei der Auswahl und dem Customizing von betriebswirtschaftlicher Standardsoftware Sta01 Requirements Engineering Par98 Qualit tsmanagement beispielsweise DIN ISO 9000 ff oder die Definition von Workflows sowie prozessorientiertes Wissensmanagement Gesch ftsprozessmodell Gesch ftsprozessmodelle sind zweckorientierte vereinfachte Abbildungen von Gesch ftspro zessen Aufgrund ihrer allgemeinen Modellcharakteristik dienen Gesch ftsprozessmodelle der Dokumentation Analyse und Gestaltung von Gesch ftsprozessen sowie zur Unterst tzung der Kommunikation ber Gesch ftsprozesse 94 Die Gesch ftsprozessmodellierung zugriffssicherer Systeme ProjectInformation l Project Activity description String name String budget Real k 1 1 plannedStart Timestamp plannedEnd Timestamp realStart Timestamp realEnd Timestamp plannedHours Real 1 Administrator ProjectManager TeamWorker name String address String email String pswd String userid String name String address String email String pswd String userid String name String address String email String pswd String userid String 1 1
138. die Aspekte der Zugriffssicherheit in kleinen Einheiten umgesetzt Die iterative Entwicklung ist durch die Anwendung des Sicherheitsmikroprozesses sowie durch weitere Iterationsm glichkeiten innerhalb des Prozessablaufs der Analysemodellierung gege ben 194 Die Analyse zugriffssicherer Systeme 9 Zusammenfassung und Ausblick In zugriffssicheren Systemen sind die dem System anvertrauten Informationen vor unautori siertem Zugriff zu schiitzen Heutige Vorgehensmodelle widmen sich nur in geringem Umfang der systematischen Entwicklung von Aspekten der Zugriffssicherheit sodass diese h ufig erst am Ende der Designphase in einem zus tzlichen Entwicklungsschritt ermittelt werden Da in diesem Fall zur Abdeckung der Sicherheitsanforderungen gro e Teile des Designs grundlegend zu berarbeiten sind und zumeist die Projekte am Ende der Entwicklung die Zeit und Ko stenkalkulationen berschritten haben bleiben viele Anforderungen an die Zugriffssicherheit unerf llt Dazu haben die sichtbaren Funktionen stets Entwicklungspriorit t nichtfunktio nale Eigenschaften werden oftmals nur in untergeordnetem Ma e behandelt Dies f hrt dazu dass die zu entwickelnden Systeme mit Sicherheitsl cken und Schwachstellen behaftet sind Die vorgestellte Methode zur Integration von Sicherheitsanforderungen in die Entwicklung zugriffssicherer Informationssysteme beugt die Entwicklung l ckenhafter Systeme vor indem sie die Aspekte der Zugriffssicherhei
139. die Rechte an dem Objekt besitzt und verwaltet Er kann sie an weitere Subjekte ohne vorherige Vermittlung und Genehmigung eines Ad ministrators weitergeben oder auch widerrufen Die Verwaltung der Rechte und die durch sie beeinflusste Zugriffskontrolle unterliegen somit der Diskretion des Benutzers was dem Zugriffsmodell auch den Namen gab Systembasierte regelbasierte Festlegungen engl mandatory access control MAC spezifi zieren systemglobale Eigenschaften die benutzerbestimmten Rechten bergeordnet sind Ein Zugriff wird verweigert wenn es eine verbietende systembestimmte Festlegung gibt auch wenn der Zugriff durch eine benutzerbestimmbare Strategie erlaubt w re Systembestimmte Rechte k nnen in diesem Modell jedoch auch durch benutzerbestimmbare explizite Berech tigungsverbote weiter eingeschr nkt werden Das MAC Modell stellt somit eine Erweiterung der benutzerbestimmbaren Zugriffskontrolle dar Nach sind die beiden Zugriffsmatrixmodelle f r Anwendungsf lle geeignet in denen Objekte unterschiedlicher Granularit t und unterschiedlichen Typs zu sch tzen sind und im Wesentlichen Integrit tsanforderungen stellen Wegen der objektbezogenen Modellierung soll ten die Objekte m glichst wenige Wechselwirkungen beziehen um inkonsistente Festlegun gen zu minimieren Wegen seiner mangelhaften Skalierbarkeit eignet sich dieser Matrixansatz kaum zur Modellierung einer gro en Menge von Subjekten die sich in hoher Frequenz dyna misch
140. die bei der Erstellung des monatlichen Berichts auftre ten Sie versuchen dabei auf vertrauliche Information zuzugrei fen und diese zu manipulieren R019 Das Risiko wird als hoch eingestuft da geheime Projektinforma tionen ermittelt und Statistiken gef lscht werden k nnen Insbe sondere k nnen Projektbeteiligte konkurrierender Projekte ver suchen das gegnerische Projekt negativ darzustellen Die Liste der Bedrohungen mit ihren Risiken ist f r alle Gesch ftsprozesse zu erg nzen Wur den in den Gesch ftsprozessen auch Schutzziele zu Flussobjekten und zur Autorisierung er mittelt vgl Abbildungen 6 16 und 6 17 so sind f r diese potenziellen Angriffsziele ebenfalls Bedrohungen und Risiken zu ermitteln 6 4 Der Prozess der Gesch ftsprozessmodellierung zugriffssicherer Systeme 135 Da Schutzziele zur Autorisierung wie sie in Abbildung 6 15 eingefiihrt wurden keiner Klasse oder Aktivit t zugeordnet sind betrachten wir die potenziellen Angriffe gegen die Autorisie rung bei der Modellierung der Bedrohungen und Risiken des zugeh rigen Flussobjektes Entwurf von Ma nahmen Nachdem die Bedrohungen und Risiken ermittelt wurden sind Ma nahmen zu entwickeln die den Bedrohungen entgegenwirken soweit das Risiko nicht als minder gering eingestuft werden kann Nicht alle Bedrohungen k nnen bereits in der Phase der Gesch ftsprozessmodellierung zu griffssicherer Systeme behandelt werden da zu diesem Zeitpunkt die interne
141. die zu ergreifenden Ma nahmen sind die Eintretenswahrscheinlichkeiten und der potenzielle Schaden der Bedrohungen welche bei der Bewertung der Risiken ermittelt werden Nach ergeben sich die Eintrittswahrscheinlichkeiten aus dem gesch tzten Aufwand den ein Angreifer zur Durchf hrung eines Angriffes treiben muss und einer Einsch tzung des m glichen Nut zens den ein Angreifer aus einem erfolgreichen Angriff ziehen k nnte e Entwurf von Ma nahmen Abh ngig von dem Ergebnis der Risikobewertung sind f r die Bedrohungen mit nicht vermeidbarem Risiko Ma nahmen zu entwerfen die diesen entgegenwirken Die Ma nahmen sind nach in die Produktartefakte des jeweiligen Prozessab schnitts Gesch ftsprozess Anwendungsfallmodellierung oder Analyse zu integrieren e berpr fung der Ma nahmen Nachdem die Ma nahmen entworfen und in die Produktartefakte integriert worden sind ist bereits innerhalb der Anforderungsspezifikation eine informale semiformale oder auch formale berpr fung der Zielf hrung der Ma nahmen durchzuf hren Auf Besonderheiten bei der Ausf hrung des Sicherheitsmikroprozesses in den einzelnen Pro zessabschnitten gehen wir bei der Beschreibung der Prozessabschnitte in den Kapiteln 6 bis 8 n her ein Zudem werden die Bearbeitungsschritte an der im Kapitell3leingef hrten Fallstudie TimeTool exemplarisch gezeigt Produktartefakte Im Gegensatz zu den in den Abschnitten und vorgestellten Prozessmustern zum Software
142. diese Ver nderung Mitarbeiter zus tzliche Stunden auf ein Projekt buchen k nnen Zudem wird der Projektplan inkonsistent TeamWorker B003 Ein Projektmitarbeiter ein Projektmanager oder ein weiterer Be nutzer des Systems versucht das Passwort eines Projektmitarbei ters zu lesen oder zu ver ndern R003 Das Risiko wird als hoch eingesch tzt da dadurch falsche Stun denbuchungen eingetragen werden k nnen B004 Ein Projektmitarbeiter ein Projektleiter oder ein weiterer Benut zer des Systems liest und ver ndert private Daten eines Projekt mitarbeiters Fortsetzung auf der n chsten Seite 132 Die Geschaftsprozessmodellierung zugriffssicherer Systeme Fortsetzung von Tabelle 6 1 R004 Das Risiko wird als mittel eingestuft da das lesen privater At tribute wie etwa der Adresse Telefonnummer etc dem Daten schutz widerspricht Beispielsweise k nnen diese Daten f r Mob bing verwendet werden Weiterhin kann durch die Ab nderung z B der Telefonnummer der Projektmitarbeiter im Notfall nicht erreicht werden ProjektManager B005 Ein Projektmitarbeiter ein Projektmanager oder ein weiterer Be nutzer des Systems versucht das Passwort eines Projektmitarbei ters zu lesen oder zu ver ndern R005 Das Risiko wird als hoch eingesch tzt da dadurch Aktionen die nur vom Projektleiter ausgef hrt werden d rfen durch einen Pro jektmitarbeiter eines Projektleiters eines weiteren Projekts oder durch einen weiteren Benutzer
143. dings of the 7th World Multiconference on Systemics Cybernetics and Informatics Orlando Florida USA July 27 30 2003 volume VI of IS Technologies and Applications I 2003 Helmut Balzert Lehrbuch der Software Technik Software Entwicklung Spek trum Akademischer Verlag first edition 1996 Helmut Balzert Lehrbuch der Software Technik Software Management Soft ware Qualit tssicherung Unternehmensmodellierung Spektrum Akademischer Verlag first edition 1998 Richard Baskerville Information Systems Security Design Methods Implicati ons for Information Systems Development ACM Computing Surveys 25 4 375 414 December 1993 Friedrich L Bauer Entzifferte Geheimnisse Methoden und Maximen der Kryp tologie Springer Verlag second edition 1997 Ruth Breu Klaus Burger Martin Eberle and Michael Hafner Projekthand buch zum Projekt TimeTool im Sommersemester 2003 Universit t Inns bruck M rz 2003 200 Literaturverzeichnis BBH 03 BBHP04 BBHPO5 BDL03 BKLO1 BL73 BN89 Boe86 B0094 BP04 BreO1 Bre04 BRJ98 Bro98a Ruth Breu Klaus Burger Michael Hafner Jan Jiirjens Gerhard Popp Guido Wimmel and Volkmar Lotz Key Issues of a Formally Based Process Model for Security Engineering In Proceedings of the 16th International Conference on Software amp Systems Engineering and their Applications ICSSEA03 Paris December 2 4 2003 2003 Ruth B
144. drahtlosen Ver bindungen im LAN und WAN Bereich stellt die Basis f r den notwendigen Informationsaus tausch dar So werden unter anderem bei Drogeriehandelsketten die Eink ufe in den Filialen zu einem zentralen Rechner f r die Rabattberechnung bermittelt oder Kontobuchungen in Form von Last und Gutschriften bertragen Das Navigationssystem im Auto informiert den Fahrer ber die aktuelle Position und den weiteren Streckenverlauf ein Flug kann mittels ei nes Web Formulars gebucht werden und Abrechnungsdaten vom Arzt sind den Krankenkassen elektronisch zu bermitteln Bei den von Rechnern zu verarbeitenden Daten handelt es sich oftmals um wertvolle Infor mationen Durch kriminelle Vorgehensweisen wird versucht diese Daten auszuspionieren oder zu manipulieren Berichte und Statistiken wie beispielsweise Sil04 zeigen dass die Compu terkriminalit t in den letzten Jahren stark angestiegen ist Die Bandbreite hierbei reicht von kleinen Angriffen wie etwa das Ausspionieren von Personaldaten eines Mitsch lers bis hin zu terroristischen bergriffen die ausgef hrt werden k nnen ohne ein zu attackierendes Land betreten und ohne Security Checks am Flughafen ber sich ergehen lassen zu m ssen Da in den vergangenen Jahrzehnten gr tenteils Einzelplatzrechner oder isolierte Netzwerke eingesetzt wurden reichte es zumeist aus die Rechner in abgesperrten R umen vor mutwil ligen Angriffen zu sch tzen oder die Rechner mit einer einfach
145. e ein iterativ ausf hrbarer Sicherheitsmikroprozess eine Integration der Anforderungsspezifikation in einen Softwarelebenszyklus sowie Produktartefakte f r eine Modellierung zugriffssicherer Systeme eingef hrt In den folgenden Kapiteln werden nun die Prozessabschnitte der Anforderungsspezifikation zugriffssicherer Systeme im Detail erkl rt d h es wird gekl rt e welche klassischen Aktivit ten zur Modellierung des aktuellen Prozessabschnitts ohne Betrachtung der Aspekte der Zugriffssicherheit durchzuf hren sind e welche Beschreibungstechniken dabei notwendig sind e welche zus tzlichen Aktivit ten f r die Modellierung der Zugriffssicherheit notwendig sind e welche Beschreibungstechniken und Produktartefakte f r eine Modellierung der Zugriffs sicherheit zu erweitern bzw neu hinzuzuf gen sind soweit dies nicht schon in diesem Kapitel gekl rt wurde 90 Ein Prozess zur Entwicklung von Anforderungsspezifikationen e wie die Abh ngigkeiten der Produktartefakte fiir eine sukzessive Entwicklung aussehen d h welche Artefakte in einem Arbeitsschritt aus anderen Artefakten erzeugt werden k nnen als Verfeinerung der Abh ngigkeiten wie sie im Abschnitt 5 4 eingef hrt wur den e wie eine iterative Modellierung erfolgen kann und e Beispiele die die Aktivit ten Beschreibungstechniken Produktartefakte und iterative Entwicklung im Einsatz zeigen F r die Modellierung der Benutzerrechte wird in den folgenden Proze
146. e Authentifikation abgel st bei der die Glaubw rdigkeit beider an der Kommunikation beteiligter Partner vorab berpr ft wird Diese gegenseitige Authentifikation wird vor allem dann gefordert wenn offene Systeme ber ein unsicheres Transportmedium kommunizieren wie beispielsweise ber das Internet oder ber eine Funkverbindung wie etwa Wireless LAN Zur berpr fung der gegenseitigen Authentifikation werden kryptografische Protokolle eingesetzt 7 2 2 Authentifikation und Sitzungen Die Authentifikation ist eine Voraussetzung damit Akteure oder externe Systeme sicherheits kritische Daten lesen oder schreiben sowie sicherheitskritische Aktivit ten ausf hren k nnen Sie stellt somit eine gesonderte Aktivit t dar die vor der Ausf hrung von derartigen Zu griffen erfolgreich ausgef hrt werden muss Es kann jedoch eine Reihe von Aktivit ten und Datenzugriffen geben deren Ausf hrung nicht beschr nkt ist Beispielsweise k nnen bei Web basierten Bibliothekssystem anonyme Benutzer Such und Informationsdienste nutzen Vor der Bestellung oder Reservierung eines Buches m ssen sie sich jedoch im System authentifi zieren Innerhalb der Gesch ftsprozessmodellierung zugriffssicherer Systeme haben wir die Abl ufe bereits exemplarisch modelliert Im Rahmen der allgemeinen Anwendungsfallmodellierung wurden die exemplarischen Abl ufe derart verfeinert dass manuell zu verrichtende Akti vit ten aus den Abl ufen entfernt wurden In den exe
147. e Pha wewe sae ee 157 158 159 163 7 5 1 _ Prozessmuster 7 1 Anwendungsfallmodellierung zugriffsicherer System 164 See hes wondi oes 172 Paes 173 7 7 Zusammenfassung oaoa ee 175 177 hh ee Pe ee ee be aoe ee ee Ee ce Bye ee 178 ee ee a ee ee nee ee 178 De cle aod OY ete ee ie ee 179 Ga eed nie een oe eee act ES a ote een ee 179 ee 180 a ee 182 BER EEE 184 8 4 1 Prozessmuster 8 1 Analyse zugriffssicherer Systeme 184 erde 190 EP dee hk RE as 191 8 6 Zusammenfassung 22222 nn nn 192 195 199 Literaturverzeichnis 2 2222 2 o on nn 199 i an Bee eh een Maa Re ee EA Bae ee 209 Abbildungsverzeichnis 2 2222 2 mn nn nn nn 211 Inhaltsverzeichnis 1 Einf hrung Die Durchdringung unseres Lebens mit Rechnern ist un bersehbar W hrend anfangs nur gro e Unternehmen und Beh rden wie beispielsweise Banken und Milit r ihre Aufgaben rechnergest tzt bearbeitet haben fand vor allem innerhalb der letzten zehn bis zwanzig Jahre eine Durchdringung des privaten Bereichs statt Die Wiedereinf hrung von Rabatten auf Basis von elektronischen Kundenkarten der Entertainment Bereich in Form von Satellitenanlagen oder Video on Demand sowie das mittlerweile klassische Online Banking sind neben dem Informationsangebot und der Bestellabwicklung im Internet weit verbreitete rechnergest tzte Dienste die von vielen Privatpersonen genutzt werden Die Vernetzung in Form des Internets von lokalen Firmennetzen sowie von
148. e Sicherheitsbetrachtungen nach dem Wasserfallmodell zu bearbeiten sind Solche Arbeitsschritte die aufgrund der Sicherheitsbetrachtungen zus tzlich in das Vorgehensmodell integriert wurden sind in der Abbildung grau hinterlegt Zudem beeinflusst die Betrachtung der Sicherheitsaspekte auch einige herk mmliche Aktivit ten des Wasserfallmodells dahinge hend dass sie zus tzlich Anforderungen der CC abdecken m ssen und deshalb in ihrer ge wohnten Ausf hrung ge ndert werden mussten Diejenigen Aktivit ten des Wasserfallmodells die bez glich der CC ge ndert werden mussten sind wei grau hinterlegt Zu Beginn der Entwicklung muss zun chst der Evaluierungsgegenstand engl Target of Eva luation TOE festgelegt werden der zus tzlich zu den allgemeinen funktionellen Anforde rungen die Sicherheitsanforderungen erf llen muss Ein TOE kann sowohl das gesamte zu entwickelnde System umfassen oder aber nur einen Teil davon als zu evaluierenden Systemteil beinhalten Weiterhin ist in der Planungsphase nach dem CC Vorgehen neben der Durchf hr barkeit und Aufwandssch tzung auch der Einsatz eines Konfigurationsmanagementsystems engl Configuration Management System CMS festzulegen sodass eine eindeutige Identifi kation des Evaluierungsgegenstands m glich ist Die Analysephase beinhaltet die Formulierung der fachlichen Anforderungen in Form einer Systemanalyse die Erstellung eines vorl ufigen Benutzerhandbuchs und eines Produktmo dells die
149. e Zur Realisierung der Sicherheitsfunktionen sind im Klassendiagramm Vorgangsklassen und Fachklassen zu erg nzen Die Vorgangsklassen enthalten nach der Entwicklung des Designs die Sicherheitsgrundfunktionen die zur Gew hrleistung der Zugriffssicher heit eingesetzt werden Dabei sind gegebenenfalls Attribute vor unerlaubtem Zugriff zu sch tzen In den Fachklassen zur Sicherheit werden zus tzliche Informationen gehal ten wie beispielsweise private und allgemeine Schliissel die ebenfalls vor unerlaubtem Zugriff zu schiitzen sind Bei der Spezifikation der Szenarien werden zum Klassendiagramm Vorgangsklassen er mittelt und wenn n tig Interaktions und Fachklassen erg nzt e Zu den hinzugef gten Klassen sind im Klassenmodell neue Beziehungen einzuf gen Da die Analyse zugriffssicherer Systeme der letzte Prozessabschnitt der dreistufigen Anforde rungsspezifikation ist m ssen die ermittelten Ma nahmen noch in diesem Abschnitt umge setzt werden Im Gegensatz zu den vorausgehenden Prozessabschnitten ist es nicht m glich die Ma nahmen erst im n chsten Abschnitt zu integrieren 8 5 Produktartefakte der Analyse zugriffssicherer Systeme Abschlie end betrachten wir die Produktartefakte aus dem Prozessmuster zur Analyse zu griffssicherer Systeme und gehen dabei auf die notwendigen Erg nzungen zur Modellierung der Zugriffssicherheit n her ein In Abbildung sind die Produktartefakte zur Sicherheitsanalyse mit ihren Teilprodukten darge
150. e das Leistungsprogramm eines Unternehmens darstellen und als Ergeb nis einen Wert f r einen Kunden erzeugen Der zweiten Interpretation liegt ein allgemeines Prozessverst ndnis zugrunde Gesch ftsprozesse werden als betriebliche Prozesse die zur Er stellung der Unternehmensleistung beitragen verstanden Dazu geh ren beispielsweise auch Prozesse der Produktentwicklung oder Marktforschung Aus systemtheoretischer Sicht sind Gesch ftsprozesse Folgen bestimmter diskreter Zustands nderungen des betrachteten Systems Unternehmen Im Rahmen dieser Arbeit wird von dieser Unterscheidung abstrahiert und unter einem Ge sch ftsprozess die inhaltlich abgeschlossene zeitlich sachlogische Abfolge von Aktivit ten ver standen die zur Bearbeitung eines f r die Leistungserbringung des Unternehmens relevanten Objekts oder Dienstleistung erforderlich sind Wir betrachten einen Gesch ftsprozess als Mu ster f r einen Arbeitsablauf Thu04 Dieses Muster gibt vor aus welchen Aktivit ten sich der Prozess zusammensetzt in welcher Reihenfolge und kausalen Ordnung die Aktivit ten ausgef hrt werden m ssen und welches Ziel damit erreicht wird Die Daten Informationen und Gesch ftsobjekte auf denen der Gesch ftsprozess arbeitet sowie die Ergebnisse und Pro dukte die im Gesch ftsprozess erstellt werden sind im Muster zu beschreiben Im Rahmen der Betrachtung der Organisation des zu modellierenden Gesch ftsbereichs interessieren wir uns insbesondere f r
151. e entweder alter nativ begleitend im Vorfeld als n chste Schritte als Teilmu ster oder als bergeordnete Prozessmuster ausgef hrt werden k nnen oder mit einer hnlichen Menge von Produktartefakten arbeiten kurz beschrieben Der Abschluss eines Prozessmusters ist mit einer Raute zur Ab grenzung von nachfolgendem erkl renden Text gekennzeichnet 2 2 Grundlagen zur IT Sicherheit 15 die Suche nach m glichen L sungen erleichtert In Abh ngigkeit vom Problem mit den gege benen Eingabeartefakten und den gew nschten Ausgabeartefakten kann unter Betrachtung der Vor und Nachteile das geeignete Muster ausgew hlt und die darin vorgeschlagene L sung abgearbeitet werden Alle Muster bestehen stets aus dem Trio von Problem L sungs und Kontextbeschreibung Rau01 Entscheidend dabei ist die Diskussion des Kontexts der eine detaillierte Problemstellung erm glicht Unter Einbeziehung dieses Kontexts kann eine optimale L sung ausgew hlt werden Tabelle 2 1 stellt das Beschreibungsformat f r Prozessmuster vor das wir in dieser Arbeit verwenden Dieses Beschreibungsformat ist angelehnt an die bekannten Musterschablonen aus Rau01 GMPt01b GMP t01a GMP 02a GMP t03a GMP 03b 2 1 4 Die grafische Beschreibungssprache UML Bei der Unified Modeling Language UML handelt es sich um eine Beschrei bungssprache zur Spezifikation Darstellung Konstruktion und Dokumentation von ganzen Softwaresystemen Die UML bietet eine Sam
152. e um Aspekte der Zugriffssicherheit Aktivit ten der Gesch ftsprozesse werden auf Anwendungsf lle abgebildet und darin weiter verfeinert Hierbei kann eine n m Zuordnung auftreten d h eine oder mehrere Aktivit ten k nnen auf einen oder mehrere Anwendungsf lle abgebildet werden Wurden in einer Aktivit t Schutzziele spezifiziert so m ssen ein oder mehrere um Sicher heitsaspekte erweiterte Anwendungsf lle entwickelt werden Dabei sind die Schutzziele auf die erweiterten Anwendungsf lle zu transformieren Im Fall einer 1 1 Zuordnung k nnen die Schutzziele direkt auf den Anwendungsfall bernommen werden Wird eine Aktivit t auf mehrere Anwendungsf lle transformiert 1 n Zuordnung so sind die Schutzziele auf die An wendungsf lle zu bertragen und es ist zu berpr fen inwiefern die spezifizierten Schutzziele f r jeden einzelnen Anwendungsfall zutreffen Bei der Zuordnung von mehreren Aktivit ten zu einem oder mehreren Anwendungsf llen k nnen in den Aktivit ten unterschiedliche Schutz ziele definiert worden sein In diesen F llen m 1 oder m n Zuordnung muss f r alle n Anwendungsf lle erneut berpr ft werden inwiefern alle Schutzziele aus den m Aktivit ten f r die einzelnen Anwendungsf lle Bedrohungen hervorrufen In einem Anwendungsfall sind die Ein und Ausgabedaten sowie die modifizierten Daten be schrieben Bei der Ermittlung der Schutzziele des Anwendungsfalls sind neben den Schutzziele aus den Aktivit ten auch
153. e wird das Stereotyp Au thentifikation eingef gt und das Sitzungskonzept integriert Die Abl ufe mit annotierten Ak tivit ten zur Authentifikation werden in Aktivit ten zur berpr fung der Authentifikation und der Autorisierung verfeinert F r die Verhaltensbeschreibung der Anforderungen an die Zugriffssicherheit werden die strukturellen Anwendungsfallbeschreibungen erg nzt F r die Realisierung der Sicherheitsgrundfunktionen werden der funktionalen Anforderungsspezifi kation eigene Sicherheitsanwendungsf lle hinzugef gt Benutzerrechte die bereits nach der Anwendungsfallmodellierung stabil sind werden von der textuellen in eine pr dikative Form pr zisiert Der Zusammenhang zwischen Ausf hrungs und Zugriffsrechten wird w hrend der Ablaufmodellierung berechnet Die Grenzen der Berechenbarkeit sowie die Berechnungsvor schrift werden im Rahmen der Anwendungsfallmodellierung zugriffssicherer Systeme vorge stellt Innerhalb der Sicherheitsanalyse wird das Dom nenmodell durch ein Klassendiagramm der Analyse mit Fach Vorgangs und Interaktionsklassen verfeinert Aus den Anwendungsfall beschreibungen werden Szenarien mit exemplarischen Interaktionsverhalten erstellt Die Si cherheitsanforderungen werden dabei ebenfalls wie die funktionalen Anforderungen durch funktionale Abl ufe verfeinert An dieser Stelle erfolgt der bergang der nichtfunktionalen Sicherheitsanforderungen in funktionale L sungen zur Gew hrung der Zugriffssicherheit
154. eben werden d h sie sind neu zu definieren vgl hierzu Vererbung von Benutzerrechten in Abschnitt 4 4 3 Abbildung 6 18lzeigt ein Beispiel f r eine m gliche Akteurhierarchie Der Akteur A ist von den Akteuren B C D E unabh ngig Die Akteure C E sind eine spezielle Form des Akteurs B der Akteur D ist zus tzlich eine Sonderform des Akteurs C er erbt somit die Benutzerrechte der Akteure B C ACActor A ACActorA ACActorB A ACActorC ACActorE A ACActorD Abbildung 6 19 Hierarchiebildung in den Akteurklassen In Abschnitt 4 4 wurde bereits die interne Repr sentation der Akteure mittels Akteur Rollen vorgestellt Dabei wurde f r jede Akteur Rolle des Systems eine Akteurklasse eingef gt Zwischen den derart eingef hrten Klassen l sst sich die Hierarchie in so genannten Verer bungsb umen darstellen Weiterhin wird eine abstrakte Superklasse A CActor eingef hrt die Basis aller Akteurklassen ist In dieser Superklasse k nnen allgemeine Berechtigungen die f r alle Akteure im System gelten sollen eingef gt werden Abbildung 6 19 zeigt die Akteurklas sen zum Beispiel aus Abbildung 6 18 F r unsere TimeTool Fallstudie ist die Akteurhierarchie in Abbildung dargestellt Die Akteure Administrator und Others sind unabh ngig zu den anderen Akteuren der Fallstu die Der ProjectManager ist eine Sonderform des TeamWorkers sodass f r ihn seine eigenen Rechte sow
155. echte Zugriffsrechte Ausf hrungsrechte gt Berechtigungen zum gt Berechtigungen zur Zugriff auf Ausf hrung von Datenobjekte Vorgangsmethoden gt READ WRITE und EXECUTE CREATE Berechtigungen Berechtigungen Abbildung 6 21 Unterscheidung von Benutzerrechten Wie wir im Folgenden sehen werden unterscheidet sich die Beschreibung von Ausf hrungs rechten in Syntax und Semantik nicht von der der Zugriffsrechte Wir f hren die begriffliche Trennung der Benutzerrechte in Zugriffs und Ausf hrungsrechte nur zur Verdeutlichung ein sodass begrifflich unterschieden werden kann inwiefern es sich bei den Rechten um Zugriffs berechtigungen auf Daten oder auf Ausf hrungsberechtigungen zu Vorgangsmethoden zu Ak tivit ten und Anwendungsf llen handelt Abbildung 6 21 fasst die Unterscheidung zwischen Zugriffs und Ausf hrungsrechten zusammen Bei der Entwicklung von zugriffssicheren Systemen w re es in einigen speziellen F llen m g lich die Zugriffssicherheit nur durch Zugriffsrechte auszudr cken Die Beschreibung mittels 6 3 Berechtigungsmodellierung 115 Zugriffsrechte reicht jedoch in folgenden Fallen nicht aus sodass eine explizite Definition von Ausf hrungsrechten notwendig ist e Externer Code in Form von Systemfunktionen DB Funktionen DB Trigger Applets etc ist auszuf hren und der Zugriff hierzu ist zu beschr nken e Durch die Kombination von Zugriffen innerhalb eines Ablaufs ndert sich der Wert der Info
156. edenen Prozessabschnitten der Anforderungsspezifikation zugriffssiche rer Systeme sind die aktuell zu erstellenden und zu ver ndernden Produktartefakte bez glich der Schutzziele Vertraulichkeit Verbindlichkeit Integrit t und Authentizit t 5 3 Das Vorgehen 81 zu untersuchen So k nnen etwa innerhalb der Gesch ftsprozessmodellierung vertrauli che Daten identifiziert oder Aktivit ten f r die vorab eine Authentifikation notwendig ist ermittelt werden Werden die Schutzziele innerhalb der einzelnen Prozessabschnitte der Anforderungsspezifikation zugriffssicherer Systeme in einem eigenen Arbeitsschritt erarbeitet so kann diese Aktivit t bersprungen werden Besondere Bedeutung hat die Ermittlung der Schutzziele im Sicherheitsmikroprozess vor allem bei der iterativen An wendung da dabei die Schutzziele vorab in keiner eigenen Prozessaktivit t des jeweiligen Prozessabschnitts ermittelt wurden e Modellierung der Bedrohungen F r die innerhalb der vorausgehenden Aktivit t gefundenen Schutzziele sind Bedro hungen zu modellieren d h die Gef hrdungsbereiche sowie die potenziellen organisa torischen technischen und benutzerbedingten Ursachen sind systematisch zu ermitteln siehe Eck03 Hier sind beispielsweise Gef hrdungsbereiche von vertraulichen Daten genauer zu spezifizieren e Bewertung der Risiken Nicht f r jede Bedrohung die ermittelt wurde sind umfangreiche Ma nahmen zur Ab wendung notwendig Ausschlaggebend f r
157. edrohungs und Risikoanalyse erarbeitet werden Dabei werden auf Basis der operationellen Anforderungen und im Hinblick auf das das zu erreichende Sicherheitsziel die Bedrohungen festgestellt und die Risiken ermittelt Es werden diejenigen Bedrohungen als relevant eingestuft die ein nicht akzeptables Risiko bergen Um diese als relevant eingestuften Bedrohungen abzuwehren m ssen geeignete Ma nahmen ergriffen werden Die Gesamtheit aller Ma nahmen bildet das Sicherheitskonzept Im Rahmen der fachlichen Strukturierung werden die Ma nahmen durch Sicherheitsfunktionen realisiert sodass sie den Bedrohungen entgegenwirken k nnen Diese Funktionen werden als sicherheitsspezifische Funktionen be zeichnet da sie direkt zur Sicherheit des Systems beitragen Im Systementwurf ist das System technisch zu entwerfen die Realisierbarkeit zu untersuchen sowie die Anwenderforderungen zuzuordnen Beim technischen Systementwurf sind neben den sicherheitsspezifischen Funktionen auch solche Funktionen gegeben deren korrektes Verhalten f r die Sicherheitsfunktionen unerl sslich ist Diese sicherheitsrelevanten Funktionen tra gen indirekt zur Sicherheit bei wenn sich eine oder mehrere Sicherheitsfunktionen auf diese 58 Ein Prozess zur Entwicklung von Anforderungsspezifikationen Funktionen verlassen Beim Systementwurf ist darauf zu achten dass sowohl die Sicherheits funktionen als auch die sicherheitsrelevanten Funktionen von den nicht als siche
158. ehmern Anforderungsentwicklern und Endanwendern zu Beginn der Gesch ftsprozessmodellierung zu definieren sind Allgemeine Regeln des Gesch ftsprozessmo dells Erg nzungen zur Systembeschreibung und die Architektur sind bei der Erarbeitung der Sicherheitsaspekte mit heranzuziehen aber nicht zu ndern 6 6 Zusammenfassung 139 Business View Gesch ftsprozess Bedrohungs und Modell modell Risikomodell Projektidee Akteure Bedrohungen Projektmission Gesch ftsprozesse Risiken Sicherheitsziel Architektur Ma nahmen Regeln berpr fungsergebnisse Glossar Erg nzungen Dom nenmodell Benutzerrechtemodell Legende erweitert angeordnet verwendet Gesch ftsobjekte Benutzerrechtematrix C hinzugef gt Abbildung 6 34 Produktartefakte der Gesch ftsprozessmodellierung zugriffssicherer Systeme Das Bedrohungs und Risikomodell ist ein eigenes Produktartefakt der Modellierung zugriffssi cherer Systeme Dieses ist in der gew hnlichen Gesch ftsprozessmodellierung nicht vorhanden und wird deshalb zur Systembeschreibung hinzugef gt Bedrohungen und Risiken werden textuell in Auflistungen oder Tabellen beschrieben F r eine Referenzierung sind diese zu nummerieren Ma nahmen k nnen ebenfalls textuell oder se
159. eilen zu streichen Die Berechtigung f r den Anwendungsfall sind aus den Berechtigungen der Aktivit ten zu ermitteln 7 4 Evolution von Berechtigungen 157 m n Werden mehrere Aktivit ten durch mehrere Anwendungsf lle verfeinert jedoch nicht in einer 1 1 Zuordnung so sind m Zeilen der urspr nglichen Benutzerrechtematrix durch n Zeilen zu ersetzen und anzupassen Falls die Benutzerrechte von Anwendungsf llen nicht 1 1 aus Aktivit ten bernommen werden k nnen so muss vor der Bestimmung der Schutzziele der Sicherheitsmikroprozess ausgef hrt werden siehe hierzu Prozessmuster zur Anwendungsfallmodellierung zugriffssicherer Systeme in Abschnitt 17 5 7 3 2 Erg nzung von Sicherheitsanwendungsf llen Neben der Erweiterung von bestehenden Anwendungsf llen sind auch eigene Sicherheitsan wendungsf lle siehe auch Fir03 zu modellieren in welchen die Sicherheitsgrundfunktionen des Systems modelliert sind In diesen Grundfunktionen wird die Basisfunktionalit t der Si cherheitsma nahmen beschrieben Diese Funktionen sind eine Art Baukasten von allgemei nen Ma nahmen zur Abwehr von Bedrohungen m ssen jedoch entsprechend den individuellen Anforderungen des zu konstruierenden Systems angepasst werden Eck03 Sicherheitsanwen dungsf lle umfassen beispielsweise Funktionen zur Authentifikation Autorisierung Rechte verwaltung Beweissicherung und Verschl sselung Die Funktionalit t wird entsprechend der vorgestellten st
160. ein P MOS Ausdruck vom Typ Set Activity im Klassendiagramm oben Abbildung 4 3 4 Assoziationen Gegeben sei eine Assoziation in dem folgenden Klassendiagramm Der P MOS Ausdruck e role ist vom Typ Set D beziehungsweise D im Spezialfall a b 1 1 wenn e ein Ausdruck vom Typ C ist role a b Der Rollenname kann auch weggelassen werden In diesem Spezialfall erh lt die Assoziation den vordefinierten Rollennamen d als klein geschrieben Klassennamen Dies ist allerdings nur m glich wenn dadurch keine Zweideutigkeiten entstehen zum Beispiel bei mehrfachen Assoziationen 38 Akteurzentriertes Modell zur Spezifikation von Benutzerrechten Bei bidirektionalen Assoziationen k nnen Ausdr cke durch Navigation in beide Richtungen gebildet werden Beispiel mewadis projectmanager ist ein P MOS Ausdruck vom Typ User bez glich der in Abbildung dargestellten Asso ziation projectmanager 5 Generalisierung Ist e ein P MOS Ausdruck vom Typ C und C ist Subklasse von Klasse D in der transitiven H lle dann ist e auch ein P MOS Ausdruck vom Typ D Da jedes Objekt einer Subklasse auch Objekt der Superklasse ist wird jeder Ausdruck einer Subklasse auch Ausdruck der Superklasse Diese Eigenschaft wird in vielen Ans tzen auch als Subtyp Polymorphismus bezeichnet 6 Zustandsfunktionen Um die Formulierung von P MOS Ausdr cken zu erleichtern erlaubt P MOS die Definition von Zustandsfunktionen Zustand
161. eine Sonderform des Team Workers vgl Abbildung 6 20 der ProjectManager erh lt somit implizit das Execute Recht f r die Methode process der Vorgangsklasse PCViewProjectInfo Zur Methode process der Vorgangsklasse PC ViewAllTeam Worker ist folgende Permission zu definieren Vtw ACTeamWorker V pe PCViewAllTeamW orker gt perm PCViewProjectInfo process tw pc 6 3 Berechtigungsmodellierung 119 Im Gegensatz zur allgemeinen Permission aus dem vorigen Abschnitt wurde hier die Bedin gung nur f r den konkreten Akteur AC Team Worker spezifiziert Objektstruktur Permission Eine weitere Beschr nkung der Ausf hrung von Aktivit ten ergibt sich dadurch dass die Ausf hrung an Bedingungen ber Objekten oder Objektbeziehungen gekn pft ist Eine Ak tivit t mit einer derart spezifizierten Berechtigung kann nur dann ausgef hrt werden wenn die vorab berpr ften Attribut und Referenzbelegungen von Objekten erf llt sind TeamWorker insert new accounting Abbildung 6 25 Beispiel zur Objektstruktur Permission Abbildung 6 25lzeigt ein Beispiel f r eine Aktivit t die von der Objektstruktur abh ngig ist In unserer TimeTool Fallstudie kann ein TeamWorker nur dann neue Buchungen einf gen wenn die Buchung zu einem seiner Projekte geh rt und wenn die Aktivit t zum Buchen frei gegeben wurde In der folgenden Zugriffsmatrix ist diese Objektstrukturberechtigung textuell als Execute Berechtigung formuliert c
162. eitere Entwicklung ist durch die Integration der Anwendungsf lle in das objektorientierte Modell getrieben In der hybriden Sichtweise werden Klassendiagramme zur Konzeption des Anwendungskerns sowie Anwendungsfalldiagramme zusammen mit schematischen textuellen Beschreibungen als Beschreibungstechniken eingesetzt Die objektorientierte und funktionsorientierte Sicht sind dabei lose gekoppelt und k nnen zeitgleich erstellt werden Diese hybride Sichtweise des Systementwurfs eignet sich zur Fortsetzung unseres bereits vor gestellten Entwurfs der Gesch ftsprozessmodellierung zugriffssicherer Systeme Vorarbeiten 7 1 Grundlagen der Anwendungsfallmodellierung 143 im Bereich der Gesch ftsprozesse werden bei der Beschreibung des Verhaltens wieder verwen det und in Anwendungsfalldiagramme und textuelle Beschreibungen berf hrt Das bereits erstellte Dom nenmodell ist zu bernehmen zu verfeinern und zu erg nzen Bei der Wiederverwendung der Ergebnisse aus der Gesch ftsprozessmodellierung ist insbe sondere zu beachten dass bei der Beschreibung der Gesch ftsprozesse und des Dom nenmo dells auch Bestandteile modelliert worden sein k nnen die nicht automatisiert werden d h die nicht im zu entwickelnden System umgesetzt werden Aus diesem Grund sind bei der berf hrung der Abl ufe diese zun chst anzupassen d h manuelle Aktivit ten sind in den Abl ufen zu entfernen und das Dom nenmodell darf nur Klassen enthalten die in dem aut
163. eitert Diese Erweite rung umfasst folgende nderungen an Standardprodukten 138 Die Geschaftsprozessmodellierung zugriffssicherer Systeme e Klassendiagramme und Aktivit tsdiagramme werden um Klassen und Aktivit ten erweitert e Es werden vollst ndig neue Aktivit tsdiagramme zur Beschreibung von Abl ufen hinzugef gt e In UML Diagrammen werden durch den Erweiterungsmechanismus der UML sie he EP00 Stereotypen Constraints oder Tagged Values zur Be schreibung von Sicherheitsanforderungen eingefiigt e Textuelle Beschreibungen werden erg nzt verwendet Produktartefakte der allgemeinen Modellierung werden innerhalb der Gesch fts prozessmodellierung zugriffssicherer Systeme verwendet aber nicht ver ndert angeordnet Ermittelte Entit ten wie beispielsweise Akteure oder Klassen werden hierar chisch angeordnet Im Rahmen der Spezifikation der Benutzerrechte spielt diese hierar chische Anordnung der Akteure und Klassen eine bedeutende Rolle hinzugef gt Neue Produktartefakte zur Beschreibung von Sicherheitsaspekten werden zu den herk mmlichen Produktartefakten hinzugef gt Erweiterung der Produktartefakte Im Prozessmuster zur Gesch ftsprozessmodellierung zugriffssicherer Systeme wurden die Pro duktartefakte bereits vorgestellt Wir betrachten im Folgenden die Produktartefakte zur Gesch ftsprozessmodellierung zugriffssicherer Systeme sowie die verfeinerten Beziehungen in der vorab vorgestellten Art Abbildung
164. eitskritischen Systemen am System authentifizieren sondern zu Be ginn einer Sitzung mit Ausnahme von einigen Web Anwendungen und Geldautomaten In Hinblick auf die Trennung von Authentifikation und Autorisierung sind innerhalb der modellierten Abl ufe Sitzungen zu ermitteln innerhalb derer ein Akteur im System au thentifiziert ist und Aktivit ten ausf hren kann Die Modellierung von Sitzungen ist Vorstufe f r die Analyse von Authentifikation und Autorisierung Die Modellierung von Sitzungen wird im Abschnitt 7 2 2 diskutiert 7 5 Der Prozess der Anwendungsfallmodellierung zugriffssicherer Systeme 167 Analyse der Anwendungsf lle Basierend auf den Aktivit ten der Gesch ftsprozesse ist das Verhalten in Anwendungs f llen zu verfeinern Im Rahmen der Analyse der Anwendungsf lle sind diese zu ermit teln jedoch noch nicht auszuarbeiten Wie wir bereits im Abschnitt 7 3 1 beschrieben haben werden Aktivit ten nicht immer direkt d h 1 1 Anwendungsf llen zugeordnet sondern m n d h ein oder mehrere Aktivit ten werden einem oder mehreren Anwen dungsf llen zugeordnet Analyse von Authentifikation und Autorisierung Im Rahmen der Modellierung von Sitzungen siehe oben werden in den Abl ufen die jenigen Aktivit ten f r die ein Akteur authentifiziert sein muss gekennzeichnet Da jedoch nicht f r jede Aktivit t die Authentifikation d h die berpr fung der Echt heit und Glaubw rdigkeit des Akteurs durchzuf hren i
165. ekannte wichtigste Ans tze sind die Methode von Coad und Yourdon CY91b OMT vom Rumbaugh et al RBP 91 die Methoden von Booch und Jacobson sowie die Methode von Fusion von Coleman et al CAB 94 Eine Vereinheitlichung und Standardisierung der unterschiedlichen Notationen wurde mit der Entwicklung der Unified Modeling Language UML unternommen Metho dische Rahmenwerke die auf Basis der UML definiert wurden sind beispielsweise der Unified Software Development Process JBR99 der Catalysis Ansatz DW98 oder der Rational Uni fied Process Kru00 2 1 3 Prozessbeschreibung mit Prozessbausteinen Allumfassende Vorgehensmodelle wie zum Beispiel das oben vorgestellte Wasserfallmodell Roy70 sind sehr restriktiv und f r Erweiterungen nicht offen sodass eine methodische Ent wicklung von nichtfunktionalen Aspekten wie beispielsweise die Zugriffssicherheit nur schwer in den Prozess integriert werden k nnen In generischen Prozessmodellen wie zum Beispiel ist der Anpassungsaufwand sehr gro da die Modelle sehr m chtig und umfangreich sind Im Rahmen dieser Arbeit ben tigen wir eine Prozessbeschreibung die es uns erm glicht einen kleinen Teil eines Entwicklungsprozesses in den Gesamtprozess einzuordnen und den kleinen Teil detailliert zu beschreiben Um nicht den Anpassungsaufwand eines generischen Prozessmodells zu unterlaufen verwenden wir im Rahmen dieser Arbeit Prozessbausteine zur Beschreibung der relevanten Teile eines ge
166. ele der gemeinsamen Entwicklung von Funktionalit t und Sicherheit sowie die lokale Spezifikation abgedeckt Die Sicherheitsaspekte werden in kleinen Einheiten spezifiziert sodass diese nicht erst nach Fertigstellung des Gesamtsystems syste matisch aufgebrochen und analysiert werden m ssen Der im Rahmen des Prozessmusters zur Anwendungsfallmodellierung zugriffssicherer Systeme vorgestellte Prozess sowie der Sicherheitsmikroprozess erm glichen eine iterative Entwicklung der Funktionalit t und der Aspekte der Zugriffssicherheit Durch die gezeigte Methode ist die Entwicklung von Aspekten der Zugriffssicherheit fest in den Prozess verankert In Hin blick auf eine durchg ngige und sukzessive Entwicklung sowie eine vollst ndige Beschreibung der Prozessbausteine in Prozessmustern sind auch die Produktartefakte der Anwendungsfall modellierung zugriffssicherer Systeme zentral Die Produktartefakte wurden im Rahmen der Anwendungsfallmodellierung zugriffssicherer Systeme bez glich Informationen zur Beschrei bung von Aspekten der Zugriffssicherheit untersucht Bez glich der nderungen an Struktur und Verhalten sowie der Verfeinerung des Verhaltens in Anwendungsf llen muss das Benutzerrechtemodell angepasst werden Dies wird ebenfalls von 176 Die Anwendungsfallmodellierung zugriffssicherer Systeme einer Anpassung des Akteurmodells getrieben die sich aus der Festlegung der Systemgrenzen ergibt Fiir Teile der Struktur und Verhaltensbeschreibung
167. elle Arbeiten zu einer formalen Fundierung von Benutzerrechten besch ftigen sich mit dem Entwicklungsprozess und der berpr fung von Benutzerrechten in SAP Anwendungen IBMO3l In Wim05 wird ein Ansatz zur modellbasierten Entwicklung sicherheitskritischer Syste me vorgestellt der auf den Ergebnissen der Sicherheitsanalyse sowie der Anforderungsspe zifikation aufsetzt und sich mit der Unterst tzung der nachfolgenden Phasen Verifikation anhand von Bedrohungsszenarien Einf hrung von Sicherheitsmechanismen Testfallgenerie rung besch ftigt Die Grundprinzipien zu Vorgehensmethoden stammen aus dem Gebiet des Software Engineer ings Som00 Einfluss auf den methodischen Teil der Arbeit hatten nahezu alle modernen objektorientierten Softwareentwicklungstechniken Im Kontext dieser Arbeit ist die angewendete Methodik MOS hervorzuheben insbeson dere in Zusammenhang mit dem Konzept der Anwendungsf lle Die hybride Vorgehensweise zur Modellierung von Objekten und Abl ufen in Anwendungsf llen basiert auf den Arbeiten von Jacobson JBR9J9 hnliche Ideen finden sich auch bei in Form von Gesch ftsvorf llen und mit den Systemoperationen in Fusion CAB 94 10 Einf hrung Die vorgestellte Vorgehensweise basiert auf den neueren generischen iterativen objektorien tierten Vorgehensmodellen Bo094 Der Prozessmuster ba sierte Ansatz zur Beschreibung von Vorgehensbausteinen wurde aus Arbeiten von der Pro cess Pattern Community bernomm
168. elt und die Benutzerrechte formalisiert Da die Beschreibungssprache UML Unified Modeling Language im Rahmen von objekt orientierten Vorgehensmethoden in gro em Ma e angewendet wird aber mit ihren grafischen textuellen und formalen Beschreibungen keine geeigneten Notationen zur Modellierung von Aspekten der Zugriffssicherheit innerhalb den fr hen Phasen einer Systementwicklung bie tet werden notwendige Erweiterungen der Beschreibungstechniken vorgestellt Insbesondere werden Stereotypen zur Annotation von Schutzzielen in Aktivit ts und Klassendiagrammen eingef hrt Die erarbeiteten Konzepte der Vorgehensbausteine des Rechtemodells und der erweiterten grafischen Beschreibungstechniken werden prototypisch an einer Fallstudie zur Projektver waltung untersucht Dankesworte Vorab m chte ich mich bei allen bedanken die mich in den letzten Jahren unterst tzt und mir so das Gelingen dieser Arbeit erm glicht haben Ein besonderer Dank geht an Herrn Prof Dr Dr h c Manfred Broy der es mir erm glichte an diesem aktuellen Thema zu arbeiten Die wissenschaftliche Betreuung die gro en Freir ume und das entgegengebrachte Vertrauen geb hren einen besonderen Dank Ein weiterer beson derer Dank ergeht an Frau Prof Dr Ruth Breu f r die zahlreichen inhaltlichen Diskussionen sowie f r die bernahme des Zweitgutachtens Gro er Dank geb hrt auch den Kollegen des MEwaDis Projekts Herrn Martin Deubler Herrn Johannes Gr nbauer un
169. eme werden aus den Sicherheitsanwendungsf llen aus dem mit Sicherheitsaspekten angereichertem Klassendiagramm und aus der Zugriffsmatrix Szena rien modelliert und die identifizierten Sicherheitsanforderungen und ziele in diesen Szenarien umgesetzt Abbildung 5 6 gibt einen berblick ber die Anforderungsspezifikation zugriffssicherer Syste me mit ihren drei Prozessabschnitten F r eine schrittweise Erarbeitung der Aspekte der Zugriffssicherheit in den einzelnen Pro zessabschnitten wird innerhalb jedes Abschnitts der Sicherheitsmikroprozess ausgef hrt in dem die Schutzziele erarbeitet die Bedrohungen modelliert und die Risiken bewertet sowie Ma nahmen erarbeitet und berpr ft werden Eine genaue Beschreibung des Sicherheitsmi kroprozesses wird im Prozessmuster zum Sicherheitsmikroprozess im Abschnitt gegeben Gesch ftsprozess N Anwendungsfall A j 5 nalyse modellierung modellierung zugriffssicherer zugriffssicherer zugriffssicherer S nn Systeme Systeme Abbildung 5 6 Die Phasen der Anforderungsspezifikation zugriffssicherer Systeme 5 3 Das Vorgehen 77 Die mehrmalige Anwendung des Sicherheitsmikroprozesses innerhalb der einzelnen Phasen fiihrt zu einer iterativen Erarbeitung der Anforderungen an die Zugriffssicherheit Besonders im Bereich der Sicherheitsmodellierung ist eine derartige iterative Vorgehensweise von beson derer Bedeutung da spezifizierte funktionale oder strukturelle Eigenschaften oftmals durch gege
170. en e Ma nahmen der Sicherheitsanalyse in der Gesch ftsprozessmodellierung zugriffssicherer Systeme Wurden dabei Ma nahmen zur Abwehr von Bedrohungen getroffen die sich auf die Struktur des Anwendungskerns auswirken so sind diese nderungen am Anwen dungskern bei dieser erneuten Ausf hrung des Sicherheitsmikroprozesses zu beachten Beispielsweise wurde in unserer Time Tool Fallstudie zur Nichtabstreitbarkeit von nde rungen an Buchungen eine Logging Klasse im Anwendungskern eingef gt Schutzziele und Bedrohungen auf diese Logging Klasse m ssen spezifiziert werden Der Sicherheitsmikroprozess muss auf folgende nderungen in den Ablaufbeschreibungen Ein fluss nehmen 7 6 Produktartefakte der Anwendungsfallmodellierung sicherer Systeme 173 e Anpassung der Gesch ftsprozesse an die Funktionalit t des Systems Bedingt durch die Festlegung der Grenzen des Systems sind auch die Abl ufe zu berarbeiten d h ma nuelle Aktivit ten oder gesamte manuell ausf hrbare Gesch ftsprozesse sind von der Beschreibung der Systemfunktionalit t zu entfernen Die zu automatisierenden Abl ufe m ssen an diese nderungen angepasst werden und Aktivit ten zur Interaktion mit externen Systemen sind zu spezifizieren nderungen und Erg nzungen der Abl ufe m ssen bez glich Aspekten der Zugriffssicherheit untersucht werden e bergang von Gesch ftsprozessen zu Anwendungsf llen Wie in Abschnitt 7 3 beschrie ben wurde wird das Verhalten a
171. en Die Studien zu den Gesch ftsprozessen und zur Unter nehmensmodellierung basieren auf den Arbeiten von Hans Erik Eriksson und Magnus Penker EP00 Josef Staud Sta01 Helmut Balzert Bal98 und Philippe Kruchten Kru00 2 Grundlagen Zu Beginn der Arbeit geben wir einen kurzen berblick ber die beiden Themenschwerpunkte in die sich diese Arbeit eingliedert Die Arbeit beschreibt eine Methode zur Integration von Sicherheitsanforderungen in die Entwicklung zugriffssicherer Systeme Eine Methode liefert Vorgaben f r ein systematisches Vorgehen bei der Softwareentwicklung Der Begriff umfasst sowohl einzelne Aktivit ten wie Analyse Entwurf oder Programmierung als auch die Softwareentwicklung insgesamt RP97 Methoden verk rpern eine Sicht der Soft wareentwicklung beziehen sich dabei auf einen Einsatzbereich und geben Richtlinien in Form von Techniken Mitteln und Organisationsformen an Auf Vorgehensmodelle die die Grund lage zu den Methoden bilden und die Prozesse der Softwareentwicklung in berschaubare Abschnitte aufteilen gehen wir in Abschnitt 2 1lein Das zweite zentrale Themengebiet der Arbeit ist die Zugriffssicherheit Darunter verstehen wir die Summe aller Ma nahmen die durchzuf hren sind um unautorisierten Benutzern den Zugriff auf gesch tzte Systemressourcen zu verwehren Auf grundlegende Begriffe zur Sicherheit Ziele der Schutzma namen und Techniken gehen wir in Abschnitt 2 2 genauer ein 2 1 Vorgehensmodel
172. en die sich in dem zu realisierenden System nicht wieder finden d h die sp ter nicht umgesetzt werden F r derartige Objekte kann eine Spezifikation der Rechte jedoch ebenfalls sinnvoll sein denn die Zugriffsrechte k nnen auch Berechtigungen im manuellen Ablauf festlegen F r manuelle Abl ufe reicht jedoch die textuelle Spezifikation der Berechtigungen aus da eine Generierung von Zugriffsmethoden hier nicht erforderlich ist Eine pr zise formale Spezifikation der Zu griffsrechte ist hier nicht m glich wenn der Zusammenhang des manuell zu verarbeitenden Objekts mit der internen Objektstruktur der Gesch ftsprozessmodellierung nicht festgelegt wurde Die Zugriffsrechte werden innerhalb einer Berechtigungsmatrix abgelegt wie dies bereits im Kapitel 4 vorgestellt wurde 6 3 3 Modellierung von Ausf hrungsrechten Neben den Benutzerrechten auf Datenobjekten die wir als Zugriffsrechte bezeichnen sind bei der Rechtemodellierung auch die Ausf hrungsrechte festzulegen Ausf hrungsrechte le gen fest welche Akteure die Berechtigung haben einen Ablauf in diesem Kapitel in Form von Ausf hrungsrechten f r Aktivit ten in sp teren Kapiteln in Form von Ausf hrungs rechten f r Anwendungsf lle auszuf hren Dabei handelt es sich um die Festlegung von Execute Berechtigungen auf Methoden w hrend Zugriffsrechte Read Write oder Create Berechtigungen auf Attribut Zugriffsmethoden festlegen Benutzerr
173. en Entit t d h einem Benutzer oder einem weiteren System eine Menge von Aktivit ten zur Verf gung f r die sie autorisiert ist Hierzu untersuchen wir im Folgenden wie in den verfeinerten Abl ufen der Gesch ftsprozessmodel lierung zugriffssicherer Systeme die Authentifikation in Verbindung mit so genannten Sitzun gen engl sessions modelliert werden und wie wir Sitzungen in den bereits modellierten Abl ufen beschreiben k nnen Aus diesen Sitzungen leiten wir so genannte Authentifikations anwendungsf lle ab und integrieren diese in die Abl ufe 7 2 1 Authentifikation Bei der Authentifikation berpr fen wir die Echtheit und Glaubw rdigkeit einer ausf hrenden Entit t anhand ihrer eindeutigen Identit t und ihrer charakteristischen Eigenschaften vgl Eck03 Ausf hrende Entit ten sind im Rahmen der von uns betrachteten Systeme Akteure als Instanz von Rollen sowie weitere externe Systeme die mit dem zu entwickelnden System interagieren In herk mmlichen Systemen basiert eine Identifikation auf der Vergabe von eindeutigen Be nutzerkennungen oder Benutzernamen Charakteristische Eigenschaften zum Nachweis der Identit t sind beispielsweise Passworte deren Kenntnis der Benutzer beim Systemzugang nachweisen muss oder biometrische Merkmale wie Fingerabdr cke Im Rahmen der Betrach tung von offenen Systemen wird diese einseitige Authentifikation siehe auch RE99 ein seitige Authentisierung zunehmend durch eine gegenseitig
174. en Login Maske durch Benut zerkennwort und Passwort zu sch tzen Die Zugriffssicherheit konnte hierbei mit einfachen Mitteln gew hrleistet werden Durch die zunehmende Vernetzung Verteiltheit und Mobilit t der Systeme w hrend der letz ten Jahre ergeben sich v llig neue Angriffsm glichkeiten auf einzelne Rechner spezielle An wendungen oder ganze Rechnernetze Beispielsweise k nnen Angreifer durch die Anbindung der Rechner an ffentliche Netze versuchen die ber das Netz ausgetauschten Informationen mitzulesen oder direkt auf die Rechner zu gelangen um Daten auszuspionieren oder um ille gal Applikationen auf fremden Rechnern auszuf hren Um derartige und weitere Angriffe auf Rechner zu verhindern ist es notwendig zugriffssichere Systeme zu entwickeln die Angriffe sowohl auf die Rechner selbst sowie auch auf die zu bertragenden Daten erfolgreich abwehren k nnen 2 Einf hrung Die Softwarekrise in den 60er Jahren des letzten Jahrhunderts siehe Bal96 hat gezeigt dass die Entwicklung softwareintensiver Produkte schwierig ist und dass hierzu konkrete Vorge hensweisen zur Strukturierung und Beschreibung angewendet werden m ssen Da f r die Ent wicklung von zugriffssicheren Systemen zus tzlich Aspekte der Zugriffssicherheit betrachtet werden m ssen steigt mit der Komplexit t der Systemanforderungen auch die Schwierigkeit der Systementwicklung und die Fehleranf lligkeit vgl Jiir04 der Systeme Die Notwendig keit vo
175. en Methoden immer wieder zu Problemen gef hrt sodass die Entwicklung von neueren Ans tzen vorangetrieben wurde 2 1 2 Objektorientierte Vorgehensmodelle Die zu entwickelnden Softwaresysteme wurden ber die Jahre immer gr er sodass die Kom plexit t der Softwareentwicklung stets anstieg und mit der Top Down Vorgehensweise der strukturierten Vorgehensweisen nur schwer in den Griff bekommen zu waren Die Modell br che in der funktionsorientierten Softwareentwicklung und der Beginn der objektorientier ten Programmierung in den 90er Jahren f hrten dazu dass erste Methoden zur objektorien tierten Softwarekonstruktion entstanden wie zum Beispiel HS93 Die Objektorientierung stellt dabei die Gegenst nde der Anwendungswelt in den Vorder grund die abstrakt oder konkret sein k nnen Auf den Gegenst nden k nnen Operationen durchgef hrt werden die auf den gekapselten Daten arbeiten Diese Operationen werden nicht zu standardisierten Abl ufen zusammengesetzt sondern als Dienstleistungen zur Benutzung angeboten Ein wichtiges Strukturierungsmerkmal f r Entw rfe und die Softwarearchitektur sind Konzepthierarchien die programmiertechnisch durch Vererbung umgesetzt werden vgl RP97 Die Objektorientierung bietet die M glichkeit Beschr nkungen strukturierter Methoden zu berwinden d h Daten zusammen mit Operationen zu modellieren existierende Systeme fle xibel zu erweitern und st ckweise zu integrieren F r alle Ebenen wird
176. en Schutzziele an die neuen und verfeinerten Modelle im System anzupassen und ebenfalls zu verfeinern Um zu vermeiden dass neu hinzugef gte oder ge nderte Systemanforderungen keiner Si cherheitsanalyse unterzogen werden m ssen auch wie bei der Gesch ftsprozessmodellierung zugriffssicherer Systeme Schutzziele sowie Bedrohungen Risiken und Ma nahmen ermittelt werden Bei der Ablaufmodellierung ist zudem das Schutzziel Authentifikation zu betrachten sodass geeignete Zeitpunkte und Techniken zur Authentifikation und Autorisierung ermittelt werden k nnen Problem Bei der Anwendungsfallmodellierung werden aus den Gesch ftsprozessen und dem Dom nen modell die Anforderungen an das System abgeleitet Struktur und Verhalten werden dabei verfeinert Bekannte Verfahren zur Entwicklung der Systemanforderungen DW98 beschr nken sich hier auf die Modellierung der Funktionalit t die Transformation von nichtfunktionalen Anforderungen wie zum Beispiel die Zugriffssicherheit bleibt au en vor Zu Beginn der Anwendungsfallmodellierung ist festzulegen welche von den ermittelten Ge sch ftsprozessen in dem zu entwickelnden System umgesetzt werden Dadurch dass nun die nicht zu automatisierenden Abl ufe entfallen sind die entwickelten funktionalen Modelle nicht mehr konsistent Da wir die Anforderungen der Zugriffssicherheit gemeinsam mit der Funk tionalit t ermitteln f hren Inkonsistenzen und L cken in den funktionalen Modellen und Besch
177. en an den Produkten des Produktmodells innerhalb der Anwendungsfallmodel lierung zugriffssicherer Systeme sind in der in Abschnitt 6 5 vorgestellten Art gekennzeichnet Die Produkte des Bussiness View Modells Projektidee Projektmission und globales Sicher heitsziel werden bei der Anwendungsfallmodellierung zugriffssicherer Systeme betrachtet jedoch nicht ver ndert ebenso der berblick ber die Architektur die globalen Regeln und allgemeine Erg nzungen aus dem Gesch ftsprozessmodell Alle diese Produkte sind Rahmen bedingungen f r die Sicherheitsanalyse Das Glossar wird mit neu eingef hrten Begriffen erg nzt Durch die Festlegung der Systemgrenzen sind die zu automatisierenden Gesch ftspro zesse auszuw hlen und die Abl ufe gegebenenfalls mit weiteren Aktivit ten und Assoziationen zu erg nzen Insbesondere sind hier Aktivit ten zur Authentifikation einzubringen und die Au torisierung festzulegen Die Akteure werden ebenfalls an die Systemgrenzen angepasst Dabei sind auch externe Systeme zu den Akteuren hinzuzuf gen und hierarchisch anzuordnen 174 Die Anwendungsfallmodellierung zugriffssicherer Systeme Business View Gesch ftsprozess Bedrohungs und Modell modell Risikomodell Projektidee Akteure Bedrohungen Projektmission
178. en in nerhalb den Swimlanes Akteur Rollen zugeordnet sind Diesen Akteur Rollen wurden wie in Abbildung 4 5 gezeigt bereits Akteurklassen zugeordnet sodass in den process Methoden Akteur spezifisiche Ausf hrungsrechte definiert werden k nnen 6 3 Berechtigungsmodellierung 117 In Abbildung sind auch nochmals die zum internen Klassendiagramm der Time Tool Fallstudie hinzugef gten Akteurklassen ACOthers ACTeamWorker ACProjectManager und ACAdministrator dargestellt In den process Methoden der Vorgangsklassen PC Activity1 und PCActivity2 k nnen Ausf hrungsberechtigungen f r diese Akteure spezifiziert werden 6 3 3 2 Modellierung der Ausf hrungsrechte Die im vorausgehenden Abschnitt eingef hrten Ausf hrungsrechte k nnen f r Rollen oder Individuen von Rollen vergeben werden Weiterhin k nnen Ausf hrungsrechte auch an Be dingungen ber Individuen oder Rollen gekn pft werden Im Folgenden diskutieren wir die verschiedenen Arten von Ausf hrungsrechten All Role Permission TeamWorker view project info ProjectManager view project info Administrator view project info Others view project info Abbildung 6 23 Beispiel zur unbeschr nkten Ausf hrung Aktivit ten im System die keiner Einschr nkung bez glich der Ausf hrungsrechte unterlie gen sind die allgemeinste Form der Ausf hrungsrechte Diese Aktivit ten d rfen unabh ngig vom aktuellen Akteur ausgef
179. en werden ist der Schutz der Daten eng mit den zwei Sicherheitsaspekten Authentifizierung und Zugriffskontrolle verkn pft W hrend sich die Authentifizierung damit besch ftigt agierende Akteure im System zu identifizieren betrachtet die Zugriffskontrolle siehe hierzu Abschnitt den Schutz von Informationsquellen Mit dem bekannten RBAC Modell wurde ein geeignetes Paradigma zur Implementierung von Benutzerrechten entwickelt Trotz des darin eingef hrten Rollenpa radigmas vgl Abschnitt 4 2 2 bleibt die Zugriffskontrolle in realen Anwendungen eine schwie rige und komplexe Aufgabe Die Zugriffskontrolle betrifft in den meisten F llen verschiedene Schichten angefangen von der Dialogschicht mit der Benutzerschnittstelle bis hin zur Anwen dungsschicht und Datenbankschicht vgl Schichtenarchitekturen in Bre01 Dar ber hinaus ben tigen wir f r neu entstehende B2B Anwendungen neue berechtigungs basierte Techniken zur Gew hrleistung von Benutzerrechten vgl MFSK97 Gesch ftsprozess Anwendungsfall g Analyse modellierung modellierung Spezifikation von ER gt textuell Benutzer tEn pri gt Z Abbildung 4 1 Beschreibung von Benutzerrechten in der Anforderungsspezifikation Trotz der Komplexit t der Aufgabe wurde bis jetzt eine Rechtemodellierung innerhalb der Analysephase in der Literatur nicht erw hnt Die Entwicklung von Rechtekonzepten f r gro e Anwendungen wie beispielsweise in den Bereichen Gesundheit E
180. enutzergruppen so genannten Rol len den Zugang zum System Neben Projektmitarbeitern sind spezielle Zug nge f r die Rollen Projektleiter und Administrator vorhanden weitere Benutzer werden in der Rolle Andere zu sammengefasst TimeTool untersch tzt auch verschiedene Sichten auf die Projektdaten Zum Beispiel kann sich ein Projektmitarbeiter die geleisteten Stunden zu einem Projekt oder ein Projektmanager die Gesamtheit der bereits verbuchten Stunden anzeigen lassen Das mehrbenutzerf hige System TimeTool wurde in Java mit einer Swing Oberfl che und einer Oracle Datenbank realisiert 3 2 1 System berblick Wie bereits beschrieben befassen sich die umgesetzten Funktionen in erster Linie mit der Termin und Ressourcenplanung Zielgruppe des Systems TimeTool sind die Akteure Projekt mitarbeiter Team Worker Projektmanager Project Manager Administrator und Andere Others Die derzeitige Realisierung des Systems umfasst im Wesentlichen die Funktionen Anmeldung im System Verwaltung von Benutzerdaten Verwaltung von Projektdaten Planen von Pro jekten Analysieren von Projekten Buchen von Stunden f r Projektaktivit ten Anzeige von Projektdaten sowie die Archivierung von Projekten Eine Fallstudie Das Projektverwaltungssystem TimeTool gt aN neun Project Manage view all team worker insert new accounting account online account offline adjust accountings administrate user data Crete new projec gt
181. er Rolle sein f r die die Berechtigung erteilt wurde Im Zusammenhang mit gro en Informationssystemen wie sie in Unternehmen und Beh rden eingesetzt werden sind Aufgaben und Zust ndigkeiten innerhalb von Abteilungen und Pro jekten oftmals hierarchisch zu ordnen Durch die Erweiterung um eine partielle Ordnung auf den Rollen lassen sich mit dem RBAC Modell auch hierarchische Berechtigungsstrukturen erfassen Wir erweitern hierzu das gegebene Modell wie folgt e Die Relation rh C RL x RL ist eine partielle Ordnung auf den Rollen bezeichnet als Vererbungsrelation geschrieben als gt wobei r gt ra nur dann gilt wenn alle Berechti gungen von ra auch Berechtigungen von r sind und alle Subjekte von r auch Subjekte von ra sind 4 3 Der Spezifikationsrahmen P MOS 35 e Die Funktion as r RL 2 ist eine Abbildung der Rolle r auf eine Menge von Subjekten welche die autorisierten Subjekte liefert e Die Funktion ap r RL 2 ist eine Abbildung der Rolle r auf eine Menge von Berechtigungen welche die autorisierten Berechtigungen liefert Die Vererbung von Benutzerrechten kann jedoch auch problematisch sein da dadurch ein Subjekt unter Umst nden mehr Rechte erh lt als es zur Erf llung einer Aufgabe ben tigt Mit einem derartigen RBAC Modell sind Objekte anwenderspezifisch modellierbar und die Zugriffsberechtigungen f r Objekte k nnen somit aufgabenbezogen vergeben werden Mit der RBAC Strategie lassen sich die
182. er Umst nden die Aspekte der Zugriffssicherheit in hn lichen Abl ufen mehrfach spezifiziert Auch f r Abl ufe auf operierenden Daten als auch f r die Daten selbst werden potenzielle Angriffsziele ermittelt Da jedoch die Sicherheit nur dann gew hrleistet werden kann wenn alle Abl ufe und Daten hinreichend betrachtet wurden ist dieser Overhaed innerhalb der Sicherheitsmodellierung zu tolerieren In Beziehung stehende Prozessmuster bergeordneter Prozess e Prozessmuster zur Anforderungsspezifikation zugriffssicherer Systeme siehe Abschnitt 5 3 2 Auszuf hrender Teilprozess e Prozessmuster zum Sicherheitsmikroprozess siehe Abschnitt 5 3 3 Weitere referenzierte Prozessmuster e Prozessmuster zur Anwendungsfallmodellierung zugriffssicherer Systeme siehe hierzu Abschnitt 7 5 1 6 4 Der Prozess der Gesch ftsprozessmodellierung zugriffssicherer Systeme 131 6 4 2 Anwendung des Sicherheitsmikroprozesses Innerhalb des Prozesses zur Gesch ftsprozessmodellierung zugriffssicherer Systeme wird erst mals der im Prozessmuster 6 3 vorgestellte Sicherheitsmikroprozess angewendet wobei Bedro hungen Risiken und Ma nahmen f r mit Schutzzielen annotierte Aktivit ten und Objekte des Dom nenmodells ermittelt werden Im Folgenden zeigen wir exemplarisch an unserer TimeTool Fallstudie die Anwendung des Sicherheitsmikroprozesses Modellierung von Bedrohungen und Bewertung der Risiken Im Abschnitt 6 2 1 haben wir im Dom nenmo
183. er zentrale Begriff f r die Erfassung einzelner Benutzer und ihrer Rollen in der Gesch ftspro zessmodellierung und in der Anwendungsfallmodellierung ist der des Akteurs Beispielsweise steht der Akteur im Gesch ftsprozessmodell f r eine Person oder genauer betrachtet f r die Rolle in der die Person im Gesch ftsprozess agiert Weiterhin k nnen Akteure in der Anwendungsfallmodellierung auch die Rolle von externen Systemen bernehmen Die zugrunde liegende Idee f r die Modellierung von Benutzerrechten in unserem Ansatz besteht darin dass Akteure auf den Objekten des Klassendiagramms diverse Berechtigun gen besitzen vgl Abbildung 4 4 In dieser Hinsicht referenziert unser Benutzerrechtemodell 40 Akteurzentriertes Modell zur Spezifikation von Benutzerrechten i TeamWorker ProjectInfo ActivityType has permission to gt rate gt Project Activity User Accounting has permission to PCView PCInsertNew ProjectInfo Accounting gt execute gt PCAdjust Accounting Abbildung 4 4 Akteure besitzen verschiedene Benutzerrechte auf Objekten sowohl das Modell mit dem Akteur das Gesch ftsprozessmodell oder das Anwendungsfall modell als auch das Klassenmodell Die Trennung des Rollenkonzepts von den Klassen hat den Vorteil dass die Art und Weise wie Rollen im System darzustellen sind nicht innerhalb der Erarbeitung der Anforderungen gel st werden muss In den fr he
184. ere Abarbeitung der Methode fehl was in den gegebenen F llen auch das Ziel sein soll Zur Verdeutlichung dieser Eigenheit der Benutzerrechtespezifikation verwenden wir bei der Beschreibung der Berechtigungen eine differenzierte Schreibweise Mit dem Symbol zwischen der linken und der rechten Seite heben wir hervor dass von dem Ausdruck der rechten Seite nicht selbstverst ndlich der boolsche Wert true erwartet wird Das Ergebnis ist also different w hrend bei Vor und Nachbedingungen stets der Wert true erwartet wird und dies mit einem einfachen zwischen linker und rechter Seite des Bedingungsausdrucks dargestellt wird Die Repr sentierungsfunktion rolerep wird hier wieder als Anfrageoperation der Akteurhie rarchie verwendet wie dies im Abschnitt 4 4 1leingef hrt wurde und wie die Funktion rolerep in den Beispielen in Abschnitt 4 4 2 bereits verwendet wurde Beispiel la Ein Projektmitarbeiter team worker kann alle seine eigenen Buchungen lesen unabh ngig von dem Projekt zu dem die Buchungen geh ren veranschaulicht an der Berechtigung zur Methode get AccountingDate context Accounting getAccountingDate perm act ACTeamWorker self user act rolerep Beispiel 1b Ein Projektleiter project manager kann alle Buchungen zu eigenen Projekten lesen veran schaulicht an get AccountingDate 4 6 Erweiterungen 47 context Accounting getAccountingDate perm act ACProjectManager self ac
185. ergrund treten d rfen d h dass Sicherheitsaspekte in einer eigenen Iteration am Ende ermittelt werden Bei den vorgestellten Iterationsm glichkeiten kann das System in kleineren Inkrementen entwickelt werden Sicherheitsaspekte sind dabei in jeder Iteration durchgehend zu ermitteln Wie bereits bei der Gesch ftsprozessmodellierung zugriffssicherer Systeme erw hnt erfordert dieses Verfahren der integrierten Entwicklung von Sicherheitsaspekten zus tzlichen Aufwand Besonders bei der Entwicklung der Anwendungsf lle m ssen gegebenenfalls Schutzziele Be drohungen Risiken und Ma nahmen aus der Gesch ftsprozessmodellierung zugriffssicherer Systeme erneut berpr ft werden Dem ist jedoch entgegenzuhalten dass es f r die Ent wicklung von zugriffssicheren Systemen nicht ausreicht Sicherheitsaspekte in einem einzigen Durchgang zu ermitteln W hrend bei der Entwicklung von funktionalen Anforderungen das Ziel klar vor Augen und direkt verfolgt werden kann m ssen bei der Entwicklung der Zugriffs sicherheit alle potenziellen Angriffe und somit Verletzungsm glichkeiten des Systems erfasst werden Der zus tzliche Overhead in der Analyse ist somit gerechtfertigt 172 Die Anwendungsfallmodellierung zugriffssicherer Systeme In Beziehung stehende Prozessmuster Ubergeordneter Prozess e Prozessmuster zur Anforderungsspezifikation zugriffssicherer Systeme siehe Abschnitt 5 3 2 Auszuftihrender Teilprozess e Prozessmuster zum Sicherheit
186. ermeiden m ssen Anwendungsf lle die den Wert der Informa tion erh hen durch eigens definierte Ausf hrungsrechte gesch tzt werden Wie insbesondere die zuletzt genannte Einschr nkung zeigt kann es notwendig oder sinnvoll sein dass f r einzelne Anwendungsf lle bzw Aktivit ten die Benutzerrechte nicht berech net sondern spezifiziert werden Hierbei k nnen zus tzliche Bedingungen spezifiziert werden sodass der Benutzerzugriff noch weiter eingeschr nkt wird Weiterhin ist es auch m glich die Benutzerrechte f r Anwendungsf lle zu spezifizieren und f r Datenobjekte zu berechnen Innerhalb eines Ablaufs wird dann f r alle Datenzugriffe die Berechtigung des Anwendungsfalls bernommen Werden dieselben Daten von verschiede nen Anwendungsf llen gelesen und manipuliert so errechnen sich die Zugriffsrechte aus der Kombination der Ausf hrungsrechte der Anwendungsf lle die auf die Daten zugreifen Da wir jedoch in unserem Ansatz davon ausgehen dass die Zugriffsrechte spezifiziert werden verfolgen wir innerhalb dieser Arbeit diesen Ansatz nicht weiter Berechnung der Ausf hrungsrechte Sei einer Aktivit t ein Anwendungsfall zugeordnet und in diesem Anwendungsfall seien ein e xemplarischer Ablauf sowie Ablaufvarianten definiert Dieser exemplarische Ablauf beschreibt eine Abfolge von Methodenaufrufen wobei Methoden aufgerufen werden die sich entweder in weitere Methodenaufrufe zerlegen lassen oder nicht weiter zerlegt werden k
187. errechtematrix sind keine nderungen an der Matrix erforderlich Werden innerhalb der Analyse zugriffssicherer Systeme noch weitere Fach oder Inter aktionsklassen zum Klassendiagramm hinzugef gt so sind gegebenenfalls weitere Zu griffsrechte zu spezifizieren Diese leiten sich aus der Anwendung des Sicherheitsmikro prozesses ab Ebenso wie bei der Modellierung der Ausf hrungsrechte sind alle noch textuell spezifi zierten Zugriffsrechte in eine pr dikative Form zu verfeinern 188 Die Analyse zugriffssicherer Systeme Produktartefakte Die folgende Auflistung beschreibt die Eingaben und Ausgaben zum Prozess der Analyse zu griffssicherer Systeme Um Sicherheitsaspekte erweiterte Standardproduktartefakte sind ge kennzeichnet Eingabe Produktartefakte e Business View Modell aus der Startphase e Dom nenmodell mit Sicherheitsaspekten erweitert e Gesch ftsprozessmodell mit Sicherheitsaspekten erweitert e Anwendungsfallmodell mit Sicherheitsaspekten erweitert e Bedrohungs und Risikomodell e Benutzerrechtemodell Ausgabe Produktartefakte e Anwendungsfallmodell mit Sicherheitsaspekten erweitert e Analysemodell mit Sicherheitsaspekten erweitert e Bedrohungs und Risikomodell erweitert und verfeinert e Benutzerrechtemodell erweitert und verfeinert Kontext Dieses Prozessmuster kann nur im Rahmen einer Anforderungsspezifikation zugriffssicherer Systeme vgl Abschnitt 5 3 2 basierend auf einem objektorienti
188. ert 6 2 Spezifikation der Schutzziele in Struktur und Verhalten 97 6 2 1 Schutzziele in den Gesch ftsobjekten des Dom nenmodells Im Rahmen der Identifikation von Gesch ftsobjekten innerhalb der Geschaftsprozessmodel lierung sind die Gesch ftsobjekte bez glich ihrer potenziellen Angriffsm glichkeiten zu unter suchen Als zentrale Fragestellung f r die Untersuchung der Angriffe ist zu kl ren inwiefern einzelne oder mehrere Attribute der Gesch ftsobjekte potenzielles Angriffsziel f r e unerlaubten lesendem Zugriff e unerlaubter Manipulation oder e Verbindlichkeit des lesenden Zugriffs bzw der Manipulation sind Falls ein oder mehrere dieser potenziellen Angriffsziele f r ein Gesch ftsobjekt erf llt sind so ist die zugeh rige Klasse im Dom nenmodell der Gesch ftsprozessanalyse zu anno tieren lt lt Confidentiality gt gt lt lt Integrity gt gt lt lt NonRepudiation gt gt Class A Class B Class C Il Il G I N Class A SEC Class B SEC Class C Abbildung 6 3 Stereotypen zu den Schutzzielen der Gesch ftsobjekte Zur Annotation von potenziellen Angriffen fiihren die in Abbildung gezeigten Stereoty pen ein Wir kennzeichnen ein Klasse mit dem Stereotyp lt Confidentiality gt falls die Klasse Attribute enthalt die vor unerlaubten Leseangriffen zu schiitzen sind Sind Attribute der K
189. erten Vorgehensmodell aus gef hrt werden F r die Ausf hrung des Prozessmusters werden mit Schutzzielen annotier te Klassen und mit Sicherheitsaspekten erg nzte Anwendungsf lle vorausgesetzt Weiterhin m ssen die Benutzerrechte in einer Benutzerrechtematrix spezifiziert werden Der Fokus die ser Analyse zugriffssicherer Systeme liegt auf einer Neuentwicklung eines betrieblichen Infor mationssystems Aktivit ten zur Analyse bestehender Systeme sind kein Bestandteil dieses Prozessmusters Neben den Entwicklungsschritten sind auch projekt bergreifend Managementaufgaben durch zuf hren auf die jedoch im Rahmen dieses Prozessmusters nicht n her eingegangen wird Struktur Innerhalb der L sung wurde bereits der Ablauf der Analyse zugriffssicherer Systeme skizziert Im Aktivit tsdiagramm in Abbildung 8 6list der verfeinerte Ablauf dargestellt Zudem werden auch geeignete Iterationsm glichkeiten aufgezeigt Die Entwicklungsphase der Analyse kann inkrementell ausgef hrt werden Insbesondere k n nen die Analyse Packages die zu Beginn der Analyse zugriffssicherer Systeme definiert werden schrittweise umgesetzt werden Die Identifikation von Klassen und die Realisierung der An wendungsf lle kann vollst ndig oder nur teilweise abgeschlossen sein bevor einzelne Klassen im Detail spezifiziert werden Nach der Analyse der Klassen steht es dem Entwickler offen weitere Packages oder Klassen und Anwendungsfallrealisierungen zu erarbeiten ode
190. erung Spezifikation Ermittlung von Monts eran von Gesch fts von Schutzzielen Modellierung Bedrohungen S prozessen und in Abl ufen und der Akteure Risiken und de en Dom nenmodell Dom nenmodell Ma nahmen Abbildung 6 30 Die Aktivit ten der Gesch ftsprozessmodellierung zugriffssicherer Systeme potenziellen Bedrohungen zu ermitteln und die Risiken als Eintrittswahrscheinlichkeit der Bedrohung sind zu bestimmen Weiterhin sind geeignete Ma nahmen f r eine Gegenabwehr zu finden und diese Ma nahmen sind auf ihre Tauglichkeit zu berpr fen Abbildung 6 30 gibt einen berblick ber die Aktivit ten der Gesch ftsprozessmodellierung zugriffssicherer Systeme Die Aktivit ten die sich mit der Analyse der Sicherheitsaspekte befassen sind dabei grau hinterlegt Besondere Bedeutung bei der Ausf hrung der Aktivit ten zur Gesch ftsprozessmodellierung zugriffssicherer Systeme liegt dabei auf der Zusammenarbeit von Anforderungsentwicklern Auftragnehmern Auftraggebern und Anwendern bei der Bestimmung der Sicherheitsaspekte Sowohl bei der Ermittlung der sicherheitskritischen Aktivit ten als auch bei der Identifizierung der schutzbed rftigen Objekte werden herk mmliche Bearbeitungsschritte und Dokumente analysiert Der Umgang der Anwender mit den Dokumenten sowie der genaue betriebsinterne Ablauf sind wichtige Informationen f r die Behandlung der Abl ufe und Daten im System Weiterhin k nnen zus tzliche Sicherheitsanforderungen d
191. es Objekts Wir kennzeichnen dies durch ein Schutzziel Icon mit dem Label A an der gestrichelten Linie des Objektflusses wie dies in der oberen H lfte von Abbildung 6 15 dargestellt ist Um jedoch sicherzustellen dass der Sender mit dem gew nschten Server und nicht mit einem anderen Server kommuniziert ist eine zweiseitige Authentifikation engl mutual authenti cation And0l Eck03 RE99 erforderlich Wir kennzeichnen dies durch ein Schutzziel Icon m Tona eee os Fc o Abbildung 6 15 Schutzziel Authentifikation in Objektfliissen P F ig cal 5 i Ig 6 2 Spezifikation der Schutzziele in Struktur und Verhalten 109 mit dem Label A vgl Abbildung 6 15 untere H lfte Die zweiseitige Authentifikation ist beispielsweise in Zukunft im Bereich des Mobilfunks geplant Derzeit antwortet ein mobiles Ger t immer derjenigen Basisstation die das st rkste Signal aussendet Errichtet ein Angrei fer eine Basisstation mit einem st rkeren Signal so authentifiziert sich eine mobile Station beim Angreifer Im Rahmen der Gesch ftsprozessmodellierung wird die allgemeine Authentifikation neben der Authentifikation der Flussobjekte nicht weiter betrachtet Eine detaillierte Betrachtung der Authentifikation findet im Rahmen der Anwendungsfallmodellierung zugriffssicherer Systeme in Kapitel 7 statt Project Manager Team Worker initialise project change project dat
192. es innerhalb des Systems gibt und welche Abh ngigkeiten es zwischen den Akteuren gibt Anschlie end gehen wir in den Abschnitten und auf die Modellierung von Zugriffsrechten des Dom nenmodells und Ausf hrungsrechten zu Aktivit ten ein Die Berechtigungsmodellierung basiert auf dem in Kapitell4 vorgestellten akteurzentrierten Modell zur Spezifikation von Benutzerrechten Be nutzerrechte unterteilen wir hier in zwei Kategorien im Fall von Lese Schreib und Create Berechtigungen auf Dom nenobjekten sprechen wir von Zugriffsrechten Von Ausf hrungs rechten sprechen wir bei Execute Berechtigungen auf Aktivit ten 6 3 1 Modellierung der Akteure Innerhalb der Gesch ftsprozessmodellierung sind w hrend der Entwicklung des Dom nenmo dells und der Gesch ftsabl ufe auch die Akteure des Systems die auf den Daten arbeiten oder an den Abl ufen beteiligt sind zu identifizieren vgl Rat00 ye F r die Festlegung der Benutzerrechte ist im Rahmen der Gesch ftsprozessmodellierung zu griffssicherer Systeme zu kl ren welche Abh ngigkeiten zwischen den Akteuren des Systems bestehen sodass Benutzerrechte nicht redundant spezifiziert m ssen und widerspruchsfrei de finiert werden k nnen Werden f r hnliche Akteure die Benutzerrechte jeweils separat defi niert besteht die Gefahr dass den Akteuren verschiedene Benutzerrechte zugeordnet werden Um dies zu vermeiden m ssen Gemeinsamkeiten in den Rechten einmalig f r alle hnlichen A
193. es isolierten Speicherbereichs Sandbox innerhalb dessen der mobile Code freien Zugriff besitzt gesch tzt werden 2 2 5 Sicherheitsgrundfunktionen Mit den Sicherheitsgrundfunktionen aus steht ein Baukasten von allgemeinen Ma nah men zur Abwehr von Bedrohungen zur Verf gung Diese Grundfunktionen sind entsprechend der individuellen Anforderungen eines zu konstruierenden Systems zu kombinieren und rea lisieren Die f r diese Arbeit relevanten Sicherheitsgrundfunktionen listen wir im Folgenden auf Identifikation und Authentifikation Um Bedrohungen die sich aus Maskierungsangriffen ergeben abwehren zu k nnen und um generell unautorisierte Zugriffe zu unterbinden m ssen Subjekte und sicherheitsrelevante Ob jekte im System eindeutig identifizierbar sein Die Identit t ist bei der Authentifikation an hand der charakteristischen Eigenschaften des Subjekts bzw Objekts zu berpr fen F r die Authentifikation ist festzulegen wann diese durchzuf hren ist Beispielsweise findet bei Betriebssystemen eine berpr fung nur beim Systemzugang statt F r sicherheitsrelevante Aktionen kann es aber n tig sein dass die Identit t von Subjekten erneut zu berpr fen ist Rechteverwaltung Die Rechteverwaltung liefert die Basis zur Abwehr von Bedrohungen der Integrit t und Ver traulichkeit von Objekten infolge unautorisierter Zugriffe Subjekte besitzen Rechte zum Zu griff auf Objekte Aus den Sicherheitsanforderungen ist zu ermitteln we
194. es zu entwickeln sind so etwa die Sicherheitsvorgaben die CC Spezifikation oder die Benutzer und Systemverwalterhandb cher Die CC fordern bei spielsweise f r eine Evaluierung nach Stufe EAL2 neben Beschreibungen ber die funktionale Spezifikation und des Entwurfs auf hoher Ebene Nachweise ber die Testabdeckung Jedoch ist die geforderte Menge an Produktartefakten im CC Vorgehen zu grob granular und unvoll st ndig So wird zum Beispiel im Design der funktionalen Bestandteile nur eine Systemspe zifikation f r Komponenten gefordert die eine Grundlage f r die Implementierung darstellen soll Es fehlen hier beispielsweise noch ein Dom nenmodell und eine fein granularere Betrach tung der Sicherheitsartefakte beispielsweise in einem Bedrohungs und Risikomodell Die Produktartefakte m ssten so fein granular angegeben sein dass zu jeder Aktivit t und Phase die f r die Bearbeitung notwendigen und erzeugten bzw ver nderten Dokumente angegeben werden k nnen Auf iterative Aspekte innerhalb einer Ausf hrungsphase wird im CC Vorgehen nicht eingegan gen Es wird nur erw hnt dass f r eine iterative Entwicklung der gesamte Prozess mehrfach durchlaufen werden kann Eine fr hzeitige Reaktion auf fehlende oder falsche Anforderungen sowie auf iterative Entwicklung der Sicherheitsaspekte ist in diesem Ansatz nicht vorhanden Wie auch bei dem phasenstrukturierten Vorgehen und beim V Modell ITSEC Vorgehen be ginnt die Modellierung mit der Planun
195. ezifikation der Sicherheit ausgesprochen d h die Sicherheit wird nicht in seiner Gesamtheit 88 Ein Prozess zur Entwicklung von Anforderungsspezifikationen spezifiziert sondern es werden kleine Einheiten die funktionell modelliert werden auch der Sicherheitsanalyse unterzogen Dies hat zum Ziel dass alle Systemteile einer Analyse der Zu griffssicherheit unterzogen und somit keine Bereiche bersehen werden Das vorgestellte Vorge hen verfolgt diese Anforderung dahingehend dass bei der Spezifikation der Gesch ftsprozesse und der Anwendungsf lle sowie innerhalb der Analyse die Zugriffssicherheit lokal modelliert wird Betrachtung von Produktartefakten SPA5 Da unser Vorgehen an modernen objektorientierten Vorgehensweisen ausgerichtet ist sind neben den eigentlichen Vorg ngen auch die Produktartefakte welche die Ein und Ausga beprodukte der Prozesse bilden von besonderem Interesse Wie bereits im Abschnitt zur sukzessiven Entwicklung der Sicherheit SPA2 gezeigt wurde arbeitet das im Abschnitt beschriebene Vorgehen auf klassischen und sicherheitsspezifischen Produktartefakten Eine bersicht ber die Produktartefakte der Anforderungsspezifikation zugriffssicherer Systeme ist im Abschnitt 5 4zu finden Iterative Entwicklung SPA6 Insbesondere wegen der Komplexit t heutiger Softwaresysteme unterst tzen objektorientier te Entwicklungsprozesse eine iterative Vorgehensweise F r die Entwicklung zugriffssiche rer Systeme is
196. f hren wir im Abschnitt 4 3lein Die formale Modellierung der Benutzerrechte inklusive einer Repr sentierungsfunktion zur Abbildung von Akteuren im System ist Gegenstand des Abschnitts 4 4 Im Abschnitt besch ftigen wir uns mit der formalen Spezifikation von Benutzerrechten mit der Object Constraint Language OCL als Spezifikationssprache im Kontext der grafischen Beschreibungssprache UML Abschnitt zeigt Erweiterungen zum vorgestellten Basisansatz und Abschnitt 4 7 gibt einen Ausblick auf die Transformation der in OCL spezifizierten Berechtigungen in die Implementierung Die Einordnung des Ansatzes in den fr hen Phasen eines Entwicklungsprozesses wird in Abschnitt beschrieben 30 Akteurzentriertes Modell zur Spezifikation von Benutzerrechten 4 1 Einf hrung Der Schutz von Daten vor unautorisierten Benutzerzugriffen ist eine grundlegende Anforde rung bei der Entwicklung zugriffssicherer Systeme Anwendungen wie beispielsweise ERP Systeme oder Gesundheitsinformationssysteme mit hunderten oder tausenden von Benut zern die sensible Daten handhaben m ssen enthalten komplizierte Mechanismen zur Rechte modellierung Mit der Einf hrung von Web Anwendungen hat das zentrale Thema des Schut zes von Daten noch weiter an Bedeutung gewonnen Je mehr Firmen ihre grundlegenden Gesch ftsprozesse ihren externen Partnern ffnen desto wichtiger wird eine fein granulare Anwendung von Benutzerrechten Wie wir in den Kapiteln 6 bis 8 noch zeig
197. ffssicherheit zu integrieren und die Verfeinerung der Produktartefakte aufzuzeigen Parallel zur Entwicklung der vorliegenden Arbeit wurde das V Modell 97 berar beitet Das neue V ModellTMXT beschreibt ein flexibles Vorgehensmodell zum Planen und Durchf hren von Systemprojekten Es definiert die Aktivit ten T tigkeiten und Produkte Ergebnisse die w hrend der Entwicklung von Systemen durchzuf hren beziehungsweise zu erstellen sind Dar ber hinaus legt das V Modell die Verantwortlichkeiten jedes Projektbetei ligten fest WEIO4 Da das V ModellTMXT ein sehr generisches Produktmodell besitzt und bereits Produkte zur Spezifikation von sicheren Systemen integriert sind ist zu untersuchen wie sich die Produkte und Prozessbausteine der vorgestellten Methode in die Struktur des V Modells MXT integrieren lassen Die vorliegende Arbeit konzentriert sich auf die fr hen Phasen der Entwicklung zugriffssi cherer Systeme In Wim05 wird die Entwicklung von Sicherheitsaspekten in den folgenden Phasen untersucht insbesondere die modellbasierte Entwicklung innerhalb der Design und der Testphase Neben der Zugriffssicherheit gibt es noch eine Reihe weiterer nichtfunktionaler Anforderungen wie zum Beispiel Zuverl ssigkeit Effizienz Benutzbarkeit nderbarkeit und bertragbarkeit Im Gegensatz zu diesen weiteren nichtfunktionalen Anforderungen kann die Zugriffssicherheit nach Schutzzielen weiter unterteilt werden sodass eine strukturelle Ermi
198. fied Modeling Language Specification Version 1 5 March 2003 Thomas Ottmann and Peter Widmayer Algorithmen und Datenstrukturen Spektrum Akademischer Verlag 3 edition 1996 Helmuth Partsch Requirements Engineering systematisch Modellbildung f r softwaregest tzte Systeme Springer Verlag 1998 Gustav Pomberger and G nther Blaschek Software Engineering Prototyping und objektorientierte Software Entwicklung Carl Hanser Verlag zweite edition 1996 Gerhard Popp Ruth Breu Jan J rjens and Guido Wimmel Security Critical System Development with Extended Use Cases In Proceedings of the 10th Asia Pacific Software Engineering Conference APSEC 2003 Chiang Mai Thai land December 10 12 pages 478 487 IEEE Computer Society 2003 Rational Software Corporation Rational Unified Process HTML Documentati on 2000 Version 2000 02 10 Andreas Rausch Componentware Methodik des evolution ren Architekturent wurfs PhD thesis Technische Universit t M nchen 2001 James Rumbaugh Michael Blaha William Premerlani Frederick Eddy and Wil liam Lorensen Object Oriented Modeling and Design Prentice Hall Verlag GmbH 1991 Wolfgang Rankl and Wolfgang Effing Handbuch der Chipkarten Aufbau Funk tionsweise Einsatz von Smart Cards Carl Hanser Verlag third edition 1999 Stuart Russell and Peter Norvig Artificial Intelligence A Modern Approach Prentice Hall Pearson Education Inc second edition 2003
199. finden sind Weiterhin ist der Sicherheitsmikropro zess durch die aufgef hrten Produktartefakte insbesondere durch das Gesch ftsprozessmo dell f r betriebliche Informationssysteme geeignet Struktur Abbildung 5 9 gibt den genauen Ablauf der in der L sung spezifizierten Durchf hrung des Si cherheitsmikroprozesses wieder Die vorgestellten Aktivit ten des Mikroprozesses werden hier in einen konkreten Ablauf integriert Wie bereits erw hnt wurde sind nach dem Entwurf der Ma nahmen diese zu testen um sicherzustellen dass den Bedrohungen mit ihrem ermittelten Risiko entgegengewirkt wird Falls die Ma nahmen nicht zum Ziel f hren m ssen gegebe nenfalls neue Ma nahmen ermittelt und diese erneut einer berpr fung unterzogen werden Erst nach Findung der geeigneten Ma nahmen terminiert der Sicherheitsmikroprozess und es kann mit der Modellierung fortgefahren werden Vor und Nachteile Der vorgestellte Sicherheitsmikroprozess unterst tzt durch seine Anwendung in allen Pro zessabschnitten der Anforderungsspezifikation eine durchg ngige und sukzessive Entwicklung von Aspekten der Zugriffssicherheit bereits ab der Phase der Gesch ftsprozessmodellierung Der Sicherheitsmikroprozess ist iterativ anwendbar Durch die Bindung an die vorgestellten Produktartefakte ist der Sicherheitsmikroprozess an objektorientierte Beschreibungstechniken ausgerichtet Grunds tzlich k nnte jedoch die vor gestellte Vorgehensweise des Mikroprozesses au
200. fiziert wurden Im Rahmen der Spezifikation der Anwendungsf lle wurde das Ver halten angepasst und detailliert beschrieben Gegen Ende der Anwendungsfallmodellie rung zugriffssicherer Systeme sind die Abl ufe bis auf einige wenige Ausnahmen festge legt und in geeignete Einheiten aufgeteilt In diesem Stadium k nnen die anf nglich nur textuell spezifizierten Benutzerrechte pr dikativ spezifiziert und verfeinert werden wie dies im Kapitel 4 vorgestellt wurde Die Benutzerrechte zu den wenigen Abl ufen die noch kein stabiles Stadium erreicht haben k nnen weiter textuell beschrieben werden Im Rahmen der Analyse zugriffssicherer Systeme vgl Kapitel 8 sind die Abl ufe zu konkretisieren und die Benutzerrechte zu diesen Abl ufen pr dikativ zu spezifizieren Die bereits spezifizierten Ausf hrungsrechte sind auch an das ge nderte Akteurmodell anzupassen Anderungen in der Hierarchie sowie neu hinzugef gte Akteure beispiels weise f r externe Systeme sind bei der Spezifikation der Benutzerrechte heranzuziehen Modellierung der Zugriffsrechte Modifikationen am Dom nenmodell des zu entwickelnden Systems erfordern eine Anpas sung der Zugriffsechte Sowohl erg nzte Klassen als auch modifizierte Attribute Asso 7 5 Der Prozess der Anwendungsfallmodellierung zugriffssicherer Systeme 169 ziationen oder Klassen erfordern eine erneute Uberpriifung der Benutzerrechte Zudem sind die Zugriffsrechte auch den Anderungen und Erg nzungen im
201. fizierung notwendig wird Diejenigen Aktivit ten oder Teilsequenzen k nnen dann nach einem Login alternativ ausgef hrt werden Bei spiele sind hierzu beispielsweise die Aktivit ten activity4 und activity6 in Abbildung Abl ufe die eine zus tzliche spezielle Authentifikation erfordern m ssen als zus tzli cher Pfad nach der allgemeinen Authentifikation zu den bisherigen Abl ufen hinzugef gt werden In Abbildung wurde hierzu die Teilsequenz bestehend aus logins activi ty5 und logouts hinzugef gt Vor und nach den Aktivit ten zur zus tzlichen speziellen Authentifikation k nnen innerhalb des Pfades auch weitere Aktivit ten notwendig sein d h es ist nicht zwingend erforderlich dass die spezielle Authentifizierung unmittelbar 154 Die Anwendungsfallmodellierung zugriffssicherer Systeme nach der allgemeinen Authentifizierung stattfindet und die Abmeldung im speziellen Fall unmittelbar vor dem allgemeinen Logout e Kommen im System sowohl Abl ufe mit einseitiger sowie beidseitiger Authentifikation vor so k nnen diese nicht dieselbe login Aktivit t verwenden Hierzu sind im kombi nierten Ablaufdiagramm zwei alternative Aktivit ten f r die entsprechenden Authenti fikationen einzuf hren Das durch diese Methode entstehende Ablaufdiagramm erhebt nicht den Anspruch dass es alle Abl ufe vollst ndig modelliert Ziel dieses Ablaufdiagramms liegt darin die notwendigen Aktivit ten zur Authentifikation zu ermitteln und Gemeins
202. fordert wird oder umgekehrt muss der Ablauf aus Abbildung 7 4 d bzw 7 4 e angepasst werden Abbildung 7 5 zeigt einen Ablauf der TimeTool Fallstudie bei dem im Rahmen der Anwen dungsfallmodellierung zugriffssicherer Systeme die Akteure verfeinert sowie Sitzungen und Authentifikationsschutzziele erg nzt wurden Im Ablauf wurden drei Sitzungen identifiziert F r den Team Worker wurde eine Sitzung mit nur einer einzigen Aktivit t ermittelt Die Sitzungen von Project Manager und Administrator wurden mittels der eingef hrten Symbole annotiert Alle drei Sitzungen erfordern dass vor Ausf hrung der ersten Aktivit t der zu geh rige Akteur authentifiziert wird und nach Abschluss der letzten Aktivit t innerhalb der Sitzung vom System abgemeldet wird Vor Ausf hrung der Aktivit t administrate user data muss sich der Administrator explizit nochmals authentifizieren nach der Ausf hrung wechselt er wieder zu seiner urspr nglichen Identit t im System zur ck 7 2 4 Verfeinerung der Authentifikation und der Sitzungen Aus den Aktivit ten die wir mit dem Schutzziel Authentifikation annotiert haben und der Modellierung der Sitzungen k nnen wir die Abl ufe derart verfeinern dass wir eigene Akti vit ten zur Authentifikation in die Abl ufe integrieren Hierzu f gen wir innerhalb der exemplarischen Ablaufdiagramme vor der ersten Aktivit t f r die der Akteur oder ein externes System authentifiziert sein m ssen eine Aktivit t logi
203. g bzw Organisation auszuarbeiten Es wird festgelegt welche Akteure die Gesch ftsprozesse ausf hren Verfeinerung der Rollen und Verantwortlichkeiten Die Hardware Software Produkte und die Zust ndigkeiten der Bearbeiter sind genau zu definieren Weiterhin ist zu berpr fen inwiefern die Ergebnisse hier die Gesch fts objekte und Abl ufe den Vorstellungen der Auftraggeber entsprechen Dom nenmodellierung Ein unvollst ndiges Dom nenmodell vgl Kru00 mit strategisch wichtigen Informa tionen siehe EP00 ist auszuarbeiten Dabei sind die grundlegenden Daten auf denen die Gesch ftsprozesse operieren zu erfassen Von internen Details wie beispielsweise die Repr sentation der Daten innerhalb einer Datenbank wird abstrahiert Es wird ein Klassendiagramm mit den wichtigsten Informationsquellen erstellt Untersuchung der Prozessautomatisierung Die bisher identifizierten und verfeinerten Gesch ftsprozesse beschreiben die Gesch fts prozesse einer Unternehmung Nicht alle Prozesse sind f r eine Automatisierung ge eignet denn bestimmte Aufgaben k nnen nicht oder nur schwer von einem System bernommen werden Die Gesch ftsprozesse sind deshalb dahingehend zu untersuchen inwiefern sie sich f r eine Automatisierung eignen Die Prozessautomatisierung sind exi stierende L sungen heranzuziehen die Teilaufgaben l sen und in den L sungsprozess integriert werden k nnen Aus den Ergebnissen der Untersuchung zur Prozessautoma
204. g von Schreib Zugriffsmethoden auf At tribute Wir f gen das Tupel aus Attribut A und Methodenidentifikator genau dann in unsere Relation protect aus Abschnitt 6 2 1 1 ein A writec a protect wenn die Schreib Zugriffsmethode writec 4 der Klasse C den Schreibzugriff auf das Attribut A einschr nkt F r den erzeugenden Zugriff f hren wir Create Zugriffsmethoden funct createc a a ACActor o Tin 0i1 Tip funct createc a a AC Actor Oimn Tims Pimp Timp 6 2 Spezifikation der Schutzziele in Struktur und Verhalten 101 ein die einen erzeugenden Zugriff auf ein Attribut A vom Typ T genau dann erlauben wenn die zugeh rige Create Berechtigung permc createc Au AC Actor C T Ty f r den Akteur erf llt ist Wir f gen das Tupel aus Attribut A und Methodenidentifikator der Create Methode genau dann in unsere Relation protect ein A createc a protect wenn die Create Zugriffsmethode createc a der Klasse C den erzeugenden Zugriff auf das Attribut A einschr nkt Unter Betrachtung der Relation protect und der vorgestellten Schreib und Create Zugriffs methoden mit Berechtigungen k nnen wir nun das Schutzziel Stereotyp lt Integrity gt folgen derma en beschreiben VAEC Va ACActor dwritec a Au writec a protect gt aperme writeo An perme writec a As C Op true amp Ay o PETMC writec A a C 0p false gt writeo a Q 04
205. g werden in dieser fr hen Phase keine Sicherheitsaspekte betrachtet obwohl bei der Analyse von Dom nenobjekten und Gesch fts prozessen Aspekte der Zugriffssicherheit schon betrachtet werden k nnen Bei der Model lierung des Dom nenmodells k nnen beispielsweise die bereits ermittelten Daten bez glich potenzieller Angriffe in Bezug auf Vertraulichkeit Integrit t und Verbindlichkeit der Daten untersucht werden Bei der Evaluierung der gegenw rtigen Prozesse in Hinblick auf eine Automatisierung bleiben ebenfalls Aspekte der Zugriffssicherheit au en vor Im Vordergrund f r nderungen der Pro zesse stehen allgemeine Verbesserungen und Anpassungen eine Optimierung aufgrund von Sicherheitsbetrachtungen findet nicht statt Dies kann dazu f hren dass ein zu ndernder Prozess bei einer sp teren Integration von Sicherheitsaspekten erneut ge ndert und optimiert werden muss Weiterhin wird in den heute blichen Verfahren zur Gesch ftsprozessmodellierung siehe zum Beispiel IDW98 das gemeinsame Wissen ber Sicherheitsanforderungen nicht ausgen tzt Obwohl zu Beginn Anforderungsentwickler Auftragnehmer Auftraggeber und Anwender gemeinsam die Rahmenbedingungen und Anforderungen festlegen werden exi stierende L sungen in der manuellen oder automatisierten Abarbeitung zur Gew hrleistung der Sicherheit nicht ausgen tzt Beispielsweise werden hier vertrauensw rdige Daten oder Aktivit ten deren Ausf hrung im Nachhinein nicht abstreitbar
206. gefasst werden Das Basismodell eines rollenbasierten Sicherheitsmodells wird in Eck03 durch ein Tupel RBAC S O RL P sr pr session definiert wobei e S die Menge der Benutzer im System e O die Menge der zu sch tzenden Objekte und e RL die Menge der Rollen ist Jede Rolle beschreibt eine Aufgabe und damit die Berech tigungen der Rollenmitglieder e P ist die Menge der Zugriffsberechtigungen und e sr pr und session beschreiben Relationen Die Abbildung sr modelliert die Rollenmit gliedschaft eines Subjektes s S sr S QRL Falls sr s R Rn gilt dann ist das Subjekt s autorisiert in den Rollen R Rn aktiv zu sein ber die Berechtigungsabbildung pr RL gt 2 wird jeder Rolle Re RL die Menge derjenigen Zugriffsrechte zugeordnet die die Mit glieder der Rolle w hrend ihrer Rollenaktivit ten wahrnehmen d rfen Die Relation session C S x 28 beschreibt Paare s rl die als Sitzungen bezeichnet werden F r ein Subjekt s S und f r eine Sitzung s rl session gilt dass s alle Berechtigungen der Rollen R rl besitzt Sei s rl eine Sitzung dann sagen wir dass s aktiv in den Rollen Re rl ist Ein Subjekt kann in einem RBAC System gleichzeitig in verschiedenen Sitzungen aktiv sein Es besitzt dann alle Berechtigungen aller Rollen in denen es aktiv ist mit Ausnahme derer die sich gegenseitig ausschlie en Um Berechtigungen wahrnehmen zu k nnen muss ein Subjekt aktiv in ein
207. gelt einzuf gen Zur Beschreibung des Interakti onsverhaltens sind UML Sequenzdiagramme oder UML Objektinteraktionsdiagramme siehe JBR99 zu erstellen Bei der Analyse der Klassen sind f r jede ermittelte Klasse des Analyseklassenmodells die Aufgaben der Klassen sowie Attribute Assoziationen Aggregationen und Generalisierungen festzulegen Bei allen Aktivit ten der Analyse sind nichtfunktionale Anforderungen festzule gen 8 1 3 Produktartefakte der Analyse Zentrales Produkt der Analyse ist das Analysemodell Im Analysemodell werden die Anfor derungen an das System in der Sprache der Entwickler beschrieben Die textuellen Ablaufbe schreibungen werden in Szenarios verfeinert welche den Nachrichtenfluss zwischen Objekten beschreiben Durch diese Transformation wird eine objektorientierte Sicht des Gesamtsystems erstellt Das Analysemodell wird durch folgende Teilprodukte beschrieben e In einem UML Klassendiagramm wird das Klassenmodell der Analyse dargestellt Vor gangs Fach und Interaktionsklassen Bre01 JBR99 sind durch spezielle Stereotypen gekennzeichnet 180 Die Analyse zugriffssicherer Systeme e Anwendungsfallrealisierungen werden in UML Sequenzdiagrammen oder in UML Ob jektinteraktionsdiagrammen siehe JBR99 beschrieben e Die nichtfunktionalen Anforderungen die ber die gesamte Analysephase ermittelt wer den sind in einer textuellen Beschreibung der Spezialanforderungen zu erg nzen e Die Analyse Packages
208. gestuft denn durch fehlerhafte Stun denbuchungen werden die Projektkosten falsch berechnet Wei terhin treten Inkonsistenzen bei der berpr fung des Zeitmana gements auf Neben den Dom nenobjekten werden auch innerhalb der Gesch ftsprozesse sicherheitskriti sche Aktivit ten mit den in Abschnitt 6 2 eingef hrten Schutzziel Stereotypen annotiert Im Folgenden erweitern wir das Bedrohungs und Risikomodell Wir ermitteln f r den in Ab bildung dargestellten Gesch ftsprozess Bedrohungen und Risiken analog zu denen des Dom nenmodells Tabelle 6 2 Bedrohungen und Risiken zum TimeTool Gesch ftsprozess aus Abbildung Aktivit t Bedrohung und Risiko initialize project B014 Ein Projektmitarbeiter ein Projektleiter aus einem anderen Projekt oder ein weiterer Nutzer des Systems manipulieren die zu Projektbeginn erstellten Projektaktivit ten Projektmitar beiter sowie die Projektinformation R014 Das Risiko wird als mittel eingesch tzt da sich Inkonsisten zen im geplanten Projektablauf und in den Budgetplanungen ergeben Unzul ssig zugeordnete Projektmitarbeiter haben so mit Zugang zum Projekt und k nnen legitime nderungen und Buchungen ausf hren sowie vertrauliche Projektinformationen lesen change project data B015 Daten die w hrend der Initialisierung und w hrend Stundenbu chungen im System eingetragen wurden k nnen in dieser Akti vit t ver ndert werden Projektadministratoren Projektmitar beiter sowie
209. gging und Activity muss nun entweder im Rahmen der Gesch ftsprozessmo dellierung zugriffssicherer Systeme oder der Anwendungsfallmodellierung zugriffssicherer Sy steme der Sicherheitsmikroprozess ausgef hrt werden und die Benutzerrechte sind zu spezifi zieren Wir f hren hier f r die eingef hrten und ge nderten Klassen den Sicherheitsmikroprozess nicht nochmals in der Gesch ftsprozessmodellierung zugriffssicherer Systeme aus sondern befassen uns mit diesen nderungen im Rahmen der Anwendungsfallmodellierung zugriffssi cherer Systeme berpr fung der Ma nahmen Nach dem Entwurf der Abwehrma nahmen verlangt der Sicherheitsmikroprozess eine ber pr fung der eingef hrten Ma nahmen Dabei ist informal semiformal oder formal zu ber 6 5 Produktartefakte der Gesch ftsprozessmodellierung sicherer Systeme 137 pr fen inwiefern die eingef hrten Ma nahmen zum Ziel f hren d h den ermittelten Bedro hungen entgegenwirken Im Rahmen unserer Fallstudie k nnen wir die Ma nahmen informal berpr fen Die eingef hr te Klasse Logging speichert alle nderungen an Buchungen Unter der Voraussetzung dass in der weiteren Modellierung alle nderungen darin mitprotokolliert werden und dass Benutzer des Systems die Logging Informationen nicht ver ndern k nnen wird dadurch ein Kontroll instrument eingef hrt sodass die Verbindlichkeit von Buchungen und Buchungs nderungen gew hrleistet wird Ebenso wirkt die Ma nahme de
210. gsphase Eine Gesch ftsprozessmodellierung ist nicht 64 Ein Prozess zur Entwicklung von Anforderungsspezifikationen Gegenstand des CC Vorgehensmodells sodass hierzu auch keine weiteren Aussagen getroffen werden k nnen 5 1 4 Weitere Vorgehensbeschreibungen Nach dieser ausf hrlichen Vorstellung und Bewertung von drei Ans tzen zur Entwicklung von sicheren Systemen stellen wir im Folgenden noch drei weitere Ans tze vor die sich noch in einem fr hen Stadium ihrer Entwicklung befinden oder nur erg nzend in B chern zur Entwicklung sicherer Systeme vgl And01 VM02 angegeben sind jedoch einige interessante Gedanken f r eine sichere Systementwicklung beinhalten Security Engineering in fr hen Phasen Grundprinzipien und Ideen zu einem Security Engineering Process stellt vor Dabei wird insbesondere das Problem der sp ten Integration von Sicherheitsaspekten in bestehen den Ans tzen angemahnt und ein Vorgehen zur Modellierung von Sicherheitseigenschaften ab den fr hen Phasen umrissen Ein weiteres Ziel dieses Vorgehens ist es eine Menge an Richtlinien und Funktionen zur Sicherheit bereitzustellen sodass gew hnliche Entwickler al so keine Sicherheitsexperten sichere Software erstellen k nnen Dieser Ansatz ist nicht auf die Entwicklung einer eigenen vollst ndigen Methode ausgerichtet sondern schl gt vor ein bestehendes objektorientiertes Vorgehensmodell mit Sicherheitsaspekten zu erweitern beson ders in der Phase
211. gsspezifikation zugriffs sicherer Systeme erw hnt wurde erfordert dieses Verfahren durch die integrierte Entwicklung der Sicherheitsaspekte zus tzlichen Aufwand Schutzziele Bedrohungen Risiken Ma nahmen und Berechtigungen sind in jeder Phase erneut zu berpr fen und gegebenenfalls zu erg nzen Wie bereits erw hnt reicht es bei zugriffssicheren Systemen nicht aus die Sicherheitsanfor derungen wie funktionale Anforderungen einmalig zu erfassen da alle potenziellen Angriffe und somit Verletzungsm glichkeiten des Systems erfasst werden m ssen In Beziehung stehende Prozessmuster bergeordneter Prozess e Prozessmuster zur Anforderungsdefinition zugriffssicherer Systeme Abschnitt Auszuf hrender Teilprozess e Prozessmuster zum Sicherheitsmikroprozess siehe Abschnitt Weitere referenzierte Prozessmuster e Prozessmuster zur Gesch ftsprozessmodellierung zugriffssicherer Systeme siehe Ab schnitt 6 4 1 e Prozessmuster zur Anwendungsfallmodellierung zugriffssicherer Systeme vergleiche Ab schnitt 7 5 1 8 4 2 Anwendung des Sicherheitsmikroprozesses Wie in den beiden vorausgehenden Phasen der Anforderungsspezifikation zugriffssicherer Sy steme kommt auch bei der Analyse zugriffssicherer Systeme der Sicherheitsmikroprozess aus Abschnitt 5 3 3lerneut zur Anwendung Dabei werden Bedrohungen Risiken und Ma nahmen zu folgenden nderungen und Erg nzungen ermittelt 8 5 Produktartefakte der Analyse sicherer Systeme 191
212. heksverwaltungs system nur dann ausgef hrt werden wenn sich der Administrator f r diesen Vorgang speziell authentifiziert hat Innerhalb der Sitzung ist keine Authentifikation notwendig Die Sitzung stellt nur ei ne zusammengeh rende Folge von Aktivit ten dar die von einem anonymen Akteur ausgef hrt wird Im Rahmen unserer Sicherheitsanalyse sind f r uns die ersten drei Sitzungstypen von Inte resse F r diese Typen stellen wir im Folgenden geeignete Beschreibungstechniken vor 7 2 3 Beschreibungstechniken zum Schutzziel Authentifikation Um diese Arten von Authentifikationen und Sitzungen innerhalb der Prozessabl ufe model lieren zu k nnen f hren wir f r Aktivit ten weitere Stereotypen ein Zur Unterscheidung von einseitiger und gegenseitiger Authentifizierung f hren wir f r das Schutzziel Authentifikation zwei Stereotypen lt Authenticity gt und MutualAuthenticity gt ein wie sie in Abbildung 7 3ldargestellt sind F r Aktivit ten die mit dem Stereotyp lt Authentici ty gt gekennzeichnet sind wird gefordert dass der ausf hrende Akteur oder ein externes System vorab am System authentifiziert sein muss Aktivit ten die mit dem Stereotyp MutualAu thenticity gt gekennzeichnet sind erfordern dass der ausf hrende Akteur oder ein externes System sowie das modellierte System vorab gegenseitig ihre Identit ten berpr fen lt lt Authenticity gt gt lt lt MutualAuthenticity gt gt activity activity Sr a
213. herheitsbetrachtungen oftmals erst zu sp t in die Entwicklung mit einbezogen werden oder dass Sicherheit nicht in allen Entwicklungsphasen Betrachtung findet Im vorgestellten Prozess zur Anforderungsspezifikation zugriffssicherer Systeme werden Aspekte der Zugriffssicherheit bereits ab der Gesch ftsprozessmodellierung erarbeitet und in den Prozessabschnitten der Anwendungsfallmodellierung und der Analyse erweitert und verfeinert Die Durchg ngigkeit der Entwicklung der Zugriffssicherheit ist erf llt denn in allen Prozessabschnitten der Anfor derungsspezifikation werden Sicherheitsaspekte herausgearbeitet und verfeinert Sukzessive Erarbeitung von Sicherheit SPA2 Eine durchg ngige Ausarbeitung der Sicherheitsaspekte in allen Teilphasen reicht nicht aus Wie Anderson in beschreibt werden die Ergebnisse die innerhalb einer Phase produ ziert werden oftmals beiseite gelegt und in der n chsten Phase zur Modellierung nicht heran gezogen Neben der durchg ngigen Entwicklung ist es somit notwendig dass die Sicherheitsas pekte in verschiedenen Phasen und auch innerhalb der Phasen der Anforderungsspezifikation zugriffssicherer Systeme sukzessive ermittelt werden d h dass Ergebnisse des vorausgehen den Prozessabschnitts in den n chsten Prozessabschnitt einflie en Wie aus der Tabelle zur bersicht ber die Produktartefakte und aus der Abbildung 5 10lzu den Produktartefak ten und deren Abh ngigkeiten hervorgeht werden innerhalb der Anforde
214. hlt werden hier die getAccountingDatePermission fiir den Pro jektmitarbeiter oder fiir den Projektleiter Die Berechtigungsfunktion fiir den Projektleiter weist hierbei eine Besonderheit auf Da ein Projektleiter eine besondere Form des Projektma nagers ist treffen nach der in Abschnitt vorgestellten Vererbung von Benutzerrechten die Benutzerrechte des Projektmitarbeiters auch fiir den Projektleiter zu Es ist in diesem Zusammenhang zu tiberpriifen inwiefern Zugriffe aus der Mitarbeiterrolle des Projektleiters seine Benutzerrechte erweitern Nach dem fail safe default principle vgl Abschnitt 4 4 2 und Abschnitt 2 2 3 zu den Si cherheitsprinzipien wird jeder Zugriff der nicht explizit erlaubt ist nicht gew hrt was sich in der Umsetzung dadurch zeigt dass nur die wahren Berechtigungsausdrticke spezifiziert werden Eine Ablehnung des Zugriffs kann nun durch die Nichterfiillung eines derartigen Aus drucks auftreten oder durch das Fehlen einer Berechtigungsspezifikation In diesem Fall wird implizit die getAccountingDatePermission Methode der Basisklasse AC Actor aufgerufen die false zur ckliefert Soll beispielsweise der Zugriff auf eine Objektmethode f r alle Akteure erm glicht werden so kann in der Basisklasse die globale Benutzerberechtigung true spezifi ziert und die Zugriffsmethoden in den Subklassen k nnen weggelassen werden 4 8 Einordnung im Entwicklungsprozess Abbildung zeigt zusammenfassend die Entwicklung unsere
215. hre Unterschriften best tigt Spezifikation der Schutzziele in den Objekten des Dom nenmodells Parallel zur Spezifikation der Schutzziele in den Gesch ftsprozessen sind potenzielle An griffsziele in den Objekten des Dom nenmodells als Schutzziele zu annotieren Falls in den Dom nenobjekten vertrauliche verbindliche oder integrielle Daten gelesen geschrie ben oder erzeugt werden sind diese mit den in Abschnitt 6 2 1 eingef hrten Schutzziel Stereotypen zu annotieren Ausf hrung des Sicherheitsmikroprozesses Bei der Ausf hrung des Sicherheitsmikroprozesses sind f r jedes annotierte Schutzziel sowohl in den Gesch ftsprozessen als in den Dom nenobjekten Bedrohungen Risiken und Ma nahmen zu suchen Einzelheiten zum Sicherheitsmikroprozess sind im Pro zessmuster zum Sicherheitsmikroprozess in den Abschnitten 5 3 3 und 6 4 2 beschieben Modellierung der Akteurhierarchie F r die Festlegung der Benutzerrechte zum Ausf hren von Aktivit ten Ausf hrungs rechte und zum Zugriff auf Daten Zugriffsrechte m ssen die Akteure angeordnet werden Die innerhalb der oben beschriebenen Aktivit ten Gesch ftsprozessl sungen entwerfen und Verfeinerung der Rollen und Verantwortlichkeiten ermittelten Akteure sind wie im Abschnitt gezeigt hierarchisch anzuordnen sodass die Benutzerrechte widerspruchsfrei und ohne Redundanzen spezifiziert werden k nnen Modellierung der Ausf hrungsrechte F r die ermittelten und hierarch
216. hreibung die Architektur und Designbeschreibung existierender Code sowie Testf lle wichtige Produktartefakte die beim Risikomanagement und bei der Umsetzung der Sicherheit anzuwenden sind Die Besonderheit bei der Anwendung des Spiralmodells liegt darin dass in jeder lokalen Iteration eine Folge von Entwicklungsschritten durchgef hrt wird in der die Bedrohungen und Risiken verfeinert werden Dabei sind die Sicherheitsaspekte nicht in ihrer Gesamtheit zu erarbeiten sondern ebenfalls lokal zu betrachten sodass auf alle neuen Probleme die w hrend der Bearbeitung entstehen k nnen eingegangen werden kann Im Gegensatz zum Wasserfallmodell ist dieses Modell bei der Erarbeitung von Sicherheitsrisiken und Ma nahmen flexibler denn die in fr hen Phasen erarbeiteten Ergebnisse sind in die Entwick lung einbezogen neue Probleme k nnen in die Bearbeitung aufgenommen und gegebenenfalls kann eine Iteration erneut ausgef hrt werden falls am Ende einer Iteration Inkonsistenzen oder Sicherheitsl cken festgestellt werden Dieser Ansatz erlaubt die durchg ngige Betrachtung von Sicherheitsaspekten denn bereits ab der Anforderungsanalyse werden Sicherheitsaspekte ermittelt und L sungen entwickelt Durch das iterative Vorgehen wird die Sicherheit sukzessive entwickelt Lokale Probleme sind sowohl nach funktionalen Aspekten als auch nach Aspekten der Sicherheit zu betrachten und zu beheben Der Ansatz zum Spiralmodell betrachtet zudem Produktartefakte im
217. hrt werden Da wir jedoch bei der Entwicklung von zugriffs sicheren Systemen das Erlaubnisprinzip engl fail safe defaults principle zugrunde legen ist grunds tzlich jeder Zugriff verboten und nur durch eine explizite Erlaubnis kann ein Zu griffsrecht gew hrt werden Aus diesem Grund m ssen auch f r Aktivit ten die ohne Ein schr nkung ausgef hrt werden k nnen Berechtigungen vergeben werden Abbildung 16 23 zeigt ein Beispiel f r eine Aktivit t ohne Beschr nkung der Ausf hrung aus der TimeTool Fallstudie Die Aktivit t view project info kann von jedem Akteur ausgef hrt werden Da eine Aktivit t immer nur einer Rolle im Aktivit tsdiagramm zugeordnet werden kann ist f r jeden Akteur ein eigenes Aktivit tsdiagramm zu zeichnen Die Abbildung zeigt vier Aktivit tsdiagramme f r die verschiedenen Akteure der TimeTool Fallstudie In der Benutzerrechtematrix ist ein unbeschr nktes Ausf hrungsrecht dadurch gekennzeich net dass das Execute Recht f r alle Akteure als gegeben ist Eintrag true in der Berechti gungsmatrix F r die Time Tool Fallstudie ergibt sich der folgende Ausschnitt der Benutzer rechtematrix Adminis Others trator Project Manager actor gt Team class Worker PCViewProjectInfo E true E true E true E true 118 Die Gesch ftsprozessmodellierung zugriffssicherer Systeme Aus den Ausf hrungsberechtigungen der Zugriffsmatrix l sst sich folgende Berechtigung fiir die Methode pr
218. ht gegeben ist Es werden zum Beispiel die Bedrohungen und Risiken innerhalb der Anforderungsanalyse ermittelt jedoch wird kein Artefakt angegeben in dem diese Si cherheitsaspekte dokumentiert werden Einzig und allein kommt ein Sicherheitskonzept als Gesamtheit aller Ma nahmen innerhalb der Aktivit tsbeschreibungen vor Iterative Entwicklung wird in SEC nur an einer einzigen Stelle erw hnt Beim Entwurf der Softwarearchitektur innerhalb des Softwaregrobentwurfs ist zu untersuchen inwiefern durch die Verfeinerung weitere Bedrohungen und Risiken entstehen Neben dieser und den generellen Iterationsm glichkeiten des V Modells 97 wird nicht angegeben wie die Sicher heit in den Phasen der Software Anforderungsanalyse des Systementwurfs der SW HW Anforderungsanalyse sowie in Feinentwurf Implementierung und Integration umgesetzt wer den kann Auf eine Sicherheitsmodellierung in der Gesch ftsprozessanalyse geht SEC ebenfalls nicht ein SEC startet mit der Systemanforderungsanalyse und ben tigt hierzu die operationellen Anforderungen an das System und das Sicherheitsziel vom Auftraggeber 5 1 3 Ein Prozess konform zu den Common Criteria Ein weiteres Vorgehen zur Entwicklung sicherer Systeme wurde innerhalb einer Diplomar beit zum Thema Security Engineering nach den Common Criteria Eine Fallstudie CC Vorgehen Vet01 VWW02 ausgearbeitet welches innerhalb des Softwaretechnikpraktikums 5 1 Existierende Vorgehensmodelle 61 Pa
219. ht hervor Das Konzept der Misuse Cases auch als Abuse Cases bezeichnet besch ftigt sich mit der Analyse und Spezifikation von Bedrohungen w hrend sich Sicherheitsanwendungsf lle engl Security Use Cases mit der Spezifikation von Sicherheitsanforderungen besch ftigen Fir03 zeigt einen Vergleich der beiden Konzepte und stellt sehr grob granulare Sicherheitsanwendungsf lle vor Das Konzept der Security Use Cases wird in dieser Arbeit bei der Anwendungsfallmodellie rung zugriffssicherer Systeme f r Sicherheitsgrundfunktionen bernommen Da es schwierig 1 4 Verwandte Arbeiten 9 ist Misuse Cases vollst ndig zu erfassen und hierzu keine methodischen Richtlinien angege ben werden betrachten wir dieses Konzept nicht weiter Die Modellierung von Anforderungen an die Autorisierung in Sicherheitsanwendungsf llen wird in AWO3a diskutiert Dieser Ansatz besch ftigt sich dabei insbesondere mit der Ver meidung von Inkonsistenzen und Unvollst ndigkeiten Fine fr he Modellierung von Sicher heitseigenschaften wird auch in AWO3b vorgeschlagen Dabei wird das Konzept der Anwen dungsf lle bei der Modellierung der Anforderungen diskutiert und eine erweiterte Anwen dungsfallbeschreibung vorgestellt In Verbindung mit einer Erweiterung der UML um Sicher heitsaspekte UMLsec wurden Sicherheitsanwendungsf lle in er rtert In wird eine erste Integration von Sicherheitsanwendungsfallen in ein dediziertes Prozessmodell fiir die Entwicklung s
220. ich Sicherheitseigenschaften abstrakt d h auf einer hohen Model lierungsstufe einzubeziehen So kann beispielsweise fr hzeitig eine Beweissicherung in einen Ablauf integriert und eine sp tere zus tzliche Ver nderung des Ablaufs vermieden werden Bei der gemeinsamen Daten und Funktionsmodellierung mit Aspekten der Zugriffssicher heit ergeben sich gegenseitige Erkenntnisse Analog zur Anwendungsfallmodellierung bei der Synergien zwischen Daten und Abl ufen ermittelt und in der gegenseitigen Modellierung integriert werden liefert hier die Modellierung der Zugriffssicherheit Erkenntnisse f r Verhal ten und Daten Die Modellierung der Daten und des Verhaltens stellt andererseits Input f r die Modellierung der Zugriffssicherheit zur Verf gung Getrieben durch die Betrachtung des Schutzziels Authentifikation kann etwa in Web basierten Anwendungen ein Sitzungskonzept vgl hierzu Abschnitt 7 2 eingef hrt werden und dies erfordert nderungen an den Abl ufen Im Gegenzug kann beispielsweise bei der Beschreibung eines Anwendungsfalls erkannt werden dass zur Ausf hrung dieser Funktion der Benutzer im System angemeldet sein muss Aspekte der Zugriffssicherheit und die Funktions und Datenmodellierung beeinflussen sich gegensei tig es findet eine so genannte feature interaction statt Die Erkenntnisse zur L sung sind bei beiden Modellierungen zu betrachten sodass letztendlich ein Systemverhalten auftritt das beide Modellierungen abdeckt P
221. icherer Systeme vorgestellt Diese Arbei ten von stellen wichtige Grundlagen und Konzepte fiir die Betrachtungen zur Anwendungsfallmodellierung zugriffssi cherer Systeme in dieser Arbeit dar wie beispielsweise die erweiterte strukturelle Beschreibung von Anwendungsf llen und die Integration von Sicherheitsanwendungsf llen zu Sicherheits grundfunktionen Im Kontext einer formalen Fundierung von Anforderungsspezifikationen zur Sicherheit und Protokollverifikationen sind eine Reihe von Arbeiten entstanden siehe beispielsweise Jiir04 JWO3 Der in dieser Arbeit vorgestellte Ansatz zur formalen Spezifika tion von Benutzerrechten basiert auf dem RBAC Modell und auf der formalen Sprache P MOS Bre04 Ein Schema zur Modellierung von Benutzerrechten im Kontext von Anwendungsf llen wurde in erstmals untersucht Unser Ansatz basiert auf einigen dieser Ideen stellt jedoch eine grundlegendere Theorie zur Verf gung Die in dieser Arbeit vorgestellte akteurbezogene Modellierung von Benutzerrech ten grenzt sich von dahingehend ab dass die Benutzerrechte schon in einer fr hen Phase der Softwareentwicklung implementierungsunabh ngig zu modellieren sind In werden die Benutzerrechte beim Design des Klassendiagramms modelliert und in werden zus tzlich zum Klassendiagramm eigene Sichten auf die Zu griffsrechte eingef hrt sind Vorarbeiten zu dem in dieser Arbeit vorgestellten akteur zentrierten Modell zur Spezifikation von Benutzerrechten Weitere spezi
222. icherheit erg nzt und f r die Modellierung der Zugriffssicherheit spezielle Produktartefakte eingef hrt werden Die Erweiterungen der Produktartefakte werden detailliert in den Prozessabschnitten zur Entwicklung zugriffssiche rer Systeme vorgestellt zur Gesch ftsprozessmodellierung in Kapitel 6 zur Anwendungsfall modellierung in Kapitel 7 und zur Analyse in Kapitel 8 Neben den Erg nzungen an den Produktartefakten wird auch ein berblick ber die Abh ngigkeiten der Artefakte gegeben Die Abdeckung der Prozessanforderungen des eingef hrten Vorgehens ist Gegenstand des Abschnitts Die Abdeckung der in Kapitel vorgestellten Prozessanforderungen wird am vorgestellten Vorgehen berpr ft 5 1 Existierende Vorgehensmodelle Die Notwendigkeit sichere Software nach vorgegebenen Vorgehensmodellen zu entwickeln wurde nach dem Scheitern von Security Projekten analog zu herk mmlichen Softwarepro 54 Ein Prozess zur Entwicklung von Anforderungsspezifikationen jekten erkannt Erste Methoden zur Entwicklung zugriffssicherer Systeme wurden durch eine Erweiterung von klassischen Vorgehensmodellen geschaffen Da die klassischen Modelle fiir die Adaption von Sicherheitseigenschaften kaum offen sind konnten die notwendigen Anderun gen nicht im erforderlichen Umfang eingebracht werden Diese ersten um Sicherheitsaspekte erweiterten Vorgehensmodelle enthalten jedoch inh rent eine Reihe von Aspekten die in ein Vorgehensmodell zur Entwicklung zugr
223. ickelt und Sicherheitsfunktionen sowie sicherheitsrelevante Funktionen werden darauf aufbauend im System und im Softwareentwurf zu sicherheitsrelevanten SW Komponenten Prozessen und Moduln erarbeitet wobei eine strikte Abgrenzung des sicherheitsrelevanten Teils von dem allgemeinen Teil gefordert wird Dadurch dass die in einer Phase erarbeiteten Sicherheitsas pekte in der n chsten Phase wieder verwendet und zur Entwicklung neuer Sicherheitsaspekte eingesetzt werden findet eine sukzessive Entwicklung der Sicherheitsaspekte statt in der in den verschiedenen Phasen die Sicherheit nicht von der gr nen Wiese spezifiziert wird sondern die bereits erarbeiteten Ergebnisse strukturell umgesetzt werden 60 Ein Prozess zur Entwicklung von Anforderungsspezifikationen Funktionalit t und Sicherheit werden in diesem Modell gemeinsam entwickelt denn inner halb des Prozesses werden aufeinander aufbauend sowohl operationelle als auch sicherheitsge triebene Aspekte betrachtet Durch diese Arbeitsweise werden Ergebnisse der operationellen Analyse der Sicherheitsmodellierung zugef hrt und die daraus entstehenden Resultate in der operationalen Systemmodellierung mit einbezogen Im Gegensatz zu einer strikt getrennten Vorgehensweise k nnen somit fr hzeitige gegenseitige Beeinflussungen engl feature interac tion erkannt und modelliert werden Ein Beispiel hierf r ist die Vorgabe der operationalen Anforderungen sowie des Sicherheitsziels und die d
224. ie Realisierung der Anwen dungsf lle in Vorgangsklassen F r eine durchg ngige und sukzessive Entwicklung der Sicher heit sind die bereits in Struktur und Verhalten spezifizierten Aspekte der Zugriffssicherheit in die neuen Modelle zu transformieren und zu verfeinern Erg nzungen zur Gew hrleistung der Zugriffssicherheit in Struktur und Funktionalit t sind erneut nach Aspekten der Zugriffssicherheit zu untersuchen Problem Bei der Analyse zugriffssicherer Systeme werden aus den Anwendungsf llen und Klassen des Dom nenmodells Fach Vorgangs und Interaktionsklassen abgeleitet Bekannte Verfahren zur Analyse von Systemen wie zum Beispiel und JBR99 konzentrieren sich auf die Entwicklung der Funktionalit t und betrachten die Sicherheitsaspekte nur im Rahmen der Ermittlung von nichtfunktionalen Anforderungen Ein strukturiertes Vorgehen dazu wird nicht beschrieben Die in den Anwendungsf llen und im Dom nenmodell gewonnenen Aspekte der Zugriffssi cherheit sind jedoch in die Modelle der Analyse zu berf hren Dabei m ssen die textuell beschriebenen Anforderungen an das zu entwickelnde System in pr zisere Modelle in der Sprache der Entwickler verfeinert werden 8 4 Der Prozess der Analyse zugriffssicherer Systeme 185 Im Rahmen der Analyse m ssen im Klassendiagramm der Analyse zur L sung der Anforde rungen an die Zugriffssicherheit neue Klassen aufgenommen werden Da diese neuen Klassen noch keiner Analyse zugriffssicherer
225. ie Rechte des Team Workers g ltig sind soweit diese nicht berschrieben d h ex plizit definiert wurden Zus tzlich wurde hier noch der abstrakte allen bergeordnete Akteur Actor dargestellt Dieser abstrakte Akteur entspricht keiner Rolle Dieser Akteur entspricht 6 3 Berechtigungsmodellierung 113 TeamWorker Administrator Other A ProjectManager AN Abbildung 6 20 Hierarchie der Akteure der TimeTool Fallstudie der abstrakten Akteurklasse AC Actor in der allgemeine Berechtigungen die f r alle Akteure des Systems gelten spezifiziert werden k nnen In Literatur zur allgemeinen Gesch ftsprozessmodellierung wird die Hierarchisierung von Per sonen und Rollen kaum behandelt Zwar findet sich in ARIS Architektur integrierter Infor mationssysteme innerhalb der Organisationsmodellierung eine hierarchische Anordnung der Organisation wieder jedoch basiert diese nur auf Stellen oder Abteilungen d h Personen oder Personentypen sind Abteilungen zugeordnet und diese werden wiede rum Abteilungen zugeordnet Die Abteilungen selbst k nnen hierarchisch angeordnet werden In k nnen Rollen durch Teamobjekte die an Abteilungen assoziiert sind dargestellt werden 6 3 2 Modellierung von Zugriffsrechten auf das Dom nenmodell Die Zugriffsrechte auf Objekte des Gesch ftsmodells beschreiben wir in der in Abschnitt 4 4 vorgestellten Weise Diese leiten wir aus den Schutzzielannotationen i
226. ie durch die Einf hrung eines Sy stems entstehen von den Anforderungsentwicklern mit eingebracht und in die Modellierung aufgenommen werden Bei der Ermittlung der Bedrohungen k nnen ebenfalls durch den gewohnten Ablauf und Umgang mit Daten potenzielle Angriffsm glichkeiten ermittelt werden Entscheidend ist auch die Mitwirkung der Anwender und Auftraggeber bei der Bestimmung der Benutzerrechte Die Benutzerrechte der Akteure zum Zugriff auf die Dom nenobjekte sowie zur Ausf hrung von Aktivit ten der Gesch ftsprozesse werden au erhalb des Klassendiagramms zun chst tex tuell und sp ter formal innerhalb einer Benutzerrechtematrix modelliert Dies hat zum einen den Vorteil dass Benutzerrechte nicht bei jeder kleinen nderung des Klassendiagramms ge ndert werden m ssen wenn sich beispielsweise Assoziationen ndern oder Klassen neu strukturiert werden Weiterhin k nnen die Benutzerrechte vorab bei der gemeinsamen Frar beitung gemeinsam mit den Endanwendern Anforderungsentwicklern Auftragnehmern und Auftraggebern rein textuell spezifiziert werden F r eine automatische Codegenierung der Benutzerrechte sind diese im Verlauf der weiteren Entwicklung zu formalisieren Objekte und Aktivit ten die innerhalb der Gesch ftsprozessmodellierung bereits stabil sind d h f r die keine nderungen zu erwarten sind k nnen bereits innerhalb dieser Phase formalisiert werden w hrend instabile Klassen und Aktivit ten erst in den weiteren Teilab
227. ie zum Beispiel int int int oder true Bool Wenn ej en P MOS Ausdr cke ber den Typen s Sn sind dann ist f ei n ein P MOS Ausdruck vom Typ s 2 Variablen Sei X eine Menge von getypten Variablen dann ist jede Variable z vom Typ s ein P MOS Ausdruck vom Typ s Die Variable eines Klassentyps steht dabei f r einen Objektidentifikator Sie stellt einen vom Entwickler gegebenen Objektnamen dar und dient als Ausgangspunkt f r eine Navigation in der zugrunde liegenden Objektstruktur 4 3 Der Spezifikationsrahmen P MOS 37 Beispiele klaus User setX Set Integer projekt Aktivitaeten Set Activity 3 Attribute Sei A T ein Attribut der Klasse C T ist entweder ein Klassenname oder ein Basistyp und e ein P MOS Ausdruck vom Typ C Dann ist e A ein P MOS Ausdruck vom Typ T Beispiele klaus name und mewadis name sind P MOS Ausdr cke vom Typ String aus dem Klassendiagramm in Abbildung 4 3 Project i 2 User name String j name String budget Real project address String act 1 Activitiy manager email String pswd String userid String state userstate Abbildung 4 3 Klassendiagramm mit Attributen und Assoziationen Spezialf lle sind Attribute mit Vielfachheiten A a b T Falls a b 1 1 ist e A ein men genwertiger Ausdruck d h vom Typ Set T Ist a b 1 1 so ist e A vom Typ T Beispiel mewadis act ist
228. iert werden kann Die Modellierung von Ausf hrungsrechten ist im Detail im Abschnitt beschrieben e Modellierung der Zugriffsrechte Neben den Ausf hrungsrechten sind auch die Zugriffsrechte auf die Dom nenobjekte zu spezifizieren Alle mit Schutzzielen annotierten Klassen sind einer Benutzerrechte modellierung zu unterziehen Auch hier sind die Rechte vorab textuell und in Hinblick auf eine automatische Generierung formal zu spezifizieren Fiir Objekte ohne Schutz ziele sind die Zugriffsrechte nicht beschr nkt Da unsere Benutzerrechtespezifikationen auf dem Frlaubnisprinzip vgl Abschnitt basiert muss f r derartige Objekte und Aktivit ten der allgemeine Zugriff explizit erlaubt werden Die Modellierung von Zugriffsrechten wurde bereits in Abschnitt 6 3 2 beschrieben Produktartefakte Die folgende Auflistung beschreibt die Eingaben und Ausgaben zum Prozess der Gesch ftspro zessmodellierung zugriffssicherer Systeme Um Sicherheitsaspekte erweiterte Produktartefakte der allgemeinen Gesch ftsprozessmodellierung sind gekennzeichnet Eingabe Produktartefakte e Projektidee e Projektmission und Sicherheitsziel aus der Startphase Ausgabe Produktartefakte Dom nenmodell mit Sicherheitsaspekten erweitert Gesch ftsprozessmodell mit Sicherheitsaspekten erweitert Bedrohungs und Risikomodell Benutzerrechtemodell Kontext Dieses Prozessmuster kann nur im Rahmen einer Anforderungsspezifikation zugriffssicherer Systeme vgl Ab
229. iffssicherer Systeme Iterationsm glichkeiten aufgezeigt Hierzu wird ein iterativ anwendbarer Sicherheitsmikroprozess zur Ermittlung von Bedrohungen Risiken und Ma nahmen vorgestellt Alle erarbeiteten Konzepte werden an einer Fallstudie zur Projektverwaltung untersucht Der in dieser Arbeit vorgestellte Ansatz zur Modellierung von Aspekten der Zugriffssicherheit in den fr hen Phasen der Softwareentwicklung reduziert gegen ber anderen Ans tzen die An zahl von Objekten im Dom nenmodell indem die Berechtigungen au erhalb in einer Benutzer rechtematrix spezifiziert werden W hrend in den Ans tzen f r jedes Objekt f r das der Zugriff beschr nkt werden muss ein Objekt zur Spezifikation der 1 3 Aufbau der Arbeit 7 Berechtigung eingesetzt wird verdoppelt sich in diesen Ans tzen die Zahl der Objekte und Assoziationen nahezu Durch die pr dikative Spezifikation der Benutzerrechte auf Basis von Methodenberechtigungen k nnen die Benutzerrechte im Rahmen der Implementierung aus der formalen Beschreibung in ausf hrbaren Code zur Abpr fung der Berechtigungen generiert werden Weiterhin wird durch die vorgestellte Methode die durchg ngige Entwicklung von Aspekten der Zugriffssicherheit wie sie bei der Entwicklung von funktionalen Aspekten in ver schiedensten Ans tzen diskutiert wird beispielsweise in TAB auf den Bereich der Zugriffssicherheit bertragen Anstelle von textuellen Anforderungsbe schreibungen in Form von nichtfunktio
230. iffssicherer Systeme hervor Die Prozessanforderungen zur Entwicklung zugriffssicherer Systeme werden durchnummeriert SPAr sodass sie sp ter in der Arbeit referenziert werden k nnen SPA1 Durchg ngige Sicherheitsbetrachtungen Derzeitige Entwicklungen von zugriffssicheren Systemen scheitern oftmals daran dass Sicher heit erst in sp ten Phasen der Entwicklung betrachtet wird Die Systementwicklung erfolgt vorab gr tenteils ohne Analyse von Sicherheitsaspekten und im Nachhinein wird versucht diese zu integrieren Dies f hrt entweder zu einem zus tzlichen Arbeitsaufwand der dadurch entsteht dass bei der Integration der Sicherheitsaspekte in den sp teren Phasen Aktivit ten aus den fr heren Phasen wiederholt werden m ssen oder dazu dass Aspekte der Zugriffssi cherheit nicht in dem erforderlichen Ma betrachtet werden Durch eine durchg ngige Ent wicklung von Aspekten der Zugriffssicherheit kann die Sicherheitsanalyse auf nderungen und Erweiterungen eingehen und Sicherheitsl cken k nnen vermieden werden Ungeeignete Ma nahmen zur Gew hrleistung der Sicherheit k nnen erkannt werden in dem beispielsweise in der Phase des Testens die gew hlten Ma nahmen zur Abdeckung der Zugriffssicherheit bez glich ihrer Tauglichkeit berpr ft werden SPA2 Sukzessive Erarbeitung von Sicherheit So wie es bei einer Softwareentwicklung entscheidend zum Erfolg beitr gt dass die ausgear beitete Spezifikation als Grundlage zum Design u
231. iffssicherer Systeme zu integrieren sind Die Analyse von St rken und Schw chen existierender Vorgehensmodelle zur Entwicklung sicherer Systeme ist Gegenstand dieses Abschnitts 5 1 1 Ein phasenstrukturiertes Vorgehensmodell Da dedizierte Methoden zur Konstruktion sicherer IT Systeme im Sinne eines systematischen Security Engineerings bislang kaum entwickelt wurden stellt eine Erweiterung eines phasenstrukturierten Vorgehens mit Sicherheitsaspekten vor Abbildung 5 1 fasst die Phasen zusammen die bei einer methodischen Konstruktion sicherer Systeme zu durchlaufen sind Aufbauend auf einem Pflichtenheft in dem die funktionalen Eigenschaften des Systems seine Einsatzumgebung der Verwendungszweck die vorhandenen und einzusetzenden Systemkom ponenten und dienste sowie die Leistungs Zuverl ssigkeits und Sicherheitsanforderungen festgehalten sind wird hier die Entwicklung mit einer Bedrohungsanalyse fortgesetzt In der Bedrohungsanalyse sind die Gef hrdungsbereiche sowie die potenziellen organisatorischen technischen und benutzerbedingten Ursachen f r Bedrohungen systematisch zu entwickeln Umwelt und Einsatzgebiet Funktionale Anforderungen ne berpr fen revidieren Analyse K Vv Aufrechterhaltung im laufenden Betrieb Risikoanalyse k erg nzen pr zisieren Vv Sicherheits Sicherheitsstrategie gr
232. igung erlaubt wird verboten Jede Methodenberechtigung kann vom aufru fenden Akteur vom aktuellen Objekt und von den aktuellen Parametern des Methodenaufrufs abh ngig sein Deshalb sind die Benutzerberechtigungen Zustandsfunktionen der Art funct perm cm AC Actor C Ti Tn Bool wobei C eine Klasse und m eine Methode von C der Form m id x1 Ti n Tn T ist In dem Spezialfall von Create Methoden oder Klassenmethoden wird der Parameter C weggelassen Die Eigenschaften von Methodenberechtigungen werden durch P MOS Pr dikate spezifiziert die Bedingungen ber der gegebenen Objektstruktur beschreiben Im Folgenden geben wir einige Beispiele zur Spezifikation von Benutzerberechtigungen an Dabei modellieren wir einige Rechte aus Tabelle 4 2 f r Projektmitarbeiter team worker und Projektleiter project manager aus der TimeTool Fallstudie In Abbildung 4 7 ist nochmals Akteurzentriertes Modell zur Spezifikation von Benutzerrechten ProjectInformation Project description String name String budget Real Activity Administrator name String address String email String pswd String userid String project manager 1 x plannedStart Timestamp plannedEnd Timestamp realStart Timestamp realEnd Timestamp plannedHours Real state ActivityState User 1 ActivityType
233. ihe weite rer nichtfunktionaler Anforderungen die bei der Systementwicklung betrachtet werden 8 4 Der Prozess der Analyse zugriffssicherer Systeme 187 miissen Innerhalb der Analyse sind diese Anforderungen zu ermitteln und zu inte grieren siehe Zur Analyse der so genannten Spezialanforderungen sind die Beschreibungen zu den Erg nzungen aus dem Gesch ftsprozessmodell sowie zur Anfor derungserg nzung aus dem Anwendungsfallmodell heranzuziehen Analyse der Klassen F r alle Klassen des Klassendiagramms der Analyse sind die Beziehungen und Attri bute zu verfeinern bzw zu erg nzen Basierend auf den entwickelten Szenarien sind die Verantwortlichkeiten der Klassen festzulegen Ausf hrung des Sicherheitsmikroprozesses Bei der Realisierung der Anwendungsf lle werden weitere Klassen zum Klassendia gramm der Analyse hinzugef gt Da diese Klassen noch keiner Sicherheitsanalyse unter zogen wurden muss im Rahmen der Analyse f r diese Klassen der Sicherheitsmikropro zess aus Abschnitt 5 3 3 erneut ausgef hrt werden Die ermittelten Ma nahmen gegen Bedrohungen mit nicht vermeidbarem Risiko sind innerhalb der Analyse zugriffssicherer Systeme in den Szenarien zu integrieren Modellierung der Ausf hrungsrechte Innerhalb der Anwendungsfallmodellierung wurden die Ausf hrungsrechte f r Anwen dungsf lle spezifiziert Die Anwendungsf lle wurden auf Szenarien abgebildet die in der Designphase auf die bereits im Klassendiagramm in
234. in Gesch ftsprozessen modelliert vgl EP00 Die Menge aller Gesch ftspro zesse mit den beteiligten Akteuren sowie eine Beschreibung von Architektur Regeln Glossar und Erg nzungen bilden das Gesch ftsprozessmodell Dieses klassische Modell muss ebenfalls um Aspekte der Zugriffssicherheit erg nzt werden Anwendungsfallmodell Die einzelnen Aktivit ten in den Gesch ftsprozessen die compu tergest tzt ausgef hrt werden k nnen werden auf Anwendungsf lle des Systems vgl Bre01 abgebildet Die Menge aller Anwendungsf lle mit Ul Prototyp und Erg nzungen bilden das Anwendungsfallmodell welches ebenfalls um Aspekte der Zugriffssicherheit erweitert werden muss Analysemodell Exemplarische Szenarien vgl Bre01 f r das in den Anwendungsf llen be schriebene Verhalten ein Analyseklassenmodell die Analyse Packages und die Spezial anforderungen bilden das Analysemodell Das Analysemodell ist um Aspekte der Zu griffssicherheit zu erg nzen Bedrohungs und Risikomodell Dieses spezielle Modell zur Spezifikation der Zugriffssicher heit beschreibt die Bedrohungen und Risiken Ma nahmen sowie die berpr fungen der Ma nahmen die bei der Modellierung der Zugriffssicherheit durchzuf hren sind Dieses Modell ist eine Sammlung der Ergebnisse aus den Prozessabschnitten der Anforderungs spezifikation zugriffssicherer Systeme Benutzerrechtemodell Die Benutzerrechte vgl Kapitel 4 aus der Gesch ftsprozessmodel lierung der An
235. in Wirklichkeit nicht durchgef hrt haben R017 Das Risiko wird als hoch eingesch tzt da durch fehlerhafte Stundenbuchungen Budget berschreiten auftreten und Termin probleme nicht rechtzeitig erkannt werden k nnen account offline B018 DBuchungsdaten die auf einem externen Rechner eingegeben werden sind f r Angriffe besonders anf llig Auf dem Offline Rechner k nnen Attacken zum Auslesen und Modifizieren der zwischengespeicherten Buchungsdaten ausgef hrt werden An greifer k nnen entweder weiter Projektmitarbeiter Projektleiter anderer Projekte oder weitere Systemnutzer sein R018 Das Risiko wird als hoch eingesch tzt da sich durch unbefugte nderungen an den Stundenbuchungen fehlerhafte Budgetbe rechnungen ergeben Weiterhin k nnen durch derartige Angrif fe auch Projektmitarbeiter von Teamkollegen etc unzul ssig berwacht werden Eine besondere Gefahr bei Offline Rechnern besteht darin dass die Buchungsdaten auf diesen Rechnern zwi schengespeichert werden m ssen und diese Daten z B ber das Filesystem oder eine Datenbank ausgelesen und modifiziert wer den k nnen Dies wird u a dadurch unterst tzt dass derartige Offline Rechner wie zum Beispiel Notebooks in privaten Um gebungen ohne ausreichendem Schutz aktueller Virenscanner OS Update Firewall ber Modemverbindungen mit dem Inter net verbunden sind prepare monthly re B019 Unbefugte Akteure k nnen auf Statistiken und Berichte Angriffe port starten
236. ine Teilmenge A Tj Aj Ti der Attribute der Klasse C deren lesender schreibender oder erzeugender Zugriff durch einen Akteur a im Nachhinein nicht abgestritten werden kann F r den verbindlichen Zugriff auf ein einzelnes Attribut f hren wir f r den Methodenzugriff eine Zugriffshistorie ein d h f r Attribute deren Zugriff im Nachhinein nicht abgestritten werden kann wird der Zugriff in einer Zugriffshistorie gespeichert Zur Gew hrleistung der Nichtabstreitbarkeit f hren wir deshalb eine Relation history C AC x OB x MT x P ein wobei AC die Menge aller Akteure OB die Menge aller Objekte MZ die Menge aller Methodenidentifikatoren und P eine Sequenz ber Parametern sei F r Attribute deren Zugriff verbindlich ist gilt Ein Akteur A ein Objekt O als Attributbele gung einer Klasse C ein Methodenidentifikator methIDc und eine Sequenz von Parametern P1 Pp sind genau dann ein Element der Relation history A O methI Dez p Pp history wenn der Akteur mittels einer Zugriffsmethode methI Dc mit Parameterbelegung pi Pp auf ein Attribut eines Objekt der Klasse C mit der Belegung O zugegriffen hat Voraussetzung 6 2 Spezifikation der Schutzziele in Struktur und Verhalten 103 Project 1 Activity name String plannedStart Timestamp budget Real plannedEnd Timestamp realStart Timestamp realEnd Timestamp plannedHours Real 1
237. ing the Standard Object Modelling Language Addison Wesley Longman Inc 7th edition June 1998 David F Ferraiolo Ravi Sandhu Serban Gavrila D Richard Kuhn and Ramas wamy Chandramouli Proposed NIST Standard for Role Based Access Control In ACM Transactions on Information and System Security number 3 pages 224 274 ACM August 2001 http csre nist gov rbac rbacSTD ACM pdf GDBA SEC Anwendung des V Modells und der ITSEC In AU250 Vorge hensmodell V Modell Teil 3 Handbuchsammlung uni bremen de uniform gdpa part3_d p3sec htm Erich Gamma Richard Helm Ralph Johnson and John Vlissides Design Pat terns Elements of Reusable Object Oriented Software Addison Wesley Long man Inc 15th edition 1998 Tim Grance Joan Hash and Marc Stevens Security Considerations in the In formation System Development Life Cycle Special Publication 800 64 National Institute of Standars and Technology NIST Technology Administration U S Department of Commerce October 2003 http downloads securityfocus com library NIST SP800 64 pdf Michael Gnatz Frank Marschall Gerhard Popp Andreas Rausch and Wolf gang Schwerin Modular Process Patterns supporting an Evolutionary Software Development Process In Proceedings of the Third International Conference on Product Focused Software Process Improvement 2001 Michael Gnatz Frank Marschall Gerhard Popp Andreas Rausch and Wolfgang Schwerin Towards a Living Software Develop
238. innerhalb der bungen w hrend eines Semesters bearbeitet werden konnte Aus diesem Grund befasst sich TimeTool nur mit Ausschnitten aus dem Termin und Ressourcenmana gement In der Praxis wird eine Projektdurchf hrung auf kleine Teilaufgaben abgebildet so genann te Aktivit ten Diese Aktivit ten werden von einem oder mehreren Mitarbeitern bearbeitet Die Aufgabe eines Projektmanagementwerkzeug besteht unter anderem darin dass die Mit arbeiter zu den bearbeiteten Teilaufgaben ihre ben tigten Stunden in so genannten Stun denbuchungen eintragen k nnen Somit ist es m glich den aktuellen Projektfortschritt zu beobachten und eventuelle Zeitverz gerungen und Budget berschreitungen fr hzeitig zu er kennen Das Projektverwaltungssystem TimeTool erm glicht es beispielsweise den Mitarbeitern in einem Projekt die geleisteten Stunden zu einer Produktaktivit t zu buchen so kann zum Beispiel der Mitarbeiter K Burger 8 Stunden f r die Aktivit t Testen im Projekt OnlineBan king buchen TimeTool ist nicht nur auf ein Projekt beschr nkt es unterst tzt somit das Einrichten von neuen Projekten mit zugeordneten Projektaktivit ten Da ein Projektablauf bereits zu Beginn eines Projektes geplant wird und somit die Einzelaktivit ten in ihrer Dauer bereits festgelegt sind wird bei der Definition der Projektaktivit ten der geplante Aufwand sowie ein geplanter Start und Endtermin festgelegt Das Projektverwaltungssystem erlaubt zudem mehreren B
239. ion der Zugriffe auf sicherheitsrelevante Daten kann ein erweiterter Schutz der Da ten erforderlich werden So muss beispielsweise in einem Versandunternehmen f r einzelne Buchungseintr ge nur die Integrit t der Buchungsdaten gew hrt werden Die Vertraulichkeit der Daten muss bei reinen Buchungsdaten wie etwa in einem Buchhandel ISBN Nr Preis des Buchs Anzahl etc nicht gew hrt sein Hingegen muss ein Zugriff auf alle Buchungsdaten wie dieser im Rahmen einer Statistikauswertung notwendig ist in Bezug auf die Vertraulichkeit gesch tzt werden da andernfalls aus diesen Einzeldaten die Umsatzzahlen des Unternehmens offen gelegt werden k nnen Da sich der Wert der Information durch die Verarbeitung ndert kann mithilfe der transitiven H lle ber die Datenzugriffe nur das Minimum der Schutzziele f r die Gesch ftsprozesse aus den Gesch ftsobjekten berechnet werden F r eine vollst ndige Erfassung der Schutzziele m ssen Schutzziele f r wertsch pfende Teilabl ufe gegebenenfalls manuell erg nzt werden Im Rahmen der Gesch ftsprozessmodellierung annotieren wir eine Aktivit t mit dem Schutz ziel Icon e Vertraulichkeit Confidentiality wenn bei der Ausf hrung der Aktivit t kein un autorisierter Informationsgewinn m glich sein darf e Integrit t Integrity wenn bei der Ausf hrung der Aktivit t Objekte nicht unbe merkt oder unautorisiert manipuliert werden d rfen oder e Verbindlichkeit Non Repudiation wenn die Du
240. ird dies nicht dokumentiert Anforderungsentwickler m ssen sich in einem eigenen Arbeitsschritt dieses Wissen erarbeiten oftmals auch ohne Beisein des Kunden Um dies zu vermeiden wird ein Vorgehensmodell ben tigt welches das bereits bekannte Wissen innerhalb der Gesch ftsprozessanalyse geeignet dokumentiert und ein In strument zur analytischen Ermittlung der Anforderungen an die Zugriffssicherheit darstellt 5 3 Das Vorgehen 71 Tabelle 5 2 Abdeckung der Prozessanforderungen in Vorgehensbeschreibungen Anforderung Sicherheit Sicherheit Security in fr hen im Spiral Engineering Phasen modell Management Durchg ngige Sicherheitsbetrachtung o o o Sukzessive Erarbeitung der Sicherheit o o o Gemeinsame Entwicklung von Funktionen und Sicherheit Lokale Spezifikation der Sicherheit o o Betrachtung von Produktartefakten o o o Iterative Entwicklung o o o Sicherheitsmodellierung in der 7 u 7 Geschaftsprozessanalyse Legende o wird unterst tzt oder erw hnt wird nicht unterst tzt 5 2 2 Bewertung existierender Vorgehensmodelle In den Tabellen 5 1 und 5 2 sind die Bewertungen der oben vorgestellten existierenden Vor gehensmodelle bzw beschreibungen zusammengefasst Derzeit existierende Prozessmodelle betrachten Aspekte der Zugriffssicherheit durchg ngig d h ber allen Phasen hinweg und die Sicherheitsaspekte werden zudem sukzessive erar beitet Weitgehend gemeinsam wird auch der Ansatz verfolgt da
241. isch angeordneten Akteure sind die Ausf hrungsrechte auf Aktivit ten zu spezifizieren Alle Aktivit ten die vorab mit einem Schutzziel an notiert wurden sind dabei einer genauen Analyse zu unterziehen Den verschiedenen Akteuren des Systems sind aufbauend auf den Analyseergebnissen Ausf hrungsrechte zu vergeben F r alle Aktivit ten die mit keinem Schutzziel versehen wurden ist die Ausf hrung nicht beschr nkt Da der Benutzerrechtespezifikation das Erlaubnisprinzip zugrunde liegt m ssen jedoch den Akteuren zur Ausf hrung von nicht beschr nkten Aktivit ten die notwendigen Benutzerrechte einger umt werden Da innerhalb der Gesch ftsprozessmodellierung viele Einzelheiten noch offen sind k n nen sich die Ausf hrungsrechte w hrend der weiteren Analyse noch ver ndern Aus diesem Grund werden die Ausf hrungsrechte vorab textuell beschrieben Sobald die Ausf hrungsrechte stabil sind d h keine nderungen mehr zu erwarten sind wer den sie in Hinblick auf eine automatische Generierung der Zugriffsmethoden pr dika tiv formalisiert F r diejenigen Aktivit ten des Systems f r die bereits innerhalb der Gesch ftsprozessmodellierung die Ausf hrungsrechte stabil sind k nnen auch bereits hier diese Rechte formal spezifiziert werden Jedoch ist zu erwarten dass im Rahmen der Gesch ftsprozessmodellierung nur ein kleiner Teil der Ausf hrungsrechte formal 128 Die Gesch ftsprozessmodellierung zugriffssicherer Systeme spezifiz
242. ist abh ngig A pen p B von Produkt B Abbildung 5 10 Produktartefakte der Anforderungsspezifikation mit ihren Abhangigkeiten Geschaftsprozessmodell das Anwendungsfallmodell und das Analysemodell Bestandteil einer herk mmlichen objektorientierten Entwicklung Diese Modelle m ssen an die Entwicklung zugriffssicherer Systeme angepasst werden Beim Bedrohungs und Risikomodell sowie beim Benutzerrechtemodell handelt es sich um eigenst ndige Modelle zur Spezifikation der Zugriffs sicherheit Produktartefakte sind die Ein und Ausgaben f r die Prozessmuster bestimmte Produktar tefakte m ssen f r die Ausf hrung des Prozessmusters vorhanden sein sodass ein Prozessmu ster abgearbeitet werden kann Dabei werden Ausgabe Produktartefakte erzeugt Derartige Abh ngigkeiten zwischen den Produktartefakten k nnen in einem Abh ngigkeitsgrafen model liert werden Abbildung 5 10lzeigt die Produktartefakte mit ihren Abh ngigkeiten als Grafen Bei der Erarbeitung des Gesch ftsprozessmodells wird das Dom nenmodell sowie das Bedro hungs und Risikomodell gemeinsam und unter gegenseitigem Einfluss erarbeitet ebenso das Anwendungsfallmodell und das Analysemodell nur dass hierbei die bereits erarbeiteten Er gebnisse aus dem Gesch ftsprozessmodell bzw aus dem Anwendungsfallmodell mit einflie en Das Benutzerrechtemodell das wie in Tabelle 5 3 gezeigt innerhalb der Gesch ftsprozessmo dellierung der Anwendungsfallmodellierung und der An
243. iten wie beispielsweise einzelnen Gesch ftsprozessen oder Anwendungsf llen findet nicht statt Die existierenden Ans tze beschreiben zumeist nur Vorgehensprozesse gehen dabei auf Produktartefakte mit Ausnahme des vorgestellten CC konformen Prozesses vgl Abschnitt kaum ein F r eine iterative Entwicklung werden bei bereits erste Ideen vorgestellt jedoch wurden diese in heutigen Vorgehensmetho den zur Entwicklung zugriffssicherer Software kaum umgesetzt Im Bereich der Standardentwicklung werden heute auch objektorientierte Vorgehensweisen eingesetzt die bereits mit der fr hen Phase der Gesch ftsprozessmodellierung beginnen kleine Portionen von Struktur und Verhalten in Anwendungsf llen ausarbeiten und starke Betonung auf Produktartefakte als Ein und Ausgaben zu den Prozessen legen Der in diesem Kapitel vorgestellte Prozess zur Entwicklung einer Anforderungsspezifikation f r zugriffssichere Systeme vereinigt die objektorientierte Standardentwicklung mit der Model lierung von zugriffssicheren Systemen und integriert so die durchg ngige und sukzessive Ent wicklung von sicheren Systemen in ein objektorientiertes Vorgehen Prozessanforderungen die aus gegenw rtigen Security Engineering Methoden und aus Standardentwicklungsmethoden abgeleitet worden sind wurden in dem Prozess der Anforderungsspezifikation zugriffssicherer Systeme betrachtet In diesem Kapitel wurde hierzu ein Prozess zur Anforderungsspezifikation zugriffssicherer System
244. kteure festgelegt Widerspr che k nnen vermieden werden wenn die Gemeinsamkeiten der Akteure ermittelt und f r diese Gemeinsamkeiten die Rechte einmalig vergeben werden i O ii O AA B IN gt gt 10 Legende X Y Y is a special kind of X J Abbildung 6 18 Hierarchie der Akteure Die redundante Vergabe von Benutzerrechten f r verschiedene Akteure mit gleichen Benut zerrechten ist ebenfalls zu vermeiden da hier beispielsweise bei einer Anderung der Benut zerrechte ein einzelnes Benutzerrecht bersehen werden und dies zu Inkonsistenzen f hren 112 Die Geschaftsprozessmodellierung zugriffssicherer Systeme kann Um derartige Probleme bei der Modellierung der Benutzerrechte von vornherein auszu schlie en sind die Benutzer vorab in einer Hierarchie anzuordnen sodass Gemeinsamkeiten ermittelt und die Benutzerrechte m glichst einheitlich vergeben werden k nnen Bei der Hier archisierung sind zwei Abh ngigkeitsvarianten m glich e Die Akteure existieren nebeneinander im System und haben eigene Benutzerrechte Derartige Akteure sind nur von einem gemeinsamen abstrakten bergeordneten Akteur abh ngig zwischen konkreten Akteuren gibt es keine Abh ngigkeiten e Die Akteure sind hierarchisch angeordnet Der speziellere Akteur erbt die Benutzer rechte von dem bergeordneten Akteur und besitzt selbst weitere eigene Benutzerrech te Zudem k nnen vererbte Benutzerrechte berschri
245. ktivit ten muss jeweils nur die Autorisierung berpr ft werden 7 3 Entwicklung der Sicherheitsanwendungsf lle Wie wir bereits in Abschnitt beschrieben haben sind im Rahmen der Anwendungsfall modellierung Aktivit ten der Gesch ftsprozesse in Anwendungsf lle berzuf hren Es sind nur diejenigen Aktivit ten zu transformieren die durch das zu entwickelnde System realisiert werden sollen Alle zu realisierenden Anwendungsf lle beschreiben die Gesamtfunktionalit t des zu entwickelnden Systems Bei der Gesch ftsprozessmodellierung zugriffssicherer Systeme haben wir den sicherheitskri tischen Aktivit ten bereits Schutzziele zugeordnet Bedrohungen und Risiken ermittelt so wie Ma nahmen zur Abwehr entworfen Im Rahmen der Entwicklung der Sicherheitsanwen dungsf lle sind nun die Schutzziele aus den Aktivit ten der Gesch ftsprozesse in die Anwen dungsf lle zu integrieren und die ermittelten Bedrohungen Risiken und Ma nahmen anzu passen Da die Betrachtung der Zugriffssicherheit auch weitere funktionale Anforderungen mit sich bringt muss die Beschreibung der funktionalen Anforderungen des Systems um so genannte Sicherheitsanwendungsf lle erg nzt werden 7 3 Entwicklung der Sicherheitsanwendungsfalle 155 Auf die Erweiterung von Anwendungsf llen um Sicherheitsaspekte gehen wir in Abschnitt 7 3 1 ein Die Erg nzung von Sicherheitsanwendungsf llen wird in Abschnitt 7 3 1leingef hrt 7 3 1 Erweiterung der Anwendungsf ll
246. l er zwischendurch die Rechte darauf verloren hat Prinzip der minimalen Rechte Durch das Prinzip der minimalen Rechte engl need to know principle enth lt ein Subjekt nur genau die Zugriffsrechte die es zur Erf llung seiner Aufgaben ben tigt Ein Superuser mit uneingeschr nkten Rechten im System ist ein offensichtliches Gegenbeispiel zu diesem Prinzip Prinzip der Benutzerakzeptanz Dass die eingesetzten Sicherheitsmechanismen einfach zu nutzen sind und dass sie automatisch und routinem ig angewendet werden wird durch das Prinzip der Benutzerakzeptanz engl economy of mechanism prinicple gefordert 2 2 Grundlagen zur IT Sicherheit 19 Offener Entwurf Das Prinzip des offenen Entwurfs engl open design fordert dass die im Entwurf eingesetzten Mechanismen und Verfahren offen gelegt werden miissen no security through obscurity Die Sicherheit eines Systems darf nicht von der Geheimhaltung spezieller Verfahren abh ngig sein zum Beispiel darf die Sicherheit kryptografischer Verfahren nicht darauf beruhen dass die Verschl sselungsverfahren nicht bekannt sind Sicherheitskern Bei der Konstruktion von gro en Systemen wie beispielsweise bei Web basierten Informa tionssystemen und Betriebssystemen werden sicherheitsrelevante Dienste und Ma nahmen h ufig von den brigen Systemteilen isoliert in einem Sicherheitskern engl security kernel realisiert Die vertrauensw rdigen Sicherheitsdienste nennt man die Trusted Co
247. lME im Sommersemester 2001 an der TU Miinchen exemplarisch angewendet wurde Inner halb PalME wurde eine sichere elektronische Geldb rse f r den Palm Pilot mit einer Gruppe von 18 Studenten nach dem in der Diplomarbeit vorgestellten Security Engineering Prozess entwickelt Das Vorgehen war auf eine anschlie ende Sicherheitsevaluierung nach den Com mon Criteria BSI99 Sicherheitsstufe EAL2 ausgerichtet Es wurden im Entwicklungsprozess alle notwendigen Spezifikationen f r eine Sicherheitsevaluierung in die Entwicklung mit ein bezogen die nach der Sicherheitsstufe 2 der siebenstufigen Gliederung gefordert werden und diese Dokumente wurden im weiteren Entwicklungsprozess verwendet Durch dieses Vorge hen setzen sich die Entwickler fr hzeitig mit Sicherheitsaspekten auseinander und k nnen so fr her auf Fehler oder Sicherheitsl cken reagieren und Gegenma nahmen einleiten Eine Erkennung von Fehlern und Sicherheitsl cken in sp ten Phasen des Entwicklungsprozesses ist immer mit hohem Zeit und Kostenaufwand verbunden und kann somit vermieden werden Abnahme und 1 1 Planun Analyse i Design i Implementierun gees 8 y 8 P 8 Einf hrung i i i 1 KM System i i w hlen i 1 l 1 Systemspezifikation TOE en of ST erstellen f r Komponenten erstellen Implementieren und Dokumentieren Durchf hrbar keitsstudie durchf hren CC Spezifikation erstellen eae Mi Projektplan erstellen
248. lass actor TeamWorker ProjectManager PCInsertNewAccounting E insert new accountings E to released activities from own projects Die Bedingung ber der Objektstruktur tritt in der pr dikativen Spezifikation der Execute Permission auf Bei der Spezifikation der Berechtigung der process Methode der Vorgangs klasse PCInsertNewAccounting wird das hinzuzuf gende Accounting Objekt als Parameter bergeben Ytw ACTeamWorker Va Accounting V pe PCInsertN ew Accounting a user tw rolerep A a activity state treleased gt perm PCInsertNew Accounting process tw pe a Die Objektstrukturberechtigungen auf Aktivit ten stehen eng in Bezug mit Zugriffsberechti gungen auf Objekten Finden innerhalb einer Aktivit t nur Objektzugriffe und keine Aufrufe weiterer Ablaufmethoden aus Vorgangsklassen statt so kann die Objektstruktur Permission aus den Zugriffsberechtigungen der Objektzugriffsmethoden berechnet werden Sie ist dann die logische and Verkn pfung von allen Berechtigungen der Objektzugriffsmethoden die in der process Methode aufgerufen werden Der Zusammenhang von Zugriffs und Ausf hrungs berechtigungen wird in Abschnitt 7 4 diskutiert 120 Die Gesch ftsprozessmodellierung zugriffssicherer Systeme Instanz Permission Eine Sonderform der Objektstruktur Permission stellt die Instanz Permission dar Hierbei darf eine Aktivit t nur von bestimmten Instanzen der zugeordneten Rolle ausgef hrt werden d h
249. lasse Logging muss bei der Ermittlung der Benutzerrechte betrachtet werden Die Abl ufe bei denen Eintr ge zu Stundenbuchungen erzeugt oder ver ndert werden sind entsprechend anzupassen Aus den Bedrohungen B011 und B013 ergeben sich nderungen am Dom nenmodell In Ab bildung sind diese Anderungen am Klassendiagramm zum Dom nenmodell grau gekenn zeichnet Project SET Activity ProjectInformation l description String name String plannedStart Timestamp budget Real plannedEnd Timestamp x x realStart Timestamp realEnd Timestamp plannedHours Real state ActivityState 1 1 1 n CI i CI CI Administrator a ProjectManager a TeamWorker Ir name String name String name String address String address String address String email String email String email String pswd String pswd String pswd String userid String userid String userid String 1 1 1 1 F 1 CIN Logging Accounting EN accountDate Timestamp accountDate Timestamp requiredHours Real requiredHours Real Abbildung 6 32 Erg nzungen am TimeTool Dom nenmodell zur Abwehr von Bedrohungen Alle nderungen m ssen ebenfalls einer Analyse der Sicherheitsaspekte unterzogen werden An den Klassen Lo
250. lasse vor unerlaubter Ver nderung zu sch tzen so annotieren wir die Klasse mit dem Ste reotyp lt Integrity gt Falls der Zugriff auf Attribute einer Klasse nicht abstreitbar sein muss so kennzeichnen wir die Klasse mit dem Schutzziel lt NonRepudiation gt Zur Abgrenzung von allgemeinen Stereotypen und den eingef hrten Stereotypen f r die Schutzziele f hren wir eigene Schutzziel Icons ein In Abbildung 6 3 sind die drei Schutzziel Icons zu den eingef hrten Stereotypen abgebildet Die Schutzziel Icons enthalten das Schl s selwort SEC f r Security und den ersten Buchstaben des zu sch tzenden Schutzziels Cl CN IN CIN Class D ae Class E Class F gt Class G r Abbildung 6 4 Kombinierte Stereotypen zu den Schutzzielen der Gesch ftsobjekte Attribute sind nicht nur gegen einzelne Angriffe zu sch tzen sehr h ufig sind Kombinationen m glich So kann beispielsweise ein unerlaubtes Lesen und ein unerlaubtes Manipulieren eines Attributes eines Objektes ein potenzieller Angriff sein Um derartige kombinierte Angriffe in einem einzigen Klassendiagramm zu annotieren ben tigen wir komplexe Stereotypen sodass 98 Die Geschaftsprozessmodellierung zugriffssicherer Systeme wir derartige Schutzziele im Klassendiagramm ausdr cken zu k nnen Da jede Kombinati onsm glichkeit der vorgestellten einzelnen Sch
251. lassen und Create Methoden um fasst definieren wir Berechtigungen perm Cat AC Actor Bool und induzieren die folgenden Methodenberechtigungen f r alle Methoden m von Klassen C in Cat Va AC Actor o C a Ti an Tn perm Cat a gt perm c m Q 0 Q1 n Kategorieberechtigungen dieser Art h ngen nur von dem Akteur ab der den Methodenaufruf ausf hrt Bez glich der Anwendung dieses Konzepts stellen wir eine Menge von vordefinierten Kategorien zur Verf gung REA Dc Kategorie ber allen Methoden die Attribute der Klasse C lesen UPDATEc Kategorie ber allen Methoden die Attribute der Klasse C ndern CREATEc Kategorie ber allen Create Methoden der Klasse C Weiterhin definieren wir get und set Methoden zu Attributen als vordefinierte Elemente der READc bzw UPDATEc Kategorien Dabei ist zu betonen dass es Methoden geben kann die sowohl zur REA Dc als auch zur UPDATEc Kategorie geh ren Als Beispiel k nnen wir die informalen Berechtigungen aus Tabelle 4 2 direkt in entsprechende Berechtigungen mit Methodenkategorien transformieren Als Beispiel f r eine Kategoriebe rechtigung transformieren wir die folgende informale Berechtigung Ein Projektmitarbeiter kann alle seine eigenen Buchungen lesen unabh ngig vom Projekt Die Kategorieberechti gung hierzu lautet Vtw ACTeamWorker Va Accounting a user tw rolerep gt perm READ Accounting ac a Die Menge der vordefinierten Methodenkategorien kan
252. laudia Eckert IT Sicherheit Konzepte Verfahren Protokolle Oldenbourg Wissenschaftsverlag GmbH second edition 2003 Hans Erik Eriksson and Magnus Penker Business Modeling with UML Business Patterns at Work John Wiley amp Sons Inc 2000 202 Literaturverzeichnis FCK03 FH97a FH97b Fir03 FKK96 Fla97 FS98 FSG o1 GDB GHJV98 GHS03 GMP 01a GMP 01b David F Ferraiolo Ramaswamy Chandramouli and D Richard Kuhn Role Based Access Control Artech House Publishers first edition April 2003 E B Fernandez and J C Hawkins Determining Role Rights from Use Cases In Workshop on Role Based Access Control pages 121 125 ACM 1997 E B Fernandez and J C Hawkins Extending Use Cases and Interaction Dia grams to Develop System Architecture Requirements Technical Report TR CSE 97 47 Department of Computer Science and Engineering Florida Atlantic University Boca Raton Florida 1997 Donald G Firesmith Security Use Cases Journal of Object Technology 2 3 53 64 May June 2003 http www jot fm issues issue_2003_05 column6 Alan O Freier Philip Karlton and Paul C Kocher The SSL Protocol Version 3 0 Netscape Communications 1996 http wp netscape com eng ss13 David Flanagan Java in a Nutshell A Desktop Quick Reference O Reilly amp Associates Inc second edition May 1997 Martin Fowler and Kendal Scott UML Distilled Apply
253. lche Rechte f r zu sch tzende Objekte festzulegen sind In der Rechteverwaltung ist dar ber hinaus festzulegen unter welchen Umst nden ein Subjekt ein vergebenes Recht wahrnehmen darf beispielsweise Mitgliedschaft in einer Rolle Rechtepr fung Die Zugriffskontrolle ist ein weiteres notwendiges Instrument zur Abwehr von unautorisierten Zugriffen Mit der Sicherheitsgrundfunktion der Rechtepr fung ist festzulegen wann d h bei welchen Aktionen eine berpr fung stattfinden muss Gem dem Vollst ndigkeitsprinzip sollte jeder Zugriff kontrolliert werden Aus Leistungs und Aufwandsgr nden wird davon aber h ufig abgewichen Beweissicherung Die Beweissicherung ist zur Abwehr von Angriffen notwendig die versuchen durchgef hrte Aktionen im Nachhinein abzustreiten Dabei ist festzulegen welche Ereignisse zu protokol lieren und welche Informationen dabei zu erfassen sind Minimal m ssen dabei die Identit t des ausf hrenden Subjekts die betroffenen Objekte und Operationen sowie der Zeitpunkt der Ausf hrung protokolliert werden Mit der Beweissicherung ist dar ber hinaus festzule gen welche Subjekte unter welchen Randbedingungen auf die protokollierten Daten zugreifen d rfen Zugriffe auf protokollierte Daten sind restriktiv zu gew hren um eine nachtr gliche unautorisierte Modifikation zu verhindern 22 Grundlagen 3 Eine Fallstudie Das Projektverwaltungssystem Time Tool Im vorausgehenden Kapitel haben wir eine
254. le Ausarbeitung der Anwendungsf lle Entwurf der UI Prototypen le Ausf hrung des Sicherheits mikroprozesses lt Modellierung der Ausf hrungsrechte Modellierung der Zugriffsrechte Abbildung 7 13 Der Ablauf der Anwendungsfallmodellierung zugriffssicherer Systeme 7 5 Der Prozess der Anwendungsfallmodellierung zugriffssicherer Systeme 171 zugriffssicherer Systeme erlauben es dass beispielsweise die Anwendungsf lle zu einem Ge sch ftsprozess vollst ndig ausgearbeitet werden Anschlie end steht es dem Entwickler offen weitere Anwendungsf lle auszuarbeiten oder Bedrohungen und Risiken durch die Ausf hrung des Sicherheitsmikroprozesses zu ermitteln Ebenso k nnen die Berechtigungen jeweils nach Ermittlung der Schutzziele oder am Ende der Anwendungsfallmodellierung zugriffssicherer Systeme bestimmt werden Durch den vorgestellten Prozess wird die gemeinsame Entwicklung von Funktionalit t und Sicherheit gefordert Sobald Aspekte der Zugriffssicherheit betrachtet werden k nnen schreibt der Prozess die Behandlung von Sicherheitsaspekten vor Insbesondere sind die Modellierung der Akteurhierarchie die Modellierung von Sitzungen Authentifikation und Autorisierung sowie die Entwicklung der Sicherheitsanwendungsf lle stark mit der funktionalen Entwicklung verzahnt Schutzziele Bedrohungen Ma nahmen und Benutzerrechte m ssen vor Abschluss der Anwendungsfallmodellierung zugriffssi
255. le F r komplexe Aufgaben ist es notwendig den L sungsprozess in kleinere Einheiten zu glie dern Ein Vorgehensmodell gibt eine Gliederung f r den Prozess der Softwareentwicklung vor es regelt den Ablauf des L sungsprozesses und unterteilt ihn in berschaubare Abschnitte sodass eine schrittweise Planung Durchf hrung Entscheidung und Kontrolle erm glicht wird vgl PB96 Diese Grundidee der Systemtechnik wird auch auf die Vorgangsweise bei der Entwicklung von Software angewandt Softwareprojekte werden dabei in Phasen unterteilt Die Menge der Phasen und die Ordnung ihrer zeitlichen Abfolge bezeichnet man als Softwarelebenszyklus In so genannten Phasenmodellen werden die einzelnen Phasen strukturiert hintereinander ausgef hrt In den objektorientierten Lebenszyklusmodellen stehen atomare Modellierungs einheiten mit Verhaltens und Strukturbeschreibungen im Vordergrund 2 1 1 Klassisch strukturierte Vorgehensweisen Das bekannteste und lteste Phasenmodell ist das Wasserfallmodell Roy70 In den 70er Jah ren entstanden eine Reihe unterschiedlicher Phasenmodelle und kombinierte Phase T tig keitsmodelle Den damaligen Modellen lag die Idee zugrunde dass man ein Problem nur detailliert genug planen m sse um es bew ltigen zu k nnen Die sequenzielle Abarbeitung der Phasen bewirkt in diesen Modellen dass Planungs und Entwicklungsfehler erst sp t 12 Grundlagen bemerkt und Risiken zumeist sp t erkannt werden Ver nde
256. lebenszyklus und zur Anforderungsspezifikation zugriffssicherer Systeme k nnen wir zu diesem Prozessmuster die Menge der Ein und Ausgabe Produktartefakte nicht pr zise trennen da das vorgestellte Prozessmuster auf verschiedenen Stufen der Modellierung zu griffssicherer Systeme angewendet wird und somit unterschiedliche Produktartefakte als Ein und Ausgabe f r den Prozess dienen Bedingt durch die Verfeinerung stellen zumeist die 82 Ein Prozess zur Entwicklung von Anforderungsspezifikationen Ausgabe Produktartefakte der Modellierungsstufe n die Eingabe Produktartefakte der Stufe n 1 dar sodass sich in dem bergeordneten Sicherheitsmikroprozess Ein und Ausgabe Produktartefakte decken Ein und Ausgabe Produktartefakte Gesch ftsprozessmodell Anwendungsfallmodell Analysemodell Dom nenmodell Bedrohungs und Risikomodell Benutzerrechtemodell Kontext Da eine Bedrohungs und Risikoanalyse in den fr hen Phasen einer Entwicklung zugriffssiche rer Systeme durchzuf hren ist eignet sich der vorgestellte Sicherheitsmikroprozess zur Anwen dung innerhalb der im Abschnitt 5 3 2 vorgestellten Anforderungsspezifikation zugriffssicherer Systeme Durch die Erarbeitung der Sicherheitsanforderungen im mehrmaligen Ausf hren des Mikroprozesses eignet sich dieser besonders f r mehrphasige Anforderungsspezifikationen und f r iterative Vorgehensweisen wie sie beispielsweise in heutigen objektorientierten Vorgehens modellen vgl Kru00 zu
257. len dar und definiert grundlegende Begriffe zur Sicherheit Um die abstrakt eingef hrten Bausteine der Methode die Benutzerrechtemodellierung die Beschreibungstechniken und die Produktartefakte an einem durchg ngigen Beispiel zu illu strieren wird in Kapitel 3 als Fallstudie das Projektverwaltungssystem TimeTool vorgestellt Das akteurzentrierte Modell zur Spezifikation von pr dikativen Benutzerrechten wird in Kapi tel 4 vorgestellt Neben einer allgemeinen Vorstellung des RBAC Ansatzes wird das zugrunde liegende Spezifikationsframework P MOS vorgestellt und die formale Modellierung von Be nutzerrechten eingef hrt Dabei wird auch die Spezifikation von Zugriffsrechten in OCL sowie eine Erweiterung des methodenbasierten Ansatzes auf Klassen gezeigt Kapitel 5 stellt den Prozess zur Entwicklung einer Anforderungsspezifikation zugriffssiche rer Systeme vor Hierbei werden vorab existierende Vorgehensans tze untersucht und daraus Anforderungen an ein Vorgehen zur Entwicklung zugriffssicherer Systeme abgeleitet Drei Prozessmuster zur Sicherheitsanforderungsdefinition zur Integration der Anforderungsspezi fikation in den Softwarelebenszyklus und zum Sicherheitsmikroprozess f hren das eigentliche Entwicklungsvorgehen ein Ein berblick ber die Produktartefakte und eine Bewertung der Prozessanforderungen f r den eingef hrten Prozess schlie en das Kapitel ab 8 Einf hrung Das Vorgehen der Gesch ftsprozessmodellierung der A
258. lgemeinen Sicherheit ist ebenfalls ein sehr weit reichendes Gebiet das sich beispielsweise mit e technischen L sungsm glichkeiten wie Protokollen Authentifikationstechniken Schl s selmanagement Hashfunktionen oder Realisierungen der Zugriffskontrolle etc 16 Grundlagen e anwendungsspezifischen Fragestellungen wie zum Beispiel Netzwerksicherheit und Da tenbanksicherheit sowie e mit bergeordneten Sicherheitsthemen wie beispielsweise berwachung Passw rter Biometrie Softwareanomalien Konstruktion sicherer Systeme Datenschutz und Ko pierschutz oder Steganaografie besch ftigt siehe VM02 Im Folgenden stellen wir eine kleine Auswahl an grundlegenden Begriffen Schutzzielen Sicherheitsprinzipien Bedrohungen und Angriffe sowie Sicherheitsgrundfunktionen vor Viele der Begriffe und Definitionen wurden aus dem sehr umfangreichen Buch zur IT Sicherheit von Frau Prof Dr C Eckert bernommen und wenn notwendig angepasst 2 2 1 Grundlegende Begriffe Bevor wir auf Ziele Prinzipien und Funktionen der Sicherheit eingehen sind grundlegende Begriffe und der Sicherheitsbegriff zu definieren IT System Ein IT System ist ein geschlossenes oder offenes dynamisches technisches System mit der F higkeit zur Speicherung Verarbeitung bertragung und Darstellung von Informationen Information und Datenobjekte IT Systeme speichern verarbeiten bertragen und stellen Informationen dar Die Informa tion ist ein A
259. lten Die in den Klassen des Dom nenmodells spezifizierten Schutzziele wurden bereits innerhalb der Gesch ftsprozessmodellierung zugriffssicherer Systeme als auch bei der Anwendungsfall modellierung zugriffssicherer Systeme zur Ermittlung von Bedrohungen Ma nahmen sowie zur Benutzerrechtemodellierung verwendet Diese Schutzziele sind bereits durch die Gegen ma nahmen abgedeckt und m ssen nicht in die Klassen des Analysemodells bertragen wer den F r Klassen die im Klassendiagramm des Analysemodells w hrend der Analysephase hinzu gef gt werden insbesondere f r die neu hinzugef gten Vorgangsklassen sind die Bedrohun gen Risiken und Ma nahmen durch die wiederholte Ausf hrung des Sicherheitsmikroprozes ses aus Abschnitt 5 3 3 zu berpr fen Die ermittelten Ma nahmen sind in der Analysephase umzusetzen Die Benutzerrechte sind auf das Analysemodell abzubilden insbesondere sind die Ausf h rungsrechte von Anwendungsf llen auf die process Methoden der Vorgangsklassen zu ber f hren Diejenigen Benutzerrechte die noch textuell beschrieben sind m ssen pr dikativ spe zifiziert werden Abbildung 8 5 gibt einen berblick ber die Aktivit ten der Analyse zugriffssicherer Systeme Da in allen Aktivit ten Aspekte der Zugriffssicherheit betrachtet werden sind alle Aktivit ten grau hinterlegt 186 Die Analyse zugriffssicherer Systeme Aktivitaten Innerhalb der Analyse zugriffssicherer Systeme sind bei der Proze
260. lung Das Benut zerrechtemodell basiert auf der Sprache P MOS zur Navigation ber Objekten Zust nden und Objektbeziigen die sich zur Formulierung von Benutzerrechten im Rahmen des objekt orientierten Vorgehens eignet Im Gegensatz zu existierenden Ans tzen zur Modellierung von Berechtigungen werden die Benutzerrechte au erhalb des Datenmodells in einer Berechti gungsmatrix vorab textuell spezifiziert und im Rahmen der weiteren fr hen Entwicklungsstu fen in Hinblick auf eine sp tere Generierung formalisiert Die durchg ngige Integration von Sicherheitsanforderungen und die sukzessive Erarbeitung wird in den Entwicklungsphasen der Gesch ftsprozessmodellierung der Anwendungsfallmo dellierung und der Analyse diskutiert Die einzelnen Arbeitsschritte zur Modellierung der Sicherheit in Verbindung mit der Entwicklung der Systemfunktionalit t werden anhand von Prozessmustern beschrieben Im Rahmen der Entwicklung sind bestehende Produktartefakte mit Informationen zur Abdeckung der Zugriffssicherheit anzureichern sowie neue Produktar tefakte hinzuzuf gen Die vorgestellte Analyse von Aspekten der Zugriffssicherheit basiert auf der Integration von Schutzzielen innerhalb von Abl ufen und Datenmodellen Im Vordergrund stehen dabei die Schutzziele Vertraulichkeit Integrit t Verbindlichkeit sowie Authentizit t Aufbauend auf diesen Schutzzielannotationen werden Bedrohungen Risiken und Ma nahmen innerhalb eines Sicherheitsmikroprozesses ermitt
261. m bereits ein Akteur angemeldet hat und dieser Kontext nach Beendigung der speziellen Authentifikation wiederherzustellen ist Zur Ermittlung der gemeinsamen und speziellen Authentifikationen f gen wir die eben ver feinerten Ablaufdiagramme nach folgenden Heuristiken zusammen e Werden innerhalb von durchgehend authentifizierten Abl ufen d h in Abl ufen bei denen ein Akteur oder ein externes System zu Beginn authentifiziert und am Ende des Ablaufs abgemeldet wird einheitlich nur einseitige oder gegenseitige Authentifikation verwendet so k nnen die einzelnen Abl ufe so zusammengef gt werden dass zu Beginn eine gemeinsame Authentifizierung f r alle Akteure und externe Systeme stattfindet vgl hierzu allgemeine Login und Logout Aktivit ten am Beginn und Ende der Abl ufe in Abbildung 7 6 7 2 Modellierung der Authentifikation 153 Administrator backup project freeze project login create new project create project ae freeze project activities administrate userdata jJ release project release project logout Abbildung 7 7 Authentifikation des Administrators In den exemplarischen Ablaufdiagrammen werden die Aktivit ten nach der Authentifi zierung sequenziell ausgef hrt Einige Aktivit ten oder Teilsequenzen dieser Sequenzen k nnen auch eigenst ndig d h losgel st aus der Sequenz ausgef hrt werden sodass vorab ebenfalls eine eigene Authenti
262. m unterscheidet zwischen verschie denen Akteuren und stellt in Abh ngigkeit von der Benutzerrolle verschiedene Systemfunk tionalit ten zur Verf gung Obwohl das Projektverwaltungssystem TimeTool nur sehr begrenzte Funktionen eines Pro jektmanagementtools bereitstellt eignet es sich sehr gut f r unsere Betrachtungen im Rahmen dieser Arbeit Wie wir noch sehen werden ist durch die eingeschr nkte Funktionalit t das System bersichtlich sodass beispielsweise die Systemfunktionen und das Klassendiagramm berschaubar bleiben Weiterhin bietet dieses kleine System bereits eine gro e Menge an Si cherheitsanforderungen die wir in den folgenden Kapiteln systematisch herausarbeiten und in den Phasen der Anforderungsspezifikation integrieren werden 28 Eine Fallstudie Das Projektverwaltungssystem TimeTool 4 Akteurzentriertes Modell zur Spezifikation von Benutzerrechten Nachdem wir in den vorausgehenden Kapiteln die Grundlagen zu Vorgehensmodellen und zur Sicherheit sowie die Fallstudie pr sentiert haben stellen wir hier das akteurzentrierte Modell zur Spezifikation von Benutzerrechten auf Basis eines objektorientierten Systemmodells vor Die Spezifikation der Benutzerrechte findet heute in den g ngigen Methoden am Ende der Designphase statt d h nach Fertigstellung des Klassendiagramms Die Benutzerrechte wer den dabei meist nur informal spezifiziert Da aber alle Sicherheitseigenschaften w hrend der gesamten Entwicklung durchg
263. mationen nur von berechtigten Subjekten oder Objekten zugegriffen werden kann Verbindlichkeit Die Verbindlichkeit oder Zuordenbarkeit engl non repudiation einer Menge von Aktionen ist gew hrleistet wenn es nicht m glich ist dass ein Subjekt im Nachhinein die Durchf hrung einer solchen Aktion abstreiten kann Verf gbarkeit Die Verf gbarkeit engl availability eines Systems sagt aus dass authentifizierte Subjekte in der Wahrnehmung ihrer Berechtigungen nicht unautorisiert beeintr chtigt werden k nnen 2 2 3 Sicherheitsprinzipien Bereits 1975 haben Saltzer und Schroeder SS75 allgemeine Prinzipien zur Entwicklung von sicherer Software entwickelt Weitere allgemeinere Prinzipien zur Entwicklung sicherer Sy steme sind auch in VMO2 zu finden Erlaubnisprinzip Nach dem Erlaubnisprinzip engl fail safe defaults principle ist grunds tzlich jeder Zugriff verboten und nur durch eine explizite Erlaubnis kann ein Zugriffsrecht gew hrt werden Vollst ndigkeitsprinzip Das Vollst ndigkeitsprinzip engl complete mediation principle fordert die berpr fung jedes Zugriffs auf seine Zul ssigkeit Ein System in dem Zugriffsrechte zur Nutzung von Dateien vergeben werden und eine Rechte berpr fung nur beim ffnen einer Datei durchgef hrt wird erf llt dieses Vollst ndigkeitsprinzip nicht Es w re hier m glich dass ein Benutzer eine Datei ber eine l ngere Zeit ge ffnet h lt und auf die Datei zugreifen kann obwoh
264. ment Process based on Process Patterns In V Ambriola editor Proceedings of the Eight European Workshop Literaturverzeichnis 203 GMP 02a GMP 02b GMP 03a GMP 03b GSG99 HB03 HJ03 HNS00 HS93 IAB IBM03 IITS90 on Software Process Technology 2001 number 2077 in Lecture Notes in Computer Science pages 182 202 Springer Verlag 2001 Michael Gnatz Frank Marschall Gerhard Popp Andreas Rausch Maura Rodenberg Ruiz and Wolfgang Schwerin editors Proceedings of the 1st Work shop on Software Development Process Patterns at the 17th Annual ACM Con ference on Object Oriented Programming Systems Languages and Applications OOPSLA 2002 Seattle Washington USA November 4 8 2002 Technical Re port TUM I0213 Technische Universit t M nchen December 2002 Michael Gnatz Frank Marschall Gerhard Popp Andreas Rausch and Wolfgang Schwerin Towards a Tool Support for a Living Software Development Process In HICSS 33 Proceedings of the Thirty Third Annual Hawaii International Con ference on System Sciences IEEE Computer Society January 2002 Michael Gnatz Frank Marschall Gerhard Popp Andreas Rausch and Wolf gang Schwerin Enabling a Living Software Development Process with Process Patterns Technical Report TUM I0310 Technische Universit t M nchen July 2003 Michael Gnatz Frank Marschall Gerhard Popp Andreas Rausch and Wolf gang Schwerin The Living Software Develo
265. miformal beispielsweise mithil fe von UML Diagrammen beschrieben werden Die Eignung der Ma nahmen kann textuell semiformal oder formal aufgezeigt werden Ein weiteres eigenes Produktartefakt der Modellierung zugriffssicherer Systeme stellt das Be nutzerrechtemodell dar Hier werden die Zugriffs und Ausf hrungsrechte tabellarisch textuell und pr dikativ beschrieben 6 6 Zusammenfassung Die mehrstufige durchg ngige und sukzessive Analyse von Aspekten der Zugriffssicherheit beginnt im vorgestellten Ansatz bereits mit der Modellierung der Gesch ftsprozesse Die Mo dellierung wird unabh ngig von technischen Details auf der Abstraktionsebene der Abl ufe und des Dom nenmodells begonnen In Hinblick auf eine Modellierung der Zugriffsrechte und der Bedrohungen werden hierzu potenzielle Angriffsm glichkeiten innerhalb der Gesch fts abl ufe und des Klassendiagramms ermittelt und mit Schutzzielen annotiert F r die Annotation von Schutzzielen sind ad quate Beschreibungstechniken notwendig F r die Modellierung der Abl ufe verwenden wir die von der UML zur Verf gung stehenden 140 Die Geschaftsprozessmodellierung zugriffssicherer Systeme Diagrammtypen Klassendiagramm und Aktivit tsdiagramm Da jedoch die UML innerhalb dieser Diagrammtypen keine Konstrukte zur Annotation von Schutzzielen vorsieht erweitern wir die UML um die geforderten Konstrukte Mithilfe des Erweiterungsmechanismus der UML f hren wir Stereotypen f r die Annota
266. mlung von Notationen die sich bei der Model lierung von gro en und komplexen Systemen als erfolgreich erwiesen haben Die UML erm glicht nach eine standardisierte Beschreibung von Systementw rfen auf konzeptionellen und detaillierten Ebenen Neben der konzeptionellen Beschreibung zum Beispiel von Gesch ftsprozessen und Systemfunktionen k nnen auch detaillierte technische Beschreibungen angefertigt werden Beispiele hierzu sind Klassenbeschreibungen in einer ge eigneten Programmiersprache Datenbankschemata und wieder verwendbare Softwarekompo nenten Die UML ist der Nachfolger einer ganzen Anzahl von objektorientierten Analyse und De signmethoden die in den sp ten 80er und fr hen 90er Jahren entstanden sind Insbesondere vereinigt und erweitert sie die Notationen von Grady Booch siehe Bo094 James Rumbaugh siehe RBP 91 und Ivar Jacobson siehe Nach der ersten Phase der Diversifi kation folgte eine Phase der Vereinheitlichung der objektorientierten Methoden der auch die OMG Object Management Group forciert wurde Die UML 1 5 ist seit M rz 2003 verf gbar und stellt derzeit die aktuelle Version dar 2 2 Grundlagen zur IT Sicherheit Sicherheit ist ein sehr umfassendes Thema das auch au erhalb der IT eine wichtige Rolle spielt so denke man beispielsweise an den Schutz von Kernkraftwerken oder Flugzeugen vor terroristischen Angriffen sowie an die innere Sicherheit eines Staates Die IT Sicherheit als Teilgebiet der al
267. mplarischen Abl ufen sind nun innerhalb der Anwendungsfallmodellierung zugriffssicherer Systeme die Sitzungen der verschiedenen am Ablauf beteiligten Akteure zu ermitteln Eine Sitzung stellt hier eine exemplarische Folge von Aktivit ten dar die ein Akteur oder ein externes System ausf hrt F r eine Teilmenge der Aktivit ten kann eine berpr fung der Autorisierung der Akteure notwendig sein sodass in 148 Die Anwendungsfallmodellierung zugriffssicherer Systeme diesen F llen vorab eine Authentifikation durchzuf hren ist Bei Sitzungen unterscheiden wir bez glich der Authentifikation folgende M glichkeiten e Die Aktivit ten der Sitzung d rfen alle nur nach einer vorangestellten erfolgreichen Au thentifikation stattfinden Der Akteur oder das externe System bleiben ber die gesamte Sitzung authentifiziert e Zu Beginn einer Sitzung ist keine Authentifikation notwendig da vorab anonyme Ak tionen durchgef hrt werden wie zum Beispiel das Suchen eines Buches innerhalb eines Bibliotheksystems F r weitere Bearbeitungsschritte wird jedoch eine Authentifikation erforderlich So muss sich beispielsweise ein Bibliotheksbenutzer vor der Bestellung oder Ausleihe eines Buches authentifizieren Eine Authentifizierung hat bereits zu Beginn oder innerhalb der Sitzung stattgefunden F r spezielle sicherheitskritische Aufgaben wird jedoch eine zus tzliche Authentifikati on notwendig Beispielsweise k nnen L schvorg nge in einem Bibliot
268. mputer Ba se TCB Eine TCB ist definiert als eine Menge von Komponenten Hardware Software Personen etc deren korrekte Funktionsweise ausreichend ist um die Sicherheitspolitik des Systems zu erreichen Ein Fehlschlagen der TCB w rde einen Bruch der Sicherheitspolitik bedeuten 2 2 4 Bedrohungen und Angriffe Ein IT System kann verschiedene Schwachstellen besitzen die zur Beeintr chtigung der Da tenintegrit t der Informationsvertraulichkeit und der Verf gbarkeit ausgenutzt werden k n nen Im Folgenden f hren wir die Begriffe Bedrohung und Angriff ein und gehen auf spezielle Angriffe durch Viren W rmer trojanische Pferde und mobilem Code n her ein Bedrohung Schwachstellen engl weakness eines Systems sind diejenigen Punkte an denen ein System verwundbar ist Eine Verwundbarkeit engl vulnerability ist eine Schwachstelle ber welche die Sicherheitsdienste des Systems umgangen get uscht oder unautorisiert modifiziert werden k nnen Eine Bedrohung engl threat des Systems zielt darauf ab ein oder mehrere Schwachstellen oder Verwundbarkeiten auszunutzen um einen Verlust der Datenintegrit t der Informations vertraulichkeit oder der Verf gbarkeit zu erreichen oder um die Authentizit t von Subjekten zu gef hrden Das Risiko engl risk einer Bedrohung ist die Wahrscheinlichkeit des Eintritts eines Scha densereignisses und die H he des potentiellen Schadens der dadurch hervorgerufen werden kann Angriff
269. n berblick ber die Themengebiete Vorgehens modelle und Sicherheit gegeben Da existierende Vorgehensmodelle kaum auf die Entwicklung von Aspekten der Zugriffssicherheit in den fr hen Phasen eingehen m ssen f r die Einf hrung eines Vorgehensmodells in den Phasen der Anforderungsspezifikation Prozessabl ufe definiert Beschreibungstechniken und Produktartefakte erweitert und angepasst sowie ein Modell zur fr hen Spezifikation von Benutzerrechten entwickelt werden Die eigens definierten Prozessabl ufe beschreiben dabei das Vorgehen in den Phasen der Anforderungsspezifikation Prozesse ben tigen zur Prozessabarbeitung Produktartefakte und erweitern bestehende oder erstellen neue Produkte Im Rahmen unseres Vorgehensmodells sind die Produkte zur Beschreibung von Sicherheitsaspekten die w hrend der Phasen der Anforderungsspezifikation erstellt und erweitert werden von prim rem Interesse Intuitive erweiterte Beschreibungstechniken sind notwendig um Sicherheitsaspekte in den verschiede nen fr hen Phasen angemessen darstellen zu k nnen da derzeitige Beschreibungstechniken wie beispielsweise J r04 dies kaum unterst tzen Ein Modell zur Spezifikation von Benutzerrechten ben tigen wir f r eine fr hzeitige Formalisierung und da mit einer kontextbezogenen Kl rung informaler Aussagen ber Benutzerberechtigungen Ein Benutzerrechtemodell Prozessabl ufe mit ihren Produktartefakten sowie erweiterte Be schreibungstechniken sind Gegen
270. n Komponenten zur sicheren Daten bertragung sind zum Analysemodell hinzuzuf gen Verbindlichkeit nderungen an verbindlichen Informationen sind einer Beweissicherung zu unterziehen Dabei sind neben den Modifikationen an Daten auch die ausf hrenden Akteure zu protokollieren Komponenten und Vorg nge zur Beweissicherung sind im Analysemodell zu spezifizieren oder bei der Integration von Sicherheitsprotokollen siehe Abschnitt aufzunehmen Authentifikation Zur Sicherstellung der Glaubw rdigkeit und Echtheit der Akteure und Ob jekte beispielsweise Flussobjekte sind Komponenten zur Durchf hrung der Authen tifikation einzuf gen Diese Komponenten werden aus den Sicherheitsanwendungsf llen zur Authentifizierung abgeleitet Autorisierung Die Benutzerrechte sind an geeigneten Stellen bei der Verfeinerung der Szena rien abzupr fen Methoden zur berpr fung sind nach dem in Kapitel 4 vorgestellten Ansatz im Klassenmodell der Analyse zu integrieren 182 Die Analyse zugriffssicherer Systeme Ebenso wie f r die funktionalen Aspekte sind f r Aspekte der Zugriffssicherheit geeignete Vorgangs Fach und Interaktionsklassen in den Szenarien einzuf gen und das Interaktions verhalten ist zu verfeinern Die verfeinerten Szenarien k nnen in UML Objektinteraktionsdia grammen vgl JBR99 oder in UML Sequenzdiagrammen dargestellt werden Abbildung 8 2lzeigt das Szenario zum Anwendungsfall Korrekturbuchung siehe Abbildungen 7 1 und
271. n ein am Ende der Sitzung eine Aktivit t logout Sollte innerhalb der Sitzung einer der oben erl uterten Sonderf lle auftreten so ist gegebenenfalls f r spezielle Aktivit ten eine zus tzli che Authentifikation einzuf gen In Abbildung 7 6 a b wurden die Abl ufe aus Abbildung 7 4 c d verfeinert Im Abbil dung 7 6 b ist f r die Aktivit t activity5 eine spezielle Authentifikation erforderlich sodass hierf r die beiden Aktivit ten loging und logoutg eingef gt wurden 152 Die Anwendungsfallmodellierung zugriffssicherer Systeme a b c Oo Vv Vv N login login login fg Vv Vv activity 1 activity 4 gt activity 2 logins activity 1 activity 4 activity 6 login activity 3 activity 5 activity 2 activity 5 Vv Vv i D l ogout ogouts activity 3 logout 4 FJ y activity 6 amp logout logout bh l Legende Authentifizierung Autorisierung Abbildung 7 6 Verfeinerung der Authentifikation und Sitzungen Zur Bestimmung der notwendigen Authentifikationsanwendungsf lle ist weiterhin zu unter suchen inwiefern aus den verschiedenen exemplarischen Abl ufen die Aktivit ten zur Au thentifikation durch einheitliche Login Anwendungsf lle realisiert werden k nnen F r die eingef hrten Spezialf lle kann gegebenenfalls die gew hnliche Authentifizierung nicht wieder verwendet werden da sich das Syste
272. n 123 185 129 m w a 32 Erg nzungen am TimeTool Dom nenmodell zur Abwehr von Bedrohungen 33 Beziehungen bei der Erweiterung der Produktartefakte 137 6 34 Produktartefakte der Gesch ftsprozessmodellierung zugriffssicherer Systeme 139 7 1 Beispiel eines Anwendungsfalls Korrekturbuchung adjustment posting 145 aD 7 2 Dom nenmodell der Anwendungsfallmodellierung 146 STAN 148 vt PGs we SWS ee Re Ee 149 en 150 vb cg BEd he ge Bad a 152 7 7 Authentifikation des Administrators 0 0 nn 153 7 8 Sektion zur Sicherheit des Anwendungsfalls Korrekturbuchung 156 RR Ok Pg TE 157 pete dene eed ew Sta us oe ae ee ce ee 161 7 11 Funktionsablauf des TimeTool Anwendungsfalls Copy Accounting 162 165 oe 170 174 8 1 Szenario f r den Anwendungsfall Korrekturbuchung 180 SE 181 8 3 Protokoll zur Authentifikation mittels Chipkarte und Terminal 182 8 4 Verfeinertes Szenario zur Korrekturbuchung 2 2 22 2 a 183 ARES ne oe 185 EOE 189 8 7 Produktartefakte der Analyse zugriffssicherer Systeme 192
273. n Abl ufe oft mals noch nicht gekl rt sind oder Protokolle noch nicht ausgew hlt werden k nnen Es gibt jedoch eine Reihe von Bedrohungen denen bereits durch nderungen in den Gesch ftspro zessen oder im Dom nenmodell entgegengewirkt werden kann Diejenigen Bedrohungen die zu diesem Zeitpunkt noch nicht behandelt werden k nnen sind entweder im Rahmen der An wendungsfallmodellierung oder der Analyse zugriffssicherer Systeme zu behandeln In jedem dieser Prozessabschnitte wird der Sicherheitsmikroprozess ausgef hrt vgl Abbildung 15 7 sodass dann unter den hinzugewonnenen Erkenntnissen geeignete Ma nahmen ausgew hlt werden k nnen Im Folgenden zeigen wir an Bedrohungen zur Klasse Accounting vgl Tabelle 16 1 welche Bedrohungen bereits innerhalb der Gesch ftsprozessmodellierung zugriffssicherer Systeme be trachtet werden k nnen Daf r k nnen wir folgende Ma nahmen ableiten e Da die Bedrohungen B009 bis B013 alle mit dem Risiko mittel oder hoch eingestuft wurden m ssen f r all diese Bedrohungen Ma nahmen entwickelt werden F r die Bedrohungen B009 und B010 sind die Daten verschl sselt im System abzulegen Protokolle zur Datenverschl sselung und Auswirkungen auf das Dom nenmodell sowie auf die Prozessabl ufe werden im Rahmen der Anwendungsfallmodellierung und der Analyse zugriffssicherer Systeme n her betrachtet Projektmitarbeiter d rfen nur eigene Stundenbuchungen lesen und ndern Projektleiter nur Buchungen z
274. n Iterationen vor unerlaubtem Zugriff gesch tzt werden m ssen So kann etwa eine Sicherheitsma nahme zur Beweissicherung eine Speicherung der nderungen hervorrufen Die Speicherung der nderungen f hrt zu einer zus tzlichen Anforderung die in einer der n chsten Iterationen ebenfalls gegen ber den Sicherheitsaspekten zu pr fen und umzusetzen ist SPAT Sicherheitsmodellierung in der Gesch ftsprozessanalyse In der Gesch ftsprozessanalyse werden zusammenh ngende Folgen von T tigkeiten die in Unternehmen zur Erreichung der Unternehmens und Organisationsziele erledigt werden mo delliert Sta01 Dabei stehen l ngere zusammenh ngende Folgen von T tigkeiten die zur Er ledigung einer Aufgabe notwendig sind im Mittelpunkt An der Gesch ftsprozessanalyse sind sowohl Anwender Auftraggeber Auftragnehmer wie auch Anforderungsentwickler gemein sam beteiligt Bei der Ausarbeitung der Anforderungen sto en sie unumg nglich auf Aspekte der Zugriffssicherheit beispielsweise steht zu diesem Zeitpunkt bereits fest dass bestimmte Aktionen nur einem engen Benutzerkreis vorenthalten sind dass vertrauliche Daten ber das Netz ausgetauscht werden m ssen oder dass das Ver ndern von Dokumenten Vertr gen etc protokolliert werden muss In werden Anforderungen an die Sicherheit als abstrakte QoS Eigenschaften spezifi ziert Obwohl zu diesem Zeitpunkt bereits detailliertes Wissen zur Zugriffssicherheit vorliegt oder ermittelt werden kann w
275. n Phasen der Entwicklung wollen wir die Benutzerrechte oftmals in einer infor malen textuellen Art und Weise spezifizieren Tabelle zeigt einen Ausschnitt f r Klas sen des Dom nenmodells einer derartigen textuellen Spezifikation des Benutzerrechtemodells zu unserer TimeTool Fallstudie Dieses informale Modell enth lt grob granulare Kategorien R Read W Write C Create E Execute f r jede Klasse f r Aktivit ten von Gesch ftsprozessen oder f r Anwendungsf lle Die textuelle Darstellung charakterisiert die Tabelle 4 2 Benutzerrechte von Projektmitarbeiter und Projektmanager actor Team Worker Project Manager class Accounting R all own accountings R W C all accountings of independent of the activities of own project projects i e where W C own accountings actor is the project from released manager of activities Activity R all activities from R W all activities of projects allocated own projects to the actor C W C Project R all projects R all projects W C W C User R all users R all users W C W C 4 4 Formale Modellierung von Benutzerrechten 41 Objekte einer gegebenen Klasse welche ein Akteur lesen schreiben oder erzeugen kann oder Aktivit ten und Anwendungsf lle die ein Akteur ausf hren kann F r gro e Teile des Systems kann eine derartige Beschreibung von Benutzerrechten ausrei chend sein F r kritische Systemteile ben tigen wir jedoch eine fein granularere Weise
276. n Produkte verfeinert und erg nzt Insbesondere sind die zu automati sierenden Abl ufe in Anwendungsf lle berzuf hren die Benutzerrechte hinsichtlich einer Generierung zu untersuchen und die Authentifikation als Systemfunktionalit t zu integrieren 7 Die Anwendungsfallmodellierung zugriffssicherer Systeme Im Rahmen der im vorausgehenden Kapitel eingef hrten Gesch ftsprozessmodellierung zu griffssicherer Systeme wurden betriebliche Prozesse und eine erste Version des Dom nenmo dells des zu entwickelnden Systems festgelegt Schutzziele und Benutzerrechte auf der gewon nenen Struktur und dem ermittelten Verhalten wurden spezifiziert Dieses Kapitel besch ftigt sich mit den darauf aufbauenden Aufgaben des zweiten Prozessabschnitts der Anforderungs spezifikation zugriffssicherer Systeme die im Rahmen der Anwendungsfallmodellierung zu griffssicherer Systeme auszuf hren sind Bei der Anwendungsfallmodellierung werden aus den innerhalb der Gesch ftsprozessmodel lierung gewonnenen Abl ufen diejenigen bestimmt die innerhalb des Systems umgesetzt wer den Die Aktivit ten als einzelne Bausteine der Abl ufe werden ihren ausf hrenden Akteuren zugeordnet und in so genannten Anwendungsf llen strukturell beschrieben Anwendungsfall diagramme geben eine bersicht ber die Zusammenh nge zwischen ausf hrenden Akteuren und untereinander agierenden Anwendungsf llen Das Dom nenmodell aus der Gesch ftspro zessmodellierung muss angepasst
277. n den Gesch fts und Flussobjekten ab vgl hierzu Abschnitt 6 2 d h f r alle mit Schutzzielen versehen Objek te sind Zugriffsberechtigungen zu erstellen Die Zugriffsrechte werden entweder textuell f r Klassen oder pr dikativ f r einzelne Zugriffsmethoden separat festgelegt Durch die die Ver wendung von Methodenkategorien k nnen auch Zugriffsrechte f r mehrere Zugriffsmethoden auf Attribute pr dikativ beschrieben werden Zugriffsrechte k nnen informal oder formal festgelegt werden Da die Objekte innerhalb der Gesch ftsprozessmodellierung oftmals in einer vorl ufigen Form modelliert werden und inner halb der weiteren Entwicklung beispielsweise durch Erg nzungen oder Aufteilungen noch ver ndert werden m ssen ist es sinnvoll die Rechte in dieser fr hen Phase vorab informal durch Text zu beschreiben Ausnahmen k nnen beispielsweise Objekte zur Datenspeicherung sein deren Struktur nicht mehr ver ndert werden muss Auch Schnittstellen zu externen Systemen k nnen fest vorgegeben sein Ein weiterer Grund f r eine vorab unpr zisere textuelle Darstellung der Benutzerrechte liegt auch darin dass zu diesem fr hen Modellierungszeitpunkt die Attribute der Objekte teilweise noch nicht festgelegt sind 114 Die Geschaftsprozessmodellierung zugriffssicherer Systeme Da sich die Modellierung von Gesch ftsprozessen nicht nur auf die automatisierbaren Abl ufe eines Unternehmens beschr nkt k nnen auch Objekte spezifiziert werd
278. n durch benutzerdefinierte Kategorien erg nzt oder ersetzt werden Dies ist ratsam falls ein Teil des Klassendiagramms mit derselben Art von Berechtigungen ausgestattet ist Ein Beispiel hierzu ist ein allgemeines Leserecht true Ein weiterer typischer Fall zur Anwendung von mehr fein granularen Kategorien ist beispielsweise die Unterteilung von Personendaten Die Attribute einer Klasse Person werden in sicherheitskritische Gehalte etc und unkritische Daten Name Adresse etc unterteilt 4 7 Ausblick auf Codegenerierung 49 4 7 Ausblick auf Codegenerierung In unserem Ansatz zur akteurzentrierten Modellierung von Benutzerrechten verfolgen wir das Ziel einer von der Implementierung losgel sten Benutzerrechtemodellierung Dies bedeutet jedoch nicht dass die Benutzerrechte manuell innerhalb der Implementierung codiert werden m ssen Wie in Abschnitt gezeigt wurde lassen sich unsere Berechtigungsspezifikationen in die Spezifikationssprache OCL die im Umfeld der UML angewendet wird berf hren Basie rend auf derartigen Berechtigungen in OCL ist hier eine Toolunterst tzung angedacht welche die in einem grafischen Beschreibungstool in OCL annotierten Berechtigungen in ausf hrbare Methoden berf hrt Da die Entwicklung einer derartigen Werkzeugunterst tzung der vorge stellten Konzepte erst begonnen wurde und diese auch nicht Fokus dieser Arbeit ist zeigen wir im Folgenden als Beispiel nur die manuelle Umsetzung der in den Abschnitten
279. n so genannten Entwicklungstechniken wird hierbei verst rkt gefordert Bei der Entwicklung zugriffssicherer Systeme wurde in den vergangenen Jahren die Notwendig keit von eigenen Vorgehensmodellen erkannt Eck03 Hierzu entstanden erste Vorgehensmo delle die gr tenteils eine Erweiterung bestehender Entwicklungsmethoden sind Diese Ent wicklungsmethoden haben sich jedoch nicht etabliert sodass Aspekte der Zugriffssicherheit in einer Vielzahl von Systemen ohne Systematik entwickelt werden Gr nde f r das Scheitern sind beispielsweise dass diese ersten Ans tze nur eine Ann herung an ein Vorgehensmodell waren oder dass sie fest an bestehende Vorgehensmodelle gebunden sind wie beispielsweise an das Wasserfallmodell in oder an das V Modell in GDB Die Entwicklung von Aspekten der Zugriffssicherheit kann dabei nur dann durchgef hrt werden wenn die Syste me nach diesen Vorgehensmodellen entwickelt werden Auch wird in diesen ersten Ans tzen zur Entwicklung zugriffssicherer Systeme auf aktuelle Vorgehensweisen wie beispielsweise die objektorientierte Modellierung nicht Bezug genommen sie beschr nken sich auf die klassischen phasenstrukturierten Ans tze PB96 zur Entwicklung zugriffssicherer Systeme Letztendlich wird auch auf die iterative Softwareent wicklung wie sie heute f r gro e Systeme blich ist kaum eingegangen Derzeit fehlt es an einer Weiterentwicklung dieser ersten Konzepte und an der Entwicklung einer integrierten Metho
280. n vorgestellten Schutzzielen f r Flussobjekte stellt das Schutzziel Authentifikation eine wichtige Rolle dar Bei Systemen die ber ihre Systemgrenzen hinweg mit anderen Sy stemen kommunizieren muss vor dem Empfang von Flussobjekten aus externen Systemen die Glaubw rdigkeit der Objekte anhand ihrer eindeutigen Identit t oder charakteristischen Ei genschaften berpr ft werden Das kommunizierende System muss sich vorab authentifizieren da andernfalls beliebige Software mit dem System interagieren k nnte Dieselbe Vorgehens weise gilt auch bei Systemen die sich in mehrere Teilsysteme untergliedern und zwischen den Teilsystemen verschiedene Sicherheitsstufen existieren Hier m ssen Objekte die aus einem weniger sicherheitskritischen Teil in einen kritischeren Teil Information bertragen vorab bez glich ihrer Authentizit t berpr ft werden Eng in Zusammenhang mit der Authentifikation steht in diesem Zusammenhang auch die Autorisierung d h die berpr fung der Benutzerrechte f r den authentifizierten Nutzer Im Rahmen der Betrachtung der Authentifikation in Objektfl ssen unterscheiden wir jedoch nicht zwischen den beiden Begriffen Eine detaillierte Trennung findet erst im Rahmen der Anwendungsfallmodellierung zugriffssicherer Systeme statt siehe hierzu Abschnitt 7 2 In vielen F llen reicht eine einseitige Authentifikation aus d h der Sender eines Objek tes authentifiziert sich beim Empf nger eines Objektes vor dem Senden d
281. n werden Ein weiterer Akteur ist der Web Browser Ein Anwendungsfall stellt immer einen zusammenh ngenden und vollst ndigen Ablauf dar sodass ein Anwender eine Aufgabe in Interaktion mit dem System ohne Unterbrechung erle digen kann Die unterbrechungsfreie Ausf hrung ist jedoch nicht zwingend gefordert da bei spielsweise ein Akteur diese eigenst ndig unterbrechen kann wenn er beispielsweise mehrere Aufgaben gleichzeitig bearbeitet Durch diese Definition werden jedoch Aufgaben ausgeschlos sen die nicht rechnergest tzt durchgef hrt werden k nnen wie beispielsweise die manuelle bergabe von Dokumenten Alle Anwendungsf lle eines zu entwickelnden Systems zusammen beschreiben die Gesamt funktionalit t des Systems Alle zur Beschreibung eines Systems erstellten Anwendungsf lle werden als Anwendungsfallmodell bezeichnet Zur Modellierung des vollst ndigen Systemum fangs und der Modellierungsgrenzen k nnen die Anwendungsf lle des Anwendungsfallmodells in Anwendungsfalldiagrammen dargestellt werden Ein Anwendungsfalldiagramm stellt so mit die Zusammenh nge zwischen Anwendungsf llen untereinander und den Akteuren eines Systems dar Ein Anwendungsfalldiagramm zur TimeTool Fallstudie ist in Abbildung dargestellt 144 Die Anwendungsfallmodellierung zugriffssicherer Systeme 7 1 2 Aktivit ten der Anwendungsfallmodellierung Im Rahmen der Gesch ftsprozessmodellierung wurden die Abl ufe und eine erste Version des Dom nenmodells
282. n zugeordnet wobei je de Berechtigung die Art des Zugriffs festlegt Die somit ermittelten Benutzerrechte k nnen innerhalb der Anwendungsfallmodellierung und der Analyse schrittweise ausgebaut und ver feinert werden F r eine sp tere Codegenerierung von Berechtigungen auf Methoden sind diese textuellen Benutzerrechte in kurze und pr gnante Pr dikate erster Ordnung und als OCL Ausdr cke zu transformieren Mit der Ausweitung der Vernetzung und dem Fortschritt der Technik werden in Zukunft auch bereits bestehende Softwarel sungen mit Aspekten der Zugriffssicherheit erweitert wer den oder durch neue Software abzul sen sein Hierzu sind Vorgehensweisen zur Analyse von bestehenden Sicherheitseigenschaften notwendig Im Rahmen dieser Arbeit beschr nken wir uns jedoch auf die Neuentwicklung zugriffssicherer Informationssysteme Im Rahmen von Prozessbetrachtungen treten neben dem eigentlichen Vorgehensmodell auch Managementauf gaben und Organisationsaspekte f r eine Integration der Prozesse innerhalb von Institutionen und Unternehmen auf Wir beschr nken uns hier jedoch auf das Vorgehen mit den notwendi gen Produktartefakten und Beschreibungstechniken 1 2 Ergebnisse Die Ergebnisse stellen grundlegende Konzepte und Ans tze bereit die notwendig sind um Sicherheitsanforderungen bei der Entwicklung von zugriffssicheren Systemen durchg ngig sukzessive und iterativ zu entwickeln Im Rahmen dieser Arbeit wird ein Ausschnitt aus einem Vorgehen
283. nalen Anforderungen f r die in den vorhandenen Ans tzen kaum konkrete Schritte zur Umsetzung angegeben sind wird im Prozess die schritt weise und aufbauende Erstellung von Produkten zur Spezifikation der Sicherheitsanforderun gen gezeigt Die vorgestellte Methode ist insbesondere deshalb an objektorientierte Verfahren angelehnt da diese Verfahren neben den Prozessen die Produktartefakte als Ein und Ausga ben zu den Prozessen betrachten und da f r die Dokumentation die grafische Beschreibungs sprache UML verwendet wird Der Einsatz der UML eignet sich besonders deshalb f r die vor gestellte Methode da die UML durch ihre Erweiterungsm glichkeiten Annotationen von Aspekten der Zugriffssicherheit erm glicht die UML zur Beschreibung von Gesch ftsprozessen verwendet wird EP00 die UML zudem leicht anwendbar und in der Praxis sowie in der Wissenschaft als semiformale Beschreibungssprache Anwendung findet Die Erarbeitung von Aspekten der Zugriffssicherheit innerhalb der Gesch ftsprozessmodel lierung ist insbesondere deshalb sinnvoll da dadurch das bergreifende Zusammenspiel von verschiedenen T tigkeiten innerhalb der komplexen Prozesslandschaft von Organisationsein heiten verbessert wird und dabei gemeinsam mit Auftraggebern Anwendern Auftragnehmern und Anforderungsentwicklern Aspekte der Zugriffssicherheit in die Gesch ftsprozesse aufge nommen werden k nnen 1 3 Aufbau der Arbeit Kapitel 2lstellt die Grundlagen zu Vorgehensmodel
284. nd Verantwortlichkeiten Spezifikation der Schutzziele in den Gesch ftsprozessen lt Au Laune des Modellierung der Sicherheits eh hi mikroprozesses SNENITERING lt Modellierung der Modellierung der Ausf hrungsrechte Zugriffsrechte Abbildung 6 31 Der Ablauf der Gesch ftsprozessmodellierung zugriffssicherer Systeme Die n chste Stufe die Ermittlung von Bedrohungen und Risiken sowie die Hierarchisie rung der Akteure kann entweder nach Ermittlung aller Gesch ftsprozesse und des gesamten Dom nenmodells stattfinden oder aber nur an einem Teil mit anschlie ender inkrementeller Vervollst ndigung Dieselbe iterative Entwicklung kann auch f r die Modellierung der Benut zerrechte angewendet werden Diese k nnen ebenfalls einmalig oder mehrfach in Inkrementen spezifiziert werden 130 Die Gesch ftsprozessmodellierung zugriffssicherer Systeme Vor und Nachteile Mit dem vorgestellten Prozess wird die Entwicklung von Aspekten der Zugriffssicherheit fr hestm glich begonnen Bereits bei der Definition der Prozesse wie sie im Unternehmen bzw in der Organisation ablaufen werden potenzielle Angriffsm glichkeiten festgehalten hierzu die Bedrohungen und Risiken ermittelt Ma nahmen ausgew hlt und die Benutzer rechte spezifiziert Ein Vorteil dieses Verfahrens besteht darin dass Auftraggeber Auftragnehmer Anforderungs entwickler und Anwender gemeinsam an der Entwicklung von Aspekten der
285. nd erlaubte und verbotene Daten und Systemzugriffe individuell abh ngig von den Anwenderanforderungen zu modellieren Im Bell LaPadula Modell lassen sich auch systembestimmte Regeln einfach berpr fen und effizient implementieren Dabei schreibt dieses Modell keine Granularit t f r Objekte und Subjekte vor Die Rechtefestlegungen kombiniert mit den restriktiven systembestimmten Festlegungen des Modells schr nken das Spektrum der zu beschreibenden IT Systeme jedoch sehr ein sodass sich dieses Modell ebenenfalls nicht f r die Beschreibung von universellen Benutzerrechten eignet 4 2 1 Zugriffsmatrixmodell Das Zugriffsmatrixmodell auch bekannt als Referenzmonitor ist das einfachste und lteste Sicherheitsmodell Es bietet die M glichkeit Objekte und Subjekte zugeschnitten auf die Anforderungen der jeweilig zu konstruierenden Anwendung festzulegen sowie Zugriffsrechte universell oder objektspezifisch zu modellieren Bei den Zugriffsmatrixmodellen unterscheiden wir zwei Strategieans tze die benutzerbestimmte und die systembestimmte Zugriffskontrolle Die benutzerbestimmbare Zugriffskontrolle engl discretionary access control DAC basiert auf dem Eigent merprinzip Dabei ist der Eigent mer f r den Schutz der Objekte verantwort lich und die Zugriffsrechte werden auf der Basis einzelner Objekte vergeben oder zur ckge nommen Mit der benutzerbestimmbaren Kontrolle werden somit nur objektbezogene Sicher heitseigenschaften aber
286. nd von einer Projektidee die Mission des Projekts und die globalen Sicherheitsziele bestimmt werden Der Start der Erarbeitung der Anforderungen engl Requirements wird et was verz gert in der Phase der Anforderungsspezifikation zugriffssicherer Systeme begonnen da hierf r eigene iterative Prozesse eingef hrt werden Die in Abbildung 5 4 grau hinterlegte Sicherheits Anforderungsanalyse wird detailliert in ei nem eigenen Prozessmuster in Abschnitt erl utert Aktivit ten Im Rahmen des vorgestellten Softwarelebenszyklusprozesses mit Integration der Anforde rungsspezifikation f r zugriffssichere Systeme sind die folgenden Aktivit ten durchzuf hren e Ausf hrung der Startphase in der ausgehend von einer Projektidee die Mission des Projekts und das Sicherheitsziel festgelegt werden e Durchf hrung der Anforderungsspezifikation zugriffssicherer Systeme wie dies im Pro zessmuster 5 2 im Abschnitt 5 3 2 beschrieben wird e Konstruktion des Systems mit Design Implementierung und Test wie zum Beispiel in vorgestellt e Durchf hrung der Auslieferungsphase beispielsweise nach JBR99 Produktartefakte Die folgende Auflistung beschreibt die Eingaben und Ausgaben zum Softwarelebenszyklus inklusive der speziellen Produktartefakte zur Spezifikation der Sicherheitsaspekte Falls Stan dardproduktartefakte um Sicherheitsaspekte erweitert werden ist dies vermerkt Eingabe Produktartefakt e Projektidee Ausgabe Produktartefakte e
287. nd zu zeigen wie die L sung in die zeitliche Abfolge der Phasen den so genannten Softwarelebenszyklus eingebettet werden kann Seit Anfang der 80er Jahre werden in der Softwareentwicklung mehr und mehr objektorientier te Methoden angewendet die vor allem die Ziele der Erweiterbarkeit der Wiederverwendung und der Wartbarkeit unterst tzen BreOl Besonders bei der Entwicklung von gro en Pro grammen eignen sich diese Methoden durch ihre iterativen Entwicklungsans tze und neuarti gen Spezifikationstechniken von Anforderungen beispielsweise in Form von Anwendungsf llen In der vorliegenden Arbeit wird gezeigt wie eine objektorientierte Vorgehensmethode bei der Definition der Anforderungen von zugriffssicheren Systemen erfolgreich eingesetzt werden kann wie die Sicherheitsanforderungen verfeinert und wie Iterationen dabei nutzbringend eingef hrt werden k nnen Die Zugriffssicherheit besch ftigt sich mit der Abwehr von absichtlichen Angriffen Zur ge nauen Definition dieses Begriffes ben tigen wir zun chst den Begriff der Funktionssicherheit vgl Eck03 Unter der Funktionssicherheit engl Safety eines Systems verstehen wir die Eigenschaft dass die realisierte Ist Funktionalit t der Komponenten mit der spezifizierten Soll Funktionalit t bereinstimmt Die Zugriffssicherheit ist die Eigenschaft eines funktions 4 Einf hrung sicheren Systems nur solche Systemzust nde anzunehmen die zu keinem unautorisierten Zugriff auf Sy
288. nd zur Implementierung verwendet wird ist es bei der Entwicklung von Aspekten der Zugriffssicherheit ebenfalls wichtig die erstellten Spezifikationen in die weiteren Phasen der Analyse des Designs der Implementierung und des Testens mit einflie en zu lassen und sukzessive die Sicherheitsspezifikation auszubauen Be drohungen und Risiken die bereits in der Gesch ftsprozessanalyse erkannt werden sind in der 68 Ein Prozess zur Entwicklung von Anforderungsspezifikationen Anwendungsfallmodellierung zu erweitern bei der Systemanalyse in die Ablaufmodellierung einzubeziehen und beim Ausarbeiten des Designs zur Bestimmung von sicherheitsrelevanten Komponenten heranzuziehen Auch f r die Erstellung von Testf llen und bei der Testauswer tung dtirfen die Bedrohungen mit ihren Verfeinerungen und die im Laufe der Entwicklung weiter erarbeiteten Spezifikationen zur Zugriffssicherheit nicht au er acht gelassen werden SPA3 Gemeinsame Entwicklung von Funktion und Sicherheit Die Modellierung von Funktionen Daten und Aspekten der Zugriffssicherheit hat gemeinsam zu erfolgen sodass zus tzlicher Modellierungsaufwand vermieden und gegenseitige Erkennt nisse ausgenutzt werden Indem in Abl ufen und Daten a priori Sicherheitsaspekte modelliert und Abl ufe sowie Daten nicht in einem expliziten Schritt an die Sicherheit angepasst werden wird ein zus tzlicher Modellierungsaufwand vermieden Es ist bereits in fr hen Phasen der Systemmodellierung m gl
289. nde L sungsansatz des Musters wird in diesem Abschnitt dokumentiert Die Reihenfolge in der die Akti vit ten auszuf hren sind wird textuell oder grafisch beschrie ben Die Aktivit ten die im Rahmen der Ausf hrung des Pro zessmusters durchzuf hren sind werden aufgelistet Der genaue Ablauf der Ausf hrung der Aktivit ten ergibt sich aus den Beschreibungen zur L sung und zur Struktur Dabei k nnen die Aktivit ten auf weitere Prozessmuster verweisen oder ei genst ndig erkl rt sein In diesem Abschnitt werden die Ein und Ausgabeprodukte des Prozessbausteins beschrieben Die Eingabe enth lt dieje nigen Produktartefakte die zur Ausf hrung des Prozessbau steins ben tigt werden Die Liste der Ausgaben enth lt die neu erzeugten oder ver nderten Produkte Hier wird eine textbasierte oder grafische Repr sentierung des L sungswegs des Musters aufgezeigt Die Abfolge der einzelnen Aktivit ten wird in UML Aktivit tsdiagrammen oder ber sichtsdiagrammen festgehalten Bei der Beschreibung des Kontextes geben wir Anforderun gen ber die Eingabeproduktartefakte hinaus als Vorausset zung f r die Ausf hrung des Musters an Externe Umst nde Einfl sse oder spezielle Anwendungsrichtlinien werden in die sem Abschnitt betrachtet Das Prozessmuster selbst und die Konsequenzen f r die Anwen dung werden kurz diskutiert Dies erleichtert die Evaluierung der Anwendbarkeit des Musters In einer Liste werden die Prozessmuster di
290. ndlage f r die Beschreibung der Benutzerrechte basiert auf der formalen Sprache P MOS aus Bre01 Basis zur vorgestellten Akteurmodellierung bildet die Arbeit BP04 32 Akteurzentriertes Modell zur Spezifikation von Benutzerrechten 4 2 Klassische Zugriffskontrollmodelle Nachdem wir im vorausgehenden Abschnitt die Notwendigkeit eines Benutzerrechtemodells zum Schutz von Daten motiviert haben stellen wir im Abschnitt die Grundlagen des Zugriffsmatrixmodells mit seinen zwei Auspr gungen der benutzerbestimmbaren und der systembestimmbaren Zugriffskontrolle vor Dar ber hinaus f hren wir die Erweiterung dieses Matrixmodells in Form der rollenbasierten Zugriffskontrolle in Abschnitt 4 2 2lein Grundlagen der Zugriffskontrolle und Zugriffskontrollmodelle werden unter anderem in diskutiert Neben diesen beiden Stellvertretern geh ren auch das Chinese Wall Modell und das Bell LaPadula Modell zur Klasse der Zugriffskontrollmodelle Das Chinese Wall Modell kann deshalb nicht f r eine Beschreibung der Zugriffsrechte in der hier ben tigten Weise herangezogen werden da es keine allgemeinen Zugriffsberechtigungen regelt sondern eine spezielle kommerzielle Strategie verfolgt die besonders f r Anwendungen im Umfeld von Unternehmensberatungen geeignet ist Dieses Modell verhindert den Informationsfluss zwi schen konkurrierenden Systemen Ohne weiteres ist es jedoch nicht m glich ber die sehr restriktiven systembestimmbaren Regeln hinausgehe
291. ndringen kann durch eine geeignete Konfiguration beispielsweisedurch Beschr nkung des Diensteangebots verringert oder ausgeschlossen werden Durch eine restriktive Vergabe von Zugriffsberechtigungen insbesondere auf Passw rter l sst sich unerlaubter Informationsge winn und das Eindringen von fremdem Code beschr nken Als Trojanisches Pferd bezeichnen wir ein Programm dessen implementierte Ist Funktionali t t nicht mit der angegebenen Soll Funktionalit t bereinstimmt Im Gegensatz zu Systemen bei denen die Safety nicht gew hrt wird erf llen diese Systeme die Soll Funktionalit t be sitzen jedoch eine dar ber hinausgehende beabsichtigte zus tzliche aber verborgene Funktio nalit t So genannten Trojanern kann ebenfalls durch die Beschr nkung der Benutzerrechte auf sensible Daten wie Passworte PINs und TANs sowie Programmen entgegengewirkt wer den Prinzip der minimalen Rechte Werden Programme vom Hersteller signiert so k nnen nachtr gliche Manipulationen erkannt werden Unter dem Begriff des mobilen Codes lassen sich alle Programme zusammenfassen deren Code auf entfernten partiell nicht vertrauensw rdigen Rechnern generiert wurden und die auf Gastrechnern engl hosts ausgef hrt werden Der mobile Code der bei der bertragung 2 2 Grundlagen zur IT Sicherheit 21 angegriffen werden kann ist durch Verschl sselung zu sch tzen Der Gastrechner auf dem der mobile Code ausgef hrt wird kann durch den Einsatz ein
292. ng der Anforderungen an die Zugriffssicherheit Neben der Analyse des Vorgehensmodells werden 1 1 Zielsetzung 3 SS gt 4 modellierun S J Zugriffssicherheit CFA Abbildung 1 1 Einflussfaktoren fiir die Entwicklung zugriffssicherer Systeme grafische Beschreibungstechniken im Kontext der Unified Modeling Language UML und f r zugriffssichere Systeme eine pr dikative Spezifikation von Benutzerrechten auf Basis eines rollenbasierten Benutzerrechtemodells vorgestellt Das Vorgehensmodell zur Entwicklung zugriffssicherer Informationssysteme wird von den in Abbildung 1 1dargestellten Faktoren beeinflusst Basis der Untersuchungen sind die drei Pro zessabschnitte Gesch ftsprozessmodellierung Anwendungsfallmodellierung und Analyse wie sie in neueren objektorientierten Ans tzen vorzufinden sind Dort gilt es Anforderungen an die Zugriffssicherheit zu integrieren und geeignete Beschreibungstechniken zu untersuchen Im Vordergrund stehen dabei die Auswirkungen der Aspekte Vertraulichkeit Integrit t Ver bindlichkeit und Authentifikation der Zugriffssicherheit auf die genannten Prozessabschnitte Ein Vorgehensmodell regelt den Ablauf des L sungsprozesses und unterteilt ihn in berschau bare Abschnitte zur Planung Durchf hrung Entscheidung und Kontrolle vgl PB96 Ein Kernziel der Arbeit ist es f r die Entwicklung zugriffssicherer Software einen L sungsprozess der Anforderungsspezifikation bereitzustellen u
293. ng der Aspekte der Zugriffssicherheit inner halb eines Prozessabschnitts ist notwendig da durch die Erg nzung von funktionalen Aspek ten und Aspekten der Zugriffssicherheit strukturelle und verhaltensorientierte Teile erg nzt werden die noch keiner Sicherheitsmodellierung unterzogen wurden und somit in einer weite ren Iteration nach Aspekten der Zugriffssicherheit zu untersuchen sind Da die Prozessschritte f r eine Entwicklung zugriffssicherer Systeme innerhalb der verschiedenen Prozessabschnit te gleich sind und nur auf verschiedenen Produktartefakten arbeiten ben tigen wir einen universellen Sicherheitsmikroprozess der iterativ einsetzbar sein muss L sung Derzeitige Vorgehensweisen wie beispielsweise zur Erarbeitung von Aspekten der Zugriffssicherheit sehen eine Analyse der Bedrohungen eine Bewertung der Risiken und einen Entwurf von Ma nahmen vor Dieser Prozess hat sich in der Entwicklung sicherer Syste me bew hrt und wir verwenden diesen als Basisprozess f r unseren Sicherheitsmikroprozess Untersuchung der Modellierung der Bewertung der Entwurf von berpr fung der Sicherheitsziele Bedrohungen Risiken Ma nahmen Ma nahmen Abbildung 5 8 Die Aktivit ten des Sicherheitsmikroprozesses Dadurch dass wir die Sicherheit nicht in seiner Gesamtheit untersuchen sondern lokal ge meinsam mit der funktionellen Entwicklung betrachten verwenden wir keinen Matrix oder Baum orientierten Ansatz zur Bedrohungsanalyse vgl Eck03
294. ng und unter Verwendung moderner Entwurfs methoden vgl BBEHO3 Da es sich bei der Entwicklung um ein relativ kleines System handelt basiert die Entwick lung auf dem sequenziellen Wasserfallmodell In der Anforderungsspezifikation wurden die fachlichen Anforderungen an das System und der Systemumfang identifiziert vergleiche auch Kapitel 3 2 ein Oberfl chenprototyp erstellt und ein Projektplan mit Terminplanung und Aufwandssch tzung angefertigt Im Testdrehbuch wurden die Testf lle f r den Abnahmetest beschrieben Im Softwaredesign entstanden die grobe Komponentenstruktur der Implemen tierung als Softwarearchitektur sowie ein Projektplan mit Arbeitspaketen Nach der Imple mentierung vervollst ndigten die Dokumentation und ein Abnahmetest die Entwicklung Abbildung 3 1 zeigt Screenshots zum Projektverwaltungssystem TimeTool insbesondere die Dialoge Login Projektauswahl Projektbuchung und Mitarbeiterstammdaten Da es sich bei dem Projektverwaltungssystem TimeTool um ein kleines und berschaubares System handelt und es sich f r die Darstellung sowohl vorgehensspezifischer Aspekte eignet als auch die Integration von Sicherheitseigenschaften erlaubt haben wir uns entschlossen dieses System als Fallstudie in den weiteren Kapiteln dieser Arbeit zu verwenden r ber den lo Ad stickeiteni fineion LS Ad gwManager xl amp Buchung xl JComboBox I timetoot ip EE window AdminPasswortwindow iit amp amp
295. ngewandt werden In solchen Kriterienkatalogen sind f r h ufig gen tzte Anwendungsfelder Sicherheits anforderungen klassifiziert sodass der Anwender die darin vorgeschlagenen Grundfunktionen zur Abdeckung der Anforderungen bernehmen und mit seinen eigenen Sicherheitsfunktionen kombinieren kann Bei der Konstruktion des Sicherheitsmodells werden die funktionalen und sicherheitsbezo genen Eigenschaften auf hohem Niveau modelliert d h von Realisierungseigenschaften wie beispielsweise von konkreten Protokollen wird abstrahiert Auf Basis der Modellfestlegungen wird eine berpr fung der geforderten Eigenschaften formal oder informal erm glicht zum Beispiel k nnen die Vollst ndigkeit und Konsistenz nachgewiesen werden Die zu sch tzenden Komponenten werden im Grobentwurf identifiziert und die Sicherheits komponenten sind zu definieren sodass diese im Feinentwurf erweitert und in der Implemen tierung die notwendigen Datenstrukturen und Algorithmen gew hlt werden k nnen Methodisches Testen und Evaluieren sowie eine Verifizierung der sicherheitsrelevanten Funk tionen sind in der Validierung durchzuf hren die Tests sind zu dokumentieren und die Vollst ndigkeit der Abl ufe und Testszenarien zu begr nden Das System mit seiner Do kumentation und Einsatzumgebung kann einer Evaluierung durch Dritte unterzogen werden sodass eine Sicherheitsklassifikation gem nationaler oder internationaler Kriterienkatalo ge erfolgen kann Dadur
296. nn die Implementierung oder das fertig kompilierte System stellen ebenfalls Produktartefakte dar und ein Dokument kann durchaus auch aus mehreren Produktartefak ten bestehen Produktartefakte sind somit fein granularer als Dokumente Mit ihnen ist es m glich die n tige Zustandsmenge zur Ausf hrung der Prozessaktivit t zu beschreiben und dabei abge nderte und erzeugte Produktartefakte als Ausgaben zu spezifizieren In neue ren Prozessmodellen vgl GMP 03b wird in Abh ngigkeit der aktuellen Zustandsmenge der Produktartefakte die n chste Aktion ausgew hlt so dass der Prozessablauf dynamisch bestimmt berechnet kann Eine in den Prozessanforderungen SPA1 und SPA2 geforderte durchg ngige und sukzessive Entwicklung der Zugriffssicherheit fordert die Betrachtung von Produktartefakten in der f r jede Aktivit t angegeben wird was bereits gegeben was erzeugt bzw ver ndert wird SPAG Iterative Entwicklung Risiken fr hzeitig identifizieren und reduzieren eine robuste Architektur erstellen ndernde Anforderungen betrachten das System inkrementell aufbauen sowie effektives Arbeiten der Teammitglieder sind nach Gr nde dass heutige objektorientierte Entwicklungspro zesse iterativ und inkrementell arbeiten Auch im Bereich des Security Engineerings ist es n tig dass Sicherheitsrisiken fr hzeitig identifiziert reduziert und gegebenenfalls durch die Erstellung eines Prototyps validiert werden Eine iterative Entwicklung ist notwendig f
297. nnerhalb der Analyse gew hlten Methoden und Techniken zur Abdeckung von Aspekten der Zugriffssicherheit erweitern und verfeinen die Modelle bringen aber neue potenzielle Angriffsm glichkeiten mit sich Zur Ermittlung der Bedrohungen ist im Rahmen der Analyse zugriffssicherer Systeme f r diese Erweiterungen eine Schutzzielanalyse nach dem bereits mehrfach eingesetzten Verfahren durchzuf hren F r die schrittweise und sukzessive Verfeinerung des Verhaltens und der Aspekte der Zugriffs sicherheit gehen wir in Abschnitt auf die Realisierung der Anwendungsf lle innerhalb der Analysephase ein Aus den Anwendungsf llen sind Interaktionen der Objekte sowie Abl ufe zu 178 Die Analyse zugriffssicherer Systeme modellieren die die bereits in den Anwendungsf llen spezifizierten Sicherheitsanforderungen umsetzen Abschnitt besch ftigt sich mit der Auswahl und Integration von Sicherheitsprotokollen Hier sind zur Realisierung von Anforderungen der Zugriffssicherheit g ngige Sicherheitspro tokolle auszuw hlen oder eigene Protokolle zu definieren In Abschnitt 8 4 stellen wir den Prozess zur Analyse zugriffssicherer Systeme in einem Pro zessmuster vor Dabei gehen wir auf die Aktivit ten zur Modellierung des Analyseklassendia gramms n her ein und beschreiben die Integration des Sicherheitsmikroprozesses in die Analy se zugriffssicherer Systeme Abschlie end betrachten wir in Abschnitt 8 5ldie Produktartefakte der Analyse zugriffssicherer
298. nseitige Einwirkung oder durch Einbringung von Sicherheitsaspekten abge ndert werden m ssen und somit die ge nderte Modellierung erneut einer Sicherheitsanalyse unterzogen wer den muss So kann z B die Teilung eines Datenobjekts des Dom nenmodells zu einer neuen Auspr gung der Zugriffsmatrix f hren oder die Einf hrung eines Objekts zur Beweissicherung das Dom nenmodell erweitern Beide nderungen erfordern eine erneute Sicherheitsanalyse Aktivit ten Im Rahmen der Prozessausf hrung f r die Anforderungsspezifikation zugriffssicherer Systeme sind die folgenden Aktivit ten nach der in der L sung skizzierten Vorgehensweise auszuf hren e Durchf hrung einer Gesch ftsprozessmodellierung zugriffssicherer Systeme siehe Pro zessmuster 7 1 in Abschnitt e Durchf hrung einer Anwendungsfallmodellierung zugriffssicherer Systeme siehe Pro zessmuster 8 1 in Abschnitt e Durchf hrung einer Analyse zugriffssicherer Systeme siehe Prozessmuster 9 1 im Ab schnitt e Innerhalb der einzelnen Prozessabschnitte ist jeweils der im Prozessmuster 5 3 vgl Abschnitt vorgestellte Sicherheitsmikroprozess auszuf hren Produktartefakte Die folgende Auflistung beschreibt die Eingaben und Ausgaben zum Prozess der Anforde rungsspezifikation zugriffssicherer Systeme Um Sicherheitsaspekte erweiterte Standardpro duktartefakte sind gekennzeichnet Eingabe Produktartefakte e Projektidee e Projektmission und Sicherheitsziel aus der Startphase A
299. nte formale Spezifikation berf hrt Da in den einzelnen Prozessabschnitten das Dom nenmodell iterativ weiter entwickelt wird muss das Benutzerrechtemodell in jedem Abschnitt der Anforderungsspezifikation erg nzt werden 4 9 Zusammenfassung In diesem Kapitel haben wir einen formalen Spezifikationsrahmen zur Modellierung von Be nutzerrechten eingef hrt Der Ansatz ist dahingehend neu dass die Benutzerrechte in einer Berechtigungsmatrix vorab textuell spezifiziert und dann schrittweise pr dikativ formalisiert werden F r eine durchgehende und sukzessive Entwicklung ist es entscheidend dass bereits ab der Phase der Gesch ftsprozessmodellierung Sicherheitsaspekte und damit auch Benutzer rechte betrachtet werden denn zu diesem Zeitpunkt sitzen Entwickler Anwender Auftrag nehmer und Auftraggeber bei der Festlegung der Anforderungen zusammen und es k nnen bereits sicherheitsrelevante Verhaltensweisen wie beispielsweise die manuelle Handhabung von Mitarbeiterunterlagen protokolliert werden Neben diesem bereits erw hnten Vorteil der durchg ngigen und sukzessiven Entwicklung hat dieser implementierungsunabh ngige Ansatz eine Reihe weiterer Vorteile So kann mit der Modellierung bereits begonnen werden wenn das Dom nenmodell zum Anwendungskern vor liegt Im Gegensatz zu Ans tzen in denen die Rechte in den Klassen des Klassendiagramms modelliert werden ist unser Ansatz mit einer separaten Modellierung unabh ngig von klei neren
300. nur von bestimmten Individuen als Rollenvertreter Da die Rollenvertreter durch die Navigation auf den User Klassen bestimmt werden k nnen handelt es sich bei der Instanz Permission um eine Sonderform der Objektstruktur Permission TeamWorker show project statistics Abbildung 6 26 Beispiel zur Instanz Permission Abbildung zeigt ein Beispiel aus der TimeTool Fallstudie wobei die Aktivit t show project statistics nur von der konkreten Person Maier ausgef hrt werden darf Die Person Maier ist der Rolle TeamWorker zugeordnet Hierzu ergibt sich folgender Eintrag in der Zugriffsmatrix class actor TeamWorker ProjectManager PCShowProjectStatistics E only TeamWorker Maier E Da es sich bei der Instanz Permission um einen Sonderfall der Objektstruktur Permission handelt wird diese analog zur Objektstruktur Permission beschrieben Vtw ACTeamWorker V pc PCShowProjectStatistics tw rolerep name Maier gt perm PCShowProjectStatistics process tW pe Auch in diesem Spezialfall kann die Ausf hrungsberechtigung der Aktivit t aus den Ausf h rungsberechtigungen der process Methode berechnet werden wenn es sich bei den Zugriffs methoden in der Aktivit t ausschlie lich um Objektzugriffe handelt Permission zur Instanzentrennung Ein h ufig wiederkehrendes Merkmal bei Gesch ftsprozessen ist die berpr fung der Arbeit Kontrolle durch eine weitere Person So m ssen Vertr
301. nwendungsfallmodellierung und der Analyse zugriffssicherer Systeme wird in Kapitel 6 bis Kapitel 8 beschrieben Innerhalb der einzelnen Teilphasen gehen wir auf die Berechtigungsmodellierung die Beschreibungstechni ken die Produktartefakte sowie auf die Prozesse ein Zur Verdeutlichung werden die Konzepte hier mit Beispielen aus der Fallstudie TimeTool erl utert In Kapitel 9 sind die erzielten Ergebnisse kritisch bewertet und zusammengefasst Ein Ausblick schlie t die Arbeit ab 1 4 Verwandte Arbeiten Erste einfach handhabbare Vorgehensweisen zur Entwicklung sicherer Systeme sind in zu finden Diese Ans tze stellen eine Erweiterung von Stan dardvorgehensmodellen wie beispielsweise das Wasserfallmodell oder das Spiralmodell um Sicherheitsaspekte dar Eine genauere Betrachtung der Sicherheitsanalyse ist in zu finden wobei hier Funktionalit tsanforderungen und Sicherheitsaspekte gr tenteils losgel st voneinander entwickelt werden stellen nur Grunds tze f r eine sichere Ent wicklung und die Einbettung in Vorgehensmodelle dar eine klare Durchdringung der Ent wicklung wird hierbei nicht gezeigt In wird ein erster Ansatz f r eine integrierte Entwicklung von Sicherheit und Funktionalit t mit dem Ziel der Evaluierung vorgestellt Die Sicherheit wird hierbei w hrend der gesamten Entwicklung betrachtet jedoch basiert dieses Verfahren auf dem linearen Wasserfallmodell Ross Anderson behandelt Security Engineer ing in And01 Im V
302. o matisierten Ablauf verwendet werden Entsprechend ist auch das Akteurmodell anzupassen denn durch die Selektion der automatisierbaren Abl ufe k nnen durchaus Akteure entfernt werden Anwendungsf lle Anwendungsf lle sind nach Dienste die das System einem externen Akteur anbietet Externe Akteure repr sentieren dabei alle Entit ten die mit dem System inter agieren Ein Anwendungsfall ist eine Abfolge von Aufgaben die durch ein System ausgef hrt werden und die ein Ergebnis von messbarem Wert f r einen bestimmten Akteur hervorbrin gen Die Erledigung der Aufgabe erfolgt in Abh ngigkeit von den Daten des Systems Daten k nnen dabei gelesen und ver ndert werden Unter System verstehen wir in diesem Kontext das zu entwerfende Softwaresystem Akteure k nnen in diesem Zusammenhang einzelne Personen eine Maschine ein anderes Soft waresystem oder ein Dienst sein Wie im vorgestellten Ansatz zum akteurzentrierten Modell vgl Kapitel 4 bereits erkl rt wurde ist bei einem Akteur nicht die einzelne Person an sich entscheidend sondern die Rolle die sie im Anwendungsfall einnimmt Personen k nnen mehrere unterschiedliche Rollen einnehmen Anwendungsf lle beschreiben Interaktionen von einem oder mehreren Akteuren mit dem System und die Akteure k nnen sowohl Quelle als auch Senke der Information sein In unserer TimeTool Fallstudie k nnen beispielsweise die beiden Rollen Team Worker und Projektleiter von derselben Person einge nomme
303. ocess der Vorgangsklasse PC ViewProjectInfo formulieren Va ACActor Vpe PCViewProjectInfo gt perm PCViewProjectInfo process a pe Diese Berechtigung wurde f r die Superklasse aller Akteure f r die Klasse AC Actor definiert Nach der in Abschnitt eingef hrten Vererbung von Benutzerberechtigungen gilt diese Berechtigung f r alle vererbten und transitiv vererbten Akteur Subklassen Swimlane Permission Eine Einschr nkung der allgemeinen Ausf hrungsberechtigung ist die Beschr nkung der Aus f hrung auf einzelne Akteure oder auf eine Teilmenge der Akteure Die Aktivit t darf nur noch von den explizit berechtigten Akteuren oder von Akteuren die die notwendige Berechtigung erben ausgef hrt werden TeamWorker view all team worker Abbildung 6 24 Beispiel zur Swimlane Permission Abbildung 6 24 zeigt die Aktivit t view all team worker der TimeTool Fallstudie Diese Akti vit t darf nur von Projektmitarbeitern ausgef hrt werden In der zugeh rigen Zugriffsmatrix wird nur f r die Rolle Team Worker die Execute Berechtigung auf true gesetzt actor gt Team Project Adminis Others class Worker Manager trator PCViewAllTeamWorker E true E E E Die derart definierten Berechtigungen gelten f r alle Rollen f r die sie explizit vergeben wer den sowie f r alle transitiven Rollen die eine Sonderform dieser Rolle darstellen Beispiels weise ist in der TimeTool Fallstudie der ProjectManager
304. ojekten lesen kann Wir spezifizieren hier erneut die Benutzer berechtigung f r die Methode getAccountingDate Vpm ACProjectManager Va Accounting a activity project projectmanager pm rolerep perm Accounting get Accounting Date pm a 4 4 Formale Modellierung von Benutzerrechten 45 Beispiel 2 Eine weitere Berechtigung fiir den Projektmitarbeiter team worker spezifiziert dass er nur Buchungen zu freigegebenen Aktivit ten schreiben kann Aktivit ten sind mit einem Zu standsattribut gekennzeichnet das auf freigegeben oder eingefroren gesetzt wird Auf die se Weise kann verhindert werden dass Buchungsobjekte zu abgeschlossenen Aktivit ten im Nachhinein ver ndert werden Das Berechtigungspr dikat f r die stellvertretende Schreibzu griffsmethode writeAccountingDate sieht folgenderma en aus Vtw ACTeamWorker Va Accounting a user tw rolerep A a activity state freleased gt perm Accounting writeAccountingDate tW a Beispiel 3 Als letztes Beispiel betrachten wir die Berechtigung zu einer Create Methode Der Projektlei ter project manager kann nur Buchungen zu eigenen Projekten erzeugen Hierbei nehmen wir an dass die Create Methode nur die Aktivit t und den User auf den das Accounting Objekt referenzieren soll als Parameter bergeben bekommt Vpm ACProjectManager Vac Activity Vu User ac project projectmanager pm rolerep gt perm Accounting create pm ac u 4 4 3
305. okoll Oak01 Hierzu wurde im Szenario eine Vorgangsklasse eingef gt welche die Verschl sselung die sichere bertragung und die Entschl sselung bernimmt Da wir dieses Protokoll im Design als fertige Komponente zum System hinzuf gen werden weitere Details und Subklassen zu diesem Protokoll nicht weiter spezifiziert Einzelheiten zur Speicherung des Schl ssels wie wir dies in Abbildung bereits spezifiziert haben werden nicht weiter betrachtet F r die berpr fung der Autorisierung wurden Methodenaufrufe check permission ein gef gt und der Ablauf der Beweissicherung an Buchungsobjekten wurde durch Interaktion mit der Klasse Logging spezifiziert Die f r die Abdeckung der Sicherheitsanforderungen hin zugef gten Objekte sind im Szenario zur Korrekturbuchung in Abbildung 8 4lgrau hinterlegt 8 4 Der Prozess der Analyse zugriffssicherer Systeme In diesem Kapitel haben wir bereits die Aktivit ten der Analyse zugriffssicherer Systeme zur Realisierung der Anwendungsf lle und zur Integration von Sicherheitsprotokollen vorgestellt Im Folgenden zeigen wir die Eingliederung dieser Aktivit ten in den Entwicklungsprozess Ab schnitt sowie die erneute Anwendung des Sicherheitsmikroprozesses Abschnitt 8 4 2 8 4 1 Prozessmuster 8 1 Analyse zugriffssicherer Systeme Kurzbeschreibung Kernziele der Analyse sind die Transformation des Dom nenmodells in ein Klassendiagramm der Analyse mit Fach Vorgangs und Interaktionsklassen sowie d
306. opment Based on the Common Criteria In 10th International Symposium on the Foundations of Software Engineering FSE 10 2002 Web Seite des neuen V Modell XT Der Entwicklungsstandard f r IT Systeme des Bundes 2004 http www v modell xt de Wikimedia Foundation Inc WIKIPEDIA Die freie Enzyklop die im Web http www wikipedia org Literaturverzeichnis 207 Wim05 Guido Wimmel Model Based Development of Security Critical Systems PhD thesis Technische Universit t M nchen 2005 To Appear WK99 Jos Warmer and Anneke G Kleppe The Object Constraint Language Precise Modeling with UML Addison Wesley Longman Inc first edition 1999 208 Literaturverzeichnis Tabellenverzeichnis 2 1 Vorlage f r die Beschreibung von Prozessmustern 2 2 2 22 22 14 4 1 P MOS Pradikate 2 2222 Common nn 39 4 2 Benutzerrechte von Projektmitarbeiter und Projektmanager 40 5 1 Abdeckung der Prozessanforderungen in Vorgehensmodellen 70 5 2 Abdeckung der Prozessanforderungen in Vorgehensbeschreibungen 71 5 3 bersicht ber die Produktartefakte der Anforderungsspezifikation zugriffssi cherer Systeme 2 2 Comm onen 85 6 1 Bedrohungen und Risiken zum Dom nenmodell der TimeTool Fallstudie 131 6 2 Bedrohungen und Risiken zum TimeTool Gesch ftsprozess aus Abbildung 6 13 133 210 Tabellenverzeichnis Abbildungsverzeichnis 1 1 Einflussfaktoren f r die Entwicklung zugriffssicherer Sy
307. ordergrund stehen dabei jedoch mehr die Techniken die in sicheren Systemen bei der Entwicklung Einsatz finden Der Autor besch ftigt sich in geringem Ma e mit top down orientierten und iterativen Vorgehensweisen All diese Ans tze bilden die Ba sis f r die Untersuchungen zur Integration von Sicherheitsanforderungen in die Entwicklung zugriffssicherer Systeme insbesondere werden sie zur Definition der Prozessanforderungen herangezogen betrachtet Sicherheitseigenschaften in den verschiedenen Phasen der Softwareentwicklung gibt aber wenige methodische Richtlinien zur durchg ngigen und sukzes siven Entwicklung betrachtet die Evolution von Informationssystemen und vergleicht verschiedene Methoden zur Analyse von Sicherheitseigenschaften Die darin betrachteten Me thoden basieren jedoch auf eingeschr nkten Checklisten Basis f r eine strukturierte durchgehende und sukzessive Betrachtung von Aspekten der Zugriffssicherheit ist die Unterteilung der Anforderungen in Schutzziele wie dies beispielsweise in Eck03 BSWO0O1 vorgestellt wird Anwendungsfalle zur Sicherheit wurden bereits mehrfach diskutiert In werden Uber legungen zu einer Erweiterung von Anwendungsfallen auf nichtfunktionale Eigenschaften darunter auch Sicherheit gestellt Diese auf einem Fragenkatalog basierende Analyse liefert jedoch nur sehr abstrakte Anforderungen und ein durchg ngiges Verfahren zur Entwicklung von Anwendungsf llen mit Sicherheitsaspekten geht daraus nic
308. ozess der Anforderungsspezifikation der in den n chsten Kapiteln detailliert beschrieben wird ist in einen Softwarelebenszyklus zu integrieren Da zu weicht der in diesem Prozessmuster vorgestellte Lebenszyklus von bekannten objektori entierten Lebenszyklen insbesondere dahingehend ab dass die Ausarbeitungsphase engl Elaboration Phase nach Kru00 durch eine Phase zur Anforderungsspezifikation zu griffssicherer Systeme ersetzt wird Problem Die Anforderungsspezifikation zugriffssicherer Systeme wie sie in Form eines Prozessmusters im Abschnitt vorgestellt wird ist innerhalb eines Softwarelebenszyklus zu integrieren dabei ist sie im Rahmen eines bestehenden Lebenszyklusmodells einzubinden Da die Model lierung innerhalb der Anforderungsspezifikation zugriffssicherer Systeme objektorientierten Grundkonzepten entspricht insbesondere wird die Struktur in Form von Klassendiagrammen erarbeitet und das Verhalten wird in Ablaufdiagrammen Aktivit tsdiagrammen Zustands diagrammen Anwendungsf llen und Komponentendiagrammen modelliert ist es sinnvoll die Anforderungsspezifikation in ein objektorientiertes Vorgehensmodell zu integrieren Insbeson dere durch die Komplexit t von Softwareprodukten hat der Softwarelebenszyklus eine iterati ve Systementwicklung zu unterst tzen Die notwendigen und erzeugten Produktartefakte des Prozesses sind zu spezifizieren L sung Objektorientierte Vorgehensmodelle wie zum Beispiel der Rational Unifie
309. pment Process Software Quality Professional 5 3 4 16 June 2003 Stefanos Gritzalis Diomidis Spinellis and Panagiotis Georgiadis Security Pro tocols over Open Networks and Distributed Systems Formal Methods for their Analysis Design and Verification Computer Communications 22 8 695 707 1999 Michael Howard and David Le Blanc Writing Secure Code Microsoft Press second edition 2003 Sebastian H hn and Jan J rjens Automated Checking of SAP Security Permis sions In Proceedings of the 6th IFIP WG 11 5 Working Conference on Integrity and Internal Control in Information Systems IICIS Nov 13 15 2003 Lau sanne Switzerland Kluwer 2003 Christine Hofmeister Robert Nord and Dilip Soni Applied Software Architec ture Addison Wesley Longman Inc 2000 Erika Horn and Wolfgang Schubert Objektorientierte Software Konstruktion Grundlagen Modelle Methoden Beispiele Carl Hanser Verlag 1993 IABG V Modell http www v modell iabg de Business Consulting Services IBM SAP Berechtigungswesen Design und Rea lisierung von Berechtigungskonzepten f r SAP R 3 und SAP Enterprise Portal SAP Press 2003 ITSEC Information Technology Security Evaluation Criteria Harmonised Cri teria of France Germany the Netherlands the United Kingdom May 1990 204 Literaturverzeichnis Jac87 JBR99 JCJ092 JPWO3 Jiir04 JW03 KE01 KPP03 Kro97 Kru00 LBDO2 MFSK97 M
310. r Bedro hungen und Risiken durch die Ausf hrung des Sicherheitsmikroprozesses zu ermitteln Ebenso k nnen Berechtigungen jeweils nach Ermittlung der Schutzziele oder am Ende der Analyse zugriffssicherer Systeme spezifiziert werden 8 4 Der Prozess der Analyse zugriffssicherer Systeme 189 Identifikation der Analyse Packages Identifikation der Fach und Interaktionsklasse Analyse der Spezialanforderungen Protokollauswahl und modellierung Realisierung der Anwendungsf lle lt Analyse der Klassen lt Ausf hrung des Sicherheits mikroprozesses lt Modellierung der Ausf hrungsrechte Modellierung der Zugriffsrechte Abbildung 8 6 Der Ablauf der Analyse zugriffssicherer Systeme Durch den vorgestellten Prozess wird die gemeinsame Entwicklung von Funktionalit t und Si cherheit gefordert Sobald Aspekte der Zugriffssicherheit betrachtet werden k nnen schreibt der Prozess die Behandlung von Sicherheitsaspekten vor Schutzziele Bedrohungen Ma nah men und Benutzerrechte m ssen vor Abschluss der Analyse zugriffssicherer Systeme ermittelt werden Vor und Nachteile Durch das vorgestellte Prozessmuster wird die fr hzeitige Entwicklung von Sicherheit inner halb der Phase der Anforderungsdefinition weiter unterst tzt Durch die Betrachtung von 190 Die Analyse zugriffssicherer Systeme Sicherheitsaspekten in allen Prozessabschnitten der Anforde
311. r den Aufbau einer Systemarchitektur mit Trennung der sicherheitskritischen und unkritischen Tei le Zu ver ndernde funktionale Anforderungen bringen nderungen in den Anforderungen an die Zugriffssicherheit mit sich die in weiteren Iterationen behandelt werden m ssen Die Gr e von Systemen macht es oftmals unumg nglich dass Systeme in mehreren Inkremen ten entwickelt werden und da durch die Integration der Zugriffssicherheit die Systeme noch komplexer werden wird die inkrementelle Entwicklung noch mehr gefordert 70 Ein Prozess zur Entwicklung von Anforderungsspezifikationen Tabelle 5 1 Abdeckung der Prozessanforderungen in Vorgehensmodellen Anforderung Phasen V Modell CC konformes strukturiert und ITSEC Vorgehen Durchg ngige Sicherheitsbetrachtung Sukzessive Erarbeitung der Sicherheit Gemeinsame Entwicklung von 7 pi Funktionen und Sicherheit Lokale Spezifikation der Sicherheit Betrachtung von Produktartefakten o Iterative Entwicklung o Sicherheitsmodellierung in der 7 7 7 Gesch ftsprozessanalyse Legende wird unterst tzt o wird geringf gig unterst tzt wird nicht unterst tzt Zudem spielt die iterative Entwicklung bei der Entwicklung zugriffssicher Systeme eine bedeu tende Rolle denn Ma nahmen zur Abdeckung der Anforderungen an die Zugriffssicherheit die innerhalb einer Iteration in das System integriert werden rufen nderungen und Erg nzun gen hervor die in weitere
312. r verschiedene Berechtigungstypen vor 6 3 3 1 Zusammenhang zwischen Ausf hrungsrechten und Aktivit ten Das im Kapitel 4 vorgestellte Rechtemodell spezifiziert Zugriffsberechtigungen auf Klassenme thoden Wie wir in Abbildung 4 5 gezeigt haben werden in unserem Berechtigungsansatz zur Benutzerrechtespezifikation Akteure auf User Klassen abgebildet sodass die Berechtigungen als Navigationen ber die Objektstruktur ausgedr ckt werden k nnen Um einen homogenen Spezifikationsrahmen innerhalb P MOS vgl Abschnitt auch f r Aktivit tsdiagramme bereitzustellen erweitern wir das interne Klassendiagramm um Vor gangsklassen zur Darstellung der Aktivit ten Hierzu f hren wir f r jede Aktivit t aus den Ablaufmodellierungen in Aktivit tsdiagram men zum internen Klassendiagramm eine Vorgangsklasse ProcessClass hinzu Jede dieser Vorgangsklassen enth lt eine Methode process welche die Ausf hrung der Aktivit t zur Auf gabe hat Wir setzen dabei a priori voraus dass jede Aktivit t im Aktivit tsdiagramm einer Swimlane und dass jeder Swimlane eindeutig eine Akteur Rolle zugeordnet wurde Als Beispiel betrachten wir das Aktivit tsdiagramm in Abbildung Die beiden Aktivit ten Activityl und Activity2 sind jeweils einer Swimlane zugeordnet und den Swimlanes sind die 116 Die Geschaftsprozessmodellierung zugriffssicherer Systeme Activity Model Domain Model 7 TeamWorker 7 ee ect anager PC Activityl PC Activity2
313. rchf hrung der Aktivit t nicht abstreitbar sein darf 6 2 Spezifikation der Schutzziele in Struktur und Verhalten 107 Project Manager Team Worker initialise project change project data lt gt account CIN online SEC account offline prepare Gl Monthly monthly report SEC Accounts Abbildung 6 13 TimeTool Geschaftsprozess mit Schutzzielen f r Aktivit ten Bereits in der Gesch ftsprozessmodellierung werden so am Dom nenmodell und an den Ab l ufen Schutzziele spezifiziert Da jedoch die Modelle der Gesch ftsprozessmodellierung noch nicht die endg ltige Form erreicht haben d h in einer f r das Design geeigneten Form vorlie gen finden an diesen Modellen weitere Anpassungen und Verfeinerungen statt Dies erfordert auch Anpassungen an den Schutzzielen und Benutzerrechten die in den Iterationen durch zuf hren sind Die iterative Entwicklung wird unter anderem durch den iterativ anwendbaren Sicherheitsmikroprozess unterst tzt vgl Abschnitt 5 3 3 Abbildung 6 13 zeigt einen Gesch ftsprozess unserer TimeTool Fallstudie mit Schutzzielan notationen in den Aktivit ten Zu den spezifizierten Schutzzielen sind im Rahmen der Ent wicklung die Ausf hrungsrechte festzulegen sowie innerhalb des Sicherheitsmikroprozesses die Bedrohungen und Risiken zu ermitteln 6 2 3 Schutzziele in Objektfl
314. rd ist in Abbildung 7 4 d dargestellt F r diejenigen Aktivit ten die eine eigene Authentifikation ben tigen wird im Authentifi kationsfluss zus tzlich Beginn und Ende einer Authentifikation gekennzeichnet Die explizite Authentifikation kann auch mehrere Aktivit ten berdecken und hierarchisch geschachtelt werden In derartigen F llen setzt der Akteur nach Beendigung der speziellen Authentifika tion die Ausf hrung der Aktivit ten mit seiner urspr nglichen Authentifikation fort sodass beispielsweise beim wiederholten Aufruf der Aktivit t mit eigener Authentifikation diese er neut durchzuf hren ist Im Gegensatz dazu zeigt Abbildung 7 4 e den Fall dass Akteur sich innerhalb einer Sitzung f r eine weitere Aktivit t speziell authentifiziert anschlie end diese spezielle Authentifikation aber bis zum Ende der Session weiter ausf hrt Mit Beendigung der Session werden beide Authentifikationen beendet Abbildung 7 4 f zeigt einen weiteren Sonderfall der Authentifikation bei dem der Akteur innerhalb der Sitzung zun chst eine Aktivit t ohne Authentifikation ausf hrt dann jedoch im weiteren Verlauf der Sitzung eine Authentifikation durchf hrt In Abbildung 7 4wurde in allen Beispielen stets die einseitige Authentifizierung verwendet In allen Darstellungen kann entsprechend die beidseitige Authentifizierung verwendet werden F r den Fall dass innerhalb einer einseitigen Authentifikation eine beidseitige Authentifi kation ge
315. reibungen zu L cken und Inkonsistenzen in den Sicherheitsaspekten Im Gesch ftsprozessmodell sind die Abl ufe durch eine Folge von Aktivit ten beschrieben Die Aktivit ten sind in einzelne Anwendungsf lle zu verfeinern welche die internen Abl ufe der Aktivit ten beschreiben Eine Aktivit t kann jedoch nicht immer genau einem Anwendungs fall zugeordnet werden Ein Anwendungsfall stellt immer einen zusammenh ngenden und vollst ndigen Ablauf dar w hrend die Granularit t von Aktivit ten bei der Gesch ftspro zessmodellierung nicht festgelegt ist Ver nderungen an der Aufteilung der Funktionalit t im Rahmen der Bestimmung der Anwendungsf lle f hren zu Inkonsistenzen und L cken in den Beschreibungen von Aspekten der Zugriffssicherheit F r die Ausf hrung von sicherheitskritischen Funktionen m ssen sich die Benutzer am System anmelden und die Benutzerrechte sind vor dem Zugriff auf Daten und vor der Ausf hrung von Funktionen abzupr fen Bei der Beschreibung des Ablaufverhaltens sind Aktionen und Techniken der Identit tspr fung in die Entwicklung mit einzubeziehen nderungen am Dom nenmodell ergeben sich nicht nur aus der Festlegung der zu automati sierenden Prozesse Im Rahmen der Modellierung der Anwendungsf lle wird das Datenmodell 7 5 Der Prozess der Anwendungsfallmodellierung zugriffssicherer Systeme 165 mit weiteren Typen von Nachrichten Schnittstellenobjekten Vorgangsklassen etc erweitert und die bestehenden
316. reits bei der Analyse der funk tionalen Anforderungen und des Dom nenmodells zu betrachten sodass eine nachtr gliche Aufsplittung der Systemanforderungen zur Analyse der Zugriffssicherheit vermieden werden kann Sicherlich werden durch diese Vorgehensweise Systemteile mehrfach einer Sicherheits analyse unterzogen aber es kann bei einer Sicherheitsanalyse einer Funktion gegebenenfalls auf die Sicherheitsanalyse innerhalb einer bereits erarbeiteten Funktion verwiesen werden Wird eine Sicherheitsanalyse mehrfach f r funktionale Anforderungen mit gleichen Bedro hungen und Ma nahmen durchgef hrt und dies erst sp ter festgestellt so k nnen die beiden Analysen verglichen werden und wir erhalten dadurch ein Kontrollinstrument zur Validie rung Beispielsweise kann bei der Systementwicklung zum Datenmodell eine Zugriffstabelle erstellt werden in den Funktionen werden im Rahmen der Verhaltensmodellierung die Rech te der Ein und Ausgabedaten sowie die Rechte der in der Funktion ver nderten Daten des Datenmodells spezifiziert Die Zugriffsrechte zum Ver ndern der Daten im Datenmodell sind ebenfalls Bestandteil der Zugriffstabelle und k nnen nun auf Inkonsistenzen berpr ft und ggf korrigiert bzw erg nzt werden SPA5 Betrachtung von Produktartefakten Neben den Prozessabl ufen spielen Produktartefakte welche die Ein und Ausgabeparameter der Prozesse darstellen eine bedeutende Rolle Produktartefakte sind dabei nicht zwingend Dokumente de
317. reu Klaus Burger Michael Hafner and Gerhard Popp Towards a Syste matic Development of Secure Systems Information Systems Security 13 3 5 13 July August 2004 Ruth Breu Klaus Burger Michael Hafner and Gerhard Popp Core Concepts of a Process Model for Security Engineering SoSyM Journal on Software amp System Modeling 2005 To appear David A Basin J rgen Doser and Torsten Lodderstedt Model Driven Security for Process Oriented Systems In 8th ACM Symposium on Access Control Models and Technologies ACM 2003 Gerald Brose Manuel Koch and Klaus Peter Lohr Integrating Security Policy Design into the Software Development Process Technical Report B 01 06 Freie Universit t Berlin November 2001 D Elliot Bell and Leonard J LaPadula Secure Computer Systems Mathemati cal Foundations and Model Technical Report MTR 2547 Vol 2 MITRE Corp Bedford MA November 1973 David F C Brewer and Michael J Nash The Chinese Wall Security Policy In Proceedings of the 1989th IEEE Symposium on Security and Privacy pages 206 214 1989 Barry Boehm A Spiral Model of Software Development and Enhancement In ACM Sigsoft Software Engineering Notes Vol 11 No 4 1986 Grady Booch Object Oriented Analysis and Design with Applications Addison Wesley Longman Inc second edition 1994 Ruth Breu and Gerhard Popp Actor Centric Modeling of User Rights In T Margaria Steffen M Wermelinger editor Proceedings FASE 2004
318. rgehensweisen ausgerichtet ist wird eine Erweiterung von UML Diagrammen zur Integration von Aspekten der Zugriffssicherheit vorgestellt F r die Ablaufmodellierung sind neue Techniken gefordert die wir mittels des Erweiterungsmechanis mus der UML in Diagramme integrieren Neben Erweiterungen der UML ben tigen wir auch textuelle Beschreibungen beispielsweise zur Spezifikation von Anforderungen der Zugriffssi cherheit in den Anwendungsf llen oder zur Beschreibung von Bedrohungen und Risiken Neben einer Modellierung der Schutzziele in Struktur und Verhalten sowie von Bedrohungen und Risiken stellt die Zugriffskontrolle als Schutz von Daten und Systemressourcen ein zen trales Thema bei der Entwicklung zugriffssicherer Software dar In der Literatur wurde jedoch die Modellierung von Benutzerrechten in fr hen Phasen der Softwareentwicklung betrieblicher 1 2 Ergebnisse 5 Informationssysteme kaum betrachtet obwohl eine friihzeitige Modellierung schon bereits ab der Gesch ftsprozessmodellierung sinnvoll ist da zu diesem Zeitpunkt Anforderungsentwick ler Auftragnehmer Auftraggeber und Anwender eng zusammenarbeiten Bereits hier k nnen Benutzerrechte beispielsweise nach dem rollenbasierten Paradigma vgl Role Based Access Control RBAC in San96 textuell spezifiziert werden Benutzerrechte werden dabei an abstrakte Rollen gebunden und jeder Benutzer ist an eine oder mehrere Rollen gebunden Den Rollen werden eine Menge von Berechtigunge
319. rgestellte Methode die schrittweise Entwicklung eines Benutzer rechtemodells Dieses erstreckt sich von informalen textuellen Aussagen bis hin zu einer vollst ndigen pr dikativen Spezifikation Die implementierungsunabh ngige Spezifikation der Benutzerrechte hat eine Vielzahl von Vorteilen Der bedeutendste Vorteil ist dass das ent wickelte Modell eine kurze und pr gnante Darstellung von Benutzerrechten f r viele Teile der Implementierung darstellt Dar ber hinaus erm glicht dieser Ansatz die automatische bersetzung der vollst ndigen Benutzerrechtemodelle in ausf hrbaren Code Drittens ist der vorgestellte Ansatz mit einer formalen Semantik in einer algebraischen Theo rie ausgestattet Auf der syntaktischen Ebene erweitern wir die Methodenspezifikationen um einen Benutzerrechteabschnitt der f r jeden Akteur oder f r jede Rolle das Recht zur Ausf hrung dieser Methode eines Objektes zu einer gegebenen Klasse beschreibt Da den Akteuren in diesem Ansatz eine bedeutende Rolle bei der Spezifikation der Benutzerberech tigungen zukommt bezeichnen wir diese Vorgehensweise als akteurzentriert Die Berechti gungen werden durch ein Pr dikat erster Ordnung oder im Kontext der UML mit einem OCL Ausdruck vgl IOMGO3 ber einer integrierten Objektstruktur beschrieben Zur internen Darstellung von Akteuren im System wird eine Repr sentierungsfunktion ein gef hrt Diese Repr sentierungsfunktion ist eine Abstraktion der Authentifizierungsp
320. rheitsrelevant angesehenen Funktionen ausreichend abgegrenzt werden sodass der Umfang des gesamten Sicherheitsanteils so klein wie m glich gehalten werden kann In der Realisierbarkeitsuntersu chung ist die Abgrenzbarkeit des sicherheitsrelevanten Teils vom nicht sicherheitsrelevanten zu berpr fen Die Machbarkeit der geforderten Sicherheitsstufe nach ITSEC ist zu untersuchen wobei die erwartete Komplexit t des Sicherheitsanteils ein Kriterium f r die Realisierbarkeit darstellt Es sind berlegungen bez glich der Wirtschaftlichkeit anzustellen Die Untersu chungen die durchzuf hren sind m ssen unter Ber cksichtigung des tragbaren Restrisikos die Kosten und die m glichen Sch den die beim Wirksamwerden der Bedrohungen eintreten abw gen Beim Zuordnen der Anwenderforderungen ist der Nachweis zu erbringen dass s mt liche Sicherheitsanforderungen im Sicherheitskonzept ber cksichtigt werden Dadurch kann gegebenenfalls ein vorhandenes Restrisiko festgestellt werden In der Software Hardware Anforderungsanalyse ist zu berpr fen inwiefern sich sicherheits relevante Teile auf die Software Hardware Einheiten auswirken Falls sicherheitsspezifische oder sicherheitsrelevante Funktionen in der Software Hardware Einheit realisiert werden m ssen muss innerhalb der Definition von allgemeinen Anforderungen aus Sicht der SW HW Einheit eine exakte Schnittstellenbeschreibung zum restlichen sicherheitsspezifischen oder sicherheitsrelevanten
321. rieben durch die An wendungsf lle und weitere nichtfunktionale Anforderungen Die Analyse f hrt somit zu einem nahezu idealen Abbild des Systems vgl Kru00 Der Fokus der klassischen Analysephase liegt auf den funktionalen Anforderungen Einen berblick ber die Akti vit ten der Analyse geben wir in Abschnitt Bei den heutigen g ngigen Methoden zur Analyse spielen nichtfunktionale Anforderungen eine untergeordnete Rolle f hrt beispielsweise eine eigene Aktivit t zur Erfassung von Special Requirements ein gibt jedoch kein schrittweises Verfahren zur Ent wicklung und Verfeinerung dieser Anforderungen an Auch f r die schrittweise und sukzes sive Analyse von Aspekten der Zugriffssicherheit als eine Auspr gung der nichtfunktionalen Anforderungen liefern g ngige Entwicklungsmethoden keine L sung Anforderungen an die Sicherheit und weitere funktionale Anforderungen werden nur aufgenommen jedoch beginnt die Ausarbeitung dieser Anforderungen erst in der Designphase Innerhalb der Analyse zugriffssicherer Systeme kann jedoch die in der Gesch ftsprozessmodel lierung begonnene und in der Anwendungsfallmodellierung fortgesetzte Analyse von Aspekten der Zugriffssicherheit schrittweise und sukzessive fortgesetzt werden Ma nahmen die zur Ab wehr von Bedrohungen mit nicht vermeidbarem Risiko spezifiziert wurden sind sowohl bei der Entwicklung des Analyseklassendiagramms als auch bei der Realisierung der Anwendungsf lle zu betrachten Die i
322. rmation So k nnen beispielsweise einzelne Zugriffe auf Datenobjekte im System er laubt sein Der Zugriff auf alle Objekte einer Klasse l sst jedoch Schlussfolgerungen zu Vorab unbedeutende Information wie etwa eine Buchung in einem Warensystem wird zu wertvoller Information da sich Umsatzzahlen oder hnliches berechnen lassen Der artige Zugriffe k nnen nicht mehr in den einzelnen Zugriffsrechten ausgedr ckt werden sie m ssen als Ausf hrungsrechte f r die betreffenden Vorgangsmethoden spezifiziert werden e Sind Datenzugriffe und Aufrufe von Submethoden parametrisiert so kann das zugeord nete Ausf hrungsrecht der aufrufenden Methode zu restriktiv oder unzureichend sein Um einerseits alle potenziell unberechtigten Zugriffe abzuwehren andererseits aber das Minimum an notwendigen Benutzerrechten zur Ausf hrung zu gew hren m ssen hier die Ausf hrungsrechte manuell festgelegt werden e Der Datenzugriff ist von Prinzipien abh ngig Beispielsweise darf aufgrund des 4 Augen Prinzips ein Vertrag der zweimal signiert werden muss nicht beide Male von dersel ben Person signiert werden Derartige Ausf hrungsberechtigungen sind ebenfalls an Vorg nge zu binden Im Folgenden gehen wir n her auf die Modellierung von Ausf hrungsrechten ein und zeigen wie wir den bereits f r die Spezifikation von Zugriffsrechten gew hlten Ansatz zur Beschrei bung von Ausf hrungsrechten wieder verwenden Bei der eigentlichen Modellierung stellen wi
323. rozedur der Implementierung und erlaubt Spezifikationen der Art Der Anwender hat das Recht seine eigenen Daten zu sehen Die Semantik der Berechtigungen und der Repr sentierungsfunktion kann direkt in die in vorgestellte algebraische Theorie integriert werden Verwandte Arbeiten wurden bereits in der Einleitung im Abschnitt diskutiert Der un ten vorgestellte Ansatz geht in mehreren Beziehungen ber den in der Literatur vorwie gend diskutierten RBAC Ansatz dahingehend hinaus dass wir uns mit einem Entwicklungsprozess eines Benutzerrechtemodells im Kontext objektorien tierter Modellierungstechniken besch ftigen Dar ber hinaus stellen wir eine erweiterte Aus drucksm chtigkeit bei der Spezifikation von Benutzerrechten durch beliebige pr dikatenlogi sche Ausdr cke erster Ordnung zur Verf gung Ein Ansatz mit hnlicher Ausdrucksm chtig keit wird in vorgestellt der sich mit dem prim ren Ziel der Codegenerie rung besch ftigt Davon abgrenzend liegt unser Fokus auf der Entwicklung von Konzepten die w hrend des gesamten Entwicklungsprozesses angewendet werden k nnen Ein Schema zur Modellierung von Benutzerrechten im Kontext von Anwendungsf llen wurde erstmals in pr sentiert wovon Grundgedanken bernommen wurden Mit speziellen Theorien f r die Modellierung von Benutzerrechten im Kontext eines Entwicklungsprozesses und der berpr fung von Rechten in SAP Anwendungen besch ftigen sich IBMO3 Die formale Spezifikation als Gru
324. rozess zur Entwicklung von Anforderungsspezifikationen Systeme in den fr hen Phasen einer objektorientierte Methode integriert werden k nnen Hier zu erweitern wir ein objektorientiertes Vorgehen um eine Anforderungsspezifikation zugriffs sicherer Systeme Im weiteren Verlauf der Arbeit stellen wir die Anforderungsspezifikation zugriffssicherer Systeme im Detail vor Zur Beschreibung verwenden wir das in Kapitel 2 vorgestellte Konzept der Prozessmuster Wir definieren im Folgenden Prozessmuster f r die Integration der Anforderungsspezifikation zugriffssicherer Systeme in den Softwarelebenszyklus f r die Phase der Anforderungsspezifi kation zugriffssicherer Systeme und f r den Sicherheitsmikroprozess W hrend die Anforderungsspezifikation zugriffssicherer Systeme Teil des Lebenszyklus ist wird der Sicherheitsmikroprozess innerhalb der Anforderungsspezifikation mehrfach angewen det 5 3 1 Prozessmuster 5 1 Integration der Anforderungsspezifikation zugriffssicherer Systeme in den Softwarelebenszyklus Kurzbeschreibung Mit dem Begriff des Softwarelebenszyklus engl Software Life Cycle verbindet man nach die Vorstellung einer Zeitspanne in der ein Softwareprodukt entwickelt und einge setzt wird bis zum Ende seiner Benutzung Damit verbindet man die Strukturierung dieses Zeitraums in Phasen Nach kann diese Einteilung in Phasen auch beim Einsatz ob jektorientierter Techniken erhalten bleiben Der in dieser Arbeit entworfene Pr
325. rozesse zur Entwicklung von zugriffssicheren Systemen m ssen so gestaltet werden dass Ent wickler bei allen ihren Aktivit ten zur Modellierung der Funktionalit t des Systems Aspekte der Zugriffssicherheit betrachten m ssen So kann gew hrleistet werden dass alle Teile des Systems einer Sicherheitsanalyse unterzogen werden und Ma nahmen zur Abwehr eingef hrt werden SPA4 Lokale Spezifikation der Sicherheit Wie in den vorab vorgestellten existierenden Methoden zur Entwicklung zugriffssicherer Syste me gezeigt wurde werden in den vorgestellten Ans tzen Aspekte der Zugriffssicherheit eines Systems in seinen fr hen Phasen immer in seiner Gesamtheit betrachtet So wird etwa im pha senstrukturierten Modell vor dem Grobentwurf eine Bedrohungs und Risikoanalyse f r das gesamte System durchgef hrt und daraus eine Sicherheitsstrategie und ein Sicherheitsmodell entwickelt Auch beim SEC Vorgehen wird im Rahmen der System Anforderungsanalyse eine globale Bedrohungs und Risikoanalyse f r das System durchgef hrt Obwohl bereits die Sy steme in funktionale Anforderungen zerlegt sind beginnt die Sicherheitsanalyse wieder bei der Gesamtheit des Systems Um sicherzustellen dass Systemteile in einer Sicherheitsbetrachtung 5 2 Prozessanforderungen an die Entwicklung zugriffssicherer Systeme 69 nicht tibersehen und alle funktionellen Anforderungen auch beziiglich der Sicherheit unter sucht werden sind Anforderungen an die Zugriffssicherheit be
326. rozessmuster 7 1 Prozessmuster 5 3 N VV Analyse Sicherheits zugriffssicherer E mikroprozess Prozessmuster 8 1 Prozessmuster 5 3 A Abbildung 5 7 Der Prozess der Anforderungsspezifikation zugriffssicherer Systeme Dadurch dass der Sicherheitsmikroprozess in jedem Prozessabschnitt mehrfach ausgef hrt werden kann wird eine iterative Entwicklung der Anforderungen an die Zugriffssicherheit erm glicht Der Sicherheitsmikroprozess kann in jedem Prozessabschnitt so oft wiederholt bis sich beim Ausf hren des Sicherheitsmikroprozesses keine nderungen an den Sicherheits aspekten f r die jeweilige Stufe der Modellierung ergeben d h dass bez glich Funktionalit t Sicherheit und Struktur ein lokal station rer Zustand erreicht wird In der darauf folgenden Modellierung treten durch Verfeinerung neue funktionale und sicherheitsspezifische Aspek te auf sodass weitere Iterationen mithilfe des Sicherheitsmikroprozesses notwendig werden Eine Ausnahme stellt hier nur die Analysemodellierung dar denn nach deren Abarbeitung m ssen alle funktionalen und sicherheitsspezifischen Anforderungen integriert sein sodass anschlie end mit dem Design fortgefahren werden kann Vor und Nachteile Durch das vorgestellte Vorgehen wird eine iterative Entwicklung von Funktionalit t und Aspekten der Zugriffssicherheit erm glicht in der Sicherheitsaspekte durchg ngig und sukzes sive von Anfang an d h ab
327. rukturellen Beschreibungstechnik erl utert Detaillierte Protokolle und techni sche Einzelheiten sind im Rahmen der Analyse zugriffssicherer Systeme vgl Kapitel 8 und des Designs festzulegen In Abbildung 7 9 sind die zus tzlichen Sicherheitsanwendungsf lle zu unserer TimeTool Fallstudie dargestellt 7 4 Evolution von Berechtigungen In der Gesch ftsprozessmodellierung zugriffssicherer Systeme haben wir bereits Zugriffsrech te auf die Objekte des Dom nenmodells sowie Ausf hrungsrechte auf Aktivit ten der Ge sch ftsprozesse spezifiziert Innerhalb der Sicherheitsanwendungsf lle wird das Dom nenmo dell verfeinert und die Aktivit ten in Anwendungsf llen spezifiziert Auf die damit verbundene Verfeinerung der Benutzerrechte gehen wir in Abschnitt 7 4 1lein Verschl sselung Beweissicherung Q Authentifikation ZT MT Rechteverwaltung AN Administrator AN Team Worker O Autorisierung Project Manager Abbildung 7 9 Sicherheitsanwendungsf lle der TimeTool Fallstudie 158 Die Anwendungsfallmodellierung zugriffssicherer Systeme Durch die Spezifikation der Abl ufe in Anwendungsf llen wird es m glich die Ausf hrungs rechte auf Aktivit ten aus den Zugriffsrechten zu berechnen In Abschnitt 7 4 2lbetrachten wir die Rahmenbedingungen und die Berechnung von Ausf hrungsrechten aus Zugriffsrechten 7 4 1 Verfeinerung der Benutzerrechte Die Benutzerrechte auf Klassen des Dom nenmodells und Akti
328. rungen in der Planung sind kost spielig und schwer zu bewerkstelligen da die R ckkopplung aus der Implementierungsphase erst sehr sp t erfolgt Rau0l Ende der 80er Jahre hat Barry Boehm in seinem Spiralmodell die Erkenntnis um gesetzt dass es einen ganz nat rlichen nicht umgehbaren Wandel bei der Planung und den Anforderungen gibt Das Spiralmodell ist war immer noch rein sequenziell jedoch beinhaltet es eine iterative Planung mit integrierter Risikoanalyse Das Spiralmodell eignet sich nach PB96 gut f r die Einbettung von Qualit tssicherungsma nahmen in den Softwareentwick lungsprozess Fehler k nnen fr h erkannt und verschiedene L sungsm glichkeiten k nnen mit vertretbarem Aufwand betrachtet werden Diese und weitere strukturierte Vorgehensweisen sind ausgehend von der strukturierten Pro grammierung entstanden und als die erste Generation von Methoden zur Softwareentwick lung von gro er Bedeutung siehe Bal96 Im Vordergrund stehen dabei die ablaufbezogene Funktionsmodellierung und die unabh ngige Entwicklung eines globalen Datenmodells In ei nem eigenen Arbeitsschritt werden Funktions und Datenmodell aufeinander abgestimmt Bei diesen Top Down Verfahren d h bei Entwicklungen von umfassenden abstrakten Modellen hin zu programmiersprachlichen Realisierungen ist der bergang zwischen Modellebenen oft mit Modellbr chen verbunden vgl RP97 Die Top Down Vorgehensweise und die Modell br che haben in strukturiert
329. rungsspezifikation zugriffssicherer Systeme die Produktartefakte sukzessive erstellt Das Vorgehen ist auf eine sukzessive Entwicklung ausgerichtet Auf Details der sukzessiven Entwicklung gehen wir auch innerhalb der detaillierten Betrachtung der Teilphasen in den Kapiteln 6 bis 8 ein Gemeinsame Entwicklung von Funktion und Sicherheit SPA3 Innerhalb aller Prozessabschnitte der Anforderungsspezifikation zugriffssicherer Systeme steht die gemeinsame Entwicklung von Funktion und Aspekten der Zugriffssicherheit im Vorder grund Wie bereits skizziert wurde und detailliert in den Kapiteln 6lbis 8 beschrieben ist findet beispielsweise innerhalb der Gesch ftsprozessmodellierung neben der funktionalen und struk turellen Spezifikation auch eine Modellierung des Zugriffs auf Datenobjekte des Dom nen modells und auf Flussobjekte statt Die Anwendungsf lle werden ebenfalls mit Aspekten der Zugriffssicherheit angereichert und in der Analyse finden wir bei den Interaktionen Nachrich ten zur Abdeckung der Zugriffssicherheit Weiterhin wird die gemeinsame Entwicklung von Funktion und Sicherheit auch durch den eingef hrten Sicherheitsmikroprozess unterst tzt denn beliebig gro e funktionelle Einheiten k nnen in einer Iteration des Sicherheitsmikropro zesses mit Aspekten der Zugriffssicherheit angereichert werden Lokale Spezifikation der Sicherheit SPA4 Bei den Anforderungen zum Sicherheitsmikroprozess haben wir uns weiterhin f r eine lokale Sp
330. rungsspezifikation zugriffssiche rer Systeme wird eine durchgehende Sicherheitsanalyse gefordert Insbesondere wird durch den vorgestellten Prozess die geforderte sukzessive Entwicklung erreicht da die Ergebnisse aus der Anwendungsfallmodellierung zugriffssicherer Systeme in die Analyse zugriffssicherer Systeme einfliesen und dabei verfeinert und erg nzt werden Wie bereits im Dom nenmodell bleibt das Klassendiagramm der Analyse frei von Benutzer rechten Hierzu werden Zugriffs und Ausfiihrungsrechte im Benutzerrechtemodell in einer Benutzerrechtematrix spezifiziert In dieser Benutzerrechtematrix k nnen sowohl Zugriffs als auch Ausf hrungsrechte einheitlich dargestellt werden Das Prozessmuster zur Analyse zugriffssicherer Systeme bietet wie bereits erw hnt eine Vielzahl von Iterationsm glichkeiten vgl Struktur des Prozessmusters Besonders f r gro e Systeme spielt die iterative Entwicklung eine bedeutende Rolle Eine entscheidende Rolle spielt dabei die Tatsache dass die Entwicklung der Sicherheitsaspekte nicht in den Hinter grund treten darf d h dass Sicherheitsaspekte in einer eigenen Iteration am Ende isoliert ermittelt werden Bei den vorgestellten Iterationsm glichkeiten kann das System in kleineren Inkrementen entwickelt werden Sicherheitsaspekte sind dabei in jeder Iteration durchgehend zu ermitteln da diese an die funktionale Entwicklung gebunden sind Wie bereits bei den vorausgehenden beiden Schritten der Anforderun
331. s Anforderungen A1 und A2 im Abschnitt zur Beschreibung der Sicherheitsan forderungen aufgenommen Die Anforderung A3 wurde bei der Erarbeitung des Anwendungs falls erkannt und aufgenommen Bei der Modellierung der Bedrohungen und Risiken in der Gesch ftsprozessmodellierung zugriffssicherer Systeme in Abschnitt wurde festgelegt 156 Die Anwendungsfallmodellierung zugriffssicherer Systeme Anwendungsfall Korrekturbuchung Beschreibung aus Abbildung 7 1 Sicherheit Al Das System muss die Eingabedaten vertraulich behandeln und die Integrit t muss gew hrleistet werden A2 Der Projektmitarbeiter kann den Anwendungsfall nur ausf hren wenn er im Sy stem authentifiziert ist Vor der Ausf hrung des Anwendungsfalls Korrekturbu chung wird die Autorisierung berpr ft A3 Der Web Browser und das TimeTool System m ssen sich Beginn der Transaktionen authentifizieren A4 Korrekturbuchungen werden vom System in einer Klasse Logging mitprotokolliert Varianten 4 Ist ein Projektmitarbeiter im System nicht authentifiziert so kann er den An wendungsfall Korrekturbuchung nicht ausf hren Schl gt die Autorisierung fehl informiert das System den Benutzer ber die fehlenden Benutzerrechte und bricht mit einer negativen Best tigung ab 5 Schl gt die Authentifikation des Web Browsers am TimeTool System fehl wird eine Fehlermeldung zur ckgegeben und der Anwendungsfall bricht mit einer negativen Best tigung ab Abbildung
332. s Benutzerrechtemodells im Kontext einer objektorientierten anwendungsfallbasierten Entwicklung der Anforderungsspe Benutzerrechtemodell Spezifikation der Benutzerrechte f r Struktur und Verhalten Sicherheits mikroprozess Prozessmuster 5 3 Gesch ftsprozessmodel lierung sicherer Systeme Prozessmuster 6 1 Verfeinerung in pr dikativ spezifizierte Benutzerrechte Sicherheits a mikroprozess lierung sicherer Systeme Erweiterung der informellen is 5 3 Prozessmuster 7 1 en En Struktur Verfeinerung in pr dikativ andlVerhalten spezifizierte Benutzerrechte Vervollst ndigung des informellen Benutzerrechtemodells des vollst ndigen pr dikativen Benutzerrechtemodells 4 4 Sicherheits Analyse sicherer mikroprozess Systeme Prozessmuster 5 3 Prozessmuster 8 1 Abbildung 4 8 Modellierung der Benutzerrechte innerhalb der Anforderungsspezifikation Entwicklung und mse 4 9 Zusammenfassung 51 zifikation Die einzelnen Aktivit ten sind detailliert in den Kapiteln zur Gesch ftsprozessmo dellierung Kapitell6 zur Anwendungsfallmodellierung Kapitel 7 und zur Analyse Kapitel zugriffssicherer Systeme beschrieben Wie in Abbildung 4 1 gezeigt wurde erstreckt sich die Modellierung ber alle drei Prozessab schnitte und die zun chst informale Spezifikation wird schrittweise in eine pr gna
333. s in diesem Fall keine Daten speichern Es wird eine positive Best tigung an den Akteur zur ckgegeben 3 Der Akteur Team Worker gibt ung ltige Werte falscher Datentyp berschrei tung der Minimum oder Maximumgrenzen falsche Datumsangaben etc ein Das System informiert den Benutzer dar ber und wartet auf neue Eingaben Abbildung 7 1 Beispiel eines Anwendungsfalls Korrekturbuchung adjustment posting 7 1 3 Produktartefakte der Anwendungsfallmodellierung Die zentralen Produktartefakte der Anwendungsfallmodellierung sind e das Anwendungsfallmodell in dem die Systemanforderungen strukturell und grafisch beschrieben werden und e das erweiterte Dom nenmodell welches die statischen Konzepte beschreibt Im Anwendungsfallmodell werden die Anforderungen an das System in folgender Weise be schrieben e Die funktionalen Anforderungen werden aus den einzelnen Aktivit ten der Ablaufdia gramme der Gesch ftsprozessmodellierung abgeleitet und in Anwendungsf llen struk turell beschrieben Zu jedem Anwendungsfall ist der Name des Anwendungsfalls die Ein und Ausgabedaten die zu modifizierten Klassen des statischen Anwendungskerns Dom nenmodell eine Ablaufbeschreibung sowie eine Beschreibung der Ablaufvarian ten textuell zu spezifizieren 146 Die Anwendungsfallmodellierung zugriffssicherer Systeme ProjectInformation Project description String name String budget Real
334. s zur Entwicklung von Anforderungsspezifikationen men oder eine bottom up gerichtete Failure Modes and Effects Analysis Die optimale Analyse stellt eine Kombination aus beiden Ans tzen dar F r das Requirements Engineering f hrt Anderson Grunds tze an die bei der Entwicklung zu betrachten sind e F r diese Aktivit ten sind Entwickler mit speziellen F higkeiten notwendig oder es m ssen Experten hinzugezogen werden Sicherheitsaspekte sind innerhalb der funktionalen Anforderungen und der Testdoku mentation zu betrachten denn eine externe Betrachtung der Sicherheit in allein ste henden und isolierten Dokumenten f hrt dazu dass diese Dokumente w hrend der Sys tementwicklung vernachl ssigt oder beiseite gelegt werden Dies f hrt letztendlich dazu dass Sicherheitsaspekte nicht weiter verfolgt werden Sicherheitsaspekte m ssen in die gesamte Systementwicklung integriert werden Eine nachtr gliche Entwicklung der Zugriffssicherheit funktioniert nicht und f hrt nicht zur Erf llung der Sicherheitsanforderungen Bedrohungen sind auch nach Abschluss einer Bedrohungsanalyse weiter zu betrachten gegebenenfalls in weiteren Iterationen Erfahrungen haben gezeigt dass Anforderungen zum Schutz des Systems nicht in einer einzigen Phase richtig und vollst ndig analysiert werden k nnen Nach ist in der Anforderungsanalyse eine iterative Vorgehensweise nach dem Spiral modell sinnvoll da hierbei die Anforderungen an die Sicherheit s
335. s zus tzlichen Statusattributs innerhalb der Klasse Activity einer anschlie enden Manipulation entgegen Voraussetzung ist hier ebenfalls dass Benut zer diesen Status nicht ndern k nnen was bei der weiteren Modellierung der Abl ufe und Benutzerrechte zu beachten ist 6 5 Produktartefakte der Gesch ftsprozessmodellierung zugriffssicherer Systeme Im Abschnitt wurden die Produktartefakte der allgemeinen Gesch ftsprozessmodellie rung vorgestellt Im Rahmen der Gesch ftsprozessmodellierung zugriffssicherer Systeme wer den diese Produktartefakte mit Aspekten der Zugriffssicherheit angereichert und zus tzliche Produktartefakte so genannte Sicherheitsdokumente werden hinzugef gt Beziehungen zur Erweiterung der Produktartefakte Allgemein sprechen wir hier von einer Erweiterung der Produktartefakte Bei einer genaueren Untersuchung der Beziehungen l sst sich diese Erweiterung genauer klassifizieren extends KI erweitert verwendet angeordnet I hinzugef gt Abbildung 6 33 Beziehungen bei der Erweiterung der Produktartefakte Wir k nnen die in Abbildung 6 33 gezeigten vier Beziehungstypen zwischen Produktartefakten der allgemeinen Modellierung und der Modellierung zugriffssicherer Systeme als Verfeinerung der allgemeinen extends Beziehung feststellen Die verfeinerten Beziehungen haben folgende Bedeutung erweitert Produktartefakte der allgemeinen Modellierung werden erw
336. sabschnitte zur Gesch ftsprozessmodellierung zur Anwendungsfallmodellierung und zur Analyse zugriffssicherer Systeme unterteilt In allen Abschnitten werden Aspekte der Zugriffssicherheit herausgearbeitet und analysiert Ab dem Abschnitt der Gesch ftsprozessmodellierung in der Gesch ftsprozesse zur Modellierung von Unternehmensabl ufen in Teilaufgaben zerlegt werden werden bereits Sicherheitsaspekte aus gearbeitet So werden beispielsweise im Dom nenmodell Schutzziele angegeben oder im Ak tivit tsdiagramm die Anforderungen der Zugriffssicherheit an die zu bermittelnden Daten objekte spezifiziert In der Anwendungsfallmodellierung in der ausgehend von Akteuren das Verhalten welches in der Gesch ftsprozessmodellierung spezifiziert wurde in Teilaufgaben zerlegt und detail liert analysiert wird werden die bereits erarbeiteten Sicherheitsziele wieder aufgegriffen und hieraus Anwendungsf lle erarbeitet und beschrieben Die Sicherheitsanforderungen der lo kal betrachteten Funktionalit t d h des funktional modellierten Teils des Anwendungsfalls werden hier neben den funktionalen Anforderungen im Anwendungsfall schrittweise erarbei tet und beschrieben Das mit Sicherheitsaspekten bereits angereicherte Dom nenmodell aus der Gesch ftsprozessmodellierung wird verfeinert und die Zugriffsrechte auf die Daten und Flussobjekte werden innerhalb einer Zugriffsmatrix spezifiziert und pr dikativ formalisiert In der Analyse zugriffssicherer Syst
337. samten Entwicklungsprozesses Grundidee des Prozessmuster basierten Ansatz zur Beschreibung von Vorg ngen ist die Be schreibung einzelner Prozessbausteine in so genannten Mustern Amb99 Weiterhin sind Prozessmuster ein m chtiges Konzept zur dynamischen Anpassung des Pro zessablaufs bei der System und Softwareentwicklung siehe hierzu GMP 03b F r eine bessere Verst ndlichkeit und Vergleichbarkeit werden Prozessmuster wie alle ande ren Muster in einer einheitlichen Form pr sentiert Rau01 Eine intuitive Beschreibungsform hilft die Essenz des Musters schnell aufzunehmen Dar ber hinaus liefert eine gute Beschrei bung auch alle Fakten die notwendig sind um ein Muster anzuwenden sowie die Konsequen zen die sich aus der Anwendung ergeben Weiterhin wird durch die Darstellung in Mustern 14 Grundlagen Tabelle 2 1 Vorlage fiir die Beschreibung von Prozessmustern Abschnitt Beschreibung des Abschnittsinhalts Name Kurzbeschreibung Problem L sung Aktivit ten Produktartefakte Struktur Kontext Vor und Nachteile In Beziehung stehende Muster Name des Prozessmusters Kurze Zusammenfassung der Motivation Ziele und des Hinter grunds des Prozessmusters Das zentrale Problem wird knapp umrissen Die Entwicklungsaufgabe und oder das Problem welches das Prozessmuster adressiert wird detailliert erkl rt und gegebe nenfalls werden weitere Einflussfaktoren diskutiert Der grundlege
338. schnitt 5 3 2 basierend auf einem objektorientierten Vorgehensmodell aus gef hrt werden Der Fokus dieser Gesch ftsprozessmodellierung zugriffssicherer Systeme liegt auf einer Neuentwicklung eines Systems Aktivit ten zur Analyse bestehender Systeme sind kein Bestandteil dieses Prozessmusters Neben den Entwicklungsschritten sind auch projekt bergreifend Managementaufgaben durch zuf hren auf die jedoch im Rahmen dieser Arbeit nicht n her eingegangen wird Struktur Innerhalb der L sung wurde bereits der Ablauf der Gesch ftsprozessmodellierung zugriffssi cherer Systeme skizziert Im Aktivit tsdiagramm in Abbildung 6 31list der verfeinerte Ablauf dargestellt Zudem sind auch m gliche Iterationsm glichkeiten mit aufgenommen worden Einzelne Gesch ftsprozesse oder Teile des Dom nenmodells k nnen separat entwickelt und dabei sofort mit Schutzzielen annotiert werden F r diese inkrementelle Erarbeitung der Gesch ftsprozesse und objekte wurde im Ablauf zur Gesch ftsprozessmodellierung zugriffs sicherer Systeme eine Iterationsm glichkeit eingef gt 6 4 Der Prozess der Gesch ftsprozessmodellierung zugriffssicherer Systeme 129 Untersuchung der Prozess automatisierung Identifikation der Gesch ftsprozesse Dom nen modellierung Spezifikation der Schutzziele im Dom nenmodell Verfeinerung der Gesch ftsprozesse Gesch ftsprozess l sungen entwerfen Verfeinerung von Rollen u
339. schnitten der Anforderungsspezifikation zugriffssicherer Systeme verfeinert werden Aktivit ten Bei der Prozessausf hrung der Gesch ftsprozessmodellierung zugriffssicherer Systeme sind die folgenden Aktivit ten nach der in der L sung und in der Struktur skizzierten Vorgehens weise auszuf hren Zur Vollst ndigkeit wurden bei den Aktivit ten auch die Aktivit ten der allgemeinen Gesch ftsprozessmodellierung aufgenommen und kurz umrissen 126 Die Gesch ftsprozessmodellierung zugriffssicherer Systeme Identifikation der Gesch ftsprozesse Gemeinsam im Team aus Auftraggeber Auftragnehmer Anforderungsentwickler und Anwender werden die Grenzen der zu beschreibenden Organisation Unternehmung oder Abteilung erarbeitet Nach der Festlegung der Terminologie werden die Gesch ftspro zesse skizziert und priorisiert Verfeinerung der Gesch ftsprozesse Die skizzierten Gesch ftsprozesse werden ausgearbeitet und einem Review unterzogen In diesem Review sind erneut Vertreter der Anforderungsentwickler Auftraggeber Auf tragnehmer und Anwender beteiligt Im Review wird gepr ft inwiefern die spezifizierten Gesch ftsprozesse den Abl ufen der Organisation bzw Unternehmung entsprechen Gesch ftsprozessl sungen entwerfen F r eine genaue Festlegung der Gesch ftsprozesse sind die beteiligten Rollen die zu erstellenden Produkte Software Hardware die Auslieferungen und alle potenziellen Vorf lle der zu modellierenden Unternehmun
340. sfunktionen sind Hilfsfunktionen die wie P MOS Ausdr cke eine Navigation in einer gegebenen Objektstruktur in Abh ngigkeit von Parametern be schreiben Im Unterschied zu den Funktionen der Datentypen sind Zustandsfunktionen damit abh ngig vom Zustand der Objekte Sind nun funct f T T T eine Zustandsfunktion wobei T1 Tn T entweder Basis typen oder Klassen sind und e1 n P MOS Ausdr cke der Typen T71 7 dann ist f e1 en ein P MOS Ausdruck vom Typ T Eine Zustandsfunktion beschreibt eine auf n Parametern basierende generische Navigation in einer gegebenen Objektstruktur Sie liefert ein Ergebnis vom Typ T als Basistyp oder Ob jektreferenz Eigenschaften von Zustandsfunktionen werden durch P MOS Pr dikate definiert siehe hierzu Abschnitt 4 3 2 Abfrageoperationen in Klassendiagrammen beinhalten auch Zustandsfunktionen F r jede Abfrageoperation f amp 1 T1 n Tn T in Klasse C definieren wir eine Zustandsfunktion funct f C T T T und schreiben Ausdr cke f e e1 en als e f e1 en in der gewohnten Weise Beispiel Im Kontext des Klassendiagramms accountin User i Accounting definieren wir eine Zustandsfunktion welche die Umkehrrichtung der Assoziation beschreibt funct inhaber Accounting User 4 4 Formale Modellierung von Benutzerrechten 39 Die Form der Pradikate vorwegnehmend wird die Zustandsfunktion inhaber im Beispiel durch d
341. siehe Bre01 JBR99 Da innerhalb der Gesch ftsprozess und Anwendungsfallmodellierung noch keine Vorgangsklassen bestimmt wurden sind die Klassen des Anwendungskerns in Fachklassen und Interaktionsklassen aufzuteilen Dieses Klassendia gramm der Analyse wird bei der Realisierung der Anwendungsf lle erg nzt Bereits ermittelte Schnittstellen zu externen Systemen werden im Klassendiagramm durch Interaktionsklassen erg nzt Datentypen f r die Ein und Ausgaben zu Anwendungsf llen die im Rahmen der Anwendungsfallmodellierung ermittelt wurden werden als Fachklassen in das Analyseklas sendiagramm transformiert Nach der Verfeinerung des Dom nenmodells ist die Realisierung der Anwendungsf lle in so genannten Szenarien zu erarbeiten Dazu sind die Klassen zwischen denen die Interaktionen des Anwendungsfalls stattfinden aus den Anwendungsfallbeschreibungen und dem Analyse klassenmodell zu ermitteln Falls diese Klassen noch kein Bestandteil des Analyseklassendia gramms sind sind sie zu erg nzen Aus der Ablaufbeschreibung der Anwendungsf lle sind die Interaktionen zu bestimmen Falls eine Beschreibung eines Ablaufs im Anwendungsfall zu ungenau ist muss vorab der Fluss der Ereignisse textuell verfeinert werden F r jeden internen Akteur als auch f r die externen Akteure wie zum Beispiel externe Systeme sind Interaktionsklassen zum Klassenmodell hinzuzuf gen Weiterhin ist f r jeden Anwendungsfall eine Vorgangsklasse welche den Ablauf re
342. slich von Implementierungsaspekten ist die formale Spezifikation zur Anwendung aus dem formalen Rahmenwerk in eine Spezifikationssprache im Kontext einer grafischen Be schreibungssprache wie beispielsweise UML zu transformieren Wir zeigen im Folgenden die Realisierung unserer Konzepte in der Object Constraint Lan guage OCL OMG03 welche Bestandteil der grafischen Beschreibungssprache UML ist Wir erweitern hierzu den Spezifikationsabschnitt einer Methode f r Vor und Nachbedin gungen um einen zus tzlichen Berechtigungsabschnitt engl permission section Darin be schreiben wir die Benutzerberechtigungen durch einen OCL Ausdruck unter Verwendung der Variablen der Methode des aktuellen Objekts und des aktuellen Akteurs der ebenfalls wie ein Parameter behandelt wird W hrend Vor und Nachbedingungen mehr ein Konstrukt des Entwurfs f r die abstrakte Sicht auf Klassen und Operationen sind ist ein Design und eine Implementierung dahin gerichtet dass diese Bedingungen a priori eingehalten werden und somit zumeist zu true evaluieren Hingegen trifft diese Annahme f r Berechtigungsspezifikationen unseres Ansatzes nicht immer zu In vielen F llen versuchen Benutzer die nicht die notwendigen Benutzerrechte besitzen gesch tzte Operationen auszuf hren Die Benutzerrechtespezifikationen unterscheiden sich von Vor und Nachbedingungen darin dass sie einen berechneten boolschen Wert zur ckgeben Wird false zur ckgegeben schl gt eine weit
343. smikroprozess siehe Abschnitt 5 3 3 Weitere referenzierte Prozessmuster e Prozessmuster zur Gesch ftsprozessmodellierung zugriffssicherer Systeme siehe Ab schnitt 6 4 1 e Prozessmuster zur Analyse zugriffssicherer Systeme siehe Abschnitt 8 4 1 7 5 2 Anwendung des Sicherheitsmikroprozesses Bei der Beschreibung des Prozessmusters zur Anwendungsfallmodellierung zugriffssicherer Sy steme haben wir bereits mehrfach die wiederholte Ausf hrung des Sicherheitsmikroprozesses erw hnt Wir fassen hier nochmals kurz zusammen von welchen nderungen und Weiter entwicklungen der Modelle die erneute Anwendung des Sicherheitsmikroprozesses getrieben wird Folgende nderungen am Dom nenmodell sind bei der Ausf hrung des Mikroprozesses zu beachten e Festlegung der zu automatisierbaren Gesch ftsprozesse und Definition der Gesamtfunk tionalit t des zu entwickelnden Systems Durch diese Festlegung sind im Klassendia gramm Klassen Attribute und Assoziationen f r die Kommunikation mit angrenzenden Systemen einzuf hren und berfl ssige Klassen Attribute und Assoziationen die auf grund der Festlegung der Systemgrenzen nicht mehr notwendig sind zu entfernen Die verbleibenden Assoziationen sind an die neue Struktur anzupassen e Definition der Anwendungsf lle Die bei der Spezifikation der Anwendungsf lle ermittel ten Ein und Ausgabedaten sowie Modifikationen an den Klassen des Anwendungskerns sind im Dom nenmodell zu integrier
344. smodell auf der Grundlage eines objektorientierten System und Vorgehensmodells zur Neuentwicklung von zugriffssiche ren Informationssystemen beschrieben Basierend auf einem ausf hrlichen Literaturvergleich von bestehenden Methoden zur Entwicklung sicherer Systeme werden Prozessanforderungen abgeleitet Ausgehend von einer Projektidee und einem bergeordneten abstrakten Sicherheitsziel wer den in der Gesch ftsprozessmodellierung in der Anwendungsfallmodellierung und in der Ana lyse Aspekte der Zugriffssicherheit durchg ngig sukzessiv und iterativ erarbeitet Es wird gezeigt wie die Modellierung der Zugriffssicherheit in bestehende Modellierungsaktivit ten einzubetten ist und welche Ein und Ausgaben in Form von Produktartefakten insbesondere f r die sukzessive Modellierung der Sicherheit in den einzelnen Teilschritten notwendig sind Besondere Betrachtung findet die Beschreibung der Benutzerrechte Zu Beginn werden die se innerhalb der Gesch ftsprozessmodellierung f r Daten und Aktivit ten textuell in einer Matrix beschrieben und in der Anwendungsfallmodellierung sowie der Analyse verfeinert und erg nzt Diese textuell spezifizierten Zugriffsbeschr nkungen werden im Laufe der Anforde rungsspezifikation formalisiert Mit dieser implementierungsunabh ngigen Beschreibung bei 6 Einf hrung der das Dom nenmodell sowie die Ablaufbeschreibungen frei von Benutzerrechtsspezifikatio nen sind wird die Komplexit t dieser Beschreib
345. software engl malware bezeichnet Die beabsichtigte b swillige Funktionalit t in Schadsoftware unterscheidet sich vom Fehlverhalten aus unbeabsichtigten Programmierfehlern engl bugs Ein Computervirus ist eine Befehlsfolge die zur Ausf hrung ein Wirtsprogramm ben tigt Bei der Ausf hrung eines Virus wird eine Kopie Reproduktion oder eine modifizierte Ver sion des Virus in einen Speicherbereich geschrieben Infektion Zus tzlich zur F higkeit der Reproduktion enthalten Viren in der Regel einen Schadanteil der bedingt oder unbedingt durch einen Ausl ser aktiviert werden kann Viren k nnen in Programm Boot Makro und Datenviren unterteilt werden Ma nahmen gegen den Angriff von Computerviren sind beispielsweisedie Anwendung von Virenscanner die Beschr nkung der Benutzerrechte eines Rechners das Verschl sseln von Programmen und Daten sowie der Einsatz von Hashfunktio nen zur berpr fung von Manipulationen Ein Wurm ist ein ablauff higes Programm mit der F higkeit der Reproduktion Ein Pro gramm eines Wurms besteht in der Regel aus mehreren Programmteilen den Wurmsegmen ten Die Vervielf ltigung erfolgt selbstst ndig unter Kommunikation mit anderen Wurmseg menten W rmer bedrohen die Integrit t und Vertraulichkeit sowie die Verf gbarkeit von Rechnern W rmer beanspruchen zumeist viele Ressourcen insbesondere eine hohe Netzlast W rmer nutzen zur Verbreitung L cken im System und in der Anwendungssoftware Das Ei
346. ss die Modellierung von Aspekten der Sicherheit gemeinsam mit der funktionalen Modellierung inklusive der Daten modellierung zu erfolgen hat Die in den Abschnitten bis vorgestellten Vorge hensmodelle vgl hierzu Tabelle betrachten kaum Aspekte einer iterativen Entwicklung und gehen gr tenteils auch auf Produktartefakte die w hrend der Entwicklung zu erstellen sind nicht ein Derzeit wird die Sicherheit immer in ihrer Gesamtheit betrachtet d h eine Zerlegung der Sicherheitsaspekte findet nicht wie bei der funktionalen Ausarbeitung statt Sicherheit innerhalb der Gesch ftsprozessanalyse ist weder in den ausf hrlich beschriebenen Vorgehensmodellen noch in den weiteren Vorgehensbeschreibungen enthalten Die neueren Vorgehensbeschreibungen vgl Tabelle 5 2 spezifizieren die Sicherheit lokal d h ebenso wie bei der Funktionsmodellierung wird die Sicherheit nicht als Ganzes sondern als atomare Einheiten analysiert Es werden neben den Prozessaktivit ten auch die Produktartefakte die als Ein und Ausgabeparameter f r die Prozessaktivit ten dienen mitbetrachtet und iterative Aspekte sind ebenfalls Bestandteil dieser Betrachtungen 5 3 Das Vorgehen Da unser Fokus in dieser Arbeit auf der Integration von Aspekten der Zugriffssicherheit in den fr hen Phasen der Systementwicklung und nicht auf der Entwicklung eines eigenen gesamten Prozesses liegt zeigen wir im Folgenden wie die Aktivit ten zur Entwicklung zugriffssicherer 72 Ein P
347. ss ein Mitarbeiter in einem Betrieb gewisse Unterlagen bei Verlassen des B ros in seinem Schreibtisch einsperrt bei der Umsetzung in einen automatisierten und computergest tzten Ablauf eine entscheidende Rolle Diese Daten sich auch im System vor anderen Anwendern zu sch tzen Der vorgestellte Prozess der Anforderungsspezifikation zugriffssicherer Systeme enth lt einen Prozessabschnitt zur Gesch ftsprozessmodellierung um derartige Aspekte zu kl ren 5 6 Zusammenfassung 89 5 6 Zusammenfassung Wie schon mehrfach erw hnt wurde ist ein Ziel der Entwicklung zugriffssicherer Software die durchg ngige und sukzessive Betrachtung von Aspekten der Zugriffssicherheit insbeson dere in der fr hen Phase der Anforderungsspezifikation Derzeit existieren einige Ans tze zum Security Engineering die eine fr he Modellierung von Aspekten der Zugriffssicherheit unterst tzen und diese durchg ngig und sukzessive erarbeiten Die Ermittlung der Anforde rungen an zugriffssichere Systeme beginnt bei diesen Ans tzen entweder nach der Festlegung der funktionalen Anforderungen oder nach der Erstellung eines Pflichtenhefts siehe Abschnitt 5 1 Sicherheit wird dabei zumeist ganzheitlich neben der Funktionalit t modelliert d h es wird eine eigenst ndige Aufteilung des Systems zur Ermittlung der Sicherheitsanforderungen durchgef hrt Eine Modellierung von Aspekten der Zugriffssicherheit bei der lokalen Modellie rung der Funktionalit t in kleinen Einhe
348. ssabschnitten das in Kapitel 4 eingef hrte Modell zur Beschreibung von Benutzerrechten angewendet 6 Die Gesch ftsprozessmodellierung zugriffssicherer Systeme Die fr he Modellierung von Sicherheit haben wir bereits in den vorausgehenden Kapiteln motiviert Im Prozessmuster zur Anforderungsspezifikation zugriffssicherer Systeme wurde hierf r eine Aufteilung der Anforderungsdefinition in drei Prozessabschnitte vorgestellt In diesem Kapitel gehen wir detailliert auf den ersten Prozessabschnitt der Anforderungsspe zifikation zugriffssicherer Systeme ein auf die Gesch ftsprozessmodellierung zugriffssicherer Systeme Gesch ftsprozesse sind allgemein betriebliche Prozesse die zur Erstellung einer Unterneh mensleistung beitragen Die Gesch ftsprozessmodellierung besch ftigt sich neben der eigent lichen Modellierung von Ablaufprozessen und deren Beziehungen untereinander auch mit der Modellierung von Merkmalen wie beispielsweise Organisationseinheiten Ein und Ausga ben Ressourcen Informationen und Bedingungen Bei der Modellierung sind sowohl fachli che Experten aus dem zu modellierenden Unternehmen bzw der zu modellierenden Orga nisation vertreten als auch Anforderungsentwickler und Anwender Gemeinsam werden die Unternehmens bzw Organisationsprozesse mit ihren Merkmalen erarbeitet und automa tisierbare Teile identifiziert Ein berblick ber die Gesch ftsprozessmodellierung wird im Abschnitt gegeben Bei der heutzutage bli
349. ssausf hrung die folgenden Aktivit ten nach der in der L sung und in der Struktur skizzierten Vorgehensweise aus zuf hren Aus Gr nden der Vollst ndigkeit wurden bei den Aktivit ten auch diejenigen aus der allgemeinen Analyse mit aufgenommen und umrissen vgl Abschnitt 8 1 2 e Identifikation der Analyse Packages Analysepakete dienen zur Aufteilung des Analysemodells in kleinere und handhabbarere Einheiten Um die Analyse schrittweise durchf hren zu k nnen sind die Packages zu Beginn zu ermitteln Zur Umsetzung von Anwendungsf llen zu Sicherheitsgrundfunk tionen k nnen eigene Analyse Packages definiert werden Ein Analysepaket enth lt eine Menge von Anwendungsfallrealisierungen und die dazugeh rige Menge von Klassen des Analyseklassendiagramms e Identifikation der Fach und Interaktionsklassen Das Dom nenmodell ist in das Klassendiagramm der Analyse zu transformieren und dabei sind die Klassen in Fach und Interaktionsklassen einzuteilen Klassen des An wendungskerns sowie die bereits spezifizierten Ein und Ausgabetypen von Anwen dungsf llen werden zu Fachklassen die Schnittstellen zu externen Systemen hingegen zu Interaktionsklassen Klassen die zur Abwehr von Bedrohungen zum Dom nenmodell hinzugef gt wurden sind ebenfalls im Klassenmodell der Analyse zu verfeinern so zum Beispiel die Klasse Logging aus der Time Tool Fallstudie e Realisierung der Anwendungsf lle Die Anwendungsf lle aus der Anwendungsfallmodellierung
350. ssen Aktivit ten operieren ber und auf Objekten Sind Objekte die in einem Aktivit tsablauf ausgetauscht werden von besonderer Bedeutung k nnen diese auch in die Aktivit tsdia gramme mit aufgenommen werden vgl BRJ98 Hierzu f hren wir analog zu den Schutzziel Stereotypen f r Klassendiagramme Schutzziel Stereotypen auf Flussobjekten ein Abbildung 6 14 zeigt diese Schutzziel Stereotypen f r Flussobjekte in Form von den bereits vorgestellten Schutzziel Icons Semantisch haben diese Schutzziel Stereotypen dieselbe Bedeu tung wie die Schutzziele zu den Gesch ftsobjekten vgl Abschnitt 6 2 1 Innerhalb von UML Aktivit tsdiagrammen werden jedoch keine Klassen verwendet sondern konkrete Flussobjek te Jedoch hat dies auf die Definition der Schutzziel Stereotypen keinen Einfluss sodass die Schutzziel Stereotypen f r Klassendiagramme direkt auf die Flussobjekte bernommen wer 108 Die Geschaftsprozessmodellierung zugriffssicherer Systeme activity A 2 gt Object L gt activity B activity A 2 gt Object ate L 7 gt activity B activity A 4 3 gt Object N gt activity B Abbildung 6 14 Schutzziele in Flussobjekten den k nnen In Abbildung 6 14 sind die einzelnen Schutzziel Icons dargestellt Neben diesen einzelnen Schutzzielen ist eine Kombination der Schutzziele in einzelnen Objekten m glich Neben de
351. ssicherer Systeme anzupassen Aufgrund von der mittlerweile vorliegenden detaillierten Beschreibung von Sy stemanforderungen k nnen die Benutzerrechte pr ziser beschrieben werden So kann beispiels weise bei der Gesch ftsprozessmodellierung zugriffssicherer Systeme festgelegt werden dass ein Akteur A eine Aktivit t x ausf hren darf Aufgrund von detailliertem Hintergrundwissen 7 4 Evolution von Berechtigungen 159 kann das Benutzerrecht jedoch weiter eingeschr nkt werden so etwa auf einen bestimmten Zeitraum oder auf das Vorhandensein weiterer Objekte Da wir zu den Benutzerrechten wei tere Informationen hinzuf gen sprechen wir von einer Verfeinerung der Benutzerrechte 7 4 2 Spezifikation und berpr fung von Ausf hrungsrechten Zu Beginn der Entwicklung zugriffssicherer Systeme werden die Benutzerrechte auf Objekten des Dom nenmodells sowie Aktivit ten der Gesch ftsprozesse getrennt voneinander spezifi ziert vgl Kapitel 6 3 Da die Gesch ftsprozesse jedoch auf den Objekten des Dom nenmo dells operieren besteht zwischen den Spezifikationen der Benutzerrechte ein Zusammenhang Insbesondere k nnen durch diese getrennte Spezifikation der Benutzerrechte Inkonsistenzen entstehen Den Zusammenhang zwischen Zugriffsrechten d h Benutzerrechten auf Objekten des Dom nenmodells und Ausf hrungsrechten den Benutzerrechten auf Aktivit ten k nnen wir ber die Ablaufbeschreibungen der Anwendungsf lle herstellen Hinter An
352. ssicherer Systeme vor und geben einen kurzen berblick ber die Aktivit ten in den Prozessabschnitten und die Integration der Sicherheitsaspekte Die einzelnen Abschnitte der Anforderungsspezifikation werden sp ter in den Kapiteln 6 bis 8 der Arbeit detailliert erl utert Problem Damit die Zugriffssicherheit im erforderlichen Ma innerhalb der Entwicklung von zugriffssi cheren Systemen betrachtet wird ist es notwendig diese fr hzeitig durchg ngig und sukzes sive in den Entwicklungsprozess zu integrieren F r die Anforderungsspezifikation bedeutet 76 Ein Prozess zur Entwicklung von Anforderungsspezifikationen dies dass Sicherheitsaspekte des Systems bereits von Anfang an d h ab der Gesch ftspro zessanalyse betrachtet werden F r die durchg ngige und sukzessive Entwicklung ist es not wendig dass die in der Gesch ftsprozessanalyse erarbeiteten Ergebnisse in allen weiteren Prozessabschnitten der Anforderungsanalyse erg nzt und verfeinert sowie dass die in den jeweiligen Phasen erarbeiteten Ergebnisse in Form von Produktartefakten auch in sp teren Prozessabschnitten betrachtet und verwendet werden Ebenso ist in den fr hen Phasen darauf zu achten dass Sicherheit so weit wie m glich gemeinsam mit der Festlegung der funktionalen Anforderungen stattfindet und dass eine iterative Entwicklung die bei gr eren Entwicklungs projekten unabdingbar ist unterst tzt wird L sung Die Analysephase wird in die drei Prozes
353. st m ssen eigene Aktivit ten zur Pr fung der Authentifikation eingef hrt werden Bei den annotierten Aktivit ten ist ber eine Rechteabpr fung Autorisierung oder die Durchf hrung einer Authenti fikation zu entscheiden Die Verfeinerung der Authentifikation und Sitzungen wird in Abschnitt diskutiert Priorisierung der Anwendungsf lle F r eine inkrementelle Entwicklung oder beispielsweise f r den Bau eines funktionalen Prototypen muss festgelegt werden in welcher Reihenfolge die Anwendungsfalle umzu setzen sind Ausarbeitung der Anwendungsf lle Die in der Analyse der Anwendungsf lle siehe oben ermittelten Anwendungsf lle sind zu entwerfen und nach der in vorgestellten Struktur zu beschreiben F r jeden Anwendungsfall sind beteiligte Akteure Ein und Ausgabedaten Modifikationen am Anwendungskern Ablaufbeschreibung sowie Varianten des Ablaufs zu beschreiben Entwicklung der Sicherheitsanwendungsf lle Gemeinsam mit der Ausarbeitung der Anwendungsf lle sind f r sicherheitskritische Funktionen die Anwendungsf lle zu erweitern und f r Sicherheitsgrundfunktionen Si cherheitsanwendungsf lle zu erg nzen siehe Abschnitt 7 3 Entspricht ein sicherheits kritischer Anwendungsfall genau einer Aktivit t k nnen die ermittelten Schutzziele Bedrohungen Risiken Ma nahmen sowie Benutzerechte aus der Gesch ftsprozessmo dellierung auf den Anwendungsfall bertragen werden In den sonstigen F llen ist der Anwendungsfall f r
354. st in sich weiter teilbar 6 2 2 2 Schutzziele in Aktivit tsdiagrammen Betrachten wir nun die Schutzziele zu einer Aktivit t so wird im Fall 1 Aktivit t mit zuge ordneter Datenzugriffsmethode Folgendes festgelegt Werden in der zur Aktivit t zugeord neten Methode vertrauliche Daten gelesen manipuliert oder muss ein Zugriff nachgewiesen werden so wird die Aktivit t mit dem Schutzziel lt Confidentiality gt lt Integrity gt oder lt Non Repudiation gt gekennzeichnet Vertrauliche integrielle oder verbindliche Daten sind dadurch gekennzeichnet dass die zugeh rigen Klassen mit den Schutzzielen lt Confidentiality gt lt In tegrity gt und lt NonRepudiation gt annotiert sind siehe Abschnitt 6 2 1 Im 2 Fall einer zugeordneten Vorgehensmethode kann der Ablauf weiter aufgebrochen werden sodass der Ablauf wiederum eine Folge von Aktivit ten mit Datenzugriffen und Vor gehensabl ufen regelt 106 Die Geschaftsprozessmodellierung zugriffssicherer Systeme Setzt sich nun ein Ablauf einer Aktivit t aus einer Menge von Aktivit ten mit zugeordneten Methodenaufrufen zusammen so ergibt sich das Schutzziel f r die bergeordnete Aktivit t als logisches UND der Schutzziele der Teilaktivit ten Werden beispielsweise in einer Methode zu einer Teilaktivit t vertrauliche Daten gelesen und m ssen die Zugriffe in einer Methode zu einer weiteren Teilaktivit t verbindlich sein so werden an der bergeordneten Aktivit t die
355. stand der folgenden Kapitel Die Themen in diesen Kapiteln sind teilweise von theoretischer und abstrakter Natur Da Prozessmodelle in der Praxis jedoch nur dann eingesetzt werden wenn sie verst ndlich und nachvollziehbar sind und somit den Bezug zur Praxis nicht verlieren werden wir die theoretischen Inhalte anhand eines konkreten Anwendungsbeispiels illustrieren In diesem Kapitel stellen wir die Fallstudie das Projektverwaltungssystem TimeTool vor TimeTool unterst tzt Verwaltungsaufgaben eines Projekts insbesondere zur Abrechnung und Kontrolle von Bearbeitungszeiten Zun chst erl utern wir in Abschnitt 3 1 die Motivation und den Hintergrund der Fallstudie TimeTool Eine kurze Systembeschreibung sowie eine Darstellung der Anwendungsf lle des TimeTool Systems wird im Abschnitt 3 2 gegeben In der Zusammenfassung in Abschnitt 3 3 motivieren wir den Einsatz der Fallstudie als Anwendungsbeispiel in dieser Arbeit 3 1 Motivation und Hintergrund Die Fallstudie des Projektverwaltungssystems TimeTool stammt urspr nglich aus den Ubun gen zur Vorlesung Softwareentwicklung 4 Projektorganisation die im Sommersemester 2003 an der Universit t Innsbruck abgehalten wurden Dabei galt es ein kleines Projektma nagementwerkzeug zu erstellen 24 Eine Fallstudie Das Projektverwaltungssystem TimeTool Ziel des Projektes war die Realisierung eines Projektverwaltungssystems in einem Team in einer praxisorientierten Entwicklungsumgebu
356. stellt Dabei sind alle mit Sicherheitsaspekten ver nderten oder hinzugef gten Teilpro dukte grau hinterlegt Ver nderungen an den Produkten des Produktmodells sind in der in Abschnitt 6 5 vorgestellten Art gekennzeichnet Die Elemente des Business View Modells sowie des Gesch ftsprozessmodells werden bei der Analyse verwendet und bleiben unver ndert Falls bei der Entwicklung der Szenarien festgestellt wird dass die Beschreibungen der An wendungsf lle f r die Umsetzung zu unpr zise sind m ssen die Beschreibungen angepasst werden Der verfeinerte Fluss der Ereignisse wird dann in der Anwendungsfallbeschreibung im Anwendungsfallmodell verfeinert Die weiteren Teilprodukte der Anwendungsfallmodellie rung werden verwendet und bleiben ebenfalls unver ndert Erstmals innerhalb der Anforderungsspezifikation zugriffssicherer Systeme werden nderun gen am Klassenmodell nicht mehr im Dom nenmodell vorgenommen sondern im Klassen modell der Analyse Neben diesem Teilprodukt besteht das neu hinzugef gte Analysemodell aus den Anwendungsfallrealisierungen der Beschreibung der Spezialanforderungen und der Analyse Packages Die Zugriffs und Ausf hrungsrechte werden im Benutzerrechtemodell angepasst und Bedro hungen Risiken Ma nahmen und Uberprtifungsergebnisse werden im Bedrohungs und Risi komodell erg nzt oder modifiziert 192 Die Analyse zugriffssicherer Systeme
357. stellte Metamodell zur Spezifikation von Berechtigungen Das Berechtigungsmodell basiert auf dem Spezifikationsrahmen P MOS 6 2 1 1 Schutzziel Vertraulichkeit im Klassendiagramm Seien A Ti An Tn Attribute der Klasse C T ist entweder Klassenname oder ein Basistyp Falls die Klasse C mit dem Schutzziel Stereotyp lt Confidentiality gt annotiert wird gibt es eine Teilmenge Ai Tj Ai Tip der Attribute der Klasse C deren lesender Zugriff eingeschr nkt ist 6 2 Spezifikation der Schutzziele in Struktur und Verhalten 99 F r den lesenden Zugriff f hren wir Lese Zugriffsmethoden funct readc 4 AC Actor Ti funct readc a AC Actor T m ein die einen lesenden Zugriff auf ein Attribut A f r einen Akteur genau dann erlauben wenn die zugeh rige Leseberechtigung permc reade a AC Actor C fiir den Akteur erfiillt ist F r die Zuordnung von Lese Zugriffsmethoden und Attributen deren lesender Zugriff einge schr nkt ist f hren wir die Relation protect CAx MI ein wobei A die Menge aller Attribute und MZ die Menge aller Methodenidentifikatoren sei Ein Attribut A und ein Methodenidentifikator sind ein Element der Relation protect A readc a protect wenn die Lese Zugriffsmethode readc a der Klasse C den Lesezugriff auf das Attribut A einschr nkt Unter Betrachtung der eingef hrten Relation protect und der vorgestellten Lese Zugriffsme thoden mit Leseberechtigung k nnen wir n
358. steme 3 3 1 Das Projektverwaltungssystem TimeTool 24 3 2 berblick ber die Akteure und Anwendungsf lle des TimeTool Systems 26 eae 30 ee 35 EI 37 ae 40 70 e 42 ter tice ee a dare a 43 Be Ren 44 50 5 1 Phasenstrukturierte Konstruktion sicherer Systeme 54 5 2 Aktivit ten bei Anwendung des V Modells und der ITSEC 59 5 3 Ein zu den Common Criteria konformes Vorgehen 61 5 4 bersicht ber das modifizierte Lebenszyklusmodell 73 5 5 Phasen Kernarbeitsschritte und Iterationen im Lebenszyklusmodell 74 en 76 es 78 TEN 80 ao ke eek eee ne 83 2086 9 ee 95 nn en 97 es 97 were 98 dink oie os ae 100 Er NE 102 eer 103 aera 103 thd Ban dei a eee he ek os 104 ET 104 ee 105 212 Abbildungsverzeichnis SR dk Boe alk Gy ape ge Ba Wake ane bk ae aes 108 een 108 ee 109 SOAR be ERO REE ae ee e 110 6 18 Hierarchie der Akteurel 2 2222 2 2 ee 111 ae ee ee ee ee 112 od ek oe Be ae oe 113 mbt di fee ae Be ae Re ee 114 ee 116 6 23 Beispiel zur unbeschr nkten Ausf hrung 2 2 nn nn nenn 117 De Hkh ea ea Bee ee ee ee ee 118 Pod diets ep a ood matey a brie aoe 119 be ae BR Bak eae Sergei en ee oh gs Bek ae 120 6 27 Beispiel einer Permissions zur Instanzentrennung 121 6 28 Szenario zur dynamischen Aufgabentrennung 0 122 6 29 Szenario zur statischen Aufgabentrennung 2 2 22m nn nen
359. stemressourcen und Kommunikationswege und dabei insbesondere auf Daten f hren Im Gegensatz zur Datensicherheit engl Protection bleiben bei der Zugriffssicherheit die Datensicherung sowie der Datenschutz au en vor Wir besch ftigen uns im Rahmen der fr hen Softwareentwicklung damit unbefugte Zugriffe oder Modifikationen von Daten und Informationen die innerhalb der Software gespeichert oder bertragen werden zu verhindern Die vorgestellte Definition der Zugriffssicherheit er fordert die Funktionssicherheit als Voraussetzung der Zugriffssicherheit Im Rahmen dieser Arbeit beschr nken wir uns daher bei unseren berlegungen auf den Aspekt der Zugriffssi cherheit Wir zeigen wie ein System gegen unerw nschte Zugriffe von au en zu sichern ist Die Funktionssicherheit sehen wir dabei als gegeben an Sicherheitsanforderungen werden in existierenden Methoden zur Soft wareentwicklung zumeist im Rahmen der Ermittlung der nichtfunktionalen Anforderungen lose neben den funktionalen Anforderungen betrachtet Sie werden oftmals auch als Software Qualit tsmerkmale oder als Non Behavioral Aspects bezeichnet Ziel des vor gestellten Ansatzes ist es Anforderungen an die Zugriffssicherheit bei der Beschreibung der funktionalen Anforderungen zu integrieren und schrittweise zu verfeinern Am Ende der An forderungsspezifikation k nnen damit die Anforderungen der Zugriffssicherheit in die funktio nalen Abl ufe und in die Struktur des zu entwickelnden
360. t In allen vier Gesch ftsobjekten sind jeweils alle Attribute vor unerlaub ten Ver nderungen zu sch tzen wie durch die grau hinterlegten Attribute gekennzeichnet wur de In den Klassen Project und ProjectManager existieren jeweils Create Zugriffsmethoden deren Ausf hrung ebenfalls durch Berechtigungen einzuschr nken ist 102 Die Geschaftsprozessmodellierung zugriffssicherer Systeme Project x L 1 Activity ae name String plannedStart Timestamp budget Real plannedEnd Timestamp iteN realStart Timestamp Means realEnd Timestamp plannedHours Real writePlannedStart t writePlanedEnd t writeRealStart t writeRealEnd t writePlanedHours r createActivity ps pe ph 1 1 ProjectManager Accounting da name String accountDate Timestamp address String requiredHours Real email String writeAccountDate t pswd String writeRequiredHours r userid String writeName s writeAddress s writeEmail s writePassword s writeUserID s createProjManager n a e p u Abbildung 6 7 Schutzziel Integrit t in TimeTool Gesch ftsobjekten 6 2 1 3 Schutzziel Verbindlichkeit im Klassendiagramm Seien A Ti An Tn Attribute der Klasse C T ist entweder Klassenname oder ein Basistyp Falls die Klasse C mit dem Schutzziel Stereotyp lt NonRepudiation gt annotiert wird gibt es e
361. t Sicherheitsl cken oder Schwachstellen entwickelt werden Viele objektorientierte Vorgehensweisen schlagen vor die Systementwicklung von betrieb lichen Informationssystemen mit der Definition der Anforderungen in Form von Anwen dungsf llen zu beginnen Eine vollst ndige Erfassung und Festlegung der Anforderungen er fordert es vorab die Abl ufe und Informationen des Unternehmens bzw der Organisation zu modellieren Die Anforderungen die das zu erstellende System zu erf llen hat k nnen dadurch klar festgelegt werden Die vorliegende Arbeit beschreibt insgesamt einen Ausschnitt aus einem Vorgehensmodell auf Basis eines objektorientierten System und Vorgehensmodells zur Neuentwicklung von zugriffssicheren Informationssystemen Ein zentrales Ziel des vorgestellten Vorgehensmodells ist die Integration von Aspekten der Zugriffssicherheit in die fr hen Phasen der System entwicklung Im Vordergrund steht dabei die sukzessive und durchg ngige Entwicklung der Anforderungen an die Zugriffssicherheit gemeinsam mit dem Entwurf der Systemfunktionen und des Datenmodells Die vorgestellte Sicherheitsanalyse wird abstrakt und unabh ngig von technischen Details durchgef hrt Durch die Beschreibung in Form generischer Prozessmuster kann die Methode in offene Vorgehensmodelle integriert werden Kern dieser Arbeit sind ein Rechtemodell zur Spezifikation von Benutzerrechten und die Integration der Sicherheitsanforderungen in den fr hen Phasen der Entwick
362. t der Aspekt der fr hzeitigen Identifikation und Reduktion der Risiken be sonders tragend denn Risiken im Bereich der Zugriffssicherheit sind bei der Entwicklung zu eliminieren Durch die Einbettung der Anforderungsspezifikation zugriffssicherer Syste me k nnen Iterationen ber Phasen die in einem objektorientierten Vorgehensmodell zum Beispiel JBR99 vorgegeben werden angewendet werden siehe hierzu Abbildung 15 5 Der eigentliche Prozess zur Modellierung der Zugriffssicherheit der Sicherheitsmikro prozess aus Abschnitt ist speziell f r eine iterative Entwicklung ausgelegt worden und dieser wird zudem in allen Prozessabschnitten der Anforderungsspezifikation zugriffssicherer Systeme ausgef hrt F r die Modellierung zugriffssicherer Systeme gibt es noch eine dritte Ite rationsm glichkeit beim Entwurf und der berpr fung von Ma nahmen gegen Bedrohungen innerhalb des Mikroprozesses siehe Abbildung 5 9 Durch diese dreifache Iterationsf higkeit wird durch das vorgestellte Vorgehen eine iterative Entwicklung in vollem Umfang unterst tzt Sicherheitsmodellierung in der Gesch ftsprozessanalyse SPA7 Eine Modellierung der Zugriffssicherheit in der Gesch ftsprozessanalyse ist vor allem deshalb wichtig da zu diesem Zeitpunkt Anwender und Anforderungsentwickler gemeinsam die An forderungen entwickeln und dadurch die Aspekte der Zugriffssicherheit gemeinsam ermittelt und dokumentiert werden k nnen Beispielsweise f hrt die Tatsache da
363. t in die fr hen Phasen der Systementwicklung sinnvoll und leicht anwendbar integriert Auf Basis eines objektorientierten System und Vorgehens modells beschreibt sie einen Ausschnitt zur durchg ngigen und sukzessiven Neuentwicklung von zugriffssicheren Informationssystemen Durch die vorgestellte Methode wird dem Anfor derungsentwickler ein Instrumentarium an die Hand gegeben sodass er die Anforderungen an die Zugriffssicherheit von technischen Details abstrahierend gemeinsam mit der Entwicklung der funktionalen Anforderungen an das System schrittweise erarbeiten kann Zentrales Element f r die Sicherheitsanalyse ist ein Benutzerrechtemodell zur Spezifikation von Zugriffs und Ausf hrungsrechten in den fr hen Phasen der Entwicklung Diese basiert auf der Sprache P MOS zur Navigation ber Objekte Zust nde und Objektbez ge sodass Benutzerrechte im Rahmen eines objektorientierten Vorgehens formalisiert werden k nnen Im Gegensatz zu existierenden Ans tzen werden Benutzerrechte au erhalb des Anwendungs kerns innerhalb einer Berechtigungsmatrix vorab textuell spezifiziert und im Rahmen einer dreistufigen Sicherheitsanalyse in Hinblick auf eine sp tere Generierung der Methoden zur Berechtigungs berpr fung formalisiert F r eine Integration der Berechtigungs berpr fung wird die Methodenspezifikationen um einen Berechtigungsabschnitt erweitert in dem die Zu griffsrechte beim Aufruf einer Objektmethode vorab berpr ft werden k nnen E
364. t werden e In vielen F llen m ssen Protokolle an das System angepasst werden oder es existieren keine Standardl sungen In diesen F llen ist der Protokollablauf in der Analyse zu modellieren In Abbildung 8 3 ist ein Spezialfall f r eine Authentifikation exemplarisch modelliert wor den Der Zugang zum System wird hier nicht mittels Benutzername und Passwort berpr ft sondern durch die Verwendung einer Chipkarte und eines Terminals Das exemplarisch spe zifizierte Protokoll beschreibt eine gegenseitige symmetrische Authentisierung siehe RE99 zwischen Chipkarte und Terminal Adjustment Posting Preconditions Team Worker is authenticated Web Browser and TimeTool are authenticated o 0 O O O Adjustment SSL VGAdjustment Accounting Accoinia Team Worker PostingUI Connection Posting Manager Accounung Logging check permission gt select accounting gt search accounting 55 check permission get accounting le accounting show accounting TS modifiy data a check permission back up accounting N update accounting okay a le Abbildung 8 4 Verfeinertes Szenario zur Korrekturbuchung 184 Die Analyse zugriffssicherer Systeme In unserem bekannten Szenario zur Korrekturbuchung verwenden wir zur sicheren Daten bertragung der Benutzereingaben zwischen dem System des Benutzers Web Browser und dem TimeTool System das Secure Socket Layer Prot
365. tegrierten Vorgangsmethoden transformiert werden Im Abschnitt haben wir bereits process Methoden f r die Spezifikation der Abl ufe in Vorgangsklassen vorgestellt Die zu den Anwendungsf llen spezifizierten Benutzerrechte sind nun in Benutzerrechte f r die process Methoden zu transformieren Da jedoch die Anwendungsf lle direkt auf die Vorgangsklassen abgebil det werden d h zu jedem Anwendungsfall wird eine Vorgangsklasse entwickelt k nnen die Ausf hrungsrechte direkt bertragen werden Im Rahmen der Gesch ftsprozessmodellierung und der Anwendungsfallmodellierung zu griffssicherer Systeme wurden schon alle Ausf hrungsrechte die nicht mehr abge ndert werden mussten pr dikativ spezifiziert F r alle Ausf hrungsrechte die zu Beginn der Analyse zugriffssicherer Systeme noch in textueller Form vorliegen sind die Ausf h rungsrechte endg ltig zu kl ren und in eine pr dikative Form zu berf hren sodass die berpr fung der Benutzerrechte Autorisierung im Rahmen des folgenden Designs automatisch generiert werden kann siehe Abschnitte 4 4 und 16 3 3 Modellierung der Zugriffsrechte Die Klassen des Dom nenmodells werden auf Klassen des Klassendiagramms der Ana lyse abgebildet Da die Klassen dabei nur neu eingeteilt werden die Struktur und As soziationen aber erhalten bleiben k nnen die Zugriffsrechte aus der Anwendungsfall modellierung beibehalten werden Durch die externe Beschreibung der Zugriffsrechte in der Benutz
366. tegrit t Verbindlichkeit und 2 2 Grundlagen zur IT Sicherheit 17 Verfiigbarkeit angestrebt werden ISO EEC 17799 Im Gegensatz zur Datensicherheit engl protection bleiben bei der Zugriffssicherheit Aspekte des Datenschutzes und der Datensiche rung au en vor Vereinfacht ausgedriickt ist die Zugriffssicherheit die Sicherheit gegen absichtliche Angriffe 2 2 2 Schutzziele In zugriffssicheren Systemen k nnen die Angriffsziele in Kategorien aufgeteilt werden In der Literatur haben sich hierzu die Begriffe Schutzziele Eck03 Sicherheitsdienste engl security services MFW 99 und Sicherheitseigenschaften etabliert Weiterhin werden sie auch als Dimensionen der Sicherheit engl dimensions of security Dos01 als Aspekte oder als kryptografische Ziele engl cryptographic goals bezeichnet Authentizit t Unter der Authentizit t eines Objektes bzw Subjekts engl authenticity verstehen wir die Echtheit eines Objekts bzw Subjekts die anhand seiner eindeutigen Identit t und seiner charakterisierenden Eigenschaften berpr fbar sind Unter Identit t einer Person oder Sache wird die Summe der Merkmale verstanden anhand derer sich diese von anderen unterscheidt Authentifikation Die Authentizit t eines Subjekts bzw Objekts wird durch Ma nahmen zur Authentifikation engl authentication berpr ft Dazu muss nachgewiesen werden dass eine behauptete Iden tit t eines Objekts oder Subjekts mit dessen charakteristis
367. teurzentriertes Modell zur Spezifikation von Benutzerrechten sodass neben den Subjekten die Akteure auch die zu schiitzenden Objektmethoden gruppiert und mit vordefinierten Benutzerrechten ausgestattet werden k nnen Unsere Modellierung ist auf eine objektorientierte Vorgehensweise ausgerichtet die in weiten Teilen die grafische Beschreibungssprache UML verwendet Im Kontext dieser Sprache findet sich die pr dikative Spezifikationssprache OCL wieder sodass wir unsere pr dikatenlogischen Berechtigungsausdr cke direkt in diese Sprache transformieren k nnen Dies erm glicht uns die Spezifikation der Benutzerrechte anlag zu Vor und Nachbedingungen sowie Invarianten unter Verwendung der Variablen der Methoden des aktuellen Objektes und des aktuellen Akteurs Neben der Vorstellung des formalen Rahmenwerks f r Benutzerberechtigungen mit der Trans formation nach OCL wurde in diesem Kapitel auch ein Ausblick auf eine Transformation in die Implementierung gegeben Die Berechtigungsspezifikationen in Form von P MOS Pr di katen und OCL Bedingungen sowie die Codegenerierung wurde exemplarisch an der Time Tool Fallstudie gezeigt 5 Ein Prozess zur Entwicklung von Anforderungsspezifikationen fiir zugriffssichere Systeme F r die Einf hrung eines Vorgehensmodells in den Phasen der Anforderungsspezifikation f r zugriffssichere Systeme sind Prozessabl ufe zu definieren und Beschreibungstechniken zu er weitern Zur Beschreibung von Sicherhei
368. th lt die OCL einen stark ausgepr gten Anteil vordefinierter Datentypen mit m chtigen Funktionen und n tzlichen syntaktischen Abk rzungen In unserem Ansatz dient P MOS als Zwischensprache f r die Entwicklung von Konzepten Sie liefert die notwendige Semantik f r die Einf hrung der Konzepte Die OCL verwenden wir als Zielsprache innerhalb unserer Methode bei der Spezifikation von Benutzerrechten 4 3 1 P MOS Ausdr cke Ein P MOS Ausdruck beschreibt eine Navigation in einer durch ein Klassendiagramm indu zierten Objektstruktur die einen Wert abliefert Semantisch wird jeder P MOS Ausdruck im Kontext einer so genannten Objektumgebung interpretiert welche eine konkrete Objektstruktur ber einem gegebenen Klassendiagramm beschreibt P MOS ist eine hybride Sprache d h wir unterscheiden zwischen Basistypen und Klassentypen W hrend ein Ausdruck eines Basistyps wie zum Beispiel Bool oder int in einem Wert true false 0 1 resultiert liefert ein Klassentyp Ausdruck eine Referenz auf ein Objekt innerhalb der gegebenen Objektstruktur zur ck P MOS Ausdr cke k nnen mit der Anwendung der folgenden sechs Regeln gebildet werden Dabei wird angenommen dass eine Menge von Basisdatentypen wie Bool und int sowie Typkonstruktoren zur Verf gung stehen Vorausgesetzt wird dabei auch ein Typkonstruktor Set _ zum Aufbau von Mengen ber willk rliche Elemente 1 Basisfunktionen Sei f 51 Sn s eine Funktion der Basistypen w
369. tion von Schutzzielen in Klassendiagrammen und Aktivit tsdiagrammen ein Mit dem eingef hrten Prozess zur Gesch ftsprozessmodellierung zugriffssicherer Systeme wird weiterhin das Ziel verfolgt dass die Anforderungen an die Sicherheit und Systemfunktiona lit t gemeinsam entwickelt werden Bei der lokalen Betrachtung eines Ablaufs oder eines Ausschnitts aus dem Dom nenmodell k nnen so die Sicherheitsaspekte losgel st von weiteren Abl ufen und Daten auf einer hohen Abstraktionsebene spezifiziert werden Eine iterative Entwicklung wird insbesondere durch die Anwendung des Sicherheitsmikro prozesses und durch die Iterationsm glichkeiten innerhalb der Gesch ftsprozessmodellierung zugriffssicherer Systeme erreicht Benutzerrechte Bedrohungen Risiken und Gegenma nah men k nnen nach der Ermittlung aller Schutzziele innerhalb der Abl ufe und Daten modelliert werden Genauso k nnen diese aber auch bereits nach der Ausarbeitung einer Kernfunktio nalit t ermittelt und anschlie end schrittweise erweitert werden Der entwickelte Ablauf zur Gesch ftsprozessmodellierung zugriffssicherer Systeme wurde in einem Prozessmuster formuliert und die in die Abarbeitung zentralen Produktartefakte wur den vorgesellt Zur Spezifikation der Ergebnisse sind die Produktartefakte der Gesch ftspro zessmodellierung zu erweitern und um neue zu erg nzen Im Rahmen der folgenden Anwendungsfallmodellierung zugriffssicherer Systeme werden die bereits erarbeitete
370. tivity project projectmanager act rolerep Beispiel 2 Ein Projektmitarbeiter team worker kann nur eigene Buchungen zu freigegebenen Akti vit ten schreiben veranschaulicht an writeAccountingDate context Accounting writeAccountingDate perm act ACTeamWorker self user act rolerep and self activity state ActivityState released Beispiel 3 Der Projektleiter project manager kann nur Buchungen zu Aktivit ten von eigenen Projek ten erzeugen d h zu Aktivit ten von Projekten bei denen er Projektleiter ist context Accounting create a Activity u User perm act ACProjectManager a project projectmanager act rolerep Beziiglich der Semantik von Berechtigungen auf Methoden muss betont werden dass das dem Akteur zugeordnete Objekt nicht von sich aus eine Methode aufruft sondern die Rolle initiiert den Aufruf einer Methode von au en d h au erhalb des Systems Ein solcher Methodenaufruf kann auch ber eine Kette von Methodenaufrufen erfolgen Bei der Implementierung kann der aufrufende Akteur entweder als weiterer Methodenparameter behandelt werden oder aber wie in J2EE durch eine Infrastruktur f r Methodenaufrufe 4 6 Erweiterungen Wie wir im Abschnitt 4 4 erkl rt haben ist unsere Basissicht bei der pr dikativen Spezifi kation der Benutzerrechte die dass ein Akteur Berechtigungen zum Ausf hren von Objekt methode hat Dieses fein granulare Paradigma stellt uns ein Maximum an Flexi
371. tseigenschaften sind die Produktartefakte anzupassen und Neue hinzuf gen beispielsweise zur Spezifikation von Benutzerrechten In Abschnitt 5 1 stellen wir zun chst existierende Vorgehensmodelle und Vorgehensbeschrei bungen zur Entwicklung sicherer Systeme vor F r die Definition von Prozessanforderungen f r die Eingliederung der Anforderungsphase in ein Vorgehensmodell und f r die Definition einer Anforderungsphase mit Teilabschnitten untersuchen wir diese heutigen Vorgehensweisen bez glich Vorteile und Eignung zur Entwicklung von zugriffssicheren Systemen Die Prozessanforderungen zur Entwicklung zugriffssicherer Systeme stellen wir detailliert in Abschnitt dar R ckblickend bewerten wir die existierenden Vorgehensmodelle und Vor gehensbeschreibungen bez glich dieser Prozessanforderungen In Abschnitt 5 3 wird das eigentliche Vorgehen der Anforderungsspezifikation zugriffssicherer Systeme in Form eines Prozessmusters vorgestellt Weitere Prozessmuster zeigen die Ein gliederung dieser Phase in einen objektorientierten Softwarelebenszyklus und einen Sicher heitsmikroprozess welcher zum Zwecke der Modellierung von Aspekten der Zugriffssicherheit innerhalb der Anforderungsspezifikation mehrfach zur Ausf hrung kommt Eine bersicht ber die Produktartefakte der Anforderungsspezifikation zugriffssicherer Sys teme wird in Kapitel gegeben wobei Produktartefakte aus bekannten objektorientier ten Vorgehensmodellen um Aspekte der Zugriffss
372. ttlung von Anfor derungen und schrittweise Umsetzung m glich ist F r eine Ausweitung der methodischen Entwicklung von nichtfunktionalen Anforderungen ist zu untersuchen inwiefern die weiteren nichtfunktionalen Anforderungen ebenfalls unterteilt werden k nnen Erste Ideen und Frage stellungen werden in diskutiert Literaturverzeichnis A1t04 Amb98 Amb99 And01 AWO3a Awo3b Bal96 Bal98 Bas93 Bau97 BBEHO3 Ewgeney Alter Werkzeugunterst tzte Analyse von Gesch ftsprozessen Diplom arbeit Institut f r Informatik der Technischen Universit t M nchen 2004 Scott W Ambler Process Patterns Building Large Scale Systems Using Object Technology Cambridge University Press 1998 Scott W Ambler More Process Patterns Delivering Large Scale Systems Using Object Technology Cambridge University Press 1999 Ross Anderson Security Engineering A Guide to Building Dependable Distri buted Systems Wiley Computer Publishing 2001 Khaled Alghathbar and Duminda Wijesekera AuthUML A Three phased Fra mework to model Secure Use Cases In Proceedings of the 10th ACM Conference on Computer and Communications Security CCS 2003 October 27 31 Wa shington DC U S A ACM 2003 http www acm org sigs sigsac ccs CCS2003 Christine Artelsmair and Roland R Wagner Towards a Security Engineering Process In Nagib Callaos William Lesso Belkis S nchez and Elizabeth Hansen editors Procee
373. tudie Time Tool Wie sp ter noch gezeigt wird erfolgt die Spezifikation der Akteure im Rahmen der Anwen dungsfallmodellierung zugriffssicherer Systeme Die Repr sentierungsfunktionen werden bei der Ermittlung der Sicherheitsanwendungsf lle in Anwendungsf llen zur Authentifikation be schrieben 4 4 Formale Modellierung von Benutzerrechten 43 AC Team Worker passwd String userid String rolerep Object Vtw ACTeamW orker Vu User tw rolerep u gt u state factive N tw userid u userid A tw passwd u passwd ACProjectManager rolerep Object Ypm ACProject Manager Vu User pm rolerep u gt dp Project p projectmanager u ACAdministrator passwd String userid String rolerep Object Vad AC Administrator Va Administrator ad rolerep a gt ad userid a userid A ad passwd a passwd Abbildung 4 6 Repr stentierungsfunktionen zur TimeTool Fallstudie 4 4 2 Benutzerberechtigungen Benutzerberechtigungen engl Permissions sind Vorbedingungen zu Methoden verbunden mit der Semantik dass die entsprechende Methode nur dann ausgef hrt werden kann wenn der Berechtigungsausdruck engl Permission Expression zu Beginn der Methodenausf hrung zu true ausgewertet wird Da unser Ansatz auf dem fail safe default principle vgl Abschnitt zu den Sicherheitsprinzipien beruht ist jede Methodenausf hrung die nicht explizit durch eine Berecht
374. tw ACTeamW orker pc process tw A tw rolerep 4 tw rolerep gt perm PCSignContractSecond process tW pc2 Permission zur dynamischen Aufgabentrennung Bei der dynamischen Aufgabentrennung d rfen innerhalb eines Ablaufs verschiedene Rollen nicht durch dieselbe Person vertreten werden Der allgemein g ltige Ansatz des Rollenpara digmas dass eine Person in mehreren Rollen aktiv sein kann wird hier eingeschr nkt Eine Person darf innerhalb eines Ablaufs nicht gleichzeitig in solchen Aktivit ten aktiv sein deren assoziierten Aufgaben wechselseitig ausgeschlossen sind vgl Eck03 Abbildung 6 28 zeigt ein Anwendungsszenario aus der TimeTool Fallstudie zur dynamischen Aufgabentrennung Eine Person kann sowohl Projektleiter als auch Projektmitarbeiter sein nderungen an den Stundenbuchungseintr gen eines Projektmitarbeiters m ssen jedoch vom Projektleiter best tigt werden Damit ein Projektmitarbeiter nicht seine eigenen nderun gen zu Stundenbuchungen best tigen kann muss f r diesen Ablauf die Rollenmitgliedschaft eingeschr nkt werden Der Projektleiter darf nicht seine eigenen nderungen an Stundenbu chungen best tigen 122 Die Geschaftsprozessmodellierung zugriffssicherer Systeme TeamWorker ProjectManager adjust accounting confirm adjustment Abbildung 6 28 Szenario zur dynamischen Aufgabentrennung class actor Team Worker Project Manager PCAdjustAccounting E
375. u eigenen Projekten Dies ist bei der Modellierung der Benutzerrechte zu ber cksichtigen F r die Bedrohung B011 ergibt sich folgender Projektablauf Nachdem eine Projektak tivit t beendet wurde und alle Projektmitarbeiter die Stundenbuchungen eingetragen haben kontrolliert der Projektleiter die Stundenbuchungen Anschlie end setzt er in der zugeh rigen Projektaktivit t den Status der Projektaktivit t auf frozen und es k nnen an den zugeh rigen Buchungen keine nderungen mehr durchgef hrt werden Somit ist im Dom nenmodell zur Klasse Activty das Statusattribut State mit den m glichen Belegungen frozen released hinzuzuf gen Bei der Spezifikation der Benutzerrechte ist dieses Statusattribut einzubeziehen Es k nnen Buchungen nur dann ver ndert werden wenn der Status der zugeh rigen Aktivit t auf released gesetzt wurde e Der Bedrohung B012 kann entgegengewirkt werden indem negative Stundenbuchungen grunds tzlich verboten werden Diese Bedingung wird in den Regeln zum Gesch ftspro zessmodell aufgenommen 136 Die Geschaftsprozessmodellierung zugriffssicherer Systeme e Damit Projektmitarbeiter Anderungen und Eintragungen zu Stundenbuchungen nicht abstreiten k nnen werden alle Eintragungen und nderungen in einer so genannten Historie mitprotokolliert Als Ma nahme zur Bedrohung B013 f gen wir deshalb zum Dom nenmodell eine Klasse Logging hinzu die alle nderungen an Buchungseintr gen speichert Der Zugriff auf die K
376. un das Schutzziel Stereotyp Confidentiality gt fol genderma en beschreiben VAEC Va ACActor Jreado a Ay readc a protect 4 Ppermc readc Au perme reado a 4 C true amp readc a a A V perme reado A a C false gt reado a a L Alle Attribute der Klasse C fiir die spezielle Lese Zugriffsmethoden existieren k nnen genau dann von Akteuren gelesen werden wenn die zugeh rige Leseberechtigung f r den ausf hren den Akteur true liefert Als Ergebnis liefert die Lese Zugriffsmethode den Wert des Attributs A Zur Unterscheidung zwischen Namen und Wert des Attributs kennzeichnen wir den Wert die Belegung des Attributs A durch A Ist die zugeh rige Leseberechtigung nicht erf llt so liefert die Lese Zugriffsmethode das spe zielle Element L Bottom als Abstraktion einer Fehlermeldung oder Exception zur ck Beispiel Abbildung 6 6 zeigt einen Ausschnitt der Gesch ftsobjekte der TimeTool Fallstudie In den Klassen TeamWorker und Accounting enthalten jeweils die grau hinterlegten Attribute ver trauliche Information Bei der Klasse TeamWorker sind Name und E Mail Adresse ohne Einschr nkung lesbar hingegen sind die Adresse sowie Benutzerkennung und Passwort vor unbefugtem lesenden Zugriff zu sch tzen Die zu sch tzenden Attribute sind hier eine ech te Teilmenge der Klassenattribute In der Klasse Accounting enthalten alle Klassenattribute vertrauliche Information d h die zu s
377. undfunktionen u a Modellierung Modell berpr fung Funktionalit ts Nachweis von Eigenschaften klassen in ITSEC Sicherheitsmodell Vv N Grobentwurf Validierung Struktur und Schnittstellen lui Vv Mechanismen Sicherheits Feinentwurf Die oe architektur Sicherheitsspez Komponenten Modultest a Kriterien v Code Inspektion kataloge Implementierung Verifikation i Datenstrukturen Algorithmen Abbildung 5 1 Phasenstrukturierte Konstruktion sicherer Systeme 5 1 Existierende Vorgehensmodelle 55 Fiir eine systematische Erfassung der Bedrohungen werden dabei eine Bedrohungsmatrix oder ein Bedrohungsbaum verwendet Nach der Erfassung der Bedrohungen werden Wahrschein lichkeiten f r das Eintreten innerhalb der Risikoanalyse ermittelt Der potenzielle Schaden der verursacht werden kann wird dabei abgesch tzt Aus den Bedrohungen mit ihren Risiken werden die Sicherheitsanforderungen abgeleitet d h Ma nahmen zur Abwehr der Bedrohungen sind zu ermitteln und zu klassifizieren beispiels weise nach Wichtigkeit Kosten und Aufwand Eck03 In der Sicherheitsstrategie sind die Sicherheitsanforderungen informal oder formal zu beschreiben Zur Abdeckung der Sicher heitsbed rfnisse k nnen Sicherheitsgrundfunktionen vgl Abschnitt 2 2 5 eingesetzt werden soweit diese vorhanden sind Weiterhin k nnen hier Funktionsklassen f r Anwendungsklassen aus Kriterienkatalogen wie ITSEC oder Common Criteria CC BSI99 a
378. ung betrieblicher Informationssysteme wird die durchg ngige und sukzessive Erarbeitung von Aspekten der Zugriffssicherheit in den Phasen der Gesch ftsprozessmodellierung der Anwen dungsfallmodellierung und der Analyse gezeigt Zur Spezifikation der Anforderungen in diesen fr hen Phasen werden UML Diagramme verwendet zur Darstellung der Anforderungen der Zugriffssicherheit werden diese um notwendige Konstrukte erg nzt Mittels des Erweiterungs mechanismus der UML werden Stereotypen f r die Schutzziele Vertraulichkeit Integrit t Verbindlichkeit und Authentifikation in Klassen und Aktivit tsdiagrammen eingef hrt Zur Darstellung von Sitzungen werden Aktivit tsdiagramme um spezielle Assoziationen erg nzt Die Erweiterung des Produktmodells um eigene sicherheitsspezifische Produkte sowie die Er weiterung von Standardprodukten gegen ber herk mmlichen Produktmodellen wird gezeigt Die Prozessbausteine f r die Modellierung der Zugriffssicherheit in den fr hen Phasen der Softwareentwicklung werden mit Hilfe von Prozessmustern dar gestellt Damit lassen sich die Prozesse zur Sicherheitsanalyse auch in neue generische Pro zessmodelle integrieren Besondere Bedeutung wird auch der iterativen Entwicklung der Anforderungen an die Zu griffssicherheit einger umt wie diese in den objektorientierten Methoden gefordert wird Be sonders f r die Entwicklung gro er Systeme werden in allen drei Prozessabschnitten der Anfor derungsspezifikation zugr
379. ung und Vorstellung vom System haben Ziel der Gesch ftsprozessmodellierung soll es auch nicht sein jedes Detail vollst ndig bis ins kleinste Detail zu modellieren Andernfalls w rde das Modell nicht mehr fassbar und zu komplex werden Das Gesch ftsprozessmodell beschr nkt sich somit auf die Kernkonzepte und Kernprozesse Unter diesen Voraussetzungen und Beschr nkungen hat die Gesch ftsprozessmodellierung fol gende Aufgaben zu erf llen EP00 6 1 Allgemeine Gesch ftsprozessmodellierung 93 e Die entscheidenden Mechanismen einer Unternehmung bzw Organisation m ssen ver standen werden e Es ist eine Basis f r die Entwicklung eines Systems zu schaffen Beschreibungen der Gesch ftsbereiche sind f r die Identifikation der Systemunterst tzung notwendig Die Schl sselanforderungen sind daraus abzuleiten e Die gegenw rtigen Gesch ftsprozesse und die Gesch ftsstruktur sind in Hinblick auf eine Automatisierung zu berarbeiten und gegebenenfalls zu verbessern e Die Struktur der verbesserten erneuerten Unternehmung bzw Organisation ist darzu legen In der Literatur hat sich bislang noch keine einheitliche Definition f r den Begriff des Ge sch ftsprozesses herausgebildet vgl Wik Grunds tzlich kann zwischen zwei In terpretationen unterschieden werden Die erste ist an die Definitionen von Gesch ftsprozes sen im Kontext des Business Process Reengineering angelehnt und sieht Gesch ftsprozesse als Kernprozesse di
380. ungen gering gehalten Weiterhin k nnen aus den formal spezifizierten Benutzerrechten sp ter bei der Implementierung automatisch Zugriffsprozeduren generiert werden sodass vor der Ausf hrung von Methoden die Zugriffs rechte des ausf hrenden Benutzers berpr ft werden k nnen Die implementierungsunabh ngige pr dikative Spezifikation der Benutzerrechte basiert auf dem Spezifikationsrahmenwerk P MOS vgl Bre01 Basierend auf dieser Sprache von Aus dr cken und Pr dikaten zum Navigieren ber Objekte Zust nde und Objektbez ge wird ein akteurzentriertes Modell zur Spezifikation von Benutzerrechten eingef hrt Grundidee dieses Modells ist die Erweiterung von Methodenaufrufen um eine Berechtigungsspezifikation Wie eine Vorbedingung muss die Berechtigung vor dem Ausf hren der Methode berpr ft wer den Die Ausdr cke und Pr dikate in P MOS beziehen sich dabei auf das Dom nenmodell des zu entwickelnden Systems sind rein statisch und getypt Berechtigungs berpr fungen liefern damit einen Wert zur ck sind aber nicht zustandsver ndernd Bei der detaillierten Untersu chung der Benutzerrechte werden diese in Zugriffs und Ausf hrungsrechte eingeteilt und es wird ein Berechnungsverfahren angegeben wie aus Zugriffsberechtigungen eine Ausf hrungs berechtigung ermittelt werden kann Zudem werden verschiedene Typen von Ausf hrungs rechten eingef hrt Basierend auf verschiedenen neueren objektorientierten Methoden zur Systementwickl
381. us den Aktivit ten der Gesch ftsprozesse in Anwen dungsfallbeschreibungen transformiert Gehen dabei aus einer Aktivit t mehrere An wendungsf lle hervor oder werden mehrere Aktivit ten in einen gemeinsamen Anwen dungsfall transformiert m ssen die resultierenden Anwendungsf lle einer Sicherheits analyse unterzogen werden e Einf hrung von Anwendungsf llen f r Sicherheitsgrundfunktionen Zur Beschreibung der Funktionalit t der Sicherheitsmechanismen sind Sicherheitsanwendungsf lle dem System hinzuzuf gen F r diese Anwendungsf lle sind ebenfalls Schutzziele Bedrohun gen Risiken und Ma nahmen zu ermitteln Die eigentliche Ausf hrung des Sicherheitsmikroprozesses ist im Prozessmuster in Abschnitt 15 3 3 beschrieben Die ermittelten und ver nderten Bedrohungen Risiken Ma nahmen so wie die berpr fungsergebnisse der Ma nahmen werden im Bedrohungs und Risikomodell spezifiziert 7 6 Produktartefakte der Anwendungsfallmodellierung zugriffssicherer Systeme Abschlie end betrachten wir die Produktartefakte zur Anwendungsfallmodellierung zugriffs sicherer Systeme und gehen dabei auf Erg nzungen bez glich der Modellierung der Zugriffs sicherheit ein In Abbildung sind die Produktartefakte aus dem Prozessmuster zur Anwendungsfall modellierung zugriffssicherer Systeme mit ihren Teilprodukten dargestellt Dabei sind al le durch Sicherheitsaspekte ver nderten oder hinzugef gten Teilprodukte grau hinterlegt Ver nderung
382. usgabe Produktartefakte e Dom nenmodell mit Sicherheitsaspekten erweitert Gesch ftsprozessmodell mit Sicherheitsaspekten erweitert Anwendungsfallmodell mit Sicherheitsaspekten erweitert Analysemodell mit Sicherheitsaspekten erweitert Bedrohungs und Risikomodell Benutzerrechtemodell Kontext Das Prozessmuster zur Anforderungsspezifikation zugriffssicherer Systeme wird in einen ob jektorientierten Vorgehensprozess zum Beispiel aus JBR99 integriert Die Integrati on der Anforderungsspezifikation zugriffssicherer Systeme in einen Softwarelebenszyklus wur de bereits im Prozessmuster 5 1 in Abschnitt 5 3 1 vorgestellt Neben den vorgestellten Aufgaben sind auch Aktivit ten zur Ressourcen und Budgetplanung durchzuf hren die jedoch im Rahmen dieses Prozessmusters nicht betrachtet werden Da sich 78 Ein Prozess zur Entwicklung von Anforderungsspezifikationen die vorliegende Arbeit auf Prozesse und Produktartefakte in der Entwicklung zugriffssicherer Software beschr nkt werden derartige Managementaspekte nicht behandelt Struktur Das Aktivit tsdiagramm in Abbildung zeigt den Ablauf der Anforderungsspezifikation zugriffssicherer Systeme mit Einbindung des Sicherheitsmikroprozesses wie dies in der L sung vorgeschlagen wurde Vv oe Sicherheits zugriffssicherer Systeme mikroprozess Prozessmuster 6 1 Prozessmuster 5 3 A Anwendungsfallmodellierung Sicherheits zugriffssicherer Systeme mikroprozess P
383. utzziele m glich ist bilden wir die Potenzmenge der in Abbildung 6 3 definierten Stereotypen Abbildung 6 4 zeigt die m glichen kombinierten Stereotypen als Schutzziel Icons Zur Vollst ndigkeit der Potenzmenge ber den gegebenen Stereotypen zu den Schutzzielen fehlt noch das Element f r die leere Menge das sich durch eine Klasse ohne Schutzziel Stereotyp ausdr cken l sst Kombinierte Stereotypen bilden eine AND Verkn pfung zwischen den einzelnen Stereotypen Wird beispielsweise ein Objekt mit den Schutzzielen Integrit t und Vertraulichkeit gekenn zeichnet so ist das gekennzeichnete Objekt sowohl potenzielles Angriffsziel f r unerlaubtes Lesen als auch f r unerlaubte Manipulation Individual 1 1 Class ACActor 1 1 ok Method 1 Permission l Activity Read Write Create Method Method Method Parameter Abbildung 6 5 Metamodell zur Spezifikation von Berechtigungen Im Folgenden betrachten wir die genaue Bedeutung der in Abbildung 6 3 vorgestellten Stereo typen zu den Schutzzielen Vertraulichkeit Integrit t und Nichtabstreitbarkeit in Klassendia grammen Basis f r die formale Betrachtung der Schutzziele im Kontext der Gesch ftsobjekte und Aktivit ten bilden der Spezifikationsrahmen P MOS aus Abschnitt die formale Mo dellierung von Benutzerrechten aus Abschnitt 4 4 sowie das in Abbildung darge
384. vit ten der Gesch ftsprozesse sind im Rahmen der Anwendungsfallmodellierung zugriffssicherer Systeme den neuen Struk turen und Ablaufeinheiten anzupassen zu verfeinern und zu erg nzen Das Dom nenmodell bei der Erarbeitung der Anwendungsf lle erweitert und optimiert Hier zu sind die Berechtigungen in der Benutzerrechtematrix zu berarbeiten F r neu hinzu gef gte Klassen sind Berechtigungen mit aufzunehmen Werden Klassen optimiert beispiels weise durch die Einf hrung von Superklassen zur Modellierung der Gemeinsamkeiten so sind die Berechtigungen f r die Super und Subklassen anzupassen Auch bei der nderung von Attributen der Klassen sind die Benutzerrechte zu berpr fen da beispielsweise die Hinzu nahme oder Wegnahme von sensitiven Daten zu einer Klasse die Benutzerrechte beeinflussen Weiterhin kann eine berarbeitung der Benutzerrechte auch durch die nderung der Klas senstruktur hervorgerufen werden so zum Beispiel durch die Auslagerung von Attributen in eigene Klassen und die damit verbundene nderung von Assoziationen Die Benutzerrechte zur Ausf hrung von Aktivit ten und Abl ufen sind innerhalb der An wendungsfallmodellierung zugriffssicherer Systeme zu berarbeiten Da zu Beginn der An wendungsfallmodellierung zugriffssicherer Systeme festgelegt wird welche Abl ufe im zu ent wickelnden System umgesetzt werden sind nur diejenigen Benutzerrechte f r die im System umzusetzenden Teile weiterhin zu modellieren
385. weitere Nutzer des Systems k nnen sowohl nde rungen an der Projektinitialisierung als auch an den Stunden buchungen durchf hren R015 Das Risiko wird hoch eingestuft da durch unbefugte Anderun gen an den Stundenbuchungen falsche Budgetberechnungen er geben k nnen Weiterhin k nnen sich wie in der Risikobewer tung R012 bereits beschrieben wurde Inkonsistenzen im Projek tablauf ergeben und nderungen in Buchungen k nnen legitim werden indem die Projektaktivit ten angepasst werden Fortsetzung auf der n chsten Seite 134 Die Gesch ftsprozessmodellierung zugriffssicherer Systeme Fortsetzung von Tabelle 6 2 account online B016 Beim Buchen von Stunden innerhalb des Systems d h beim Online Buchen k nnen die Daten von unbefugten Akteuren des Systems gelesen bzw modifiziert werden R016 Das Risiko wird hoch eingestuft da vertrauliche Projektinfor mation zur Erstellung von Statistiken benutzt werden kann und somit f r ein Unternehmen sicherheitskritische Projektinforma tionen erlangt werden k nnen Die Ab nderung von Buchungs daten kann zudem zu einer berschreitung des Budgets f hren B017 Projektmitarbeiter deren Stundenberechnungen bei der Kon trolle durch den Projektleiter fehlerhaft sind behaupten dass sie keine falschen Stundenbuchungen z B zu viele Stunden ge bucht durchgef hrt haben Weiterhin k nnen sie etwa behaup ten dass sie fehlende Stundenbuchen eingetragen haben obwohl sie dies
386. wendungsf llen welche einer oder mehrerer Aktivit ten eines Gesch ftsprozesses zugeordnet sind verbergen sich Abl ufe Diese Abl ufe beschreiben letztendlich mit einer Menge von Methodenaufrufen und Kontrollstrukturen eine Menge aus Datenzugriffen auf Objekten des Dom nenmodells und aus Aufrufen von Systemfunktionen Berechnungsfunktionen oder Funktionen externer Systeme wie Datenbankzugriffe etc Will nun ein Akteur einen Anwendungsfall ausf hren so muss der Akteur f r all diese Methodenaufrufe die notwendigen Benutzerrechte besitzen andernfalls w rde die Ausf hrung des Anwendungsfalls zwischendurch abbrechen Fassen wir alle Berech tigungen die ein Akteur bei der Ausf hrung eines Ablaufs ben tigt zusammen so erhalten wir das Ausf hrungsrecht f r einen Anwendungsfall Wir k nnen somit die Ausf hrungsrechte eines Anwendungsfalls aus den Methodenaufrufen innerhalb des Anwendungsfalls berechnen Da ein Anwendungsfall weiterhin einer oder mehrerer Aktivit ten zugeordnet ist k nnen wir somit auch die Ausf hrungsrechte einer Aktivit t berechnen oder gegebenenfalls mit einer spezifizierten Ausf hrungsberechtigung vgl Abschnitt 16 3 3 vergleichen Grenzen der Berechenbarkeit von Ausf hrungsrechten W re es allgemein m glich die Ausf hrungsrechte von Aktivit ten und Anwendungsf llen aus den Zugriffsrechten auf Datenobjekten und Systemfunktionen zu berechnen so w re ei ne Spezifikation der Ausf hrungsrechte unn tig
387. wendungsfallmodellierung und der Analyse sind im Benutzerrechtemodell zu beschreiben Das Benutzerrechtemodell ist kein Bestandteil der klassischen Anforde rungsspezifikation Tabelle gibt einen berblick ber die Produktartefakte der Anforderungsspezifikation zugriffssicherer Systeme inklusive der hinzuzuf genden Inhalte in den jeweiligen Prozessab schnitten der Anforderungsspezifikation Wie bereits erl utert sind das Dom nenmodell das 85 5 4 bersicht ber die Produktartefakte JIOISITEULIOF ATyeYIpesd xLIyewogy9110ZInUOgT Jop UI purs 9YQI9LIOZINUOT OV oyoIssuNnIYHJsny pun syusnz Jop Sunzurgsiq pun FunIoura lo UOTWYITUEEIN Jop usdunmm d sqn Jop pun UIWYLUJEN UoyIsty uoZunyorpog Jop Sunsseduy pun sunzuesiq Ud OYOIOIg uoA UOTPIUGod pun UemsnV USIIeUIZS UT offeJsgunpuamuy Jop SUNJoISITRoY Usse yL pun suorsge1ogu ssues10A yu asATRUY Jop WUIeISeIpuossely neuesun NZ UdlIeUIZG UL UOIYBULIOJSUELL mnz Sunqleiyosog sjey Sunqreryosoq eJSSUNPUSMUY 9 10UTOJ 10A oTTRJSSuUNpUIMUY ne oypoissuniynjsny Joep pun sujoyssunpuomuy sop oy3 0fqQ ne sypoaspLIanZz u u q nry s q AIyeyIpeId I9PO TRULIOFUL Jop SUNJOULoj10A pun JUNI P MIH UOWTBUEEIN Jop uodunmm d oqn Jop pun uourgeugepy uoyisty uesunyorpeg Jop Sunsseduy pun Sunzuesiq OT RJSSUNPUIMUY 94 19919M 19 NOLIOYDISSHLIENZ Jop usyyodsy YIU PUN WatOl UNJPUNAS IoY LOIS INJ offeJs3unpuamuespotLIioydIg
388. werden Insbesondere sind nur diejenigen Entit ten des Dom nenmodells weiterhin zu betrachten die bei den umzusetzenden Abl ufen zur Daten haltung notwendig sind Im Klassendiagramm sind Redundanzen zu eliminieren Gemeinsam keiten zu erkennen und Assoziationen anzupassen Ein berblick ber die Aktivit ten der Anwendungsfallmodellierung gibt Abschnitt Ebenso wie bei der heute blichen Gesch ftsprozessmodellierung werden Sicherheitsaspekte bei der Anwendungsfallmodellierung kaum betrachtet Auch hier steht die Entwicklung der Funktionalit t im Vordergrund Nach werden nichtfunktionale Anforderungen unter die auch Sicherheitsanforderungen eingeordnet werden k nnen innerhalb der Spezifikation der Anwendungsf lle nur aufgenommen die Ausarbeitung aber in die Designphase verschoben Innerhalb der Anwendungsfallmodellierung kann jedoch die in der Gesch ftsprozessmodellie rung zugriffssicherer Systeme begonnene Sicherheitsanalyse fortgesetzt werden F r definierte Bedrohungen m ssen die ermittelten Ma nahmen in die Abl ufe integriert werden Neu hin zugef gte oder modifizierte Abl ufe sowie Entit ten des Dom nenmodells k nnen iterativ nach dem bereits vorgestellten Verfahren siehe Kapitel 6 der Schutzzielanalyse mit an schlie ender Ermittlung der Bedrohungen Risiken und Ma nahmen unterzogen werden Die Benutzerrechte auf Aktivit ten und Entit ten sind anzupassen zu erweitern und gegebenen falls zu konkretisieren Das Schutz
389. wird Weiterhin sind auch in der Konstruktion und Auslieferung Iterationen m glich wie in Kru00 JBR99 beschrieben Phasen Inception Elaboration Construction Transition Projektmission amp Sicherheitsziel Sicherheits definition Q f f N H H a Design D 2 Implementierung z Test 1 2 is n nt 1 s n p m l m Iterationen Abbildung 5 5 Phasen Kernarbeitsschritte und Iterationen im Lebenszyklusmodell 5 3 Das Vorgehen 75 Vor und Nachteile Durch die Anwendung des um die Anforderungsspezifikation abge nderten Lebenszyklusmo dells wird eine fr hzeitige Betrachtung von Sicherheit im Prozess erm glicht da Sicherheits aspekte in den entsprechenden Prozessabschnitten analytisch erarbeitet werden wie wir in den einzelnen Prozessmustern noch sehen k nnen Anforderungen an die Zugriffssicherheit werden bei der Analyse der funktionalen Anforde rungen integriert und umgesetzt sodass sie im Design und in der Implementierung umgesetzt werden k nnen Gegebenfalls sind formale Testmethoden anzuwenden um den Nachweis der Sicherheitserbringung zu garantieren Da dies jedoch au erhalb des Rahmens dieser Arbeit liegt gehen wir darauf nicht n her ein Soweit Firmen oder Institutionen eigens definierte Prozesse innerhalb der Ausarbeitungsphase festgelegt haben k nnen diese nicht ohne weiteres gegen eine Phase der Anforderungsspezifi kation zugriffssicherer
390. xistierende Methoden zur Entwicklung von sicheren Systemen wurden vorab zur Entwick lung von Sicherheitsanforderungen untersucht Basierend auf den Ergebnissen wurden Anfor derungen an einen Prozess zur Entwicklung sicherer Systeme abgeleitet Da sich die Arbeit auf den Ausschnitt der Anforderungsdefinition zugriffssicherer Systeme beschr nkt wird die Eingliederung der Sicherheitsanalyse in den Softwarelebenszyklus gezeigt Zur Ermittlung der Sicherheitsanforderungen wurde der dreistufige Prozess der Anforderungsspezifikation zu griffssicherer Systeme entwickelt Zur Ermittlung von Sicherheitsanforderungen in den einzel nen Abschnitten der Anforderungsspezifikation zugriffssicherer Systeme kommt ein iterativ 196 Zusammenfassung und Ausblick ausfiihrbarer Sicherheitsmikroprozess zum Einsatz Im Hinblick auf eine Integration der vor gestellten Prozesse in verschiedene objektorientierte Vorgehensmodelle wurden die Prozesse mithilfe von Prozessmustern beschrieben Die drei Abschnitte der Sicherheitsanalyse die Gesch ftsprozessmodellierung die Anwen dungsfallmodellierung und die Analyse zugriffssicherer Systeme werden auf eine durchge hende und sukzessive Modellierung von Aspekten der Zugriffssicherheit untersucht In allen Abschnitten werden die Produktartefakte ermittelt die zur Spezifikation der Sicherheitsa spekte zu verwenden zu erweitern und zu erg nzen sind Bei der Beschreibung der Pro zesse werden die Aktivit ten zur Ermittlung
391. ziel Authentifikation das bis jetzt nur eine untergeordnete Rolle gespielt hat ist im Rahmen der Anwendungsfallmodellierung zugriffssicherer Systeme detailliert zu betrachten Zur Darstellung des Schutzziels Authentifikation erweitern wir in Abschnitt Aktivit ts diagramme Eine Modellierung der Autorisierung erfordert zudem die Beschreibung von Sit zungen in UML Aktivit tsdiagammen Innerhalb der Verfeinerung von Authentifikation und 142 Die Anwendungsfallmodellierung zugriffssicherer Systeme Sitzungen betrachten wir die Trennung zwischen Authentifikation und Autorisierung sowie den Ubergang von der exemplarischen Authentifikation zur allgemeinen Authentifikation die zumeist nur zu Beginn einer Systemnutzung ausgef hrt wird Sicherheitsanforderungen k nnen die Abl ufe innerhalb der Anwendungsf lle ver ndern oder eigenst ndige zus tzliche Anwendungsf lle erfordern In Abschnitt betrachten wir die Entwicklung von Sicherheitsanwendungsf llen und deren strukturierte Beschreibung Modifikationen an den Abl ufen Akteuren und am Dom nenmodell erfordern auch eine An passung der bereits spezifizierten Benutzerrechte Abschnitt 7 4 beschreibt die Evolution der Berechtigungen und geht dabei auch auf die Zusammenh nge der Benutzerrechte in Struktur und Verhalten genauer ein F r Abl ufe in denen zum Zeitpunkt der Spezifikation der An wendungsf lle schon klar definiert werden kann auf welche Teilabl ufe und Daten zugegriffen wir
392. zu transformieren Die Schutzziele mit ihren Bedrohungen Risiken und Ma nahmen m ssen hier nicht erneut in die Klassen aufgenommen werden da zur Behandlung der Bedrohungen mit nicht geringf gigem Risiko bereits Ma nahmen ermittelt und in die funktionalen Anforderungen integriert worden sind Die Benutzerrechte aus dem Dom nenmodell werden f r die Klassen des Analysemodells bernommen Die Anforderungen an das Verhalten werden innerhalb der Analyse zugriffssicherer Systeme von textuell spezifizierten Anwendungsf llen in semiformale Ablaufszenarien verfeinert Dabei 8 6 Zusammenfassung 193 sind die Anforderungen an die Zugriffssicherheit die innerhalb der Anwendungsfalle struktu rell beschrieben wurden in funktionale Abl ufe und Klassen zu verfeinern F r die Anderun gen am Klassendiagramm der Analyse und die hinzugef gten Vorgangs Interaktions und Fachklassen m ssen die Benutzerrechte transformiert oder neu ermittelt werden F r eine automatische Codegenierung zur berpr fung der Benutzerrechte m ssen diese am Ende der Analyse zugriffssicherer Systeme in einer pr dikativen Form vorliegen Alle Be nutzerrechte die vorab nur informal spezifiziert worden sind sind innerhalb der Analyse zu formalisieren Neben der durchg ngigen sukzessiven und gemeinsamen Entwicklung von Funktionalit t und Sicherheit wurde auch das Ziel der lokalen Ermittlung der Sicherheit erf llt Bei der Reali sierung der Anwendungsf lle werden
393. zung authentifiziert werden muss Um derartige Sitzungen und Authentifikationen innerhalb der Ablaufdiagramme exemplarisch darstellen zu k nnen f hren wir zwischen den Schutzziel Icons zur Authentifikation besondere Assoziationen mit Start und Endsymbolen ein Wird die Authentifikation nur f r eine einzelne Aktivit t innerhalb eines Ablaufs gefordert findet die Authentifikation unmittelbar vor der Ausf hrung der Aktivit t statt und wird an schlie end sofort beendigt Abbildung 7 4 a zeigt hierzu die speziellen Symbole zur Darstel lung des Beginns und Endes einer Authentifikation Analog zu einem Aktivit tsfluss innerhalb eines Aktivit tsdiagramms f hren wir hier einen eigenen Fluss f r die Authentifikation ein In diesem trivialen Fall der Authentifikation indem die Sitzung nur aus einer einzigen Akti vit t besteht und der Beginn und das Ende der Authentifikation aus dem Authentifikations Icon erkennbar sind k nnen wir in diesem Spezialfall die Kennzeichnung des Beginns und Endes auch weglassen siehe Abbildung 7 4 b Die alleinige Verwendung des Schutzziels Authentifikation ohne weitere Darstellung einer Sitzung fordert somit dass f r diese spezielle Aktivit t eine eigene Authentifikation stattzufinden hat 150 Die Anwendungsfallmodellierung zugriffssicherer Systeme Administrator Project Manager Team Worker Vv create new T project SEC fon aPKIo N fi

Methode zur Integration von Sicherheitsanforderungen

Contents

Download Pdf Manuals

Related Search

Related Contents