Börse

Weiterhin wurden Konzepte für die IT-Struktur erstellt. Beispiele sind:

­ Ein Sicherheits-Konzept für die landesweite AD-Gesamtstruktur

Das Konzept besteht aus einzelnen Dokumenten:

a) Sicherheitsaspekte bei Benutzerkonten und Benutzergruppen

b) Sicherheitsaspekte für den Betrieb der AD-Domänencontroller der Domäne hessen.de und der Subdomänen

c) Sicherheitsaspekte zur Kontrolle der Gesamtstruktur und der Einsatzkontrolle von Organisations- und ­ Namenskonventionen für die Objekte der landesweiten AD-Gesamtstruktur

­ Migrationspfade und -aufgaben

Es sind weitere Dokumente in Planung. Für das Sicherheitskonzept sollen noch zu den Bereichen Netzwerksicherheit und Virensicherheit ergänzende Dokumente erstellt werden.

In den Sicherheitskonzepten wird die Sicherheitspolicy festgelegt. Die Vorgaben sind so detailliert, dass die relevanten Parameter mit den Werten aufgeführt sind. Am Beispiel der Kennwortrichtlinien soll das deutlich werden.

KENNWORTRICHTLINIEN:

· Kennwörter müssen den Komplexitätsanforderungen entsprechen: deaktiviert

· Kennwortchronik erzwingen: Kennwortchronik von mindestens 13 Kennwörtern

· Kennwörter für alle Domänenbenutzer mit umkehrbarer Verschlüsselung speichern: deaktiviert

· Maximales Kennwortalter: 30 Tage

· Minimales Kennwortalter: 0 Tage

· Minimale Kennwortlänge: 8 Zeichen KONTOSPERRUNGSRICHTLINIE:

· Kontosperrungsschwelle: 5 Anmeldungen

· Kontosperrdauer: 30 Minuten

· Zurücksetzungsdauer des Kontosperrungszählers: 30 Minuten Derartige Festlegungen sind für alle sicherheitsrelevanten Systemparameter getroffen.Wenn sich ein Ressort der ADGesamtstruktur anschließt, muss es sich verpflichten die vorgegebenen Werte zu akzeptieren, d. h. in der Domäne einzustellen. Eine Verschärfung ist ohne Einschaltung des Entscheidungsgremiums möglich, während schwächere Werte nur nach Abstimmung mit den anderen Teilnehmern gewählt werden können.

In dem Dokument zur Einsatzkontrolle von Organisations-Administratoren und Schema-Administratoren werden die Maßnahmen beschrieben, mit denen der Gebrauch der Kennungen kontrolliert wird. So sollen die Maßnahmen u. a. erreichen, dass mindestens drei befugte Personen anwesend sein müssen, um mit den Kennungen arbeiten zu können.

Wie an diesen Beispielen deutlich wird, ist die Einführung eines Windows 2000-Netzwerkes und des dort verfügbaren AD mit einem hohen Aufwand verbunden. Da Fehler bei der Planung nur mit erheblichem personellen, technischen und finanziellen Einsatz zu korrigieren sind, halte ich die sorgfältig abgestimmte Vorgehensweise für unerlässlich und den entstehenden Aufwand für angemessen.

12.3

Software-Sicherheitslücken Heute verfügbare Betriebssysteme, Anwendungsprogramme und Netzkomponenten haben in vielen Fällen Sicherheitslücken, die unbefugte Zugriffe erlauben oder die Einbringung von Schadfunktionen zulassen. Nur durch rechtzeitige und ausreichende Information und geeignete Vorkehrungen können sich Betreiber vor den Folgen schützen.

12.3.1

Entstehung von Sicherheitslücken Betriebssysteme wie Windows, UNIX und auch Anwendungsprogramme wie die Office-Produkte von Microsoft sind Programme,deren Quelltext aus Hunderttausenden von Zeilen besteht.Aus dem Quelltext werden die Programme durch Compiler erstellt. Die so entstandenen Programme können unerwünschte Funktionen haben, die ausgenutzt werden können, um weitreichende Zugriffsrechte einzurichten oder Schadfunktionen einzufügen. Die unerwünschten Funktionen können aus Designfehlern, Fehlern bei der Programmierung oder einer unzulänglichen Umsetzung in den ausführbaren Code resultieren. Daneben gibt es auch Standards, die Sicherheitslücken beinhalten. Ein Beispiel ist der Standard IEEE 802.11, mit dem u. a. die Verschlüsselung für Funk-LAN beschrieben ist (siehe Ziff. 12.1). Es kann aber auch ein Standard fehlerhaft implementiert sein. Dies galt z. B. für SSL (Secure Socket Layer)/TLS (Transport Layer Security), von dem in diesem Jahr mehrfach über Schwachstellen berichtet wurde. Sie betrafen aber immer die Implementierung.

Das SSL-Protokoll wurde ursprünglich von der Firma Netscape entwickelt. In der Version 2 fanden sich noch kleinere Sicherheitslücken, die in der Folgeversion 3.0 beseitigt wurden. Es handelte sich aber um proprietäre Produkte.Auf Basis von SSL 3.0 hat die IETF (Internet Engineering Task Force) den Internetstandard TLS entwickelt. Dabei entspricht TLS 1.0 dem SSL 3.1. TLS soll in Zukunft den SSL ersetzen.

12.3.2

Umgang mit Sicherheitslücken

Wenn Schwachstellen in Programmen bekannt werden, die auch von öffentlichen Stellen verwendet werden, stellt sich die Frage, wie damit umgegangen werden soll.

12.3.2.1

Soll im Internet auf die Lücke hingewiesen werden, auch wenn keine Lösung bekannt ist?

Diese Auffassung vertreten zum Beispiel die Betreiber von kostenlosen Informationsdiensten wie mit der Mailingliste Bugtrac oder paketstorm. Sobald die Hersteller informiert wurden und Möglichkeiten zur Beseitigung gegeben waren, wird der Hinweis gemeinhin in das Internet gestellt. Die Hinweise sind aber in der Regel nicht so detailliert, dass ein Außenstehender einen Angriff darauf aufbauen kann. Nach einer Frist von etwa 30 Tagen folgen meist weitergehende Informationen, die es erlauben könnten, die Schwachstelle ausnutzen. Zum Teil werden sogar Programme bereitgestellt, um die Lücke auszunutzen (Exploits) oder, wie es die Anbieter begründen, um den eigenen Rechner auf die Lücke testen zu können. Der Nachteil dieses Vorgehens besteht darin, dass zum Teil sogar die Werkzeuge bereit gestellt werden, um Schwachstellen auszunutzen, obwohl noch keine Lösung bekannt ist, wie Angriffen begegnet werden kann.

Einige Informations-Anbieter haben eine Informationspolitik, die weniger weit geht. Im Jahr 2000 hat das CERT/CC (Computer Emergency Response Teams/Coordination Center; Carnegie-Mellon University) den bisherigen Ansatz geändert. Wenn bislang neue Sicherheitslücken bekannt wurden, wurde zusammen mit dem Hersteller und anderen Notfall-Teams versucht, die Lücken möglichst schnell und umfassend zu schließen. Sobald eine Lösung verfügbar war oder die Gesamtsituation ein Warten auf die Lösung verbot, wurden die notwendigen Informationen verteilt.

Neuerdings veröffentlichen das CERT/CC und das DFN-CERT, das sich in seiner Informationspolitik an das CERT/CC anlehnt, bekannt gewordene Sicherheitslücken nach 45 Tagen, unabhängig davon, ob es Lösungen gibt. Allerdings werden keine Programme bereitgestellt, um die verwendete Software auf Lücken zu testen. Der Zeitraum kann unter Umständen verlängert werden, wenn komplexe Änderungen nötig sind (umfangreiche Untersuchung, Änderung an Kommunikationsprotokollen oder Kernkomponenten). Er kann auch verkürzt werden, wenn bereits Exploits existieren oder Angriffe bekannt werden.

Es gibt erste Hersteller, die gegen die Veröffentlichung von Sicherheitslücken ihrer Produkte vorgehen. Außerdem ist das Wissen um Sicherheitslücken eine Ware, die vermarktet werden kann. Befürchtungen, dass bisher kostenlose Informationsdienste eingestellt oder kostenpflichtig werden könnten, wurden laut, als ein Informationsdienst von einem großen Anbieter von Sicherheitssoftware aufgekauft worden war.

12.3.2.2

Soll auf die Schwachstelle erst hingewiesen werden, wenn eine Lösung angeboten wird?

Diesen Ansatz favorisieren die meisten Hersteller. Es vergeht aber oft viel Zeit zwischen dem Zeitpunkt, zu dem in interessierten Kreisen eine Sicherheitslücke bekannt wird, und dem Zeitpunkt, zu dem der Hersteller eine Lösung anbietet. So wurden beispielsweise zum Internet Explorer der Fa. Microsoft am 2. Oktober 2002 zwanzig noch nicht beseitigte Lücken genannt, deren erste Veröffentlichung teilweise aus dem ersten Halbjahr 2002 und in einem Fall aus 2001 stammt. Wenn nach diesem Modell vorgegangen wird, profitieren davon besonders Personen, denen eine Schwachstelle bekannt ist.Gerade im Internet gibt es Gruppen,die auch ohne allgemein zugängliche Informationsdienste über die Existenz von Schwachstellen kommunizieren. Der Betreiber eines IT-Systems kann sich dagegen nur unvollständig oder mit viel Aufwand wappnen. Die Informationspolitik wiegt die Anwender in trügerischer Sicherheit, obwohl Angreifer eventuell mit wenig Aufwand Schaden verursachen können.

12.3.2.3

Empfehlenswerte Vorgehensweise

Aus meiner Sicht sind unabhängige Informationsanbieter unverzichtbar, die über Sicherheitslücken zeitnah informieren.

Der Service sollte kostenlos sein, damit möglichst viele Interessenten erreicht werden. Die grundsätzliche Vorgehensweise der CERT, die keine Exploits veröffentlichen, halte ich für richtig.

Hessischer Landtag · 15. Wahlperiode · Drucksache 15/479060

12.3.3

Beispiel SSL

Eine Übersicht von Mängeln in Betriebssystemen und Standardprogrammen lässt sich nicht geben, da eine solche Übersicht nie umfassend und aktuell wäre. Da SSL/TLS als Standard für eine Kommunikation im Internet genutzt wird

­ z. B. durch die KIV Hessen ­, möchte ich auf Mitteilungen der letzten Monate eingehen, nach denen SSL unsicher sei.

Im Internet gab es in den bekannten Informationsbörsen Nachrichten über Probleme mit Implementierungen des SSLProtokolls in einigen Programmen.

­ Fehler in OPEN-SSL Open-SSL hatte einen Fehler bei der Implementierung in einem bestimmten Server-Programm. Dazu gab es nach kurzer Zeit ein Patch (Programmupdate zur Fehlerbehebung).

­ Browser-Sicherheitslücke bei SSL-Zertifikaten

Es gab unter bestimmten Rahmenbedingungen ­ eine ausführliche Beschreibung ist auf der Homepage von Microsoft zu finden ­ die Möglichkeit, dem Browser ein SSL-Zertifikat so zu präsentieren, dass es automatisch als vertrauenswürdig akzeptiert wurde. Nur eine genaue Kontrolle der Zertifikate hätte gezeigt, dass das Zertifikat nicht authentisch ist. Dieser Fehler trat beispielsweise beim Internet-Explorer von Microsoft und bei dem im benutzten Browser Konqueror auf. Für den Linux-Browser existierte bereits nach kurzer Zeit ein Patch.

Für den Internet Explorer und andere Microsoft-Produkte, die denselben Design-Fehler hatten, lagen erst Wochen später die Patchs vor.

­ Löschen von Zertifikaten

Für alle Windows-Versionen gab es das Problem, dass SSL-Zertifikate wegen eines Fehlers in einem von außen gelöscht werden konnten. Auch hierzu gibt es inzwischen ein Patch.

Die genannten Probleme betreffen jeweils einzelne Implementierungen und nicht alle Produkte, die SSL unterstützen oder das Protokoll SSL selbst.Auch sind weder einzelne Schlüssel ­ ausreichend lange Schlüssel vorausgesetzt (mittlerweile sind 128 Bit für den symmetrischen und 1024 Bit für den RSA-Algorithmus Stand der Technik) ­ noch das Verfahren insgesamt gebrochen worden. Selbstverständlich müssen Patchs immer unverzüglich eingespielt werden, um die gefundenen Lücken zu schließen. Zusammenfassend ist festzuhalten, dass SSL als Standard keineswegs zu unsicher ist und nicht mehr benutzt werden sollte.

12.3.4

Vorgehensweise für Betreiber Jeder Administrator in Behörden oder Unternehmen muss sich über mögliche Lücken der von ihm betreuten Systeme informieren. Diese Aufgabe darf nicht nur im Geschäftsverteilungsplan genannt sein. Es muss auch die Zeit für Recherchen und Abhilfemaßnahmen zur Verfügung stehen. Um einen Überblick zu bekommen, reicht es nicht, die Informationsseiten der Hersteller zu durchsuchen. Die unabhängigen Informationsanbieter, Anbieter von Sicherheitslösungen und die CERT mit ihren Mailinglisten sind unverzichtbare Quellen. Hinweise, wie eine Lücke notdürftig geschlossen werden kann, gibt es eventuell bei verschiedenen Informationsanbietern, aber Programmupdates kann man in aller Regel nur vom Hersteller erhalten.

Als technischer Laie erhält man bei vielen Informationsanbietern keine brauchbare Hilfe, da die Beschreibungen Hintergrundwissen voraussetzen. Hier bleibt in aller Regel nur die Möglichkeit, sich über Zeitschriften oder den Hersteller zu informieren. Man sollte Programmupdates der Hersteller möglichst umgehend einspielen, wenn die Lücken im eigenen Umfeld eine Rolle spielen.

12.4

Sicherere Internetanbindung über eine Terminalserverlösung (Graphical Firewall ­ GFW) Terminalserverlösungen stellen eine gute, deutlich sicherere und praktikable Lösung zur Direktanbindung eines lokalen Netzes an das Internet dar.

Die Anbindung an das Internet ist in der heutigen Zeit für viele Menschen zum unverzichtbaren Teil der täglichen Arbeit, der Kommunikation und der Freizeitgestaltung geworden. Nicht nur der Umfang der verfügbaren Informationen hat zugenommen, auch die Kosten für eine permanente Anbindung (Flatrate oder Standleitung) sind ständig gesunken. Für Behörden- oder Firmennetze stellt diese Anbindung ein erhöhtes Risiko dar, das nicht zu unterschätzen ist.

Durch Zwischenschaltung eines Terminalservers kann dieses Risiko erheblich reduziert werden, da dadurch die Internetsitzung logisch vom lokalen Rechner getrennt wird. Der Terminalserver nimmt Eingaben entgegen und leitet sie weiter; Anwendungen werden in einer eigenen Umgebung ausgeführt und dem Benutzer nur die Ergebnisse in einem Anwendungsfenster angezeigt, das von lokalen Prozessen isoliert ist.