Grundlagen der IT-Sicherheit · Prinzip des Wohlverhaltens Konzipiere Sicherungsmaßnahmen im-mer so, dass alle Benutzer (Betroffenen) angestachelt werden, sie einzuhalten. Voraussetzungen
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
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.
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.
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!“
► 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
� 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
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.“
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, …)
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
(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.
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
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)
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
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. ◄◄◄
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.
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.
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
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.
► 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.
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
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
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) ∙ …
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.
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.
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).
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, …
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).
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
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.
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
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, …).
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).
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
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
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, …)
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“, …).
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?
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-