1

Hauptseminar Informatik � SS2002

Sicherheit für Informationssysteme Thema: Zugriffssicherheit I

am 02.05.2002

Bearbeitung: Daniel Koke Mykhaylo Mukhachov

Kapitel 1 - 7.3,11,12 Kapitel 8 - 10.5

Betreuung: Angelika Reiser

2

1. EINLEITUNG .......................................................................................................... 4

2. IDENTIFIKATION ................................................................................................... 4

3. AUTHENTIFIKATION............................................................................................. 4

3.1. Problematik..................................................................................................................................................... 4

3.2. Wissen.............................................................................................................................................................. 5 3.2.1. Passwort.................................................................................................................................................... 5 3.2.2. Challenge-Response.................................................................................................................................. 5 3.2.3. Zero-Knowledge ....................................................................................................................................... 5 3.2.4. elektronische Schlüssel ............................................................................................................................. 5 3.2.5. Telefonnetz ............................................................................................................................................... 6

3.3. Besitz................................................................................................................................................................ 6 3.3.1. Schlüssel, Ausweis ................................................................................................................................... 6 3.3.2. Karten ....................................................................................................................................................... 6

3.4. Biometrische Systeme..................................................................................................................................... 6 3.4.1. Problematik............................................................................................................................................... 6 3.4.2. Fehler ........................................................................................................................................................ 7 3.4.3. Finger........................................................................................................................................................ 7 3.4.4. Hand.......................................................................................................................................................... 7 3.4.5. Gesicht ...................................................................................................................................................... 7 3.4.6. Unterschrift ............................................................................................................................................... 8 3.4.7. Stimme & Lippenbewegung ..................................................................................................................... 8 3.4.8. Auge.......................................................................................................................................................... 8 3.4.9. Hybridsysteme .......................................................................................................................................... 8

3.5. Zukunftsprognose........................................................................................................................................... 8

4. AUTORISIERUNG.................................................................................................. 9

5. VERTRAULICHKEIT.............................................................................................. 9

5.1. Information - Daten........................................................................................................................................ 9

5.2. Unzulässiger Datenfluss ................................................................................................................................. 9

5.3. Problematik................................................................................................................................................... 10

5.4. Beispiel........................................................................................................................................................... 10

6 UMSETZUNG ........................................................................................................ 10

6.1. Secure RPC (Remote Procedure Call) ........................................................................................................ 10

6.2. Kerberos ........................................................................................................................................................ 11

6.3. CHAP (Challenge Handshake Authentication Protocol) .......................................................................... 12

6.4. Radius (Remote Authentication Dial-In User Service).............................................................................. 12

7. WEITERE BEGRIFFE .......................................................................................... 12

7.1. Zutrittskontrolle ........................................................................................................................................... 12

3

7.2. Zugangskontrolle .......................................................................................................................................... 12

7.3. Zugriffskontrolle........................................................................................................................................... 12

8. ANFORDERUNGEN AN EIN SICHERHEITSSYSTEM........................................ 13

9. RACF.................................................................................................................... 13

9.1. Begriffserklärung ......................................................................................................................................... 13

9.2. Arbeitslauf..................................................................................................................................................... 14 9.2.1. Identifikation und Authentifizierung des Benutzers ............................................................................... 14 9.2.2. Zugriffskontrolle..................................................................................................................................... 15 9.2.3. Angriff- und Zugriffsprotokollierung ..................................................................................................... 15 9.2.4. Verwaltungs-Tools ................................................................................................................................. 15

9.3. Konzepte........................................................................................................................................................ 16 9.3.1. Was ist zu sichern? - Objekte ................................................................................................................. 16 9.3.2. Welche Sicherheitsstufe ist zu erreichen?............................................................................................... 17 9.3.3. Welche Funktionen von RACF sind dazu zu verwenden?...................................................................... 17 9.3.4. Wie soll das Ganze organisiert werden? ................................................................................................. 17

10. IT-SICHERHEITSKRITERIEN ............................................................................ 17

10.1. TCSEC � Orange Book� ............................................................................................................................ 18

10.2. IT � Criteria ................................................................................................................................................ 18

10.3. ITSEC.......................................................................................................................................................... 19

10.4. Common Criteria........................................................................................................................................ 20

10.5. Evaluationsmethodologie ........................................................................................................................... 20

11. SICHERHEITSMODELLE .................................................................................. 20

11.1. Klassifikation .............................................................................................................................................. 20

11.2. Zugriffskontrollmodelle ............................................................................................................................. 21 11.2.1. Datensicherheit ..................................................................................................................................... 21 11.2.2. Informationssicherheit .......................................................................................................................... 21

11.3. Informationsflussmodelle........................................................................................................................... 21

12. FAZIT.................................................................................................................. 21

13. LITERATURVERZEICHNIS ............................................................................... 23

4

1. Einleitung Der erste Vortrag ist auf die allgemeine Sicherheitsproblematik der elektronischen Datenver-arbeitung und deren Systeme eingegangen. Der zweite Vortrag über die Gebäudetechnik in Rechenzentrum hat dann die verschiedenen Schutzmechanismen der Hardware ins Auge ge-fasst. Diese sollen Umwelteinflüssen, Vandalismus und gezielten Angriffen auf die Hardware vorbeugen. Im folgenden Vortrag wird daran angeknüpft und auf die Sicherung der Informationen, die durch die obige Hardware verwaltet und bearbeitet werden, eingegangen. Der erste Teil des Vortrags zeigt die verschiedenen Möglichkeiten, wie der Zugang zu den Daten geschützt wer-den kann. Der zweite Teil beschreibt das System RACF, das auf vorher genannte Techniken zurückgreift, und die verschiedenen Sicherheitskriterien.

2. Identifikation Identifikation dient der Feststellung der Identität. Die Identität stellt die Übereinstimmung einer Person oder Sache mit seinen jeweiligen Fähigkeiten und Eigenschaften dar. Dabei kann es sich um Personen handeln, die Zugang zu einem System bekommen oder bestimmte In-formationen erhalten wollen. Es kann aber auch ein System sein, das von einem anderen Sy-stem Informationen erhalten oder selber Informationen weitergeben will.

z.B. Hr. Peter Müller meldet sich mit seinem Benutzernamen mueller an oder Bankautomat will Kontoinformationen des Bedieners ändern (Abheben)

3. Authentifikation Authentifikation soll die Echtheit der Identität oder der Information sicherstellen. Ist die Iden-tität korrekt und stammt die Information wirklich von der vorgegebenen Quelle?

z.B. Ist derjenige, der sich mit dem Benutzernamen mueller anmeldet auch wirklich Hr. Peter

Müller?

Dabei wird der Identifikator um zusätzliche Informationen erweitert um eine eindeutige Au-thentifikation sicherzustellen. Es gibt drei verschiedene Arten der Authentifikation:

• Wissen • Besitz • Biometrik

Die verschiedenen Techniken überschneiden sich in der Definition. In der Praxis werden die Systeme kombiniert, um eine größere Sicherheit zu erhalten.

3.1. Problematik Die Authentifikation findet meistens nur einseitig statt. Nur der Benutzer kann oder muss sich authentifizieren. Das System oder der jeweilige Prozess dagegen authentifiziert sich meistens nicht gegenüber dem Benutzer. Die Gefahr besteht darin, dass der Benutzer nicht weiß ob er beispielsweise mit dem richtigen Server kommuniziert. Gelänge es einem Angreifer sich als Server auszugeben, so könnte er dem Benutzer ein Login-Vorgang durchführen lassen und dadurch an Benutzernamen und Passwort gelangen. Der Benutzer würde davon nichts mitbekommen. z.B. Aufsatz an Bankautomaten, um an die PIN-Nummer und an die Karte zu kommen

5

3.2. Wissen Hierbei wird der Identifikator um Wissen erweitert, das überprüft wird. Die Sicherheit dieser Authentifikation hängt stark von der Verwaltung dieser Daten ab. Das System muss zu jedem Identifikator das jeweilige abzufragende Wissen sicher speichern. Falls jemand an die gespei-cherten Daten gelangen würde, ist die Sicherheit natürlich nicht mehr vorhanden. Durch den Einsatz von Verschlüsselungstechniken soll die Speicherung und der Übertra-gungsweg sicher gemacht werden (siehe Vortrag 4 �Zugriffssicherheit II�). Das zweite Sicherheitsproblem stellt der Benutzer dar. Entweder lässt sich das Wissen sehr leicht erraten oder durch geeignete Programme knacken, oder der Benutzer schreibt das Wis-sen auf einen Zettel oder legt es in einer Datei oder ähnlichem ab, wo es anderen Personen zugänglich ist.

3.2.1. Passwort Das Passwortverfahren ist das einfachste Verfahren. Dabei wird dem Identifikator ein Pass-wort zugeordnet, das bei jeder Authentifizierung überprüft wird. Dabei ist die Sicherheit der Authentifizierung von der Wahl des Passwortes abhängig. Ein leicht zu erratendes Passwort bietet nur eine sehr geringe Sicherheit. Um Passwörter sicherer zu machen gibt es noch ergänzende Maßnahmen:

• Systemgenerierte Kennwörter (z.B. PIN-Nummer für EC-Karten) • Einmal-Passworte (z.B. TAN-Nummer für OnlineBanking, S/Key-Verfahren)

3.2.2. Challenge-Response Die Challenge-Response Technik stellt eine Verallgemeinerung des Passwortverfahrens dar. Zur Authentifikation wird eine Folge von Frage�Antwort Paaren durchlaufen. Viele Ver-schiedene Verfahren beruhen auf der Challenge-Response Technik (Login, PIN abfrage am Geldautomat, PGP etc.). z.B. login: mueller passwort: az3jd Geburtstag: 12.10.1967 Lieblingsfarbe: rot Häufig werden Challenge-Response Verfahren in Authentifizierungsprotokollen oder in Ver-bindung mit Chipkarten eingesetzt.

3.2.3. Zero-Knowledge Dies ist eine spezielle Challenge-Response Technik. Sie beruht auf der Frage, wie der Teil-nehmer A einem anderen Teilnehmer B überzeugen kann das er ein Geheimnis kennt, ohne das er es B nennt. Das erste Verfahren dieser Art ist das Fiat-Shamir Verfahren, dass auf der Verwendung von Schlüsselpaaren(öffentlich-geheim) beruht.

3.2.4. elektronische Schlüssel Bei Schlüssel Techniken besitzt ein Benutzer zwei elektronische Schlüssel - einen öffentli-chen und einen privaten. Mit dem öffentlichen Schlüssel wird die Information gesichert. Der Empfänger der Information kann dann mit dem privaten Schlüssel die Information entsichern. Da dafür beide Schlüssel zusammenpassen müssen ist die Authentizität der Informationsquel-le sichergestellt. Ein bekanntes Beispiel dafür ist das Public-Key Verfahren. (siehe Vortrag 4 �Zugriffssicher-heit II)

6

3.2.5. Telefonnetz Das Telefonnetz kann heutzutage auch bei der Einwahl in Netzwerke zur Authentifizierung genutzt werden. Man kann beispielsweise die übermittelte Rufnummer überprüfen oder Rück-rufnummern hinterlegen, auf der der Firmenrechner zurückruft.

3.3. Besitz Die Authentifizierung mittels Besitz wird normalerweise zusätzlich zu der Wissenbasierten verwendet. Dabei muss der Benutzer im Besitz eines bestimmten Gegenstandes sein, um sich zu authentifizieren. Die Sicherheit ist dadurch natürlich deutlich angestiegen, da es schwierig für potentielle Angreifer ist, in den Besitz des nötigen Gegenstandes zu gelangen.

3.3.1. Schlüssel, Ausweis Die einfachste Form stellen Schlüssel und Ausweise dar. Schlüssel werden benötigt um Schließmechanismen in Türen, Tresoren o.ä. zu öffnen. Die Ausweise werden beispielsweise bei Firmen an der Pforte benötigt, um sich gegenüber dem Pförtner auszuweisen.

3.3.2. Karten Der Benutzer besitzt eine Karte, auf der bestimmte Informationen gespeichert sind. Mittels eines Lesegerätes werden diese Informationen an das Authentifizierungssystem gesendet. Es gibt verschiedene Kartensysteme:

• Magnetkarten Die Karten besitzen auf einer Seite einen Magnetstreifen, in dem Informationen fest gespeichert sind.

• Chipkarten Sie besitzen nur einen kleinen, nicht flüchtigen EEPROM-Speicher indem die nötigen Informationen abgelegt sind. z.B. Telefon- oder Krankenversicherungskarten

• Intelligente Speicherkarten Diese Karten verfügen über eine zusätzliche Sicherheitslogik die meistens in Form von PIN-Speicherung und Überprüfung auf den Karten zu finden ist. Außerdem verfü-gen sie zusätzlich über Zähler, die meist Fehlversuche festhalten und bei überschreiten einer festgelegten Schwelle die Karte sperren. z.B. Kreditkarten

• SmartCard Karten, die zusätzlich programmierbaren Speicher und einen eigenen Mikroprozessor besitzen werden als SmardCard bezeichnet. z.B. Geldkarte, JavaCard, SIM-Karte im Handy, Firmen-Karte

• Super Smart Card Die SuperSmartCards besitzen zusätzlich noch eine eigene Tastatur und ein eigenes Display und werden mit Solarzellen oder Batterien betrieben.

3.4. Biometrische Systeme Bei Biometrischen Systemen werden Teile des menschlichen Körpers als Authentifizierungs-merkmal benutzt. Dabei greift man auf physiologische oder verhaltenstypische Merkmale einer Person zurück.

3.4.1. Problematik Anders als bei den bisherigen Verfahren ist eine 100% Übereinstimmung des aktuellen Wer-tes mit den Referenzwerten nicht möglich. Dies beruht darauf, dass sich Eigenschaften einer Person im Laufe der Zeit geringfügig ändern können (z.B. Verletzung, Stress, Umgebungsein-flüsse). Ab einer bestimmten prozentualen Übereinstimmung wird die Identität bestätigt.

7

Die Referenzwerte müssen dabei sicher gespeichert werden. Dies geschieht entweder in dem jeweiligem System selber oder beispielsweise auf Chipkarten. Durch Biometrische Systeme entstehen Gefahren:

• Informationelle Selbstbestimmungsrecht (z.B. illegale Rasterfandung, Mitarbeiterüberwachung, Bewegungsprofile, Krankheitsbilder)

• Gewaltsame Übergriffe (z.B. abgetrennte Körperteile) • Unveränderlichkeit der Merkmale (z.B. offen gelegte Daten können nicht erneuert

werden)

3.4.2. Fehler Bei biometrischen Systemen gibt es zwei Typen von Fehlern:

• 1.Art: Berechtigter Benutzer wird abgewiesen • 2.Art: Unberechtigter Benutzer wird akzeptiert

Umso niedriger die Toleranzschwelle ist, umso höher ist der Fehler 1.Art. Der Fehler 2.Art verhält sich genau entgegengesetzt. Angestrebt wird ein niedrige Gleichfehlerrate (Schnitt-punkt beider Fehlerkurven).

3.4.3. Finger Bei dieser Technik werden charakteristische Linien des Fingerabdruckes gespeichert und zur Authentifizierung benützt. Es gibt verschiedene Unterscheidungskriterien wie Verzweigun-gen, Wirbel oder Abstände zwischen Linien oder Poren. Das FBI war durch dieses System bereits 1960 in der Lage eine Verbrecherkartei mit Refe-renzdaten zu erstellen. Seither wurde die Technik meistens zur Verbrecherbekämpfung ver-wendet. Aber auch in anderen Spezialbereichen wie der Zugangskontrolle zu Kontrollzentren in einigen deutschen Atomkraftwerken wird die Fingerabdrucktechnik bereits verwendet. Für die Zukunft sind die verschiedensten Einsatzbereiche, wie der Zugang zu Computersystemen, Handys, SmartCards und ähnlichem denkbar. Die ersten Handys und Computermäuse mit integrierten Fingerabdrucksystemen wurden beispielsweise von Siemens schon auf der CeBit vorgestellt und sind teilweise bereits käufliche erhältlich. Beispiel: In den USA werden in manchen Staaten die Führerscheine wahlweise mit Passbild oder Fin-gerabdruck erstellt.

3.4.4. Hand Hierbei wird die Handgeometrie als Merkmal verwendet. Insbesondere die Fingerlängen sind charakteristische Merkmale einer Person. Diese Technik erzielte 1970 als erste kommerzielle Erfolge und wurde zur Zugangskontrolle zu Hochsicherheitstrakten benützt. Beispiel: Auf dem New Yorker John F. Kennedy Flughafen können sich so Reisende bei der Passkon-trolle authentifizieren und sparen sich lange Wartezeiten.

3.4.5. Gesicht Es werden bestimmte typische Gesichtsmerkmale zur Authentifizierung herangezogen. Der Vorteil daran ist, dass dies mittels Videokamera auch auf größeren Entfernungen möglich ist. Eine eindeutige Identifikation ist aber schwierig, da sich die Merkmale jeder Person oft än-dern (z.B. unterschiedliche Mimiken, Brillen, Frisuren) und unterschiedliche Lichtverhältnis-se das Ergebnis verschlechtern. Außerdem lassen sich manche Systeme bereits durch das Vorhalten eines Fotos überlisten, da das System den Unterschied nicht erkennen kann. Des-wegen muss nicht nur das Bild überprüft werden, sondern auch ob die Person wirklich anwe-send ist.

8

Beispiel: In Toronto wird diese Technik verwendet um die mehrfache Auszahlung von Unterstützungs-gelder für Sozialhilfeempfänger zu verhindern.

3.4.6. Unterschrift Bei dieser Technik werden nicht nur das Schriftbild, sondern auch der Druck des Stiftes, die Schreibgeschwindigkeit und das Schwungverhalten zur Authentifizierung herangezogen. Beispiel: Im Hotel Consul in Berlin legt der Kunde seit Anfang März 2002 den Meldezettel auf eine spezielle Schreibunterlage mit Drucksensoren. Er kann mit einem ganz normalem Stift unter-schreiben und die Sensoren registrieren zusätzlich zum Schriftbild den Druck, die Schreibzeit und die Pausen. Dadurch ist das Hotel jetzt in der Lage die Meldezettel fälschungssicher elek-tronisch abzulegen und die Aufbewahrung, die über 10Jahre erfolgen muss, kann jetzt in elek-tronischer Form Platz sparender abgelegt werden.

3.4.7. Stimme & Lippenbewegung Geräusche, die durch Resonanzen abhängig von der Mundform oder der Nasenhöhle hervor-gerufen werden, werden bei der Stimmerkennung verwendet. Bei der Erkennung mittels Lippenbewegung wird nicht auf die Stimme oder Geräusche ge-achtet, sondern nur auf die Bewegung der Lippen. Beispiel: Manhattan Chase Bank plant Stimmerkennung zur Authentifikation einzusetzen

3.4.8. Auge Für diese Art der Authentifizierung werden eindeutige charakteristische Merkmale wie die Iris oder die Retina des Auges benützt. Allein die Iris umfasst dabei 266 charakteristische Merkmale, die sich sogar bei eineigen Zwillingen unterscheiden. Kontaktlinsen, Glasaugen oder ungünstige Lichtverhältnisse haben keinen Einfluss auf die Qualität des Erkennungssy-stems. Diese Art der Authentifizierung bietet mit wenigen anderen den höchsten Grad an Sicherheit. Beispiel: Die Iriserkennung der Firma Iridian Technologies wird beispielsweise in manchen Banken (z.B. Dresdner Bank) verwendet. Auch das U.S. Department of the Treasury nützt diese Technologie.

3.4.9. Hybridsysteme Unter Hybridsystemen versteht man Systeme, die verschiedene biometrische Merkmale kom-binieren. Dadurch können äußere Störfaktoren in einigen Merkmalen leichter toleriert werden und die Gleichfehlerrate kann gering gehalten werden. Beispiel: Das Programm BioID der Firma BioID AG beruht auf den Merkmalen Lippenbewegung, Stimme und Gesichtserkennung.

3.5. Zukunftsprognose Viele neue Techniken werden in Forschungslaboren getestet. Dazu gehören beispielsweise die DNA-Analyse, die Venenanordnung auf dem Handrücken oder die Dynamik des Tastenan-schlags auf Tastaturen. Viele Unternehmen planen einige dieser Technologien im alltäglichen Leben einzusetzen. Beispielsweise in der Automobilindustrie wird über Wegfahrsperren nachgedacht, die biome-trische Eigenschaften überprüfen. Ich denke, dass sich in Zukunft verschiedene Kombinationen der obigen Techniken durchset-zen werden. Die Authentifizierung mittels biometrischen Merkmalen steht zwar noch am An-

9

fang der kommerziellen Vermarktung, aber auf lange Sicht wird sich diese Technik, in Kom-bination mit den bisherigen Techniken, durchsetzen. Sie stellt keine absolute Sicherheit dar, aber richtig eingesetzt wird der Sicherheitsgrad deutlich erhöht.

4. Autorisierung Mit Autorisierung wird die Vergabe von Rechten bezeichnet, die jeweils einer Person oder Sache zugewiesen werden. Dabei kann es sich um die verschiedensten Rechte handeln.

• Dateirechte (z.B. Schreiben, Lesen, Öffnen, Erstellen) • Zugangsrechte (z.B. Firma, Räume, PC) • Nutzungsrechte (z.B. Maschine, Internet, Drucker, Fax, Programme) • ...

Mit der Autorisierung soll der Zugriff auf Programme, Daten oder anderen Ressourcen in Netzwerken eingeschränkt werden. Außerdem kann mit der Autorisierung die Komplexität mancher Umgebungen durch speziell angepasste Menüs vereinfacht werden. Die Autorisierung muss mittels geeigneter Systeme überprüft werden. Meistens werden Auto-risierung und Authentifizierung im selben System realisiert. Systeme, die dies teilweise integriert haben, stellen beispielsweise die verschiedenen Be-triebssysteme (siehe Vortrag 9 �Sichere Betriebssysteme�), Filesysteme (siehe Vortrag 10 �Filesysteme�), Datenbanken (siehe Vortrag 6 �Implementierung in DB2�) und Spezialsyste-me wie RACF (zweiter Teil dieses Vortrags) dar.

5. Vertraulichkeit Unter Vertraulichkeit versteht man, dass keine unautorisierte Informationsgewinnung möglich ist. Also nur autorisierte Quellen (Personen, PCs, Programme etc.) erhalten die gewünschte Information.

5.1. Information - Daten Informationen werden durch IT-Systeme gespeichert und verarbeitet. Dies geschieht durch den Einsatz von Datenobjekten, in denen die Informationen abgelegt werden. Die Sicherheit der Informationen werden in folgende Stufen eingeteilt:

• Funktionssicherheit Die spezifizierte Funktionalität soll mit der tatsächlichen Funktionalität überein-stimmen. Das System soll keine funktional unzulässigen Zustände annehmen.

• Informationssicherheit Das funktionssichere System nimmt nur solche Zustände an, in denen es keine unau-torisierte Informationsgewinnung oder �veränderung gibt.

• Datensicherheit Das funktionssichere System nimmt nur Zustände an, in denen keine unautorisierten Zugriffe auf Systemressourcen und Daten möglich ist. Darunter fällt auch der Schutz der Daten durch Datensicherungen (siehe Vortrag 5 �Replikation, Spiegelung ...� und Vortrag 11 �Tertiärspeicher�).

5.2. Unzulässiger Datenfluss Datensichere Systeme müssen den unzulässigen Informationsfluss unterbinden. Erklärung anhand des folgenden Beispiels: A darf lesend auf Datei 1 und schreibend auf Datei 2 zugreifen. B darf nur lesend auf Datei 2 zugreifen. A kann jetzt die Datei 1 auslesen und die Informationen in Datei 2 schreiben. Da-durch hat B Zugriff auf die Inhalte von Datei 1. Der Informationsfluss verläuft also von Datei 1 über A und die Datei 2 zu B.

10

5.3. Problematik In vielen Bereichen ist die Vertraulichkeit der Daten nicht gewährleistet. Allein der Übertra-gungsweg stellt ein riesiges Problem dar, da in den meisten Protokollen die Daten unver-schlüsselt übertragen werden. So können unautorisierte Personen oder Objekte an personenbezogene oder vertrauliche Fir-meninformationen, Passwörter oder andere Daten gelangen. Beispiele:

• TCP/IP � Protokoll • SMTP • MIME (erlaubt außerdem ausführbare Befehle) • Telnet • Internet (siehe Vortrag 12 �Sicherheit im Internet�)

Damit das nicht so einfach geschieht, sollten die wichtigen Daten nur verschlüsselt übertragen werden (siehe Vortrag 4 �Zugriffssicherheit II�).

5.4. Beispiel Das Internet-Portal Yahoo hat sich in Amerika entschieden, die Benutzereinstellungen ihrer Kunden eigenmächtig zu ändern. Jeder Kunde erklärt sich jetzt automatisch einverstanden Werbung per E-Mail, Post und Telefon zu erhalten. Außerdem werden alle Benutzerdaten in öffentlich einsehbaren Profilen zur Verfügung gestellt. Falls gewisse Daten wie Telefonnum-mer nicht angegeben wurden, organisiert Yahoo diese von Online-Händlern und stellt sie dann ungefragt zur Verfügung. Diese Nutzungsänderungen wurden den Benutzern von Yahoo durch eine schlichte E-Mail mitgeteilt. (Süddeutsche Zeitung vom Dienstag, den 9.4.2002)

6 Umsetzung Um die Identifikation, Authentifikation und Autorisierung durchführen zu können müssen die nötigen Daten gespeichert werden. Dies geschieht in Datenbanken, die auch vor unautorisier-ten Zugriffen geschützt werden müssen (siehe Vortrag 9 �Sichere Datenbanksysteme�). Um die Verwaltung der Rechte für die Autorisierung zu erleichtern werden so genannte Be-nutzergruppen eingeführt. Jeder Gruppe werden bestimmte Rechte zugewiesen. Benutzer werden dieser Gruppe zugeteilt und erhalten dadurch die Rechte, die die Gruppe hat.

6.1. Secure RPC (Remote Procedure Call) RPC wird in verteilten Systemen eingesetzt. Der Client stellt eine Anfrage an den Server und wartet solange, bis dieser die Anfrage bearbeitet hat und seine Antwort zurücksendet. RPC baut dabei auf unsicheren Transport- und Kommunikationsprotokollen wie TCP/IP auf, die

Informationsfluss

Rechte: Lesen / Schreiben

Schreiben

LesenLesen

Datei 1 Datei 2

A B

11

die Daten unverschlüsselt übertragen. Außerdem findet keine Authentifikation zwischen Client und Server statt. Aufgrund dieser Problematik hat die Firma Sun Secure RPC entwickelt, das die Möglichkeit der Authentifikation und Verschlüsselung nach dem DES-Algorithmus bietet.

6.2. Kerberos Kerberos entstand 1983 am MIT im Rahmen des Athena Projektes in Kooperation mit IBM und DEC. Es stellt einen reinen Authentifikations- und Schlüsselaustauschdienst dar und ver-gibt keine Rechte für netzwerkweite Dienste und kontrolliert auch keine Zugriffe. Es wird in Verbindung mit herkömmliche Netzwerkdiensten wie z.B. NFS, Remote Login oder E-Mail verwendet. Kerberos besteht aus einer dezentralen Hierarchie von Authentifikationsservern, die verschie-dene Bereiche verwalten.

(1) Login mit Passwort (2) Authentifikationsbescheinigung wird von C bei AS angefordert (3) AS arbeitet mit TGS zusammen (4) AS schickt C ein Initialticket für TGS (5) C fordert bei TGS ein Ticket für NFS-Server für Joe (legt Initialticket vor) (6) TGS schickt C NFS-Ticket (7) C schickt Anfrage (legt NFS-Ticket vor)

Die Tickets sind nur für einen bestimmten Zeitraum gültig. Die Nachrichten werden jeweils mit dem zugehörigen Schlüssel verschlüsselt. Die Übertragung 4 wird beispielsweise mit dem Masterschlüssel von Joe und die Übertragung 5 mit dem Schlüssel von TGS verschlüsselt. Falls eine Authentifikation von TGS gegenüber C gefordert wird, kann dafür ein zusätzlicher Schritt 6� eingeführt werden. Der Benutzer muss sich insgesamt nur einmal gegenüber seinem Client C authentifizieren. Danach nimmt ihm diese Arbeit der Client C mit den nötigen Ticketanforderungen ab. Darin liegt aber auch die Gefahr, da die Schlüssel und die Tickets auf dem Client gespeichert werden und im Mehrbenutzerbetrieb gesichert werden müssen. Außerdem wird die Authenti-zität des Clients mittels IP-Adresse überprüft. Dieser Vorgang sollte unbedingt durch ein Challenge-Response Protokoll abgesichert werden. Weitere Gefahrenpunkte stellt die Passwortauthentifizierung des Benutzers und die Verwen-dung der Zeitstempel als Authentifizierung dar.

(7)

(6)

(5)

(4)(2)

(1)

KDC (Key Distribution Center)

Benutzer Joe

Client C

Schlüssel-datenbank

Ticket-Granting Server (stellt Ticket aus) TGS

AS (Auth.Ser.)

NFS Server

Print Server

DB Server RAS

(3)

12

6.3. CHAP (Challenge Handshake Authentication Protocol) Dieses Protokoll authentifiziert den Benutzer durch das Challenge-Response Verfahren. In diesem Fall besteht es aus drei Schritten. Ein variabler Wert wird vom Server an den Client geschickt. Beide berechnen mit einer Funktion, die nur Server und Client kennen, und einem Nachrichtenindikator ein Funktionsergebnis. Dieses wird dann zur Authentifikation vergli-chen.

6.4. Radius (Remote Authentication Dial-In User Service) Dieses Protokoll der Firma Livingston (jetzt Lucent) definiert den Datenaustausch zwischen dem RAS (Remote Access Server) und dem Radius-Server. Es wird für den Remote-Zugriff über Telefonverbindungen in Firmennetze benützt. Der Radius-Server verwaltet dabei alle Benutzer- und Konfigurationsdaten. Es können zur Authentifikation die verschiedensten oben genannten Techniken wie Passwort, Challenge-Response Verfahren oder hardwaretechnische Lösungen wie SecureID-Chipkarten verwendet werden.

7. Weitere Begriffe

7.1. Zutrittskontrolle Normalerweise wird der Zugang zu einer Firma oder einem Raum durch die Zutrittskontrolle überprüft. Hierbei soll die Zutrittskontrolle den Ein- und Ausgang kontrollieren, damit keine unbefugten Personen Zutritt erhalten oder unberechtigterweise Betriebsmittel entwendet wer-den könnten. z.B. Die Zugangskontrolle kontrolliert die Tür zum Computerraum einer Firma

7.2. Zugangskontrolle Der Zugang zu einem System wird durch die Zugangskontrolle geschützt. Beim Zugang wird die Identität festgestellt und authentifiziert. Zugang können sowohl Personen als auch Objek-te, die im Auftrag von Personen im System arbeiten (z.B. Prozesse, Server, Prozeduren), er-langen. z.B. Die Zugangskontrolle wird benötigt, um im Computerraum einen PC benutzen zu kön-nen. Der Benutzer muss ein Login durchführen.

7.3. Zugriffskontrolle Die Zugriffskontrolle überprüft dann innerhalb des Systems, ob der Zugriff auf das gewünsch-te Objekt autorisiert ist. Also ob der authentifizierte Benutzer oder das anfragende Objekt zum Informationserhalt autorisiert ist. Außerdem muss die Zugriffskontrolle den Informationsfluss kontrollieren, falls das vom jeweiligen System gewünscht ist. z.B. Um lesenden Zugriff auf die Datei mit den Kostenaufstellung der Abteilung zu haben, muss der Benutzer dafür autorisiert sein.

13

8. Anforderungen an ein Sicherheitssystem Jedes Sicherheitssystem soll folgende Funktionalitäten besitzen:

- Identifikation und Authentifizierung des Benutzers: jedes Subjekt des Sicherheitssystem soll eine eindeutige Kennung besitzen, wie auch eine Möglichkeit seine Identität nachweisen zu können;

- Zugriffskontrolle (Autorisierung): auf eine Ressource sollen nur die entsprechend autorisierte Benutzer zugreifen kön-nen;

- Angriffprotokollierung: im Falle eines Versuchs eines unautorisierten Zugriffs auf eine Ressource soll (unmit-telbar oder nach einem Zeitplan) eine Meldung in das entsprechende Protokoll ge-schrieben werden;

- Zugriffsprotokollierung (Audit): es soll eine Möglichkeit vorhanden sein, ein Protokoll der Zugriffe auf eine geschützte Ressource zu erstellen;

- Verwaltungs-Tools: die Werkzeuge für die Kennungen- und Rechtenvergabe, für die Verwaltung der Da-tenbank des Sicherheitssystems usw.

9. RACF RACF (Resource Access Control Facility) ist ein Sicherheitssystem von IBM, ein Teil des OS/390 UNIX Security Server. Wie jedes Sicherheitssystem dient es zur Bestimmung, was ein Benutzer des Rechnersystems machen darf und was er nicht darf. In anderen Worten, das Sicherheitssystem regelt die Zugriffe auf Ressourcen des Rechnersystems. Unter dem Begriff Ressource versteht man sowohl Information (Datenmengen, Applikationen usw. ), als auch die Hardware (z.B. Terminals). Jede Anfrage des Benutzers, auf eine Ressource zuzugreifen, wird vom Ressource-Manager angenommen; der Ressource-Manager erzeugt eine Anfrage an RACF zur Überprüfung, ob der Benutzer auf die Ressource zugreifen darf; RACF sieht in der RACF - Datenbank nach und erzeugt aufgrund der entsprechenden Ressource-Profile eine Antwort auf die Status-Anfrage; der Ressource-Manager bekommt die Antwort vom RACF und gestattet (oder verweigert) den Zugriff.

9.1. Begriffserklärung standardisierte Begriffe aus der Dokumentation von IBM:

- Ressource � Daten, Software, Hardware;

Anfrage vom Benutzer

RACF Daten-bank

Betriebs- system

RACF Ressource Manager

14

- Sicherheitsstufe (Security Level) � für das Rechensystem definierte geordnete numeri-sche Bezeichnung: je großer die Zahl ist, desto höher ist die Sicherheitsstufe; Beispiel: {streng geheim > geheim > vertraulich > öffentlich}

- Sicherheitskategorien (Security Category) ) � für das Rechensystem definierte Be-zeichnung der Abteilung oder des Bereichs eines Unternehmens, deren Mitglieder ähnliche Sicherheitsanforderungen haben; Beispiel: {Werbung; Finanz; Personal....}

- Sicherheitsklassifikation (Security Classification) - Verwendung der Sicherheitsstufen oder der Sicherheitskategorien (oder beider zusammen) für die zusätzliche Kontrolle des Zugriffs auf besonders vertrauliche Ressourcen;

9.2. Arbeitslauf RACF besitzt alle oben genannten Funktionalitäten:

9.2.1. Identifikation und Authentifizierung des Benutzers jeder RACF - Benutzer ist mit einer eindeutigen Kennung � �UserID� identifiziert und mittels eines geheimen Passworts authentifiziert. Es gibt auch andere Authentifizierungs-verfahren, die die Passwort-Überprüfung ersetzen oder mit ihr zusammen benutzt werden. Die Verfahren sind:

- �PassTicket� � ein einmaliges Passwort, das von RACF oder anderen dazu ver-wendeten Systemen generiert wird. Der Passticket ist in der Client � Server Um-gebung verwendet, um den RACF � Passwort nicht als klaren Text durch das Netzwerk senden. Der PassTicket kann nur einmal, auf einem bestimmten Rech-ner, innerhalb von 10 Minuten nach der Generierung benutzt werden;

- �Operator Identification Card, OIDCARD� � wird anstatt oder zusammen mit ei-nem Passwort verwendet;

- �Protected UserID� � RACF lässt eine �UserID� erzeugen, die ohne Eingabe des Passworts benutzt werden kann, aber nur für bestimmte Ziele als UNIX Dämons und andere gestartete Aufgaben;

- �Digital certificate� � in der Client-Server Umgebung kann RACF den Benutzer mit seinem digitalen Zertifikat authentifizieren. Das Zertifikat enthält Information, die den Benutzer eindeutig identifiziert.

Während der Identifikation/Authentifizierung überprüft RACF folgendes:

- ob der Benutzer für RACF definiert ist; - ob der Benutzer ein gültiges Passwort (PassTicket, OIDCARD) wie auch einen

gültigen Gruppennamen angegeben hat; - ob seine UserID und GroupID für OS/390 UNIX gültig sind; - ob der Benutzer an dem Tag zu der Zeit überhaupt zum Systemzugriff, insbeson-

dere vom Terminal berechtigt ist; - ob der Benutzer berechtigt ist, die Applikation aufzurufen.

Nachdem der Benutzer authentifiziert ist, überwacht RACF die Interaktion zwischen dem Benutzer und Ressourcen des Systems. RACF muss überprüfen, welche Benutzer auf die Res-sourcen zugreifen dürfen und wie (evtl. auch wann) sie auf diese Ressourcen zugreifen dürfen (beispielsweise �ReadOnly�).

15

9.2.2. Zugriffskontrolle Im RACF ist ein mehrstufiges System der Autorisierung realisiert. Das System funktio-niert nach dem Prinzip �Alles verboten, was nicht explizit erlaubt ist�. Nach dem An-kommen der Zugriffsanfrage vom Benutzer auf eine Ressource macht RACF folgendes:

1. überprüft die Profile des Benutzers und der Ressource um zu bestimmen, ob der Benutzer überhaupt auf die Ressource zugreifen darf.

2. überprüft die Sicherheitsklassifikation des Benutzers und der Ressource: a) RACF vergleicht die Sicherheitsstufen in den Profilen des Benutzers und der

Ressource. Ist die Sicherheitsstufe der Ressource höher, wird der Zugriff ver-weigert.

b) RACF vergleicht die Listen der Sicherheitskategorien in den Profilen des Be-nutzers und der Ressource. Enthält das Profil der Ressource eine Kategorie, die nicht in dem Profil des Benutzers vorkommt, wird der Zugriff verweigert.

3. gestattet den Zugriff, falls eine der Bedingungen erfüllt ist, wie z.B.: - UserID des Benutzers befindet sich in der Zugriffsliste mit den genügenden

Berechtigungen; - GroupID des Benutzers befindet sich in der Zugriffsliste mit den genügenden

Berechtigungen; - UserID des Benutzers befindet sich in der Liste des bedingtes Zugriff und für

den Benutzer bestimmte Bedingungen (Zeit des Zugriffes, Terminal usw.) sind erfüllt.

9.2.3. Angriff- und Zugriffsprotokollierung RACF protokolliert folgende Ereignisse:

- den unberechtigten (unautorisierten) Versuch, in das System einzuloggen; - die (un-)berechtigten Versuche auf die von RACF gesicherte Ressource zuzugrei-

fen; - die (un-)berechtigten Versuche, einen RACF - Befehl auszuführen.

Die Protokolle können mit einigen Dienstprogrammen des RACF - Systems bearbeitet werden. Mit �SMF Data Unload Utility� oder �RACF Report Writer� können die Daten aus der Protokolle sortiert, zusammengefasst wie auch in eine Datenbank importiert werden.

Es gibt auch im RACF � System Dienstprogramme, die Berichte nicht über den Datenzugriff, sondern über den RACF � Zustand erzeugen. Zum Beispiel, �Data Security Monitor� dient zur Überprüfung der grundlegenden Systemintegrität und der Steuerungselementen der Da-tensicherheit. �Icetool� erzeugt eine Menge von Berichten über die Benutzer- und Ressour-cenprofile (z.B., CONN - �Benutzer mit Sonderrechten�). Aber solche Programme gehören schon zu den Verwaltungstools.

9.2.4. Verwaltungs-Tools Das RACF � System besitzt auch einige Werkzeuge für eine bequeme Verwaltung von meh-reren Systemen, die eine oder mehrere durch das Unternehmen verteilte RACF � Datenban-ken benutzen. Der �RACF Sysplex Data Sharing� gibt dem Operator die Möglichkeit, einen Befehl auf meh-reren Systemen so auszuführen, als wäre es ein System, und eine einzige Reaktion zu be-kommen. Der Teil des �RACF Sysplex Data Sharing� � �Coupling Facility� ermöglicht dem System im �Data sharing mode� (siehe unten - RRSF) die Benutzung eines großen zentralen Puffers für die Datensätze der RACF � Datenbank.

16

Der �RACF Remote Sharing Facility� � RRSF � ermöglicht dem Administrator die Verwal-tung der mehreren durch das Unternehmen verteilten RACF � Datenbanken. Die von RRSF ermöglichte Funktionalitäten:

- Synchronisation des Passworts; - Weiterleitung des Befehls; - automatische Weiterleitung des Befehls; - automatische Weiterleitung des von Applikationen erzeugten RACF-Datenbank-

Updates; - automatische Weiterleitung des Passworts.

9.3. Konzepte Datensicherheit ist der Schutz der Daten vor zufälliger oder überlegter unerlaubter Lesean-weisung, Modifizierung oder Zerstörung. Aus der Definition folgt, dass jedes EDV-System mit dieser Datensicherheitsproblemen sich beschäftigen muss. Um die Probleme mittels RACF zu vermindern, muss man einige Fragen beantworten, und zwar:

- Was ist zu sichern? - Welche Sicherheitsstufe ist zu erreichen? - Welche Funktionen von RACF sind dazu zu verwenden? - Wie soll das Ganze organisiert werden?

9.3.1. Was ist zu sichern? - Objekte RACF unterscheidet drei globale Arten von Objekten (Ressourcen): �Data Set� � Datenmenge �Tape Data Set� � Daten auf dem Band �General Resources� - Applikationen, Terminals, ausführbare Module usw. Für jede Ressource ist in der RACF � Datenbank ein Datensatz namens �Profil� erstellt, der folgende Informationen enthält:

- Name der Ressource; - Eigentümer des Profils; - Universale Zugriffsberechtigungen; - Liste der Benutzer/Gruppen � spezifische Zugriffsberechtigungen; - Sicherheitsklassifikation; - Protokollierungsoptionen; - Warnungsoptionen; - Benachrichtigungsoptionen;

Die Profile können von folgenden Arten sein:

- �Diskrete Profile� � das Profil ist einer einzelnen Ressource zugewiesen und be-schreibt deswegen die Zugriffsmöglichkeiten ganz spezifisch (Beispiel: an ein DataSet kann nur von einen bestimmten Benutzer zugegriffen werden);

- �Generic Profile� � das Profil ist mehreren Ressourcen zugewiesen, deren Namen-strukturen einem angegebenen Muster entsprechen. In der Anleitung für den Sicherheitsadministrator ist ein Benennungspolitik vorgeschlagen (Beispiel: das Profil beschreibt alle Ressourcen mit �Schmidt� innerhalb des Namens);

- �Grouped Profile� - das Profil ist mehreren Ressourcen zugewiesen, die in einer Liste (Gruppe) angegeben sind. (Beispiel: Gruppe1 =�DataSet1, DataSet2, General Resour-ce1�)

17

9.3.2. Welche Sicherheitsstufe ist zu erreichen? Mit RACF kann Zugriff auf eine Ressource stufenweise definiert werden:

- �gestattet/ verweigert�, mit Protokollierung der Zugriffe auf die Ressource ; - �temporär gestattet� - für eine bestimmte Zeit (�grace period�). Warnungsmeldungen

werden erzeugt; - �die komplette RACF � Sicherung�. Protokollierung erfolgreicher und nicht erfolgrei-

cher Zugriffsversuche. Das Verteidigungsministerium der USA hat bestimmte Sicherheitskriterien definiert, mit de-nen man Sicherheit eines Systems bewerten und eine bestimmte Sicherheitsstufe dem System zuweisen kann. Die Kriterien werden im nächsten Kapitel betrachtet.

9.3.3. Welche Funktionen von RACF sind dazu zu verwenden? RACF hat eine Menge der Funktionen, um die notwendige Sicherheitsstufe zu gewährleisten. Die meisten davon waren schon genannt: Sicherung der Datenmengen und generellen Res-sourcen; Benennungsvereinbarungen; Gruppierung der Benutzer; Anpassung des RACF � Systems; Data Sharing; Angriffserkennung usw. Es ist auch hier zu erwähnen, dass RACF mit mehreren anderen Software-Produkten zusammenarbeiten kann: die meist bekannten � DB2, Informix, Lotus Notes � wie auch mehrere spezifische Sicherheitslösungen.

9.3.4. Wie soll das Ganze organisiert werden? Zur Organisation gehören Bestimmung der Benutzer des Systems und Zuweisung deren den Gruppen. Daten eines Benutzers sind im �User Profile� gespeichert, der sicher auch ein Da-tensatz in der RACF � Datenbank ist. Das Benutzerprofil enthält folgende Daten:

- UserID (Zahl zwischen 0 und 2147483647 = 231-1); - Passwort (verschlüsselt); - Eigentümer des Profils; - Attribute des Benutzers (Administrator, Auditor, Operator usw.) - Sicherheitsklassifikation; - TSO (Time Sharing option) Logon Daten; - andere Daten (OS/390 Unix Daten, NetView Daten usw.)

Die Gruppe ist mit einer GroupID bezeichnet. Die Information über die Gruppe ist im Grup-penprofil in der RACF � Datenbank gespeichert. Das RACF � System ist nach TCSEC- Sicherheitskriterien des Verteidigungsministerium der USA auf die Stufe B1 mit einigen Ausnahmen zertifiziert. Mehr zur Sicherheitskriterien fin-det man in der nächsten Kapitel.

10. IT-Sicherheitskriterien

Für die Bewertung der Sicherheit von IT-Systemen wurden nationale und internationale Krite-rien-Kataloge entwickelt. Dazu zählen die �Trusted Computer Security Evaluation Criteria� � TCSEC des Verteidigungsministerium der USA (1985), deutsche IT-Sicherheitskriterien (1989) , europäische �Information Technology Security Evaluation Criteria� - ITSEC (1991) und "Common Criteria for Information Technology Security Evaluation" � CCITSE (Version 2.1 - 1999), die als eine Fassung weltweit anerkannter Kriterien dienen sollen.

18

10.1. TCSEC � Orange Book� Die TCSEC wertet die Sicherheit der IT-Systeme mit Stufen D, C, B, A, wobei Stufe D ein System bezeichnet, das keine oder minimale Sicherheit gewährleistet. Die Stufe wird weiter nicht betrachtet. Stufe C erfordert, dass die Zugriffsrechte durch Benutzer individuell vergeben werden kön-nen. C1: Verteilung der Zugriffrechte nur grobgranular. Stufe C1 erfordert Maßnahmen zur Kon-trolle der Identität des Benutzers und zum Schutz dieser Kontrollfunktionen. Beispiel: klassi-sche Unix-Systeme. C2: Zugriffrechte können auch an einzelnen Benutzer vergeben oder auch Zugriffverbote festgelegt werden. Zusätzlich zur Stufe C1 soll auch die Protokollierung (Audit) der Zugriffe ausgeführt werden. Die moderne UNIX-Systeme erfüllen die Anforderungen der C2- Stufe, mit Ausnahme für Audit. Deswegen bieten mehrere Hersteller zusätzliche C2 � Programm � Pakete. Stufe B: B1: zusätzlich zur Anforderungen der Stufe C2 ist eine (linear geordnete) Menge der Sensiti-vitätsklassen {streng geheim > geheim > vertraulich > öffentlich} eingeführt. Jedem gesi-cherten Objekt ist eine Sicherheitseinstufung (Classification) und jedem Subjekt eine Sensiti-vitätsklasse (Clearance) zugewiesen. Zugriffe auf Objekte werden durch systemglobale Re-geln beschränkt. Z.B., der Subjekt darf nur für die Objekte einen Lese-Zugriff ausführen, de-ren Classification - Stufe kleiner oder gleich seiner Clearance � Stufe ist. Die systemglobale Regeln dominieren über den durch den Benutzer bestimmbaren Zugriffsrechten. B2: die Stufe erfordert eine Erstellung eines formales Sicherheitsmodells sowie Maßnahmen zur Erkennung und Behandlung verdeckter Kanäle (d.h. Kanäle, die nicht für einen Informa-tionstransfer vorgesehen sind, aber dazu missbraucht werden können) und zur Einrichtung eines vertrauenswürdigen Pfades (trusted path) beim Login � eines direkten Zugriffs des Be-nutzers zur vertrauenswürdigen Sicherheitskomponenten (trusted computing base, TCB). Das Windows NT 3.5 (Service Pack3) erfüllt die Bedingungen der StufeB2 bezüglich vertrauens-würdigen Pfades und vertrauenswürdigen Sicherheitskomponenten

B3: zusätzliche Anforderungen zum TCB � muss klein, getestet und gegen unbefugte Zugriffe geschützt sein. Alle sicherheitsrelevanten Aktionen sind zu überwachen.

Stufe A erfordert keine funktionale Erweiterungen der Stufe B3, jedoch einen formalen Nachweis einiger spezifizierter Sicherheitseigenschaften. Kritik der TCSEC - Kriterien:

- einseitige Ausrüstung auf zentralen Betriebssystemen; - starke Betonung auf die Vertraulichkeitseigenschaften � die Kriterien waren zur mili-

tärische Anwendungen angepasst, kommerzielle sind aber nicht berücksichtigt; - fehlende Trennung zwischen der Sicherheitsfunktionalität und der Qualität, mit der die

Funktionalität erbracht wird (�bestanden/nicht bestanden�, kein Punkte-System)

10.2. IT � Criteria �Grünbuch�. Deutschland 1989-90 In den Kriterien sind 10 Funktionalitätsklassen F1 � F10 beschrieben, wobei die ersten 5 de-nen des Orange Book entsprechen (F1 == C1 usw.). Als ein Maß der Vertrauenswürdigkeit der beschriebenen Funktionalitäten wurden 8 hierarchische Qualitätsstufen Q0 � Q7 einge-führt. Die Qualitätsstufe Q0 stellt die niedrigste und Q7 die höchste Qualitätsstufe dar.

19

Zur Bewertung der eingesetzten Sicherheitsmechanismen ist eine Scala definiert. Die Bewer-tung kann zum Ergebnis "ungeeignet", "schwach", "mittelstark", "stark", "sehr stark" und "nicht überwindbar" führen. Ein �ungeeigneter� Mechanismus ist nicht wirksam, während ein �schwacher� zumindest zur Abwehr unabsichtlicher Verstoße gegen die Sicherheitsanforde-rungen geeignet ist. Ein �mittelstarker� Mechanismus kann schon gegen absichtliche Angriffe schützen, ist aber mit mittelgroßem Aufwand von Personen mit normalen Kenntnissen des Systems zu überwinden. Ist der entsprechende Aufwand groß oder muss man aufwendige Hilfsmittel benutzen, um das System zu überwinden, dann ist der Mechanismus �stark� bzw. �sehr stark�, abhängig von der Große des Aufwands. Beispiel: Die Wahrscheinlichkeit der nicht korrekten Identifizierung wird untersucht. Für die �schwache� Mechanismen ist die Wahrscheinlichkeit größer als 10-2, für �mittelstarke� > 10-4 und für �sehr starke� > 10-8. Wie gesagt, die Funktionalitätsklassen F1 bis F5 sind von Klassen des Orange Book abgelei-tet. Die F6 bis F10 stellen verschiedene Anforderungen an die Integrität der Daten (in Daten-banken, z.B.). Z.B. gehören zu Anforderungen der Klasse F6 die Einführung von Rollen und Objekttypen, die Festlegung eines Trusted Path beim Login sowie die Protokollierung sicher-heitsrelevanten Zugriffe auf Daten. Die Klasse F8 benötigt die Datenintegrität während der Kommunikation, so dass Authentifizierung bei jeder Interaktion oder dem Einsatz eines feh-lererkennenden Codes erforderlich ist. Die Qualitätsstufen Q0 � Q7 bewerten folgende Parameter eines Systems:

- Qualität der Sicherheitsanforderungen, - Qualität der Spezifikation der zu evaluierenden Systemteile, - Qualität der verwendeten Mechanismen, - Qualität der Abgrenzung zu nicht zu evaluierenden Systemteilen, - Qualität des Herstellungsvorganges, - Betriebsqualität, - Qualität der Anwenderdokumentation.

Die Stufe Q0 bezeichnet ein System, dessen Qualität für keine höhere Stufe ausreichend ist. Die Q1-System ist nur grob auf Korrektheit geprüft, bietet keinen oder einen geringeren Schutz vor Manipulationen und verwendet Mechanismen mit ausreichender Stärke. Für die weiteren Stufen werden immer stärkere Mechanismen eingesetzt, bis auf �sehr starken� bei Stufen Q6-Q7. Dabei werden auch formale Techniken der Korrektheitsüberprüfung eingesetzt und es erfolgt ein Konsistenzabgleich zwischen Quellcode und Spezifikation.

10.3. ITSEC Die europäischen ITSEC � Kriterien wurden als harmonisierte Kriterien der Länder Deutsch-land, Frankreich, Großbritannien und Niederlande im Juli 1991 eingeführt. Analog zu deut-schen IT- Kriterien sind Funktionalität� und Qualitätsklassen getrennt, wobei die Bewertung der Qualität noch weiter aufgeteilt ist und zwar in die Bewertung der korrekten Funktionswei-se und in die Bewertung der Wirksamkeit der eingesetzten Mechanismen. Die Funktionali-tätsstufen entsprechen den schon dargestellten von IT � Kriterien. Zur Bewertung des Ver-trauens in die Korrektheit werden sechs hierarchische Evaluationsstufen E1 bis E6 definiert. Wichtige Forderungen, die in der angegebenen Stufe hinzukommen, sind die folgenden:

- E1: informelle Beschreibung des Architekturentwurfs, funktionale Tests und Penetra-tionstests.

- E2: informelle Beschreibung des Feinentwurfs. - E3: Bereitstellung von Quellcode bzw. Hardware-Konstruktionszeichnungen und Ab-

bildung auf die Basiskomponenten. - E4: formales Sicherheitsmodell, semiformale Notation der sicherheitsspezifischen

Funktionen, des Architektur- und des Feinentwurfs. - E5: Feinentwurf muss nachvollziehbar auf Quellcode bzw. Hardware-

Konstruktionszeichnungen abgebildet werden. - E6: formale Spezifikation des Architekturentwurfs.

20

Also, nach ITSEC � Kriterien wird die Qualität eines Systems durch ein Paar (Evaluationsstu-fe, Wirksamkeit der Mechanismen) beschrieben, z. B. (E3, hoch) � Bewertung eines AIX v4.2 � System von IBM. Das Betriebssystem NT 4.0 SP3 wird mit Stufe E3/F-C2 bewertet. Die Übereinstimmung zwischen dem �Orange Book� und den europäischen Kriterien ist in der folgenden Tabelle dargestellt: E1, F-C1 == C1 E3, F-B1 == B1 E5, F-B3 == B3 E2, F-C2 == C2 E4, F-B2 == B2 E6, F-B3 == A1

10.4. Common Criteria Mit den Common Criteria (�Common Criteria for Information Technology Security Evaluati-on�) werden seit 1996 Kriterien entwickelt, die als Grundlage für einen internationalen Stand-art dienen. Die Evaluierungsstufen (Evaluation Assurance Levels) EAL1 � EAL7 sind den ITSEC- Stu-fen sehr ähnlich. Die Stufe EAL2 entspricht der ITSEC -Stufe E1 usw. bis EAL7 entspricht E6. Die Stufe EAL1 wurde zusätzlich eingeführt, um den Zugang zur Evaluierung zu erleich-tern.

10.5. Evaluationsmethodologie Zu jedem erwähnten Kriteriensystem existieren ausführliche Erklärungen, wie ein Evaluator (Zertifizierer, Hersteller) die Kriterien anwenden soll . Für die TCSEC - Kriterien gibt es so genannte "Rainbow Series" (die heißen wegen der farbige Umschlage so - "Red book", "Blue book" usw. ). Zu den deutschen IT - Kriterien gibt es eine "Methodologie zu den IT-Sicher-heitskriterien ", die von der ZSI (Zentralstelle für Sicherheit in der Informationstechnik) er-stellt wurde. Zu ITSEC- und CC-Kriterien gibt es auch entsprechende Anwendungshinweise und Interpretationen. Im Fall der "Common Criteria" ist die Evaluationsmethodologie ein Bestandteil der Kriterien.

11. Sicherheitsmodelle Sicherheitsmodelle werden verwendet um die Sicherheitskriterien eines Systems planen und überprüfen zu können. Dafür werden die Eigenschaften eines realen Systems stark abstrahiert dargestellt.

11.1. Klassifikation Diese Modelle werden nach folgenden Gesichtpunkten gegliedert:

• Objekte & Subjekte (siehe Definition Vortrag 1) - Grobkörnig

Zusammenfassen von mehreren Dingen zu einem Objekt oder Subjekt (z.B. Be-nutzergruppen - manche bekommen zu viele Rechte)

- Anwendungsspezifisch Rechte können sehr spezifisch vergeben werden

• Zugriffsrechte - Universell

Subjekt hat große Freiheiten (z.B. Write-Rechte: darf alles ändern) - Objektspezifisch

Kann die Rechte des Subjekts ganz genau festlegen • Zugriffsbeschränkung

- Einfach Man benötigt nur Zugriffsrecht auf das Objekt

- Komplex Es gibt zusätzliche Bedingungen, die überprüft werden (z.B. Zeitraum)

21

• Sicherheitsstrategien - Zugriffskontrollstrategie

DAC (Benutzerbestimmbare Zugriffkontrolle): Eigentümer-Prinzip MAC (Systembestimmte Festlegung): Regel wird vor DAC angewendet RBAC (Rollenbasierte Zugriffkontrolle): Rechte auf Aufgaben zugeschnitten

- Informationsfluss-Strategie Verbotene Informationskanäle werden definiert

11.2. Zugriffskontrollmodelle Diese Modelle beruhen darauf, den Zugriff auf Informationen zu beschränken. Sie können in zwei Strategien unterteilt werden, für die es jeweils mehrere Modelle gibt.

11.2.1. Datensicherheit Modelle der Zugriffskontrollstrategien sind auf Datensicherheit bedacht.

• Zugriffsmatrix / Referenzmonitor Die Spalten beinhalten die Objekte und die Zeilen die Subjekte zum Zeitpunkt t. Es kann genau abgelesen werden, welche Rechte jedes Subjekt bezüglich jedes Objekts hat.

• Rollenbasierte Systeme (z.B. RACF) Hierbei werden unterschiedliche Rechte für unterschiedliche Rollen vergeben. Ein Subjekt kann ein zugeordnetes Recht nur ausüben, wenn es aktiv in einer Rolle ist.

11.2.2. Informationssicherheit Um den Informationsfluss überprüfen zu können, setzen Systeme zusätzlich noch Regeln ein.

• Chinese-Wall (Brewer-Nash) Rechte werden zusätzlich durch eine Zugriffshistorie beschränkt und in einem Objekt-Baum dargestellt.

• Bell-LaPadula Beruht auf dynamische Zugriffsmatrix. Es werden Sicherheitsebenen eingeführt und schreibend darf nur auf die gleiche oder höhere Ebenen zugegriffen werden.

11.3. Informationsflussmodelle Bei diesen Modellen ist das Ziel, nur autorisierten Informationsfluss zuzulassen. Dafür wer-den zulässige und unzulässige Kanäle definiert.

• Verbands-Modell Verallgemeinerung des Bell-LaPadula Verfahrens. Es wird nicht der Objektzugriff be-schränkt, sondern der Umgang mit den Informationen der Objekte.

• Non-Deducibility- / Restrictiveness- Modell Hierbei werden Benutzer überwacht, die unterschiedlich klassifiziert sind. Diese Mo-delle werden in der Praxis aber kaum eingesetzt.

12. Fazit Der Vortrag sollte jedem Zuhörer zwei Erkenntnisse gebracht haben:

I. Das Informationssystem ist so sicher wie sein schwächstes Glied II. 100% Sicherheit wird wahrscheinlich nie erreicht werden

Das soll aber nicht bedeuten, dass man nichts für die Sicherheit unternehmen soll. Ganz im Gegenteil, den zwischen 0% und 100% Sicherheit gibt es viele Zwischenstufen. Durch die richtige und sinnvolle Kombination der Sicherheitsfunktionen kann eine annähernd 100% Sicherheit erzielt werden.

22

Die bisherigen Vorträge haben die Sicherung der Hardware und des Zugangs zu den Informa-tionssystemen behandelt. Die folgenden Vorträge sollen auf die Problematik und die Umset-zung in den verschiedenen Systemen (siehe Vortrag 5, 6, 9, 10, 11 und 12) und auf die Siche-rung der Übertragungswege (siehe Vortrag 4, 7, 8 und 12) eingehen.

23

13. Literaturverzeichnis Kapitel 1 - 7

• IT-Sicherheit: Konzepte � Verfahren - Protokolle C. Eckert, 2001 Oldenbourg Wissenschaftsverlag GmbH

• Sicherheitskonzepte für das Internet Martin Raepple, 2001 dpunkt.verlag GmbH

• Mehrseitige Sicherheit in der Kommunikationstechnik u.a. Pfitzmann, 1999 Addison-Wesley Band 1 & 2

• Secrets & Lies Bruce Schneider, 2001 dpunkt.verlag GmbH

• IT-Sicherheit Rolf Opplinger, 1997 Friedrich Vieweg & Sohn Verlagsgesellschaft mbH

• IT-Crackdown � Sicherheit im Internet Othmar Kyas, Markus a Campo, 2000 MITP-Verlag GmbH

• Süddeutsche Zeitung www.sueddeutsche.de

• Universität Zürich � Institut für Informatik www.ifi.unizh.ch

• www.demonium.de • www.cert.dfn.de • Universität Darmstadt � Fachbereich Informatik

www.informatik.tu-darmstadt.de • Bundesministerium für Wirtschaft und Technologie

www.sicherheit-im-internet.de RACF: IBM Pubications:

• SecureWay Security Server RACF: Introduction • SecureWay Security Server RACF: General User�s Guide • SecureWay Security Server RACF: Security Administrator�s Guide • RACF Version 2 Release 2: Technical Presentation Guide . 1995

IT-Sicherheitskriterien:

• Bundesamt für Sicherheit in der Informationstechnik http://www.bsi.de/zertifiz/itkrit/itkrit.htm

• TCSEC : http://www.radium.ncsc.mil/tpep/

• CC : http://www.commoncriteria.org/

• IT - Security Cookbook. Boran Consulting