Grundlagen der IT-Sicherheit · Prinzip des Wohlverhaltens Konzipiere Sicherungsmaßnahmen im-mer so, dass alle Benutzer (Betroffenen) angestachelt werden, sie einzuhalten. Voraussetzungen

© R. Dierstein 82234 Oberpfaffenhofen – Dez-02

Grundlagen der

IT-Sicherheit Teil 3

Rüdiger Dierstein, S.M.

Technische Universität München

WS 2002/03

Thes

enSe

p01

/1/

Gru

ndl

Dez

-02


Diese Unterlagen sind Begleitmaterial zur Vorlesung „Sicherheit von IT-Systemen (IT-Sicherheit)“ an der Technischen Universität München. Sie dienen aus-schließlich dem persönlichen Gebrauch der Hörerin-nen und Hörer der Vorlesung . Alle Rechte an den Un-terlagen, einschließlich der Übersetzung in fremde Sprachen bleiben dem Verfasser vorbehalten. Teile dieses Werkes dürfen nur mit Angabe der Quelle und mit Genehmigung des Verfassers in irgendeiner Form (Fotokopie, Mikrofilm oder ein anderes Verfah-ren), auch für Zwecke der Unterrichtsgestaltung, re-produziert oder unter Verwendung elektronischer Sys-teme verarbeitet, vervielfältigt oder verbreitet werden.

Copyright Rüdiger Dierstein, 82234 Oberpfaffenhofen, 2002

Konstruktionsprinzipien sicherer Systeme



► Erlaubnisprinzip vs. Verbotsprinzip

► Vollständigkeit ► Minimalprinzip

(Geringste Berechtigung, „Need-to-know”)

► Akzeptanz ► Verhältnismäßigkeit oder

Angemessenheit ► Allgemeine Kenntnis

► Einfachheit

Problem

Prinzipien für die Konstruktion sicherer Syste-me können zu widersprüchlichen Anfor-derungen führen. Dann muss für den prakti-schen Anwendungsfall der jeweils bestmögli-che Kompromiss gefunden werden.

Mod

ell

Okt

-01

/ Mod

1/

Mod

ell

Sep-

01 /E

mpf

/ Ko

nstp

rinz

Dez

00 /

Prin

z1/



� Erlaubnisprinzip

Es sind alle Aktionen untersagt, die nicht ausdrücklich erlaubt sind.

Folge Fehlfunktion der Sicherung � kein Zugriff = keine Aktion � wird schnell bemerkt

Wichtig für Konzept- und Implementierungsfehler – müssen (sollten) immer zu Zugriffsverweigerung führen

Problem Fehlfunktion der Sicherung � „Denial of Service“ = automatische Alarmfunktion

Hinweise ► Das Bundesdatenschutz (BDSG) baut bisher

auf dem Erlaubnisprinzip auf. Widerspruch zur gängigen Praxis in der Informationstechnik!

► Für Sonderzustände wie Wartung, Reparatur Pflege, Putzen, … erzwingt das Erlaubnisprinzip Sonderregelungen.

Fortsetzung ��

Kons

tprin

z D

ez00

/Pr

inz2

/



Verbotsprinzip

Es sind alle Aktionen erlaubt, die nicht ausdrücklich untersagt sind.

Folge Fehlfunktion der Sicherung � „wilder“ Zugriff = un-befugte Aktionen möglich � werden nicht bemerkt oder nicht gemeldet

Problem Fehlfunktion der Sicherung beliebige Nutzung + Missbrauch � keine Alarmfunktion

Hinweise Die Praxis der Informationstechnik läuft nahezu ausschließlich nach dem Verbotsprinzip ab. � „Alles ist erlaubt, solange es nicht ausdrücklich verboten wird!“

Kons

tprin

z D

ez00

/Pr

inz3

/



Erlaubnisprinzip vs. Verbotsprinzip

Prinzipielle Frage der Vorgehensweise

Erlaubnisprinzip Welche Elemente (Komponenten) des Systems sollen zugänglich sein?

Verbotsprinzip Welche Elemente (Komponenten) des Systems müssen geschützt werden?

Unterschiede insbesondere beim Übergang von Normalbetrieb zu Sonderzuständen mit Ausfall (oder Aussetzen) der Si-cherungsmaßnahmen:

Erlaubnisprinzip (Total)-Sperre aller Zugänge �� Funktionsausfall (Denial of Service)

Verbotsprinzip Öffnung aller Zugänge � Ausfall aller Sicherungen

Typische Beispiele ► Übergang Routinebetrieb → Reinigung ► Übergang Routinebetrieb → Wartung ► Stromausfall, Katastrophenfälle, …

Kons

tprin

z D

ez00

/Pr

inz3

a/



� Vollständigkeit der Autorisierung

Jede Aktion mit jedem Objekt in jedem Zustand

muss autorisiert werden.

Dies gilt insbesondere für alle Sonderzustände:

► Reinigung ► Hardwarewartung (→ Fernwartung!) ► Hardwareänderung ► Softwarewartung ► Softwareanpassung und -ergänzung ► Systeminstallation und –pflege (auch Ände-

rung von Systemparametern, „patches“, etc.) ► Ausfälle des Systems ► Wiederanlauf ► Alarm- und Katastrophenzustände ► Besucher ► Vorgesetzte (Vorstände!) ► … Problem

Wer darf was in Sondersituationen?

Kons

tprin

z D

ez00

/Pr

inz4

/



� Minimalprinzip Prinzip der geringsten Berechtigung oder Prinzip des „Need-to-know“

Jedes Subjekt erhält nur so viele Rechte, wie es zur Ausführung einer Aufgabe (Aktion) benö-tigt.

Hinweise

Hierarchische Berechtigungsmodelle (z.B. Bell-LaPadula) gelten nur in engen und speziellen Be-reichen. Im Alltag richten sich Autorisierungen und damit Zugriffsmodelle immer nach dem Rollenspiel der beteiligten Elemente. Hierarchische Berechtigungsmodelle führen bei Sondersituationen (s.o.) fast immer zu Problemen! In der Wirtschaft1111 verbreitet das komplementäre Prinzip als „Need-to-withhold“

1 Don Parker, IFIP-Konferenz Helsinki (SF), 1990 Ko

nstp

rinz

Dez

00 /

Prin

z 5/



� Akzeptanz Prinzip des Wohlverhaltens

Konzipiere Sicherungsmaßnahmen im-mer so, dass alle Benutzer (Betroffenen) angestachelt werden, sie einzuhalten.

Voraussetzungen Maßnahmen sind

► angemessen ► erforderlich ► zweckmäßig ► einfach ► durchschaubar

Benutzerreaktionen ► Passivität = Versuch, den Maßnahmen aus-

zuweichen, nur das Nötigste, Unumgängli-che tun

► Reaktanz (Renitenz, Resistenz) = Sich-Sträuben gegen die Anforderungen, „Ra-che“ der Betroffenen bis zur Sabotage

► Über-Konformität = Nutzung der Maßnah-me, aber ohne aktive Beteiligung (Kreativi-tät)

Kons

tprin

z D

ez00

/Pr

inz

6/



� Verhältnismäßigkeit, Angemessenheit

Aufwand und Ziele jeder Sicherung müssen in einem vertretbaren Verhältnis zu-

einander stehen.

Verhältnismäßigkeit wird beeinflusst durch:

► alle Arten von Rechtsvorschriften (vgl. Defini-tion von Datenschutz)

► Gewährleistung der Ordnungsmäßigkeit (Ver-lässlichkeit)

► Notwendigkeit ► Wirtschaftlichkeit ► Wirkung der Maßnahmen (Effizienz) ► … …

Probleme ► Übermäßige Sicherung im Widerspruch

zur Funktionalität oder Funktionsfähigkeit ► Änderung der Erfordernisse und der

Wirksamkeit durch Änderung der Technik (Technologie)

Fortsetzung ��

Kons

tprin

z D

ez00

/Pr

inz

7/



Zitat zur Verhältnismäßigkeit Verhältnismäßigkeit Verhältnismäßigkeit Verhältnismäßigkeit

„Der Wirtschaft sind verfassungsrechtlich genau die Kosten zumutbar, die sie aufbringen muss, um ihre Verarbeitung personenbezogener Informationen frei von Eingriffen in grundrechtlich geschützte Be-reiche der Bürger zu halten, und um die Kontrolle der Rechtmäßigkeit der Verarbeitung durch die be-troffenen Bürger und die zuständigen staatlichen Stellen zu ermöglichen.“

W. Podlech

in der Computerwoche vom 26.3.1976

Kons

tprin

z D

ez00

/Pr

inz

7a/



� Offenlegung

► Alle Benutzern (Betroffenen) sol-len das Ziele und Wirkungsweise der Sicherungsmaßnahmen bekannt sein.

► Sicherungsmaßnahmen müssen so konzipiert und implementiert werden, dass diese Kenntnis ihre Verlässlichkeit nicht beein-trächtigt.

Grundsatz

Kein Sicherungsverfahren darf auf die Unwissenheit oder Unfähigkeit

möglicher Eindringlinge bauen!

Beispiele: ► Funktionsweise eines Kombinationsschlosses ► Kerckhoff’sches Prinzip in der Kryptographie

Kons

tprin

z D

ez00

/Pr

inz

8/



� Einfachheit

Der Kern jedes Sicherungssystems – oder sicheren IT-Systems muss

► so einfach und ► so klein

wie möglich sein.

Gründe und Probleme ► Korrektheitsbeweise für größere und komple-

xe Systeme problematisch ► Entdecken und Erkennen unzulässiger

Zugriffswege (→ Schnittstellen) ► Unmöglichkeit des Testens auf Nicht-

Vorhandensein von Fehlern ► Vollständiges Austesten aller Möglichkeiten

sehr schnell unausführbar oder unmöglich

Kons

tprin

z D

ez00

/Pr

inz

9/



Kriterien und Evaluierung


Warum Evaluierung nach Kriterien? ► komplexe Aufgabenstellungen ► komplexe Systeme ► Standardisierung und Vergleichbarkeit ► Erhöhung der Verlässlichkeit ► Angebotsvielfalt ► …

Was wird evaluiert? ► Produkte (Komponenten) –

mit unbekannter Einsatzumgebung � Hardware und Hardwarekomponenten � Betriebssysteme � Systemkomponenten � Anwendersysteme � offene Software aller Art � Sicherheitssysteme und -komponenten � …

► Systeme - mit bekannter Einsatzumgebung � Systeme für bestimmte Einsatzbereiche,

(militärische IT-Systeme, Systeme für Bankanwendungen, ...)

� Systeme für definierte Aufgaben, (Ver-kehrsleitsysteme, Steuerungen für Kraft-werke, Überwachungseinrichtungen, …)

Fortsetzung �

Krit.

doc

Dez

-00

/1/



Wer nutzt Evaluierung und Kriterien? Hersteller

� (neutrale) Bewertung der Sicherheit von Produkten

� Verkaufsförderung � Risikominderung bei Gewährleistung und

Haftung � …

Anwender � Entscheidungshilfe bei Beschaffung und

Einsatz � Risikominderung bei Gewährleistung und

Haftung � Sicherheitsanalyse der proprietären Sys-

teme � …

Evaluatoren � Markt � …

Krit.

doc

Dez

-00

/2/



Trusted Computer Systems EvaluatTrusted Computer Systems EvaluatTrusted Computer Systems EvaluatTrusted Computer Systems Evaluatiiiion on on on Criteria (TCSEC) Criteria (TCSEC) Criteria (TCSEC) Criteria (TCSEC) –––––––– The „Orange Book“ The „Orange Book“ The „Orange Book“ The „Orange Book“

► ab 1978 entwickelt vom US Department of Defense, 1985 veröffentlicht

► erster „offizieller“ Meilenstein zum Problem Sicherheit von DV-Systemen � als Standard für Hersteller � Versuch einer „Metrik“ für die Vertrauenswürdig-

keit von Computern ► Grundsätzlich auf militärische Anwen-

dungen ausgerichtet ► hierarchisches Modell der Sicherheitsstu-

fen

Folgen ► wesentlicher (zusätzlicher) Anstoß für ähnli-

che Vorhaben weltweit

Nachteile ► begrenzter Geltungsbereich (Verteidigung) ► begrenzter Systembegriff (Betriebssysteme) ► begrenzte Bedeutung von Sicherheit (fast nur

Vertraulichkeit)

Krit.

doc

Dez

-00

/3/



TCSEC – Historie

1967 Task Force des DoD – Entwurf von Sicher-heitsmaßnahmen für DV-Systeme, insbe-sondere gegen unberechtigten Zugriff

1970 Ergebnisbericht „Security for Computer Sys-tems“

1972 Anderson Report: „Computer Security Tech-nology Study“

1973 Bell-LaPadula Modell (1) Mathematische. Grundlagen (2) A Mathematical Model (3) Refinement of the Mathematical Model

1976 „Unified Exposition and Multics Interpreta-tion of the Bell-LaPadula Model“

1977 Beginn der DoD Computer Sec. Initiative 1978 Beginn der Arbeiten zu Evaluationskriterien

in den USA (Mitre Corp. + NBS) 1981 Gründung des DoD Computer Security Cen-

ter (CSC) 1982 1. Entwurf der TCSEC 1983 TCSEC „Orange Book“ 1984 CSC wird zum Nationsl CSC (NCSC)

– Erste Evaluationen 1985 Erste Revision der TCSEC 1987 TNI „Red Book“ – Trusted Network Inter-

pretation of the TCSEC 1988 Entwurf TDI – Trusted DBMS Interpretation

of the TCSEC

Krit.

doc

Dez

-00

/4/



Sicherheitsanforderungen nach dem „Orange Book“

(1)(1)(1)(1) Markierungen (tags) Objekte haben Markierungen, über die alle Zugriffe darauf regel- und kontrollierbar sind

(2)(2)(2)(2) Sicherheitskonzept (security policy) Es gibt ein explizites und wohldefiniertes Si-cherheitskonzept, dessen Einhaltung durch das System erzwungen wird.

(3)(3)(3)(3) Identifizierung und Authentisierung (au-thentication) Alle Subjekte müssen identifizierbar sein.

(4)(4)(4)(4) Verantwortbarkeit, Beweissicherung (accountability) Protokolldaten müssen gesammelt und sicher aufbewahrt werden, um die Verantwortlichen für sicherheitskritische Aktionen feststellen zu kön-nen.

(5)(5)(5)(5) Qualität (assurance) Sicherheitsmechanismen müssen mit nachvoll-ziehbarer Qualität die Forderungen 1.-4. erfül-len

(6)(6)(6)(6) Ständiger Schutz (continuous protection) Mechanismen nicht umgehbar und gegen unbe-fugte Änderungen geschützt.

Krit.

doc

Dez

-00

/5/



Sicherheitsanforderungen für Netze nach dem „Red Book“

Sicherheitsanforderungen nach dem „Orange Book“auf Netze nicht anwendbar (→ Kap. 2 des Red Book)

Sicherheitsdienste nach dem TNI (Trusted Network Interpretation of the TCSEC)

► Integrität der Kommunikation � Authentisierung � Integrität der Daten � Sende- und Empfangsbeweis

► Abhörsicherheit � Vertraulichkeit der Daten � Schutz vor Verkehrsflussanalyse � Auswahl von Überstragungsstrecken

► Diensteverweigerung � Kontinuität des Betriebs � protokollbasierter Schutz � Netzüberwachung

Anmerkung Erweiterung der Sicherheitsaspekte des Orange Book, aber weiterhin keine durchgreifende Syste-matik

Krit.

doc

Dez

-00

/6/



Nationale und internationale Kriterien

seit 1978 und davor

Vorarbeiten in Deutschland (IABG, GDD et al.)

1983 Veröffentlichung der IABG, Ottobrunn (v.d.Brück, Jahl et al.), Erweiterung auf Vertraulichkeit – Integrität - Verfügbar-keit ➨ erste systematische Strukturierung der Bedeutung des Begriffs Sicherheit ➧➧➧➧

1989 deutsche Kriterien (BSIEC) veröffentlicht verschiedene nationale Kriterienkataloge in UK, F, NL, D, CDN, …

1991 Versuch einer Harmonisierung der nationa-len Kriterien durch die europäische Ge-meinschaft (ITSEC)

1992 Erweiterung des Bedeutungsumfangs durch die Zurechenbarkeit (accountabili-ty) in den kanadischen Kriterien

seit 1993

Arbeit an den Common Criteria (CC) un-ter Führung der USA mit dem Ziel noch größerer Flexibilität und Allgemeinheit

1997 Version 1.0 der CC Ende 1999

Version 2.0 der CC, gemeinsames Vor-gehen mit der ISO

Fortsetzung �

Krit.

doc

Dez

-00

/7/



Nationale und internationale Kriterien (Fts.)

Kriterienkataloge 1983/85 USA DoD (US-Department of Defense)

Trusted Computer System Evaluation Cri-teria (TCSEC), genannt „Orange Book”

1985–89 Deutschland BSI (Bundesamt für Si-cherheit in der Informationstechnik) IT-Sicherheitskriterien – Kriterien für die Be-wertung der Sicherheit von Systemen der Informationstechnik (IT) – 1. Fassung (BSISEC)

1990–91 CEC Information Technology Security Evaluation Criteria, Version 1.2 (ITSEC)

1990–?? ISO/IEC (JTC1/SC27/WG3) Evaluation Criteria for IT Security (ECITS)

1992–93 Kanada (CSSC/CSE) Canadian Trusted Computer Product Evaluation Criteria Version 3.0 (CTCPEC)

1992–93 USA (NIST und NSA) Federal Criteria for Information Technology Security, Draft Version 1.0 (FC-ITS)

1994– 99/… USA/CDN/EU (Common Critria Editorial Board) Common Criteria Version 2.0 (CC)

Fortsetzung �

Krit.

doc

Dez

-00

/7/



Nationale und internationale Kriterien (Fts.)

FolgenFolgenFolgenFolgen ◆ Nutzung auch für nicht-militärische Anwendun-

gen

◆ neue Standards in IT-Sicherheit

◆ Erweiterung und Verbesserung � des Geltungsbereichs � des Systembegriffs � der Definition von Sicherheit � der Anwendungen

ProblemProblemProblemProblem ◆ zunehmend Verlust der Systematik wegen zuviel

„Harmonisierung“ und „Universalität“

Krit.

doc

Dez

-00

/6/



Krit.

doc

Dez

-00

/6/

Grundfunktionen und Mechanismen


Einige Definitionen (nach ITSEC) ► Evaluation (Evaluation)

die Bewertung eines IT-Systems oder -Produkts (TOE) anhand definierter Kriterien (Evaluationskri-terien)

► Zertifizierung (Certification) die Abgabe einer formalen (förmlichen?) Erklärung, die die Ergebnisse einer Evaluation und die ord-nungsgemäße Anwendung der benutzten Evaluati-onskriterien bestätigt

► Akkreditierung (Accreditation) hat je nach den Umständen zwei Definitionen. 1. das Verfahren, welches für ein Prüflabor die

technische Kompetenz und die Unparteilichkeit anerkennt, die zugehörigen Aufgaben durchzu-führen

2. das Verfahren, welches ein IT-System zum Be-trieb in einer speziellen Umgebung freigibt

► System (System) eine spezifische IT-Installation mit einem bestimmten Zweck und einer spezifischen Betriebsumgebung

► Produkt (Product) ein Paket aus IT-Software und/oder -Hardware, das eine bestimmte Funktionalität bietet, die zur Verwen-dung oder zur Integration in einer Vielzahl von Sys-temen entworfen wurde

Fortsetzung ��

Gru

ndfk

t.doc

D

ez-0

0 /D

ef1/



Einige Definitionen (nach ITSEC) (Fts.) ► Evaluationsgegenstand – TOE

ein IT-System oder -Produkt, das einer Evaluation unterzogen wird (Target of Evaluation)

► Sicherheitsziele (Security Objectives) Der Beitrag zur Sicherheit, den ein TOE leisten soll*)

► Sicherheitsvorgaben (Security Target) Eine Spezifikation der von einem TOE geforderten Sicherheit, die als Grundlage für die Evaluation ver-wendet wird. Die Sicherheitsvorgaben spezifizieren sowohl die sicherheitsspezifischen Funktionen des TOE als auch die Sicherheitsziele, die Bedrohungen dieser Ziele sowie die einzelnen Sicherheitsmecha-nismen oder –maßnahmen, die verwendet werden.

► Vertrauenswürdigkeit (Assurance) Eigenschaft des TOE, die das Maß an Vertrauen ausdrückt, welches man in die durch den TOE be-reitgestellte Sicherheit haben kann

► Sicherheit (Security) Die Kombination aus Vertrauenswürdigkeit, Integrität und Verfügbarkeit

►►► Hinweis: In ITSEC werden duale und mehrsei-tige Sicherheit in der Definition von Sicherheit nicht er-wähnt, obwohl an vielen Stellen die Zurechenbarkeit (engl. accountability) bereits angesprochen wird. ◄◄◄

*) Entspricht einem Punkt im semantischen Raum.

Gru

ndfk

t.doc

D

ez-0

0 /D

ef2/



Grundfunktionen der SicherheitGrundfunktionen der SicherheitGrundfunktionen der SicherheitGrundfunktionen der Sicherheit (3. Schicht des Modells)(3. Schicht des Modells)(3. Schicht des Modells)(3. Schicht des Modells)

Welche funktionellen Eigenschaften muss ein IT-System besitzen, damit es als ssssi-i-i-i-

chercherchercher angesehen werden kann?

Grundfunktionen bilden die 3. Schicht des semantischen Modells. Also lautet die Frage aus-

führlicher:

Grundfunktionen im semantischen Modell

Welche kennzeichnenden funktionellen Eigenschaften

muss ein IT-System besitzen, damit die An-forderungen an seine Sicherheit (Sicher-heitsziele) prinzipiellprinzipiellprinzipiellprinzipiell erfüllt werden kön-nen?

Beachte: Bei den Grundfunktionen wird weder gefragt, mit welchen Mitteln (Verfahren, Vorrichtungen, Maß-nahmen) die Sicherheitsanforderungen verwirklicht werden, noch wie gut das geschieht.

Gru

ndfk

t.doc

D

ez-0

0 /D

ef3/



Kennzeichnende funktionelleKennzeichnende funktionelleKennzeichnende funktionelleKennzeichnende funktionelle Eigenschaften der SEigenschaften der SEigenschaften der SEigenschaften der Siiiicherheitcherheitcherheitcherheit

Kennzeichnende Eigenschaft (Grundfunktion) im semantischen Modell heißt

► notwendig Das IT-System muss diese Eigenschaften besitzen, wenn es den Sicherheits-anforderungen genügen soll.

► vollständig Sie reichen – richtig implementiert – aus, um die Anforderungen an die Sicherheit des IT-Systems zu erfüllen.

► technisch unabhängig Sie sind nicht an bestimmte Mechanismen oder Maßnahmen – an eine bestimmte technische oder organisatorische Verwirk-lichung – gebunden.

Zusatzforderung der Wirtschaftlichkeit:Zusatzforderung der Wirtschaftlichkeit:Zusatzforderung der Wirtschaftlichkeit:Zusatzforderung der Wirtschaftlichkeit: ► überdeckungsfrei

Die Eigenschaften sollen sich nicht unnötig ü-berlappen.

Gru

ndfk

t.doc

D

ez-0

0 /D

ef4/



Sechs Grundfunktionen im semantischen Modell

1. Authentisierung 2. Rechteverwaltung 3. Rechtekontrolle

4. Protokollierung (oder Audit)

5. Fehlerüberbrückung

6. Überwachung

als Eigenschaften der elementaren Aktionen Zugriff und Übertragung

Zuordnung der Grundfunktionen Authentisierung Rechteverwaltung Rechtekontrolle

OrdnungsmäßiOrdnungsmäßiOrdnungsmäßiOrdnungsmäßiggggkeitkeitkeitkeit

Protokollierung Fehlerüberbrückung Überwachung

Berücksichtigung Berücksichtigung Berücksichtigung Berücksichtigung nichtnichtnichtnicht----ordnungsordnungsordnungsordnungs---- mäßiger Elememäßiger Elememäßiger Elememäßiger Elemennnntetetete

Gru

ndfk

t.doc

D

ez-0

0 /G

fkt1

/



Grundfunktionen im deutschen Nationalen Kriterienkatalog (BSIEC)

1. Identifikation und Authentisierung

2. Rechteverwaltung 3. Rechteprüfung

4. Beweissicherung 5. Wiederaufbereitung 6. Fehlerüberbrückung 7. Gewährleistung der

Funktionalität

8. Übertragungssicherung

Zuordnung der BSISEC-Funktionen 1.–3. ➠➠➠➠ Ordnungsmäßigkeit 4.–7. ➠➠➠➠ Berücksichtigung nicht-rdnungsmäßiger Elemente 8. ➠➠➠➠ Übertragungssicherung

8. ist ein Mechanismus �� also Ebene 4 !!

Gru

ndfk

t.doc

D

ez-0

0 /G

fkt2

/



Mechanismen (Maßnahmen) Mechanismen (Maßnahmen) auf der 4. Schicht des semantischen Modells, setzen die Grundfunktionen der dritten Schicht in

reale Abläufe, Vorgänge oder Sachverhalte um.

Mechanismen (Maßnahmen) können sein � physikalische Vorrichtungen (Hardware) oder

Software � Kombinationen aus Hard- und Software � Vorkehrungen in der Infrastruktur � organisatorische Maßnahmen � personelle Maßnahmen In der Praxis sehr häufig � Kombinationen aus technischen, organisa-

torischen und personellen Vorkehrungen

Funktionstüchtigkeit und Vertrauenswürdigkeit der Mechanismen (Maßnahmen) sind ein we-sentlicher Teil der

Qualität (engl. assurance)

der Sicherheit eines IT-Systems.

Gru

ndfk

t.doc

D

ez-0

0 /G

fkt3

/



Funktionalität vs. Qualität (BSI)

Unterscheide genau:

Funktionalität (engl. functionality)

Welche Grundfunktionen (Eigenschaften) der Sicherheit müssen in einem IT-System vorhanden sein, das als sicher angesehen werden soll?

Qualität (engl. assurance) Wie gut sind die Grundfunktionen (Eigenschaften) in ei-nem bestimmten IT-System durch Mechanis-men (Maßnahmen) verwirklicht worden?

Hinweise ► Qualität bezieht sich nicht allein auf die Güte

der Maßnahmen, d.h. der technischen oder or-ganisatorischen Verwirklichung einer Sicher-heitsforderung!

► Statt Qualität wird in den ITSEC – und anders-wo – der Begriff Vertrauenswürdigkeit (engl.: assurance) verwendet.

Gru

ndfk

t.doc

D

ez-0

0 /Q

ual1

/



Qualität, Assurance BSI – Qualität ► Maß für die Güte, mit der eine (Sicherheits)-

Anforderung in einem IT-System erfüllt wird ITSEC – Assurance ► confidence in the correctness or the effec-

tiveness of the security enforcing functions of a TOE (target of evaluation)2

Bewertung (Evaluation) der Qualität

nach der Vertrauenswürdigkeit ► der Sicherheitsanforderungen ► der Spezifikation der Systemteile ► der Abgrenzung zu nicht zu evaluieren-

den Systemteilen ► des Herstellungsvorgang (� ISO 9000) ► des Betriebs ► der anwenderbezogenen Dokumentation

sowie nach der Stärke (Güte) ► der verwendeten Mechanismen (Maß-

nahmen)

2 Darin ist vor allem das Vertrauen in die Korrektheit und Wirksamkeit der Mechanismen und ihrer Implementierung enthalten. G

rund

fkt

Jan

-02

/Qua

l2/



Zusammenhang Orange Book ⇔⇔⇔⇔ IT-Kriterien

Orange Book BSIEC ITSEC

D ⇔⇔⇔⇔ ./. ⇔⇔⇔⇔

C1 ⇔⇔⇔⇔ F2/Q1 ⇔⇔⇔⇔ F-C1, E1

C2 ⇔⇔⇔⇔ F2/Q2 ⇔⇔⇔⇔ F-C2, E2

B1 ⇔⇔⇔⇔ F3/Q3 ⇔⇔⇔⇔ F-B1, E3

B2 ⇔⇔⇔⇔ F4/Q4 ⇔⇔⇔⇔ F-B2, E4

B3 ⇔⇔⇔⇔ F5/Q5 ⇔⇔⇔⇔ F-B3, E5

A1 ⇔⇔⇔⇔ F6/Q6 ⇔⇔⇔⇔ F-B3, E6

Kennzeichnender Unterschied oberer Teil (D – C2)

DACDACDACDAC – Discretionary Access Control benutzerbestimmbare Zugriffskontrolle

unterer Teil (B1 – A1)

MAC – Mandatory Access Control vorgeschriebene (regelbasierte) Zugriffs-kontrolle

Gru

ndfk

t J

an-0

2 /K

las7

/

Authentisierung


AuthentizAuthentizAuthentizAuthentizitätitätitätität

► Bestätigung einer behaupteten Identität

► Nachweis der Originalität

► Nachweis der Unversehrtheit (Integrität, Voll-ständigkeit)

► Nachweis des korrekten Zusammenhangs

Subjekt Objekt (Veranlasser) (Ergebnis, Gegenstand,

Vorgang, …) HinweisHinweisHinweisHinweis

Authentizität ist nicht auf Personen beschränkt. Authentizität wird von jedem IT-System und dessen Kom-ponenten gefordert, insbesondere von maschinellen Systemen und den mit ihnen verarbeiteten Daten.

Auth

ent.d

oc

Dez

-02

/Def

1

Authentisierung


Identification and AuthenticationIdentification and AuthenticationIdentification and AuthenticationIdentification and Authentication ITSEC 1991

2.34 In many TOEs*) there will be requirements to deter-mine and control the users who are permitted access to resources controlled by the TOE. This involves not only establishing the claimed identity of a user, but also verifying that the user is indeed the user claimed. This is done by the user providing the TOE with some information that is known by the TOE to be associated with the user in question.

2.35

This heading**) shall cover any functions intended to establish and verify a claimed identity.

2.36 This heading shall include any functions to enable new user identities to be added, and older user iden-tities to be removed or invalidated. Similarly, it shall include any functions to generate, change, or allow authorized users to inspect, the authentication infor-mation required to verify the identity of particular us-ers. It shall also include functions to assure the in-tegrity of, or prevent the unauthorized use of authen-tication information. It shall include any function to limit the opportunity for repeated attempts to estab-lish a false identity.

*) TOE Target of Evaluation **) Generic Heading Grundfunktion, Basisfunktion Au

then

t.doc

D

ez-0

2 /D

ef2

Authentisierung


Sprachgebrauch (insb. juristisch) authentisieren

einen Gegenstand rechtsgültig machen

authentifizieren Echtheit eines Gegenstandes rechtsgültig feststellen und bezeugen

Definitionen (nach BSIEC)*)

Identifizierung Bestimmung der Identität eines Subjekts oder Objekts

Authentisierung Nachweis der angegebenen Identität

Die Feststellung der Identität eines Gegenstandes schließt in der Praxis in aller Regel eine Authentisie-rung mit ein. Zitat BSIEC

„Eine Authentisierung kann nur dann unterbleiben, wenn eine fehlerhafte Identifikation praktisch aus-geschlossen werden kann.“

*) IT-Sicherheitskriterien – Kriterien für die Bewertung der Sicherheit von Systemen der Informationstechnik (IT), – 1. Fassung 1989, ISBN 3-88784-192-1

Auth

ent.d

oc

Dez

-02

/Def

3/

Authentisierung


Aufgabe der Authentisierung

Feststellung + Gewährleistung, dass die an einer Aktion beteiligten Elemente

authentisch sind.

Das heißt:

Subjekte, Objekte und AktionenAktionenAktionenAktionen sind tatsäch-lich diejenigen, die sie zu sein vorgeben.

Zusatz

Authentisierung schließt ein die korrekte Zuordnung

von Objekten zu Veranlassern.

Dies gilt insbesondere für die Aktion Übertragung (Zu-ordnung von Nachrichten zu Absendern und Empfän-gern).

Auth

ent.d

oc

Dez

-02

/Auf

g

Authentisierung


Symmetrie der Authentisierung

Folgerung für IT-Systeme

Authentisierung in IT-Systemen muss immersymmetrisch sein!

Beispiele

� System authentisiert Benutzer und Benutzer authentisiert System

� Empfänger authentisiert Sender und

Sender authentisiert Empfänger zusätzlich � Empfänger und Sender authentisieren über-

tragene Daten Fortsetzung ��

Auth

ent

Dez

-02

/Sym

1/

Authentisierung


Symmetrie der Authentisierung (Fts.) Authentisierung bei Zugriffen

◆ Aktion: Subjekt greift zu auf Objekt. Gefordert: Authentizität von Subjekt und Objekt

Authentisierung bei Übertragung

◆ Aktion: Sender überträgt Daten (Nachrich-ten) an Empfänger. Gefordert: Authentizität von Sender, Empfänger und Daten

Auth

ent.d

oc

Dez

-02

/Sym

2/

Authentisierung


Problem der Authentizität

Wann sind Elemente authentisch?

◆ Wenn ihre Struktur authentisch ist?

oder ◆ Wenn ihre Funktion authentisch ist?

Beispiele für „Was ist authentisdch?“

Auth

ent.d

oc

Dez

-02

/Pro

bl

Benutzer mit Bart Benutzer mit Geheim-dienstauftrag („umgedreh-ter“ Mitarbeiter)

ungeändertes Pro-gramm mit Fehlern

geändertes Programm ohne Fehler

unveränderter Rechner

Rechner mit altem System auf neuer CPU

Rechner mit neuem Sys-tem auf alter CPU

Authentisierung


Komponenten der Authentisierung

Vorstellung Behaupten (Angeben, Vorzeigen) einer Identität

Verifizierung Prüfung der behaupteten Identität, d.h. Nachweis, dass diese Angabe rechtens ist

Abhängigkeit des Prüfmechanismus ► vom Gegenstand, dessen Authentizität fest-

zustellen ist, ► von der Prüfinstanz, die die Authentizität

feststellt, aber auch

► von den Anforderungen an die Verlässlich-keit der Authentisierung

Beispiele für Anforderungen: Beweisbarkeit gegenüber Dritten (wg. Rechtsverbind-lichkeit) ∙ Abhängigkeit vom Umfeld (Authentisierung an der Pforte vs. Authentisierung im Netz) ∙ …

Auth

ent.d

oc

Dez

-02

/Kom

p1/

Authentisierung


Vorstellung (Behaupten oder Angeben einer Identität)

Möglichkeiten der Vorstellung

Vorstellung als Ganzes Ein Gegenstand (Subjekt oder Objekt) wird von der authentisierenden Instanz als Ganzes erkannt (wahrgenommen) und geprüft.

Vorzeigen eines Authentikators Die authentisierende Instanz erkennt und prüft nur einen signifikanten Teil oder einen Vertreter des Gegenstandes (pars pro toto)

Beispiele ◆ Person (als Ganzes) an der Pforte ⇔⇔⇔⇔ Person (durch

Stimme oder Name) am Telefon ◆ Programm durch Lesen des (ganzen) Programmtextes

�� Programm durch Prüfen einer Checksumme oder Signatur

Hinweis Vorstellung ist immer nur Behauptung ohne Nach-weis, ob die Behauptung richtig oder rechtens ist.

Auth

ent

Dez

-02

/Kom

p2/

Authentisierung


Verifizierung (Prüfung und Bestätigung einer behaupteten

Identität)

Aufgabe der Verifizierung

Die behauptete Identität � ist richtig (korrekt)richtig (korrekt)richtig (korrekt)richtig (korrekt) und � wird zu recht bzu recht bzu recht bzu recht beaeaeaeannnnsprucht.sprucht.sprucht.sprucht.

Das heißt: ► Das Element (der Gegenstand oder die Aktion)

ist tatsächlich und ggf. beweisbar dasjenige, das es zu sein vorgibt.

Auth

ent

Dez

-02

Kom

p3

Authentisierung


Authentikatoren

In der Umgangssprache:

Etwas,

das man ist oder weiß oder kann oder hat

Der Authentikator tritt an die Stelle des zu authenti-sierenden Elements. Ein kennzeichnender Teil des Ganzen wird als „Ersatz“ für das Ganze ge-nommen (pars pro toto).

Auth

ent.d

oc

Dez

-02

/Aut

hk1/

Au

then

t.doc

D

ez-0

2 ./A

uthk

1/

Authentisierung


Arten von Authentikatoren

Originärer Authentikator vorhandene physische oder geistige Ei-genschaft eines Gegenstands

Zugewiesener Authentikator übergebener oder erworbener Besitz

OriginärOriginärOriginärOriginär ► zum Gegenstand gehörend, aus seiner Substanz

oder seinem Verhalten „ableitbar“ Beispiele Fingerabdruck oder Stimme eines Menschen, Prüf-summe eines Programms, Schriftbild einer Schreib-maschine, ….:

ZugewiesenZugewiesenZugewiesenZugewiesen ► physischer oder geistiger Besitz – Gegenstände,

Wissen oder Können Beispiele Schlüssel, Passwörter, Chipkarten, …

Auth

ent.d

oc

Dez

-02

./Aut

hk2/

Authentisierung


Verifizierung mit Authentikatoren

Zwei Forderungen:

Keine Fälschung Der Authentikator ist „echt“.

Kein Missbrauch Die Zuordnung Authentikator � Element (Gegenstand oder Aktion) besteht zu recht.

Fortsetzung ��

Auth

ent.d

oc

Dez

-02

Auth

k3

Authentisierung


Verifizierung mit Authentikatoren (Fts.)

GrundsatzfrageGrundsatzfrageGrundsatzfrageGrundsatzfrage an Authentikat an Authentikat an Authentikat an Authentikatoooorenrenrenren

Ist die Zuordnung Gegenstand �� Authentikator

eindeutig und rechtens?

Probleme

◆ Originäre Authentikatoren � Imitation � Fälschung � …

◆ Zugewiesene Authentikatoren � Verlust � Diebstahl � Vergessen � Verrat � …

Hinweis Viele Authentikatoren sind Mischformen.

Authentisierung


Authentisierung mit AAuthentisierung mit AAuthentisierung mit AAuthentisierung mit Auuuuthentikatorenthentikatorenthentikatorenthentikatoren (Fts.)

V e r g l e i c hV e r g l e i c hV e r g l e i c hV e r g l e i c h

gespeicherter Authentikator }

↓↓↓↓=

{

vorgezeigter Authentikator

Voraussetzung

Authentisierende Instanz muss den Authentikator vor dem Vergleich „kennen“

Vergleichsergebnis

Identität oder „ausreichende“ Übereinstimmung Bewertung des Vergleichs

stark abhängig von der Art und den Eigenschaften des verwendeten Authentikators und den Fähigkei-ten der authentisierenden Instanz

Beispiel Mensch: ⇒⇒⇒⇒ Passbild ⋁ Unterschrift ⋁ Stimme v Fingerab-druck

Fortsetzung ��

Auth

ent.d

oc

Dez

-02

/Aut

hk4/

Au

then

t.doc

Dez

-02

/Au

thk5

/

Authentisierung


Authentisierung mit AuthentikatorenAuthentisierung mit AuthentikatorenAuthentisierung mit AuthentikatorenAuthentisierung mit Authentikatoren (Fts.)

Bewertung des Vergleichs

Entscheidung Vergleichs-ergebnis angenommen abgewiesen

Über-einstimmung

kein Fehler FR

keine Über-einstimmung FA kein

Fehler

FR = False Rejection (fehlerhafte Abweisung) FA FA FA FA = False Acceptance (fehlerhafte Annah-me

Ziel der Bewertung

FR = FA = 0 Praktische Näherung

FR = FA mit EER ≪≪≪≪ 1% EER = Equal Error Rate

Auth

ent.d

oc

Dez

-02

/Aut

hk6/

Authentisierung


Authentisierung von PersonenAuthentisierung von PersonenAuthentisierung von PersonenAuthentisierung von Personen

Für Personen ist die Authentisierung als Ganzes

noch immer weit verbreitet, sinnvoll und wirksam.

Authentisierende Instanzen

sind dann ebenfalls Menschen: Pförtner, Wachpersonal, … aber auch: Kollegen, Vorgesetzte etc. im privaten Bereich: Angehörige, Freunde, Bekann-te, …

Juristische Formulierung „XY ist dem Unterzeichneten persönlich bekannt“.

Juristische Folge Die so authentisierte Person XY darf selbst wieder als authentisierende Instanz handeln (z.B. durch Unterschreiben eines Schriftstücks).

Fortsetzung ��

Auth

ent.d

oc

Dez

-02

/Aut

hk7/

Authentisierung


Authentikatoren für Personen ◆ Schlüssel ◆ Ausweise � ohne Photo / mit Handunterschrift / mit Photo � Magnetkarten � Chip-Karten („smart cards“) mit PIN (Passwort) � Chip-Karten mit Fingerabdruck

◆ Passwörter, PINs (Kennwörter, „Parole“) ◆ Unterschrift von Hand (Handunterschrift) � statisch: nur als Graph f(x)) � dynamisch: Graph f(x) und Geschwindigkeit

f’(x), ggf. auch Beschleunigung f””””(x) ◆ digitale Signaturen � mit geeigneten Protokollen, insbesondere mit

asymmetrischen Schlüsseln ◆ biometrische Verfahren � Fingerabdruck (� Akzeptanz, Missbrauch) � Gesicht � Stimme � Augenhintergrund (Netz-/Aderhaut (Retina /

Uvea) � genetischer Code (� Gefahr des Missbrauchs) � Adern des Handgelenks � Knochenmaße (� Praktikabilität)

Auth

ent.d

oc

Dez

-02

/Aut

hk8/

Authentisierung


Passwörter als Authentikatoren

Definition

Authentisierung mit Passwort

Angabe (schriftlich oder mündlich) einer Zeichenkombination und Vergleich mit einem gespeicher-ten (gemerkten) Duplikat

Vorteile � leichte Implementierung � leichte Installation � keine besondere Hardware � flexibel, anpassbar an Einsatzbedingungen � ausreichend sicher bei sorgfältiger Anwen-

dung

Problem

Mangelnde Sorgfalt, technisch und menschlich, ist die entscheidende Schwachstelle.

Fortsetzung ��

Auth

ent.d

oc

Dez

-02

/Pas

sw1/

Authentisierung


Passwörter als Authentikatoren (Fts.)

Forderungen an Passwortverfahren ► Einwegverschlüsselung der Passwortdatei (un-

entschlüsselbare Vergleichskopie) ► sicherer Eingabeweg (➨ Abhören, Anzapfen, …) ► Sicherung der Abfrageprozedur (➨ logon) ► Mindestlänge 8 Zeichen) ► Zeichenvorrat mit Sonderzeichen ► begrenzte Gültigkeitsdauer ► begrenzte Wiederholungsanzahl ► Dunkelfeldtastung (➨ Kommandowiederholung) ► Kontrolle auf unzulässige Passwörter (➨ Wör-

terbuch)

Problem der Handhabung Passwörter sind Wissen von Menschen. Men-schen im Alltag sind

� vergesslich � bedingt lernfähig � einfallsarm.

Folgen ► Passwörter zu kurz (Beispiel: PINs), � zu langle-

big � zu leicht erratbar � falsch aufbewahrt � … ► allgemeines Akzeptanzproblem: ➨ Vergesslich-

keit Fortsetzung ��

Auth

ent.d

oc

Dez

-02

/Pas

sw2/

Authentisierung


Passwörter als Authentikatoren (Fts.)

Falsche Lösung maschinengenerierte Zeichenfolgenfolgen als zu merkende Passwörter

Systematische Verfremdung als Lösung

(1) Verwende einen sehr vertrauten Begriff oder Satz als Ausgangstext!

(2) Verfremde diesen Text systematisch!

Beispiele

Zu (1): Vertrauter Satz Aller Anfang ist schwer.

Zu (2): Systematische Verfremdung Verwende nur die Konsonanten für ein 10-stelliges Passwort ➨ llrnfngsts

Fortsetzung ��

Auth

ent.d

oc

Dez

-02

/Pas

sw3/

Authentisierung


Authentisierung von Programmen

Vorstellung Behaupten (Angeben, Vorzeigen) einer Identität

Verifizierung

Prüfung der behaupteten Identität, d.h. Nachweis, dass diese Angabe rechtens ist.

Für Programme heißt das ► Behaupten der Identität durch bloßes Vor-

handensein (beim Laden, beim Aufruf, …) ► Verifizierung mit Hilfe von Signaturen u.a.

(heute i. A. nicht vorhanden) ► Praktische Vorgehensweise

Indirekte Prüfung der Identität durch � organisatorische Maßnahmen, z.B. strenge

Bibliotheksverwaltung � Abschotten der Zugriffe (→ „Das Programm

kann sich nicht geändert haben!“)

Fortsetzung ��

Auth

ent.d

oc

Dez

-02

/Pas

sw3/

Au

then

t.doc

D

ez-0

2 /O

bj1/

Authentisierung


Authentisierung von Programmen (Fts.)

Das aufrufende oder aufgerufene Programm ist das „.richtige“, d.h. tatsächlich dasjenige, das es zu sein vorgibt. Es ist insbesondere nicht manipuliert ( ➨➨➨➨ Viren).

Möglichkeiten der Prüfung ► Prüfung als Ganzes

Das Programm wird von der authentisierenden Instanz als Ganzes verifiziert (geprüft).

► Prüfung eines Authentikators Die authentisierende Instanz analysiert nur ei-nen signifikanten Teil oder eine Signatur als Vertreter des Programms (pars pro toto)

Hinweis Auch das Verhalten und die Umgebung von Programmen haben Signatur-Charakter.

Auth

ent.d

oc

Dez

-02

/Pas

sw4/

Au

then

t.doc

D

ez-0

2 /O

bj2/

Authentisierung


Entdeckung von Manipulationen (Viren)

Grundsätzlicher AnsatzGrundsätzlicher AnsatzGrundsätzlicher AnsatzGrundsätzlicher Ansatz

Kein Programmaufruf ohne Authentisierung

Das bedeutet insbesondere:

Jedes Programm muss vor jeder Ausführung nachweisen, dass es sich in integrem, unma-nipuliertem Zustand befindet.

Drei SchritteDrei SchritteDrei SchritteDrei Schritte (1) Validieren der Programme (2) Zertifizieren und Festhalten des zertifizier-

ten Zustands (3) Vergleich Ad-hoc-Zustand ⇔⇔⇔⇔ zertifizierter

Zustand vor jedem Aufruf (Laden)

Fortsetzung �� Au

then

t.doc

D

ez-0

2 /O

bj3

Authentisierung


Programm

):

Manipulation Detection Code – MDC

Meyer, C.H./ Schilling M.; Secure Program Load with Manipulation Detection Code Proc. Securicom 88 – 6ème Congrès Mondial de la Protection et de la Sécurité Informatique et des Communications, Pa-ris ‘88

Auth

ent

Dez

-02

/Obj

4

Hash

DEA

MDC

Programm- Bibliothek

MDC-Liste

Hash

DEA

Vergleich

integre Bereiche

integrer Kanal

integrerBereich

offener Kanal

LadenLadenLadenLaden nur, falls MDCListe = MDCaktuell

öffentlicher Schlüssel

Authentisierung


Authentisierung von Gegenständen

Der auftretende oder übertragene Gegen-stand – Subjekt oder Objekt – (Gerät, Datei, Schriftstück, Bild, aufgerufene oder auf-rufendes Programm, …) ist der „richtige“, d.h. tatsächlich dasjenige, der er zu sein vorgibt. Das heißt insbesondere für Programme und Geräte:

Sie sind nicht manipnicht manipnicht manipnicht manipuuuuliert.liert.liert.liert.

Anmerkung. Vgl. Hierzu die Themen Viren, Manipulationen in Net-zen, …).

Auth

ent

Dez

-02

/Obj

5

Authentisierung


Prüfung mit Signaturen

Signaturen sind Authentikatoren, die mit einem Gegenstand ver-bunden sind oder in Beziehung gesetzt werden können.

► Originäre Signatur Leite aus dem zu authentisierenden Gegenstand einen eindeutig zuordenbaren Code ab (z.B. Hash-Code) und verbinde Code + Gegenstand.

► Zugewiesene Signatur Verstecke im Gegenstand (Code, Hardware, …) eine Markierung (Wasserzeichen, engl. water marking) so, dass sie von einem Angreifer nicht gefälscht (nachgemacht), wenn möglich gar nicht entdeckt werden kann ( →→→→ Steganographie).

Fortsetzung �

Auth

ent

Dez

-02

/Obj

5a

Authentisierung


Funktionale Anforderungen an Signaturen (Authentikatoren)

(1) Echtheitsfunktion Authentizität von Gegenstand (Datei, Schriftstück, Bild, Programm, Dokument, …) und Veranlasser

(2) Identitätsfunktion Zuordnung von Signatur (Unterschrift) und Akteur (Signierender, Aussteller)

(3) Abschlussfunktion willentliches Definieren und Kennzeichnen des Gegenstandes als ein Ganzes

(4) Warnfunktion Hinweis auf die rechtliche Bedeutung des Signie-rens (bewusster Vollzug des Signierens und be-wusstes Erkennen möglicher Folgen)

(5) Beweisfunktion Nachweis � der Urheberschaft des Ausstellers (Signie-

renden) und � der Integrität des signierten Gegenstandes

Auth

ent.d

oc

Dez

-02

/Obj

6

Authentisierung


Handunterschrift als Authentikator

Funktionale Anforderungen Die funktionalen Anforderungen von der Handun-terschrift im klassischen Rechtsverkehr seit jeher erfüllt werden.

Folge für Forderung (5) Die klassische Unterschrift war das einzige Beweis-mittel im Rechtsstreit, das keine richterliche Bewer-tung (Beweiswürdigung) benötigte (→→→→ unmittelbare Wahrnehmung; Inaugenscheinnahme)..

Elektronische Unterschrift im Netz*) Eingabe der Handunterschrift über berührungs-intensives Pad, Touchscreen und Grafiktablett Nutzung von � statischen Merkmalen Graph f(t), � Geschwindigkeit f’(t) und � Druck (Beschleunigung) f””””(t)

*)Fraunhofer-Institut für integrierte Publikations- und Informationssys- teme (IPSI), Darmstadt Auth

ent.d

oc

Dez

-02

/Obj

7

Authentisierung


Handunterschrift als Authentikator (Fts.)

Vorteile ► Elektronische Unterschrift erfüllt die funktiona-

len Anforderungen an Authentikatoren. ► Sie erfüllt insbesondere die Abschluss- und

Warnfunktion, ► weil sie wie Handunterschrift bewusst abge-

geben wird (im Gegensatz zu Fotografie oder Video, zu Iris- oder Retina-Scanning u.Ä.).

► Akzeptanz: Nutzung eines jedermann längst vertrauten Verfahrens

► Keine kriminelle „Vorbelastung“ wie beim Fingerabdruck.

Auth

ent.d

oc

Dez

-02

/Obj

8

Authentisierung


Fingerabdruck als Authentikator Vorteile ► Elektronische Unterschrift erfüllt die funktiona-

len Anforderungen an Authentikatoren. ► Eindeutige Zuordnungen selbst bei sehr großen

Auswahlmengen (> 108–109 Exemplare) oder engsten Verwandten (eineiige Zwillinge)

► Erstellung einer Restmenge von 50-150 Exem-plaren maschinell in kürzester Zeit (Minuten?) möglich.

► Gut für Erkennungsdienstliche Probleme, weil „Spuren“ unbewusst erzeugt werden können.

► Keine Gesundheitsschäden bekannt

Nachteile ► Reduktion der Restmenge auf ein Exemplar

z.Zt. nur manuell, sehr zeit- und arbeitsaufwen-dig (mehrere Tage/ Wochen)

► z.Zt. (2002) nur mit Spezialisten möglich ► unbrauchbar für alle Zwecke, die schnell

Eindeutigkeit bei großer Teilnehmerzahl fordern (weltweiter Bankverkehr, elektronischer Handel ...)

► Gefahr des „Universal Identifier!“ (� gläserner Mensch)

Auth

ent.d

oc

Dez

-02

/Obj

9

Authentisierung


Autorisierung (Rechtevergabe)


Begriffe RechteRechteRechteRechte (authorization)

► Rechte ► Berechtigungen ► Autorisierungen ► Befugnisse ► Erlaubnisse

werden synonym verwendet. Ebenso sind synonym ► Rechtevergabe • Zuweisung von Rechten •

Zuweisung von Berechtigungen • Befugnisver-gabe • Autorisierung

Danach werden auch folgende Begriffe weitestgehend mit gleicher Bedeutung verwendet:

unbefugte unberechtigte

missbräuchliche unerlaubte

NutzungNutzungNutzungNutzung

Eigentümer (owner) Derjenige, dem ein Element eines IT-Systems oder ein Teil davon gehört oder der dafür verantwortlich ist und der damit das Recht hat zu bestimmen, in welcher Weise es benutzt, geändert oder in ande-rer Weise darüber verfügt werden darf



Zwei Bestandteile

► Autorisierung (Vergabe, Zuweisung) von Rechten an Subjekte und Objekte und deren

► dynamische Verwaltung

Rechte definieren:

„Welches Subjekt darf was wann wie mit wel-chem Objekt?“

Diese Definition ist auf

Relationen undundundund Aktionen anzuwenden.

Die Rechtevergabe muss

dynamisch

(zeitlich variabel) sein können.

Rec

htev

erw

.doc

Dez

00 /

2/



Autorisierung im IT-System

Abbildung ► externe Rechte �� interne Rechte

� Interne Rechte definieren

► Welches Subjekt darf auf welches Ob-jekt wie zugreifen?

► Welches Subjekt darf an welches Ob-jekt wie übertragen?

Rec

htev

erw

.doc

Dez

00 /

3/



Vergabe und Verwaltung der Rechte grundsätzlich anzuwenden auf

alle Gegenstände und Aktionen, also grundsätzlich auf

alle Subjekte und Objekte.

Beispiele für zu autorisierende Elemente ► Benutzer ► Geräte ► Gerätetypen ► Befehle, ..., Programme ► Programmsysteme ► Dateien ► Speicherbereiche ► .....

Vergabe der Rechte hängt von der Anwendung und deren Risiken ab, also vom Anforderungskatalog.

Rec

htev

erw

.doc

Dez

00 /

4/



Interne Autorisierungen Beispiele für interne Zugriffsrechte

1. Zugriffe auf Objekte in Dateien (Felder) � lesen (read) � schreiben, ändern, löschen (write, erase, up-

date) � ausführen (execute) � …

2. Zugriffe auf Dateien (Dateiverwaltung) � anlegen (create) � entfernen (delete) � …

3. Zugriffe auf Dateiverwaltung (Rechtevergabe) � autorisieren (authorise) � Rechte löschen (deauthorise) � …

4. … Anmerkungen � Ist solch eine hierarchische Ordnung der Rechte

geeignet für Abbildung des „Rollenspiels“? � Ausführen (execute) ≠ Lesen (read)

Rec

htev

erw

.doc

Dez

00 /

4a/



Autorisierung (Vergabe der Rechte)

Berücksichtige alle Zustände!

► Betrieb ► geplante Sonderzustände ► ungeplante Sonderzustände

Betrieb Routine- oder Produktionsbetrieb Test- und Probebetrieb …

Geplante Sonderzustände Wartung Reinigung Wiederanlauf Installation, Änderung Vorführung, Besuch (?)

Ungeplante Sonderzustände Fehler (Störung, Ausfall) Fehlerbehebung, Wiederanlauf Alarm Sabotage, Unfall, Katastrophe …

Rec

htev

erw

.doc

Dez

00 /

5/



Autorisierung (Fts.)

Explizite Spezifikation ► Zugriffslisten ► Zugriffsmatrix ► …

Zugriffsstrategien, regelbasierte Zugriffe ► Bell-LaPadula (1976) ► Biba ► Clark-Wilson ► chinesische Mauer ► …

Gesucht ► ein Modell für eine rollenspezifische Zugriffs-

strategie

Zur Vorgehensweise 1. Verwende ein Ordnungsschema der Objekte,

falls vorhanden (z.B. hierarchisch bei milit. Ver-traulichkeit, konzentrisch, o.A.)

2. Leite aus dem Ordnungsschema Zugriffsregeln ab

� Regeln für die Rechtevergabe bestimmen auch die Werkzeuge für die Rechtekontrolle �

Rec

htev

erw

.doc

Dez

00 /

6/



Prinzipien der Autorisierung

► Erlaubnisprinzip vs. Verbotsprinzip

► Vollständigkeit ► Geringste Berechtigung

(Minimalprinzip, „Need-to-know”)

Die Prinzipien der Autorisierung sind gleich-zeitig die ersten drei Prinzipien für die

Konstruktion sicherer IT-Systeme.

Anmerkung: Sprachgebrauch bei Juristen

Erlaubnisprinzip prinzipielles Verbot mit Erlaubnisvorbehalt

Verbotsprinzip prinzipielle Erlaubnis mit Verbotsvorbehalt

Rec

htev

erw

.doc

Dez

00 /

7/

Rechtekontrolle


Synonyme ► Rechteprüfung ► Befugniskontrolle

Für maschinelle IT-Systeme

Reduktion auf Zugriffskontrolle

+ Übertragungskontrolle

Für IT-Systeme generell

Kontrolle aller Aktionen anhand der

Autorisierungen

Hinweis

Vergleiche u.a. für IT-Systeme generell als (unvoll-kommenes) Beispiel die Forderungen des Anhangs zu §9 BDSG.

Rec

htek

ontr.

doc

Dez

00 /

1/

Rechtekontrolle


„Zugriffskontrolle“ – verallgemeinert

Mehrere der im Anhang zu §9 BDSG (1991) gefor-derten Kontrollen sind im verallgemeinerten Sinn

Zugriffskontrollen.

1. Zugangskontrolle

Zu„griff“ von Personen auf einen Teil der Infrastruktur (Gebäude, Raum, …)

2. Datenträgerkontrolle Zugriff von Personen (oder Programmen) auf transportierbare Speichermedien

3. Speicherkontrolle Zugriff von Personen (oder Programmen) auf Daten in Speichern

4. Benutzerkontrolle Zugriff von Personen auf ein (im Sinne ei-ner generellen Nutzung) DV-System

5. Zugriffskontrolle Zugriff von Personen auf Daten in einem DV-System

9. Transportkontrolle Zugriff auf Daten während des Transports

Rec

htek

ontr.

doc

Dez

00 /

2/

Rechtekontrolle


Leitsatz

Rechtekontrolle ist der Kern

jedes sicheren IT-Systems

Leitsatz für maschinelle Systeme

Zugriffs- und Übertragungskontrolle sind die

zentralen Sicherheitsmaßnahmen

jedes maschinellen IT-Systems

��

Folgerung – „Conditio sine qua non“| Die Rechtekontrolle darf ► weder abschaltbar ► noch umgehbar

sein.

Rec

htek

ontr.

doc

Dez

00 /

3/

Rechtekontrolle


Vollständigkeit der Kontrolle

Für die Zugriffs- und die Übertragungskontrolle gilt, mehr noch als anderswo, das Vollständigkeitsprinzip.

Das heißt für die Zugriffskontrolle:

Jeder Zugriff zu jedem Objekt muss im Prinzip vor der Ausführung auf seine Autorisierung hin geprüft

werden.

Das heißt für die Übertragungskontrolle

Bei jeder Übertragung müssen Sender, Empfänger und Daten (Objekte) auf ihre Autorisierung hin

geprüft werden.

Fortsetzung ��

Rec

htek

ontr.

doc

Dez

00 /

4/

Rechtekontrolle


Einige Folgerungen ► Externe Zugriffe sind ebenso zu prüfen wie

interne. ► Das gilt insbesondere für alle Benutzerprozes-

se. ► Aufrufe von Systemfunktionen sind zu prüfen

unabhängig vom aufrufenden Subjekt (z.B. Be-nutzer, Benutzerprogramm, Systemprogramm, …).

► Zugriffskontrolle schließt die Prüfung des Ver-anlassers ( → Zurechenbarkeit, accountability) ein. („Wer hat den Zugriff ausgelöst?“)

► Dynamische Veränderungen der Autorisie-rung während Ablauf der Prozesse müssen kontrollierbar bleiben.

► In Sonderzuständen darf die Zugriffskontrolle nicht eingeschränkt oder gar außer kraft gesetzt werden (Wartung, Fehler, Initialisierung, Wie-deranlauf, …)

► … …

Rec

htek

ontr.

doc

Dez

00 /

5/

Rechtekontrolle


LOGON als Rechtekontrolle

(Fast) alle Logon-Prozeduren enthal-ten neben der Authentisierung auch ei-ne Zugriffskontrolle.

Begründung ► Angabe eines Benutzerkennzeichens (userid)

➨ Behauptung einer Identität (= Vorstellung) ► Abgleich mit der Liste der eingetragenen Be-

nutzer ➨ Kontrolle der Befugnis, dieses System überhaupt nutzen zu dürfen (= Rechteprü-fung)

Erst danach folgt in der Regel die Passwortabfrage ➨ Verifizierung der Identität (= Authentisierung).

Rec

htek

ontr.

doc

Dez

00 /

6/

Protokollierung


Synonyme oder verwandte Begriffe ► Beweissicherung ► Registrierung ► Audit

Protokollierung ist Voraussetzung für alle Aktivitäten

nach Prozessablauf (post mortem)

► Wiederanlauf ► Fehlersuche ► Fehlerüberbrückung ► Rekonstruktion ► Überwachung

Klassische Datensicherung

Backup ist eine besondere Form der Proto-

kollierung.

Fortsetzung ��

Prot

okol

l.doc

Dez

-00

/1/

Protokollierung


Umfang Protokolliere ▶ Zustände ▶ Aktivitäten

� autorisierte Aktivitäten � Versuche nicht-autorisierter Aktivitäten

▶ Ergebnisse

Forderung – Integrität des Protokolls

Bei sicherheits-relevanten Aktivitäten darf Protokollierung

nie abschaltbar sein!!

Grundregel für die Protokollierung

Art und Umfang jeder Protokollierung werden bestimmt durch

▶ Notwendigkeit der Aufzeichnung und

▶ Möglichkeiten der Auswertung.

Fortsetzung ��

/1Pr

otok

oll.d

oc D

ez-0

0 /2

/

Protokollierung


Protokollierung von Zuständen

Voraussetzung für Wiederanlauf ► bei Fehler oder Systemabsturz ► bei Unterbrechung, gewollt oder ungewollt ► …

� Bestimme vor Beginn der Protokollierung � welche Daten sind in � welchem Umfang zu � welchen Zeiten

für den Wiederanlauf nötig?

Hinweis Welche Daten wie benötigt werden, kann bei ge-wollter oder bei ungewollter Unterbrechung ver-schieden sein!

Fortsetzung ��

/Pro

toko

ll.do

c D

ez-0

0 /3

/ /

Protokollierung


Protokollierung von Ereignissen

Voraussetzung für Suche nach Fehlern und Verur-sachern bei

► Fehlern ► Missbrauch(-verdacht) ► Sabotage(-verdacht), Unterbrechung, ► …

� Bestimme vor Beginn der Protokollierung � welche Ereignisse, � welche Elemente der Ereignisse � welche Häufigkeit der Aufnahme

(kontinuierlich, diskret), � welche Art der Stichprobe (konti-

nuierlich, diskret) werden für � die Beweissicherung � für den Wiederanlauf benötigt?

Hinweis

Protokolliere nur die Versuche unautorisierter Ak-tivitäten; die unautorisierte Aktion selbst sollte stets verhindert werden.

//Pro

toko

ll.do

c D

ez-0

0 /4

/

Protokollierung


Grundfragen der Protokollierung

Problem

Unausgewertete Protokolle sind zu teuer und sinnlos.

� Ermittle vorvorvorvor Beginn der Protokollierung die Mög-lichkeiten und Kosten der Auswertung und richte danach Art und Umfang der Protokolle.

Gefahr

Protokolldaten sind sehr leicht Objekte des Missbrauchs, vor allem durch

Zweckentfremdung. � Datenschutz �

� Überwache laufend die ordnungsgemäße Nut-zung der Protokolldaten und prüfe die Möglich-keiten einer missbräuchlichen Auswertung (neue Techniken, neue unbefugte „Interessenten“, …).

/Pro

toko

ll.do

c D

ez-0

0 /

5/

Protokollierung


Fehlerüberbrückung


Zwei Bestandteile

Fehlererkennung +

Kompensation der Folgen

Erhöhung der Verfügbarkeit (→ Zuverlässigkeit) des Systems

➨ Verbesserung der Funktionalität

Voraussetzungen ► Es gibt redundante Zustände in dem Teil des

Systems, in dem Fehler erkannt werden sollen. ► Zustände sind in bestimmten Kontexten unzu-

lässig Oder unwahrscheinlich. ► Daten zur Wiederherstellung eines ordnungs-

mäßigen Zustands sind verfügbar (→ Protokollie-rung).

Fehl

er.d

oc D

ez-0

0 /



Allgemeinere Formulierung

Erkennung und Bereinigung der Folgen nicht-ordnungsgemäßen Verhaltens von IT-Systemen oder von deren Elementen.

Anmerkung

Bei Ein- und Ausgabeaktionen sind die beteilig-ten externen Elemente in die Betrachtung mit einzubeziehen.

Beispiel: Einbeziehen des Fehlverhaltens – bewusst und unbewusst – der Bediener und Anwender

Fehl

er.d

oc D

ez-0

0 /2

//



Fehlerkompensation

Statt Fehler beheben (korrigieren) deren Auswirkungen beseitigen

oder umgehen.

Anmerkungen ► Auch Fehlerkorrektur ist letztlich eine unmittel-

bare Kompensation � „Fehlerfolgen“ (= Auswir-kungen) werden sofort unterdrückt.

► Fehlerkorrigierende Elemente (Error Correcting Codes ECC, Majoritätswähler, …

► Abschalten oder Auslassen fehlerhafter Teile (Bereiche)

► Ersatz durch redundante Komponenten (z.B. Notstromaggregate, Doppelprozessoren, Raid-Speichersysteme, …)

► …

Fehl

er.d

oc D

ez-0

0 /3

/



Beispiele

Error Correcting Codes (im Arbeitsspeicher) Fehlerentdeckung während des Zugriffs, Korrektur und Wiederholung des Zugriffs bei 1-bit-Fehlern Fehlerentdeckung, Fehlermeldung und Sperre der Speicherzelle für künftige Aktionen bei Mehrbit-Fehlern

„Bad sectors” (auf Plattenspeichern oder Disketten) Fehlerentdeckung während des Zugriffs und Wie-derholung des Zugriffs Sperrung des Sektors bei (mehrfacher) Fehlerwie-derholung

Plausibilitätskontrollen Fehlerentdeckung � Erkennen „unwahrschein-licher“ Daten in der Eingabe, während eines Pro-zesses oder in (Zwischen)-Ergebnissen Meldung (Alarm) und Sonderbehandlung Problem: Was ist „unwahrscheinlich (unerlaubt)“ und was ist eine „interessante“ Abweichung vom Gewohnten?

Fortsetzung ��

Fehl

er.d

oc D

ez-0

0 /4

/



Beispiele (Fts.)

Wiederanlauf und Rekonstruktion

nach Fehlererkennung oder nach gewollter Unterbrechung Einfachstes Beispiel: Wiederholung des Paß-worts nach Fehleingabe

Voraussetzungen für Wiederanlauf und Rekon-struktion:

► ausreichendes Zustandsprotokoll einschl. � Aufzeichnung der (benötigten) Zustände � Verwaltung der Zustandsbeschreibungen � Bereitstellung der Wiederanlauf- und Re-

konstruktionsmechanismen

/Feh

ler.d

oc D

ez-0

0 /5

//

Überwachung


Grundgedanke

► IT-Systeme sind reale Systeme, also nicht 100% ordnungsgemäß.

► Verbesserung aller Komponenten der Sicherheit (Vertraulichkeit, Integrität, Ver-fügbarkeit, Zurechenbarkeit, Revisionsfä-higkeit)

► Damit in weiten Teilen äquivalent zu Ge-währleistung der Funktionalität ➨ Verlässlichkeit (assurance)

Rekursivität

Überwachung ► des Systems und seiner

Komponenten ► der Sicherungsmaßnahmen

Ueb

erw

a.do

c D

ez-0

0 /1

/

Überwachung


Möglichkeiten

Überwachung ► während des Ablaufs der

Prozesse ► nach Ablauf der Prozesse

Kontrolle durch ► Struktur in Schichten

(Kontrollhierarchie) ► Netzstruktur (wechsel-

seitige Kontrolle)

Anmerkung Der innerste Kern jeder sicheren Systemkomponente enthält keine Überwachung mehr ( →→→→ Rekursivität).

Ueb

erw

a.do

c D

ez-0

0 /2

/

Überwachung


Werkzeuge

► systematische Tests ► Stichproben ► Penetrationsversuche ► Vier-Augen-Prinzip ► Alarme ► Auswertung der Protokolle ► …

Anmerkung

Alarm ist jede Art von ereignisbezogener Benach-richtigung oder Meldung, u.a. auch die Denunziati-on ( ➨ Zurechenbarkeit).

Ueb

erw

a.do

c D

ez-0

0 /3

/

Überwachung


Beispiele

Für Systemreaktionen ► Blockade (Abbruch externer Aktionen) ► Meldung an Verantwortlichen ► Eintrag in Alarmprotokoll ► Alarm generell (optisch, akustisch) ► Fortführung einer simulierten Aktion + verdeck-

ter Alarm Für Zugangsüberwachung

► Menschen (Pförtner = kontinuierlich, Wachrun-de = Stichproben)

► Schranken (mechanisch, infrarot, optisch, La-ser, Ultraschall, Radar)

► Vibrations- oder Schalldetektoren ► Video-Kameras mit/ohne Aufzeichnung ► Intervallkameras mit Aufzeichnung (Stichpro-

be) ► Induktionsmessungen ► …

Ueb

erw

a.do

c D

ez-0

0 /4

/

Überwachung


Documents

Grundlagen der IT-Sicherheit · Prinzip des Wohlverhaltens Konzipiere Sicherungsmaßnahmen im-mer so, dass alle Benutzer (Betroffenen) angestachelt werden, sie einzuhalten. Voraussetzungen